3. Кратко о проекте BoardReader.COM
• Поиск по форумам и социальным сетям
• >2 млн web запросов ежедневно, пик до 300 тыс/час
• >10 млрд проиндексированных документов
• >20 MySQL серверов, >15Tb сжатых данных
• Sphinx кластер
• >20 серверов
• суммарный размер индексов >3Tb
• >7 млн Sphinx запросов ежедневно
4. Требования к проекту
● Производительность
● Надежность
● Масштабируемость
● Доступность
● Легкость в обслуживании
5. Front-end
• Общедоступный поиск BoardReader.COM
• Агрегированные данные по сайтам, форумам,
тредам, топикам
• Коммерческий API к поиску по форумам, блогам,
микроблогам, новостям, картинкам, ссылкам
• Система мониторинга и управления постами
• Админки
7. Масштабируемость Sphinx кластера
• Scale Up
– добавляем памяти, диски, заменяем текущие на более
мощные сервера
• Scale Out
– MySQL — шардинг, добавляем новые DB сервера
– Sphinx - дистрибутивные индексы, добавляем новые SE
сервера, до 2^64 документов
8. Дистрибутивные индексы Sphinx
• Запросы к нескольким индексам текущего и др
инстансов searchd
• Обращения к инстансам searchd на локальном и
удаленном серверах
• Мерж результатов, удаление дубликатов
• Рапределение ресурсов нескольких серверов
• Инкрементация данных
10. Конфигурация Sphinx SE
• 4 инстанса searchd на одном сервере
• 4 конфигурационных файла для node{1,2,3,4}, в каждом
файле прописан свой собственный searchd
• множество типов индексов по назначению — форумные
посты, блог посты, новости, картинки, ссылки
• три типа индексов по дате заливки - 'big','3months','inc'
11. Конфигурация Sphinx SE
• 'big','3months','inc' sources – MySQL источники данных
• 'big','3months','inc' indexes – набор индексов
• 'big','3months' sources сохраняют состояние индексации во
вспомогательные таблицы, данные в индексах не
пересекаются
12. Конфигурация Sphinx SE
• индексы со всех нод заданного Sphinx SE объединяются в
спец дистрибутивном на node1:
• нужно для последующей передачи на Sphinx forwarder
• big_se01 = big_node{1,2,3,4} + 3months_node{1,2,3,4}+
inc_node{1,2,3,4}
• 3months_se01 = 3months_node{1,2,3,4} +
inc_node{1,2,3,4}
13. Конфигурация Sphinx forwarder
• Индексы объединяются в дистрибутивном со всех Sphinx SE
отдельно для каждого типа по дате заливки, кроме 'inc' и
каждого типа по назначению.
14. Оценка производительности Sphinx кластера
avg(t), sec 0.16
std(t), sec 1.01
t < 0.1 sec 85%
t < 0.3 sec 91%
t < 0.5 sec 93%
t < 0.7 sec 95%
t < 1 sec 96%
t < 3 sec 98%
t < 5 sec 99%
requests: 7881995
t — время выполнения Sphinx запроса
Так же подобные отчеты строятся для отдельных видов web запросов
15. Типичные проблемы
● Проблема в одном месте - проблема с
производительностью системы в целом
● Нехватка пропускной способности дисков
● Нехватка ресурсов памяти – активно используется Swap
● Нехватка ресурса CPU (встречается реже)
16. Оптимизация схемы распределения данных
в Sphinx кластере
• Цель - эффективность использования ресурсов
• Один инстанс searchd на Sphinx SE + многопоточность,
общий файл для всех node{1,2,3,4}
• Много индексов — нужна больше пропускная способность
дисков на чтение
• Оптимизация размера атрибутов
• Перебалансировка данных
17. Обновление данных
● до 100Гб новых данных в формате xml каждый день
● Обновление инрементального индекса - каждые 5 минут
● Обновление 3-х месячного индекса - раз в сутки
● Обновление большого индекса - раз в месяц, данные за 2
года
18. Обновление данных
• Перезаливка существующих данных
• Система мониторинга и управления постами
• Изменение некоторых атрибутов постов, в том числе для
пометки удаленных, скрытых, адултных и спамных
постов
• Добавление задания как из web интерфейса, так и из
сторонних скриптов
• Механизм очередей
19. Обновление данных
● indexer отнимает ресурсы по памяти и диску
● Запас места на диске для переиндексации до 50-70%
● Режим обслуживания БД MySQL
● Вместо переиндексации можно использовать мержинг
индексов
20. Оптимизация Sphinx запросов
● Multi-queries
● 10 web запросов – 1 Sphinx запрос
● Переключение запроса на индекс меньшего размера или на
индексы конечных нод
21. Балансировка данных Sphinx кластера
● Анализ лога производительности Sphinx запросов
● Оценка и перерасчет распределения данных в кластере
● Учет неравнозначности ресурсов отдельных серверов
● Переиндексация индексов, затрагиваемых
перебалансировкой
● Вместо ротации через indexer - одномоментная замена
индексов
22. Меры повышения производительности и
надежности
● Кеширование – HTTP, Memcache, файловый кеш
● Логи производительности и ошибок
● Мониторинг, система оповещения - nagios, Zabbix
● Автоматизация операций администрирования
● Тестирование изменений конфигурации кластера