Десятки миллионов пользователей просматривают Avito и публикуют почти миллион новых объявлений ежедневно. Сокращение времени появления новых объявлений в поиске - одна из важных задач сервиса. Команда поиска Avito провела в этом направлении ряд оптимизаций, значительно уменьшив время индексации, и, в качестве следующего шага, рассматривала вариант c Delta-индексами, но в результате оказалось возможным реализовать Real Time-индексы. Таким образом мы обеспечили техническую возможность практически мгновенного попадания новых объявлений в поиск в условиях высоких нагрузок по чтению (до 17000 rps) и обновлению (до 1000 rps). Решить эту и ряд других задач нам удалось после перехода на новую версию системы полнотекстового поиска SphinxSearch, появившуюся в этом году. Мы давно и успешно используем Sphinx для решения различных задач, связанных с поиском, но необходимый нам функционал был полностью доступен только в альфа-версии Sphinx 3.0. После ряда экспериментов и общения с командой разработчиков инструмента, мы решили опробовать альфа-версию в бою, чтобы быстрее получить необходимые нам улучшения, а заодно помочь довести Sphinx до стабильной версии. В докладе мы подробно расскажем: - чего не хватало в предыдущей версии Sphinx, какие фичи версии 3.0 были наиболее интересны нам; - каким образом мы организовали инфраструктуру, чтобы плавно перейти на новую версию Sphinx незаметно для остальной команды, не нарушив работу сервиса, как устроены отдельные подсистемы, как они совершенствовались в ходе работы; - с какими проблемами мы столкнулись в процессе и как их решили; - как тестировали, фиксили баги и писали репорты, взаимодействовали с командой разработчик

1. RT индексы в поиске Avito
Вячеслав Крюков, Avito

2. Поиск в Avito
● Активные объявления
● Контекстные объявления
● BackOffice
● В докладе про поиск активных объявлений на RT (Real Time) индексах

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

4. Поиск «до» внедрения RT индексов
● Активное объявление
появилось в Master базе

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

6. Поиск «до» внедрения RT индексов
● Каждые 5-8 мин строятся Plain
индексы и с этой задержкой наше
объявление проиндексировано
● В это время репликация на паузе

7. Поиск «до» внедрения RT индексов
● Plain индексы раздаются по
udp на поисковые сервера,
битые индексы дораздаются
через rsync

8. Поиск «до» внедрения RT индексов
● Ротация Plain индексов
делает доступным в поиске
наше объявление

9. Поиск «до» внедрения RT индексов
● Пользователь делает
поисковый запрос на сайте
или в мобильном приложении
через интернет

10. Поиск «до» внедрения RT индексов
● Его принимает однин из
бэкендов

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

12. Поиск «до» внедрения RT индексов
● Или выполняется
распределенный запрос по
индексам всех категорий

13. Ожидания от внедрения RT индексов
● Мгновенная доступность нового объявления в поиске
● Надежность
● Масштабируемсть
● Обслуживать высокую поисковую нагрузку (17000 RPS в пике)
● Сотни изменений в секунду
● Комбинированное решение, с тем что было «до»
● Унификация настроек

14. Чем отличается поиск на RT индексах от Plain?
● Indexer и Main+Delta схема внутри демона Searchd
● Indexer не нужен
● Запросы на изменения данных идут к Searchd
● Ram + Disk чанки
● Внутренние Kill листы

15. Изменения данных в RT индексах
● INSERT/REPLACE
● UPDATE
● DELETE

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

17. Поиск «после» внедрения RT индексов
● Активное объявление
появилось в Master базе

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

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

20. Поиск «после» внедрения RT индексов
● Событие считывается
консьюмером RT Indexer

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

22. Поиск «после» внедрения RT индексов
● Если данные найдены, то
RT Indexer выполнит запрос
REPLACE к демону Searchd
● Cоответствующие
изменения отображается в
RT индексах

23. Поиск «после» внедрения RT индексов
● Если данные не найдены,
то делается запрос DELETE

24. Поиск «после» внедрения RT индексов
● RT Indexer отмечает событие
в очереди обработанным
● Если при поступлении
события флага active не
было, то эта отметка
делается сразу и никакой
др. работы не делается

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

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

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

28. Поиск «после» внедрения RT индексов
● Зачем две очереди PGQm и
PGQrt?

29. Зачем две очереди PGQm и PGQrt?
● Очередь PGQm нужна для Londiste репликации
● Очередь PGQrt влючена последовательно
● Данные есть в реплике - операция REPLACE
● Данных нет в реплике - операция DELETE
● Гонки данных не возможны
● Возможен оверхед по уже выполненной операции

30. Поиск «после» внедрения RT индексов
● Зачем нужны Plain
индексы?

31. Зачем нужны Plain индексы?
● Нельзя бесконечно накапливать изменения в RT индексах
● Нужно сбрасывать сотояние RT индексов — делать rebuild
● Plain индексы играют промежуточную роль
● Можем откатиться к решению «до», если RT поломается

32. Поиск «после» внедрения RT индексов
● Rebuild RT индексов
● Репликация на паузе
● Переиндексация Plain
индексов

33. Поиск «после» внедрения RT индексов
● Rebuild RT индексов
● Репликация на паузе
● Раздача Plain индексов

34. Поиск «после» внедрения RT индексов
● Rebuild RT индексов
● Репликация на паузе
● Принудительная пауза, для
холостой прокрутки PGQrt

35. Поиск «после» внедрения RT индексов
● Rebuild RT индексов
● Репликация на паузе
● RELOAD Plain индексов

36. Поиск «после» внедрения RT индексов
● Rebuild RT индексов
● Репликация на паузе
● ATTACH WITH TRUNCATE
Plain индексов в RT

37. Поиск «после» внедрения RT индексов
● Rebuild RT индексов
закончен
● Репликация снята с паузы
● Установлен флаг active
● RT indexer обрабатывает
очередь PGQrt

38. Rebuild RT индексов

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

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

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

42. Поиск «после» внедрения RT индексов
● Зачем нужен Failover ?

43. Поиск «после» внедрения RT индексов
● Следит за отставанием
очереди PGQrt

44. Поиск «после» внедрения RT индексов
● Следит за отставанием и
кол-ом объявлений в RT
индексах

45. Поиск «после» внедрения RT индексов
● Следит за окончанием
периода активности RT
indexer
● Следит за перезапуском
или отсутствием процесса
RTIndexer

46. Поиск «после» внедрения RT индексов
● И устанавливает флаг
rebuild если есть
нарушения
● После этого начинается
Rebuild RT индексов

47. Что еще делает Failover?
● Перезапуск RTIndexer при зависании
● Нотификация в Slack

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

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

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

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 объявления не найдены, то оно считается удаляемым

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

58. RT Indexer
● Слушает канал с данными объявлений по категориям для запросов
REPLACE
● Слушает канал с Id объявлений для удаления
● Формирует и выполняет запросы REPLACE и DELETE

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

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

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

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

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

64. RT Indexer
● Ошибки пишутся в общий для всех канал ошибок
● Канал ошибок слушает специальная Go рутина

65. RT Indexer
● Если встречается критичная ошибка, то выставляется состояние
rebuild
● Аварийного завершения не происходит

66. Критичные ошибки в RT Indexer
● Возникновение ошибок выполнения запросов
● Появление нового поискового сервера
● Ошибки конфигурации

67. Настройка производительности
● Медленные запросы REPLACE/DELETE — отставание очереди PGQrt
● rt_mem_limit срабатывает поиндексно
● Необходим некоторый избыток rt_mem_limit

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

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

70. Отставание

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

72. Что реально получили «после» внедрения RT индексов
● Попадание нового объявление в поиск с 10 сек отставанием
● Как и прежде держит высокую нагрузку
● Не вычитываем повторно данные
● Уменьшили трафик в сети
● Гармонично вписали решение c RT индексами в ранее существующую
систему
● Получили надежную систему

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