Sphinx 3.0 и RT-индексы на основном поиске Avito / Андрей Смирнов, Вячеслав Крюков (Avito)

RT индексы в поиске Avito

Вячеслав Крюков, Avito

Поиск в Avito

● Активные объявления

● Контекстные объявления

● BackOffice

● В докладе про поиск активных объявлений на RT (Real Time) индексах

Поиск «до» внедрения RT индексов


● Активное объявление появилось в Master базе


● Через логическую репликацию оно стало доступно на сервере, где происходит индексация


● Каждые 5-8 мин строятся Plain индексы и с этой задержкой наше объявление проиндексировано

● В это время репликация на паузе


● Plain индексы раздаются по udp на поисковые сервера, битые индексы дораздаются через rsync


● Ротация Plain индексов делает доступным в поиске наше объявление


● Пользователь делает поисковый запрос на сайте или в мобильном приложении через интернет


● Его принимает однин из бэкендов


● HAProxy бэкенда отправляет SphinxQL запрос на демон Searchd и он выполняется на индексе одной из категории


● Или выполняется распределенный запрос по индексам всех категорий

Ожидания от внедрения RT индексов

● Мгновенная доступность нового объявления в поиске

● Надежность

● Масштабируемсть

● Обслуживать высокую поисковую нагрузку (17000 RPS в пике)

● Сотни изменений в секунду

● Комбинированное решение, с тем что было «до»

● Унификация настроек

Чем отличается поиск на RT индексах от Plain?

● Indexer и Main+Delta схема внутри демона Searchd

● Indexer не нужен

● Запросы на изменения данных идут к Searchd

● Ram + Disk чанки

● Внутренние Kill листы

Изменения данных в RT индексах

● INSERT/REPLACE

● UPDATE

● DELETE

Поиск «после» внедрения RT индексов


● Активное объявление появилось в Master базе


● Через логическую репликацию оно стало доступно на сервере, где происходит индексация


● По факту новых данных в реплике генерируется событие с Id объявления в очереди PGQrt


● Событие считывается консьюмером RT Indexer


● Если у RT Indexer установлен флаг active, то он делает SELECT из реплики данных по Id объявления в событии


● Если данные найдены, то RT Indexer выполнит запрос REPLACE к демону Searchd

● Cоответствующие изменения отображается в RT индексах


● Если данные не найдены, то делается запрос DELETE


● RT Indexer отмечает событие в очереди обработанным

● Если при поступлении события флага active не было, то эта отметка делается сразу и никакой др. работы не делается

Отставание «До» и «после» выкатки RT индексов

Количество объявлений в общем индексе (Distr Index)

Количество изменяемых объявлений во времени


● Зачем две очереди PGQm и PGQrt?

Зачем две очереди PGQm и PGQrt?

● Очередь PGQm нужна для Londiste репликации

● Очередь PGQrt влючена последовательно

● Данные есть в реплике - операция REPLACE

● Данных нет в реплике - операция DELETE

● Гонки данных не возможны

● Возможен оверхед по уже выполненной операции


● Зачем нужны Plain индексы?

Зачем нужны Plain индексы?

● Нельзя бесконечно накапливать изменения в RT индексах

● Нужно сбрасывать сотояние RT индексов — делать rebuild

● Plain индексы играют промежуточную роль

● Можем откатиться к решению «до», если RT поломается


● Rebuild RT индексов

● Репликация на паузе

● Переиндексация Plain индексов




● Раздача Plain индексов




● Принудительная пауза, для холостой прокрутки PGQrt




● RELOAD Plain индексов




● ATTACH WITH TRUNCATE Plain индексов в RT


● Rebuild RT индексов закончен

● Репликация снята с паузы

● Установлен флаг active

● RT indexer обрабатывает очередь PGQrt

Rebuild RT индексов

Изменение размера Ram чанка


● Поисковые запросы через бэкененды и HAProxy поступают на демон Searchd и он их отрабатывает на RT индексах

Поисковая нагрузка


● Зачем нужен Failover ?


● Следит за отставанием очереди PGQrt


● Следит за отставанием и кол-ом объявлений в RT индексах


● Следит за окончанием периода активности RT indexer

● Следит за перезапуском или отсутствием процесса RTIndexer


● И устанавливает флаг rebuild если есть нарушения

● После этого начинается Rebuild RT индексов

Что еще делает Failover?

● Перезапуск RTIndexer при зависании

● Нотификация в Slack

Неконтролируемое отставание очереди PGQrt

Контролируемое отставание очереди PGQrt

RT Indexer

● Python демон с подключенной библиотекой на Go

RT Indexer

● Если не установлен флаг active, RT Indexer прогоняет очередь PGQrt вхолостую, без какой-либо работы

RT Indexer

● В RT Indexer можно выделить три основные сущности оформленные в виде Go рутин и соединенные последовательно через каналы в Pipeline

RT Indexer

● Сортирует Id объявлений в пачки по категориям, возвращает канал, для передачи таких пачек

RT Indexer

● Передает отсортированные пачки Id в этот канал по мере поступления событий из PGQrt

RT Indexer

● Слушает канал с отсортированными по категориям пачками Id объявлений

● Извлекает для них данные объявлений из реплики исползуя конфиг для Plain индексов

RT Indexer

● Создает два канала с данными объявлений по категориям для запросов REPLACE и id удаляемых объявлений для запросов DELETE

● Если данные для Id объявления не найдены, то оно считается удаляемым

RT Indexer

● Передает в эти каналы данные по мере поступления пачек Id объявлений

RT Indexer

● Слушает канал с данными объявлений по категориям для запросов REPLACE

● Слушает канал с Id объявлений для удаления

● Формирует и выполняет запросы REPLACE и DELETE

RT Indexer

● Выполняются запросы REPLACE и DELETE для категории 1

RT Indexer

● Выполняются запросы REPLACE и DELETE для категории 2

RT Indexer

● Выполняются запросы REPLACE и DELETE для категории Nc

RT Indexer

● В RT Indexer обрабатываются абсолютно все ошибки, падения не допускаются

RT Indexer

● В RT Indexer отмечаются обработанными абсолютно все события

RT Indexer

● Ошибки пишутся в общий для всех канал ошибок

● Канал ошибок слушает специальная Go рутина

RT Indexer

● Если встречается критичная ошибка, то выставляется состояние rebuild

● Аварийного завершения не происходит

Критичные ошибки в RT Indexer

● Возникновение ошибок выполнения запросов

● Появление нового поискового сервера

● Ошибки конфигурации

Настройка производительности

● Медленные запросы REPLACE/DELETE — отставание очереди PGQrt

● rt_mem_limit срабатывает поиндексно

● Необходим некоторый избыток rt_mem_limit

0.95 время выполнения SELECT

Максимальное время выполнение REPLACE

Отставание

Полное спокойствие в пик трафика

Что реально получили «после» внедрения RT индексов

● Попадание нового объявление в поиск с 10 сек отставанием

● Как и прежде держит высокую нагрузку

● Не вычитываем повторно данные

● Уменьшили трафик в сети

● Гармонично вписали решение c RT индексами в ранее существующую систему

● Получили надежную систему

Спасибо, вопросы?

Engineering

Sphinx 3.0 и RT-индексы на основном поиске Avito / Андрей Смирнов, Вячеслав Крюков (Avito)