Как мы храним 60 тысяч событий в секунду

Ахтунг! До конференции разработчиков высоконагруженных HighLoad++ систем осталось 3 недели. Много это или мало? ОЧЕНЬ мало! Коллеги, наши бухгалтерии не работают так, как мы, дедлайн у них связан с подачей отчётности, а не с оплатой счетов. Поэтому если Вы хотели бы попасть на HL++ в этом
году, то советую поторопиться с бронированием билетов.

А мы ещё немного расскажем про доклады будущей конференции, например, доклад Арсена Мукучяна из компании AdRiver о том, как они обрабатывают 4 миллиарда показов рекламных модулей ежедневно. Причём не просто обрабатывают, но осмысленно это делают.

Тезисы большие и структурные, мы выбрали для рассылки несколько особенно удачных моментов:
1.4. Обоснование необходимости хранения событий и несколько примеров аналитической информации, которая предоставляется клиентам.
1.5. Обоснование необходимости обеспечения консистентности данных — это основное бизнес-требование к подсистеме хранения. Рассказ про далекие времена, когда события хранились в текстовых логах и регулярно приходилось объяснять клиентам природу расхождений цифр в различных отчётах.

2.1. Описание рабочих объёмов данных: 4 миллиарда событий в сутки или около 500Гб сериализованных данных в сутки. Минимальный период хранения — 1год.

3.1. Сравнительный анализ предметной области. Эксперименты с map/reduce фреймворками и СУБД. Обоснование разработки собственной системы хранения.
3.3. Обоснование важности алгоритмической оптимизации и отказа от «лишней» логики в высоконагруженных серверах.
3.3.2. Сервер, предоставляющий произвольный доступ к данным, абстрагирован от самих данных и не производит никакой их обработки. Это позволяет уменьшить нагрузку на процессор при обслуживании множественных запросов к данным.
3.4. Краткое описание используемых механизмов сериализации. Аналогия c Google protobuf.
3.5. Описание используемого механизма индексации данных, который позволяет идентифицировать любое событие системы. Это решение является ключевым к обеспечению консистентности.
3.6. Потоковое хранение данных и страничная организация — панацея в решении проблем с оперативной памятью. Предпочтительнее упереться в производительность дисковой подсистемы или процессора, чем в «Out of Memory», потому что в первом случае произойдет лишь снижение производительности системы, а во втором — отказ в обслуживании.
3.7. Сжатие данных, страничная организация хранения и абстракция сервера от самих данных позволяют любой нашей ноде отдавать гигабит информации в секунду, обслуживая 200 клиентов и обрабатывая 1000 файлов. Загрузка процессора, диска и памяти в этот момент не больше минимальной. Сервер отдает клиенту пожатые страницы данных, которые клиент должен распаковать и обработать перед тем как запросить следующую порцию. За это время сервер успевает подготовить следующую порцию данных и обслужить остальных клиентов.

4.2. Работа с диском производится асинхронно посредством POSIX AIO. В планах осуществить переход на kernel AIO и сравнить эксплуатационные характеристики.

5.2. Подведение итога эксплуатационных характеристик системы: год данных — 200 Тб, параллельное обслуживание 1000 клиентов, суммарный исходящий трафик подсистемы — 20Гбит/сек. Оценка стоимости.

Хотите подробностей?
Тезисы Арсена на сайте конференции:
http://www.highload.ru/2013/abstracts/1216.html

Но лучше, конечно, просто забронировать себе билеты:
http://conf.ontico.ru/conference/join/hl2013.html
Как никак, ключевое событие отрасли :)

 А всего-то надо нажать сюда и оформить заявку...