Sphinx для высоко-нагруженных и масштабируемых проектов, Вячеслав Крюков

Sphinx для высоко-нагруженных и масштабируемых проектов

Вячеслав Крюков[email protected]

Кратко о Sphinx

http://sphinxsearch.com/docs/current.html#intro

Кратко о проекте BoardReader.COM

• Поиск по форумам и социальным сетям• >2 млн web запросов ежедневно, пик до 300 тыс/час• >10 млрд проиндексированных документов• >20 MySQL серверов, >15Tb сжатых данных• Sphinx кластер

• >20 серверов • суммарный размер индексов >3Tb • >7 млн Sphinx запросов ежедневно

Требования к проекту● Производительность● Надежность● Масштабируемость● Доступность● Легкость в обслуживании

Front-end

• Общедоступный поиск BoardReader.COM• Агрегированные данные по сайтам, форумам,

тредам, топикам• Коммерческий API к поиску по форумам, блогам,

микроблогам, новостям, картинкам, ссылкам • Система мониторинга и управления постами• Админки

Back-end

Масштабируемость Sphinx кластера

• Scale Up– добавляем памяти, диски, заменяем текущие на более

мощные сервера• Scale Out

– MySQL — шардинг, добавляем новые DB сервера– Sphinx - дистрибутивные индексы, добавляем новые SE

сервера, до 2^64 документов

Дистрибутивные индексы Sphinx

• Запросы к нескольким индексам текущего и др инстансов searchd• Обращения к инстансам searchd на локальном и

удаленном серверах• Мерж результатов, удаление дубликатов• Рапределение ресурсов нескольких серверов• Инкрементация данных

Конфигурация Sphinx кластера

Конфигурация Sphinx SE

• 4 инстанса searchd на одном сервере • 4 конфигурационных файла для node{1,2,3,4}, в каждом

файле прописан свой собственный searchd• множество типов индексов по назначению — форумные

посты, блог посты, новости, картинки, ссылки• три типа индексов по дате заливки - 'big','3months','inc'

Конфигурация Sphinx SE• 'big','3months','inc' sources – MySQL источники данных• 'big','3months','inc' indexes – набор индексов• 'big','3months' sources сохраняют состояние индексации во

вспомогательные таблицы, данные в индексах не пересекаются

Конфигурация 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}

Конфигурация Sphinx forwarder• Индексы объединяются в дистрибутивном со всех Sphinx SE

отдельно для каждого типа по дате заливки, кроме 'inc' и каждого типа по назначению.

Оценка производительности Sphinx кластераavg(t), sec 0.16std(t), sec 1.01t < 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: 7881995t — время выполнения Sphinx запроса

Так же подобные отчеты строятся для отдельных видов web запросов

Типичные проблемы● Проблема в одном месте - проблема с

производительностью системы в целом● Нехватка пропускной способности дисков ● Нехватка ресурсов памяти – активно используется Swap● Нехватка ресурса CPU (встречается реже)

Оптимизация схемы распределения данных в Sphinx кластере

• Цель - эффективность использования ресурсов• Один инстанс searchd на Sphinx SE + многопоточность,

общий файл для всех node{1,2,3,4}• Много индексов — нужна больше пропускная способность

дисков на чтение• Оптимизация размера атрибутов• Перебалансировка данных

Обновление данных● до 100Гб новых данных в формате xml каждый день● Обновление инрементального индекса - каждые 5 минут● Обновление 3-х месячного индекса - раз в сутки● Обновление большого индекса - раз в месяц, данные за 2

года

Обновление данных

• Перезаливка существующих данных• Система мониторинга и управления постами

• Изменение некоторых атрибутов постов, в том числе для пометки удаленных, скрытых, адултных и спамных постов

• Добавление задания как из web интерфейса, так и из сторонних скриптов

• Механизм очередей

Обновление данных● indexer отнимает ресурсы по памяти и диску● Запас места на диске для переиндексации до 50-70%● Режим обслуживания БД MySQL● Вместо переиндексации можно использовать мержинг

индексов

Оптимизация Sphinx запросов● Multi-queries● 10 web запросов – 1 Sphinx запрос● Переключение запроса на индекс меньшего размера или на

индексы конечных нод

Балансировка данных Sphinx кластера● Анализ лога производительности Sphinx запросов● Оценка и перерасчет распределения данных в кластере● Учет неравнозначности ресурсов отдельных серверов● Переиндексация индексов, затрагиваемых

перебалансировкой● Вместо ротации через indexer - одномоментная замена

индексов

Меры повышения производительности и надежности

● Кеширование – HTTP, Memcache, файловый кеш● Логи производительности и ошибок● Мониторинг, система оповещения - nagios, Zabbix● Автоматизация операций администрирования● Тестирование изменений конфигурации кластера

Спасибо за внимание !Вопросы ?