Sphinx для высоко-нагруженных и
масштабируемых проектов
Вячеслав Крюков
vkrukov@ivinco.com
Кратко о 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.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 запросов
Типичные проблемы
● Проблема в одном месте - проблема с
производительностью системы в целом
● Нехватка пропускной способности дисков
● Нехватка ресурсов памяти – активно используется 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
● Автоматизация операций администрирования
● Тестирование изменений конфигурации кластера
Спасибо за внимание !
Вопросы ?

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

  • 1.
    Sphinx для высоко-нагруженныхи масштабируемых проектов Вячеслав Крюков vkrukov@ivinco.com
  • 2.
  • 3.
    Кратко о проектеBoardReader.COM • Поиск по форумам и социальным сетям • >2 млн web запросов ежедневно, пик до 300 тыс/час • >10 млрд проиндексированных документов • >20 MySQL серверов, >15Tb сжатых данных • Sphinx кластер • >20 серверов • суммарный размер индексов >3Tb • >7 млн Sphinx запросов ежедневно
  • 4.
    Требования к проекту ●Производительность ● Надежность ● Масштабируемость ● Доступность ● Легкость в обслуживании
  • 5.
    Front-end • Общедоступный поискBoardReader.COM • Агрегированные данные по сайтам, форумам, тредам, топикам • Коммерческий API к поиску по форумам, блогам, микроблогам, новостям, картинкам, ссылкам • Система мониторинга и управления постами • Админки
  • 6.
  • 7.
    Масштабируемость Sphinx кластера •Scale Up – добавляем памяти, диски, заменяем текущие на более мощные сервера • Scale Out – MySQL — шардинг, добавляем новые DB сервера – Sphinx - дистрибутивные индексы, добавляем новые SE сервера, до 2^64 документов
  • 8.
    Дистрибутивные индексы Sphinx •Запросы к нескольким индексам текущего и др инстансов searchd • Обращения к инстансам searchd на локальном и удаленном серверах • Мерж результатов, удаление дубликатов • Рапределение ресурсов нескольких серверов • Инкрементация данных
  • 9.
  • 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 ● Автоматизация операций администрирования ● Тестирование изменений конфигурации кластера
  • 23.