Р
И если у тебя будет база из ста тысяч клиентов, то она будет весить максимум гигов 100
Size: a a a
2020 November 30
F
Если ты работаешь не в сфере банкинга, соц сетей, и облачных хранилищ, то у тебя будет очень мало пользовательских данных, по типу: имя фамилия отчество, телефон, дата рождения, емеил и еще какие нибудь специфические параметры по типу размера стопы или ведичины астигматизма
Ну как бы тебе сказать...
У меня тут недалеко есть база (Oracle SQL), обслуживающая фирму, предоставляющую телефонию на несколько сотен тысяч абонентов. Она весит терабайты (точно не скажу, у меня туда доступа нет)
У меня тут недалеко есть база (Oracle SQL), обслуживающая фирму, предоставляющую телефонию на несколько сотен тысяч абонентов. Она весит терабайты (точно не скажу, у меня туда доступа нет)
F
причем это не единственная БД, это просто учет звонков
F
Но если ты занимаешься телефонией в России, то у тебя внезапно появляется необходимость хранить запись звонков. и вот тут уже огого
F
итак, сто тысяч абонентов, шесть месяцев актуальности, 180 минут в месяц (какая-то старая стата МТС, лень искать более свежие). 180 * 6 *10^5*кодек GSM (331 килобайт в минуту на одну ногу) = 80+ терабайт пользовательских данных. 80 на диске дает нам минимум 200тб физических дисков, плюс массив, способный это ворочать. Даже если мы не полные дебилы и сделаем объектное хранилище, а не файловую систему...
Мне продолжать?
Мне продолжать?
F
Желающие покурить объемы данных за минуту - https://www.3cx.com/blog/docs/bandwidth-utilised-for-voip/
аᶘ
итак, сто тысяч абонентов, шесть месяцев актуальности, 180 минут в месяц (какая-то старая стата МТС, лень искать более свежие). 180 * 6 *10^5*кодек GSM (331 килобайт в минуту на одну ногу) = 80+ терабайт пользовательских данных. 80 на диске дает нам минимум 200тб физических дисков, плюс массив, способный это ворочать. Даже если мы не полные дебилы и сделаем объектное хранилище, а не файловую систему...
Мне продолжать?
Мне продолжать?
А можешь объяснить, в чём разница между объектным хранилищем и файловой системой в рамках записи звонков?
F
А можешь объяснить, в чём разница между объектным хранилищем и файловой системой в рамках записи звонков?
в том, что объектное хранилище дешевле
F
оно гораздо проще горизонтально масштабируется, чем файловая система
аᶘ
оно гораздо проще горизонтально масштабируется, чем файловая система
а есть что-то self-hosted для реализации объектного хранилища или это вендор-лок на какой-нибудь амазон?
F
а есть что-то self-hosted для реализации объектного хранилища или это вендор-лок на какой-нибудь амазон?
да сколько угодно. Ну у тебя всё равно будет вендор-лок на скэлити/делл/хуавей/... :)
Ну или Ceph поставь.
Ну или Ceph поставь.
∀
а есть что-то self-hosted для реализации объектного хранилища или это вендор-лок на какой-нибудь амазон?
openstack swift
ł
minio/ceph/glusterfs (хотя последний не совсем про объекты емнип)
F
minio/ceph/glusterfs (хотя последний не совсем про объекты емнип)
Red Hat Gluster Storage is based on glusterFS, an open source distributed file system. Object Store technology is built upon OpenStack Swift. OpenStack Swift allows users to store and retrieve files and content through a simple Web Service REST (Representational State Transfer) interface as objects. Red Hat Gluster Storage uses glusterFS as a back-end file system for OpenStack Swift.
Выглядит как ёб твою мать
Выглядит как ёб твою мать
ł
Red Hat Gluster Storage is based on glusterFS, an open source distributed file system. Object Store technology is built upon OpenStack Swift. OpenStack Swift allows users to store and retrieve files and content through a simple Web Service REST (Representational State Transfer) interface as objects. Red Hat Gluster Storage uses glusterFS as a back-end file system for OpenStack Swift.
Выглядит как ёб твою мать
Выглядит как ёб твою мать
Так и есть
аᶘ
Red Hat Gluster Storage is based on glusterFS, an open source distributed file system. Object Store technology is built upon OpenStack Swift. OpenStack Swift allows users to store and retrieve files and content through a simple Web Service REST (Representational State Transfer) interface as objects. Red Hat Gluster Storage uses glusterFS as a back-end file system for OpenStack Swift.
Выглядит как ёб твою мать
Выглядит как ёб твою мать
А как оно ещё должно работать? Все эти Object Storage же должны на что-то опираться в любом случае, пусть это будет эта странная glusterFS + софт-координатор + REST API, что не так?
F
А как оно ещё должно работать? Все эти Object Storage же должны на что-то опираться в любом случае, пусть это будет эта странная glusterFS + софт-координатор + REST API, что не так?
То, что в object storage у тебя обычно много глупых нод и координатор, который отправляет запросы на правильную ноду. А здесь получается репликация уровня фс на нодах вроде бы - все достоинство топологии теряется.
F
Гластер довольно медленный. Мы его пробовали, на 30 нодах по 500гб каждая ему уже очень тяжело.
Р
Но если ты занимаешься телефонией в России, то у тебя внезапно появляется необходимость хранить запись звонков. и вот тут уже огого
ебу*** пакет яровой, это ненормально когда телефонные звонки записываются и хранятся без ведома и желания пользователей
п.с. критиковать человека по способу его заработка я конечно же не буду.
п.с. критиковать человека по способу его заработка я конечно же не буду.
F
ебу*** пакет яровой, это ненормально когда телефонные звонки записываются и хранятся без ведома и желания пользователей
п.с. критиковать человека по способу его заработка я конечно же не буду.
п.с. критиковать человека по способу его заработка я конечно же не буду.
даже без Яровой тебе как минимум нужно хранить всю SIP-сессию.