Предположим, что БС обслуживает одновременно 10 000 звонков. Пускай ув. _adept_ уточнит, сколько их на самом деле.
Берем 100 мбайт RAM. Складываем туда эти звонки. 16 мбайт\сек. Каждые 5 сек сбрасываем блок в сторейдж, с указанием, кто кому звонил в данном блоке. <1 IOPS, 20 мб\c. Под блок номеров выделяем еще 10 мбайт, сбрасываем каждую минуту, gzip'аем, естественно.
Когда приходит запрос "выдать звонки таких-то абонентов", проводим линейный скан по блокам с номерами и грепаем их на предмет нужного номера. Вычитываем нужные блоки с звонками. Фильтруем прочитанное в RAM. Передаем ответ. ~2-5 IOPS, 160 мбайт\сек, ориентировочное время выполнения запроса "за сутки" - <1 минуты.
На сутки хватит ОДНОГО SATA-диска (180 мбайт\с, 2 тб, 60 IOPS). С дублированием - двух. Pooling не нужен. Если рейд софтверный, то мы спрашиваем, какие части зеркал отвалились, и по возможности на развалившиеся зеркала не пишем. Хотя, нагрузка никакая, выдержат, имхо.
Проблема дублирования разговора решается на клиентской машине, на которую приходит свалка результатов ото всех базовых.
Винты, на которые не производится запись, тупо отключаем, экономя электроэнергию. Пришел запрос? замечательно, включаем столько, сколько сможем отпарсить read bandwidth.
Кстати, можно вообще на кассетках делать, благо, ТЗ позволяет - будет слегка дороже, но намного проще, и, возможно, дешевле в эксплуатации.
Ну кто здесь строил high-load системы, в самом деле? Я так, рядом стоял, самое сложное что было - 30м хитов в сутки на 1 сервер стоимостью 2k$ (аналитика от датчиков и сбоев софта), и у нас вполне себе soft realtime получалось, с окном задержки в 10 секунд...
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
asenathwaite
(no subject)
Date: 2012-05-20 12:51 pm (UTC)Берем 100 мбайт RAM. Складываем туда эти звонки. 16 мбайт\сек.
Каждые 5 сек сбрасываем блок в сторейдж, с указанием, кто кому звонил в данном блоке. <1 IOPS, 20 мб\c. Под блок номеров выделяем еще 10 мбайт, сбрасываем каждую минуту, gzip'аем, естественно.
Когда приходит запрос "выдать звонки таких-то абонентов", проводим линейный скан по блокам с номерами и грепаем их на предмет нужного номера. Вычитываем нужные блоки с звонками. Фильтруем прочитанное в RAM. Передаем ответ. ~2-5 IOPS, 160 мбайт\сек, ориентировочное время выполнения запроса "за сутки" - <1 минуты.
На сутки хватит ОДНОГО SATA-диска (180 мбайт\с, 2 тб, 60 IOPS). С дублированием - двух. Pooling не нужен. Если рейд софтверный, то мы спрашиваем, какие части зеркал отвалились, и по возможности на развалившиеся зеркала не пишем. Хотя, нагрузка никакая, выдержат, имхо.
Проблема дублирования разговора решается на клиентской машине, на которую приходит свалка результатов ото всех базовых.
Винты, на которые не производится запись, тупо отключаем, экономя электроэнергию. Пришел запрос? замечательно, включаем столько, сколько сможем отпарсить read bandwidth.
Кстати, можно вообще на кассетках делать, благо, ТЗ позволяет - будет слегка дороже, но намного проще, и, возможно, дешевле в эксплуатации.
Ну кто здесь строил high-load системы, в самом деле?
Я так, рядом стоял, самое сложное что было - 30м хитов в сутки на 1 сервер стоимостью 2k$ (аналитика от датчиков и сбоев софта), и у нас вполне себе soft realtime получалось, с окном задержки в 10 секунд...