HighLoad++

Конференция разработчиков
высоконагруженных систем

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

Доклад принят в Программу конференции

1. Введение.
1.1. Про AdRiver.
1.2. Определение события как информационной единицы системы.
1.3. Условное разделение системы на две части: realtime-часть отвечает за выборку баннеров и порождает события, а статистическая подсистема отвечает за их хранение и обработку.
1.4. Обоснование необходимости хранения событий и несколько примеров аналитической информации, которая предоставляется клиентам.
1.5. Обоснование необходимости обеспечения консистентности данных - это основное бизнес-требование к подсистеме хранения. Рассказ про далекие времена, когда события хранились в текстовых логах и регулярно приходилось объяснять клиентам природу расхождений цифр в различных отчетах.

2. Постановка задачи и требования.
2.1. Описание рабочих объемов данных: 4 млрд событий в сутки или ~500 Гб сериализованных данных в сутки. Минимальный период хранения - 1 год.
2.2. Обеспечение консистентности данных.
2.3. Обеспечение произвольного доступа к данным.
2.4. Обеспечение надежности, отказоустойчивости и масштабируемости.

3. Реализация и ключевые решения.
3.1. Сравнительный анализ предметной области. Эксперименты с map/reduce фреймворками и СУБД. Обоснование разработки собственной системы хранения.
3.2. Общее описание разработанной системы History.
3.3. Обоснование важности алгоритмической оптимизации и отказа от "лишней" логики в высоконагруженных серверах.
3.3.1. Наша аксиома проектирования: каждый компонент должен ХОРОШО выполнять одну функцию, вместо того, чтобы ПЛОХО предоставлять множество.
3.3.2. Сервер, предоставляющий произвольный доступ к данным, абстрагирован от самих данных и не производит никакой их обработки. Это позволяет уменьшить нагрузку на процессор при обслуживании множественных запросов к данным.
3.4. Краткое описание используемых механизмов сериализации. Аналогия c Google Protobuf.
3.5. Описание используемого механизма индексации данных, который позволяет идентифицировать любое событие системы. Это решение является ключевым к обеспечению консистентности.
3.6. Потоковое хранение данных и страничная организация - панацея в решении проблем с оперативной памятью. Предпочтительнее "упереться" в производительность дисковой подсистемы или процессора, чем в "Out of Memory", потому что в первом случае произойдет лишь снижение производительности системы, а во втором - отказ в обслуживании.
3.7. Сжатие данных, страничная организация хранения и абстрагирование сервера от самих данных позволяют любой нашей ноде отдавать гигабит информации в секунду, обслуживая 200 клиентов и обрабатывая 1000 файлов. Загрузка процессора, диска и памяти в этот момент не больше минимальной. Сервер отдает клиенту пожатые страницы данных, которые клиент должен распаковать и обработать перед тем как запросить следующую порцию. За это время сервер успевает подготовить следующую порцию данных и обслужить остальных клиентов.

4. Ремарки к реализации.
4.1. Однажды мы нарушили собственную аксиому проектирования и нагрузили сервер оптимизацией чтения данных (группировка по ключам). В результате "открылся ящик Пандоры" - теперь при ошибках в конфигурации система может "закопаться" в io wait.
4.2. Работа с диском производится асинхронно посредством POSIX AIO. В планах осуществить переход на kernel AIO и сравнить эксплуатационные характеристики.

5. Выводы и перспективы.
5.1. Задача решена, все довольны.
5.2. Подведение итога для эксплуатационных характеристик системы: год данных - 200Тб, параллельное обслуживание 1000 клиентов, суммарный исходящий трафик подсистемы - 20Гбит/сек. Оценка стоимости.
5.3. Краткий обзор инструментов аналитики, построенных на базе History. Размышления на тему того, что вся "лишняя" логика, от которой отказались в п.3.3., ушла на более высокие уровни.
5.4. Требуется существенное увеличение скорости получения данных. Описание способов реализации этого требования.
5.5. Требуется уменьшение задержки в работе (latency) системы без потери консистентности данных.

Золотой спонсор

  • Вadoo

Золотой спонсор

  • Percona

Игровой партнёр

  • WarGaming

Генеральный интернет-партнёр

  • Mail.Ru Group

Бронзовые спонсоры

  • Microsoft

Бронзовые спонсоры

  • Nutanix

Серебряный спонсор

  • http://www.google.com/

Серебряный спонсор

  • Webzilla

Travel-спонсор

  • Интернет Хостинг Центр

Технический партнёр

  • Филанко

HR-партнёр

  • SuperJob

HeadHunter-партнёр

  • HeadHunter

Партнёр по персоналу

  • http://www.rabota.ru/

Фри-ланс партнёр

  • http://www.free-lance.ru/

Информационная поддержка

  • Макхост
  • TRINET
  • Интуит
  • Нетология
  • Elama
  • Rusonyx
  • SpaceWeb
  • PС Мagazine
  • http://www.hse.ru/
  • ServerNews
  • Бизнес-школа RMA
  • http://e-personal.ru/
  • Учебный центр Luxoft Training
  • Webnames.ru
  • ExpoMap.ru
  • Русская школа управления
  • Internest
  • ООО «Юмисофт»
  • Финам
  • HackDay
  • SoftKey
  • GISMETEO / ГИСМЕТЕО
  • Agilecamp
  • ESET CLUB
  • Агава
  • Digitale
  • Блогун
  • CMS Magazine
  • Bugtraq.ru
  • Xakep.ru
  • http://www.samag.ru/
  • SQLInfo.ru
  • http://webew.ru/
  • HSE INC
  • timeofnewz
  • Moscow Business School
  • REG.RU
  • PeterHost
  • RUcenter
  • Хостинг-Центр
По любым вопросам обращайтесь:
Программный комитет :
Олег Бунин , +7 (916) 635-95-84
Бухгалтерия и вопросы оплаты :
, +7(495) 646-07-68
Организационный комитет :
Олег Бунин , +7 (916) 635-95-84

Почтовый адрес:
119180, Москва, Бродников пер., д. 7 стр. 1, +7(495) 646-07-68, ООО «Онтико»

Rambler's Top100
Рейтинг@Mail.ru