среда, 22 июня 2011 г.

Re: про БД

наверное что то типа map reduce
--
OK



2011/6/22 Andrey Voronkov <voronkovaa@gmail.com>
Еще пример: когда работал в ISP у нас была трехступенчатая обработка
биллинга. Объяснили мне так: сначала на маршрутизаторах чистый netflow
(дада - на netflow) проходил предобработку, потом предобработанный
трафик шел на сервер биллинга филиала, а потом еще более очищенный
уходил в центральный филиал по региону. Как-то так.

В общем и целом надо постараться большой трафик не гонять "в чистую".
Обычно он не нужен в сыром виде, т.к. служит для описания какой-то
более общей картины.

22 июня 2011 г. 17:55 пользователь Max Lapshin <max.lapshin@gmail.com> написал:
> 2011/6/22 Andrey Voronkov <voronkovaa@gmail.com>:
>> Это какой-то нереальный поток данных. По-моему даже больше, чем от
>> телематики при запуске ракетоносителей (там по моему всего порядка 16
>> Мб/с). Как мне объясняли, они сохраняют весь трафик - полет
>> относительно недолгий, а для вывода статистики делают оперативную
>> предобработку. Я не думаю, что какая-то база выдержить такой поток в
>> чистом виде. SSD stripe еле-еле дотягивает до таких значений записей.
>
> Если предположить, что одна запись порядка 128 байт, около 8 тыс
> серверов (например, человек из РЖД или из Мосэнерго, или из
> какого-нибудь датацентра), то выходит что порядка 2000 событий в
> секунду дают трафик в 2 гигабайта в секунду.
>
> Правда, всё так же непонятно, что же это за задача такая.
>
> Совершенно точно на один сервер это не записать: нет даже смысла с
> этим возиться.
>
> Когда я предыдущий раз сталкивался с аналитикой на больших объёмах, то
> удивительно неплохо себя показала база данных Caché,
> при заливке в неё пачки турпредложений (а у туроператоров чудовищные
> объёмы информации), вышло что она сходу,
> при отсутствии специалистов и при наличии оракловых специалистов,
> показала в несколько раз лучшие характеристики по записи и чтению.
>
> Впрочем, я бы не стал в этой ситуации советовать какое-то конкретное
> решение, а попробовал бы потеребить кого-нибудь из Яндекса
> (их гораздо проще спросит, чем кого-то ещё с таким же опытом), как они
> хранят и обрабатывают свои логи.
> Но у них скорее всего самописное решение
>
> --
> --
> Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
> FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
>
>  Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
> ror2ru@googlegroups.com
>  Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
>  Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ

 Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
 Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
 Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
 
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru

Комментариев нет:

Отправить комментарий