5. Поиск «до» внедрения RT индексов
● Через логическую
репликацию оно стало
доступно на сервере, где
происходит индексация
6. Поиск «до» внедрения RT индексов
● Каждые 5-8 мин строятся Plain
индексы и с этой задержкой наше
объявление проиндексировано
● В это время репликация на паузе
7. Поиск «до» внедрения RT индексов
● Plain индексы раздаются по
udp на поисковые сервера,
битые индексы дораздаются
через rsync
8. Поиск «до» внедрения RT индексов
● Ротация Plain индексов
делает доступным в поиске
наше объявление
9. Поиск «до» внедрения RT индексов
● Пользователь делает
поисковый запрос на сайте
или в мобильном приложении
через интернет
11. Поиск «до» внедрения RT индексов
● HAProxy бэкенда отправляет
SphinxQL запрос на демон
Searchd и он выполняется на
индексе одной из категории
12. Поиск «до» внедрения RT индексов
● Или выполняется
распределенный запрос по
индексам всех категорий
13. Ожидания от внедрения RT индексов
● Мгновенная доступность нового объявления в поиске
● Надежность
● Масштабируемсть
● Обслуживать высокую поисковую нагрузку (17000 RPS в пике)
● Сотни изменений в секунду
● Комбинированное решение, с тем что было «до»
● Унификация настроек
14. Чем отличается поиск на RT индексах от Plain?
● Indexer и Main+Delta схема внутри демона Searchd
● Indexer не нужен
● Запросы на изменения данных идут к Searchd
● Ram + Disk чанки
● Внутренние Kill листы
21. Поиск «после» внедрения RT индексов
● Если у RT Indexer
установлен флаг active, то
он делает SELECT из
реплики данных по Id
объявления в событии
22. Поиск «после» внедрения RT индексов
● Если данные найдены, то
RT Indexer выполнит запрос
REPLACE к демону Searchd
● Cоответствующие
изменения отображается в
RT индексах
24. Поиск «после» внедрения RT индексов
● RT Indexer отмечает событие
в очереди обработанным
● Если при поступлении
события флага active не
было, то эта отметка
делается сразу и никакой
др. работы не делается
29. Зачем две очереди PGQm и PGQrt?
● Очередь PGQm нужна для Londiste репликации
● Очередь PGQrt влючена последовательно
● Данные есть в реплике - операция REPLACE
● Данных нет в реплике - операция DELETE
● Гонки данных не возможны
● Возможен оверхед по уже выполненной операции
31. Зачем нужны Plain индексы?
● Нельзя бесконечно накапливать изменения в RT индексах
● Нужно сбрасывать сотояние RT индексов — делать rebuild
● Plain индексы играют промежуточную роль
● Можем откатиться к решению «до», если RT поломается
44. Поиск «после» внедрения RT индексов
● Следит за отставанием и
кол-ом объявлений в RT
индексах
45. Поиск «после» внедрения RT индексов
● Следит за окончанием
периода активности RT
indexer
● Следит за перезапуском
или отсутствием процесса
RTIndexer
46. Поиск «после» внедрения RT индексов
● И устанавливает флаг
rebuild если есть
нарушения
● После этого начинается
Rebuild RT индексов
47. Что еще делает Failover?
● Перезапуск RTIndexer при зависании
● Нотификация в Slack
51. RT Indexer
● Если не установлен флаг active, RT Indexer прогоняет
очередь PGQrt вхолостую, без какой-либо работы
52. RT Indexer
● В RT Indexer можно выделить три основные сущности оформленные в
виде Go рутин и соединенные последовательно через каналы в
Pipeline
53. RT Indexer
● Сортирует Id объявлений в пачки по категориям, возвращает канал,
для передачи таких пачек
54. RT Indexer
● Передает отсортированные пачки Id в этот канал по мере
поступления событий из PGQrt
55. RT Indexer
● Слушает канал с отсортированными по категориям пачками Id
объявлений
● Извлекает для них данные объявлений из реплики исползуя конфиг
для Plain индексов
56. RT Indexer
● Создает два канала с данными объявлений по категориям для запросов
REPLACE и id удаляемых объявлений для запросов DELETE
● Если данные для Id объявления не найдены, то оно считается удаляемым
58. RT Indexer
● Слушает канал с данными объявлений по категориям для запросов
REPLACE
● Слушает канал с Id объявлений для удаления
● Формирует и выполняет запросы REPLACE и DELETE
72. Что реально получили «после» внедрения RT индексов
● Попадание нового объявление в поиск с 10 сек отставанием
● Как и прежде держит высокую нагрузку
● Не вычитываем повторно данные
● Уменьшили трафик в сети
● Гармонично вписали решение c RT индексами в ранее существующую
систему
● Получили надежную систему