Документ описывает процесс создания высоконагруженной системы поиска для платформы Одноклассники с использованием Apache Lucene. Основные аспекты включают причины выбора Lucene, архитектуру системы, а также проблемы и решения, связанные с производительностью и индексацией. Также затрагиваются требования к системе и детали реализации поиска по данным пользователям и музыкальным произведениям.

1. Как, используя Lucene, построить
высоконагруженную систему поиска
разнородных данных

2. Одноклассники в цифрах
• Что у нас есть:
– 100 млн пользователей;
– 3.3 млн групп;
– .....
• 4.1 млн пользователей онлайн;
• В секунду:
– 250. тыс. страниц, 50мс, 70Гбит/с;
– 6 тыс. сообщений и комментариев;
– 1.5 тыс. поисковых запросов.
1

3. Зачем нам понадобились свои поисковые
системы?
• Пользователь не всегда знает, как именно
регистрировался искомый друг
• На сайте были огромные каталоги групп и
сообществ
• Планировались новые сервисы, которым
понадобится поиск
• Как правило, человек ищет то, что уже есть у
кого-то из его друзей
2

4. Почему Lucene?
• Поиск по MS SQL базе был крайне медленным
• На Java написано 99% нашего кода, поэтому
Sphinx даже не смотрели
• Apachе Lucene/Solr поддерживаются большим
сообществом и хорошо себя зарекомендовали
• Уже был опыт использования Solr
• Быстрый поиск других поисковых
Java-проектов результатов не дал
3

5. Как устроен Lucene?
The bright Term DocId DocId Values
blue blue 1,2 1 333, Author A
Index Reader & Searcher & Query parser
butterfly bright 1,2 2 777, Author C
hangs on
Tokenizers & Filters & IndexWriter
butterfly 1
the breeze
breeze 1
hangs 1
Under blue
sky, in bright need 2
sunlight, search 2
one need sky 2
not search
around
Term DocId DocId Values
It’s best to best 1 1 555, Author C
forget the forget 1
great sky
great 1
and to retire
from every retire 1
wind sky 1
wind 1
4

6. Требования к системе индексов
• Отказоустойчивость и масштабируемость
• Высокая производительность поисковых
серверов
• Гибкое индексирование
• Возможность сбора дополнительной
информации перед индексацией
• Возможность анализа готового индекса
5

7. Что нас не устроило в Solr
• Solr:
– сервер использует только один процессор
– репликация индексов на bash-скриптах
– http - это дорого и медленно
– сложно модифицировать
• Но Lucene нас устраивает, поэтому пишем
свой сервер
6

8. Архитектура
Presentation
Query
Event
Result
Result
Search processing system Read Services
Update/Notify
Query
Read
Results
Index Replication Indexer + DB
7

9. Требования к поисковой системе
• Отказоустойчивость
• Использование социального графа
• Эффективность
• Простое изменение и расширение
функциональности
• Сбор статистики по пользователям
• Высокая пропускная способность
8

10. Как работает поисковая система
Get session for Schema
Schedule queries
Execute queries
waitAll ()
waitFor (queries complete)
waitAtLeast (result items)
Reduce results
Load results
9

11. Проблемы: работа с индексом
• Lucene активно читает файлы во время поиска
• Пробовали:
– Диск с FSDirectory и NIODirectory
– RamDrive с FSDirectory и NIODirectory
– Lucene RamDirectory
– Собственный UnsafeDirectory
• Победил:
– HeapDirectоry файлы как byte[] в хипе
10

12. Проблемы: ThreadLocal кэши
• Долгий GC из-за уймы мелких объектов в хипе
• Причины:
– Lucene использует ThreadLocal кэши для
некоторых объектов
– Jboss Remoting на каждое соединение содает
поток, а их тысячи
• Первое решение:
– Пул для выполнения запросов
• Второе решение:
– Делая другую оптимизацию, убрали эти кэши
11

13. Проблемы: медленные хранимые поля
• Медленная работа с хранимыми полями
• Причина:
– При считывании хранимого поля создается много
мусора и производятся ненужные операции
• Решение:
– Считывать значение в нужный тип сразу из byte[]
• Результат:
– На порядок быстрее стали операции с хранимыми
полями
– Время GC упало в 2 раза
12

14. Распознавание полей
• Поиск пользователей идет по следующим полям:
имя и фамилия, город, страна, интервал возростов
• Друга можно искать, вводя известные данные:
«илья широков 30»
«илья широков москва»
«илья широков 25-30 россия»
Query Line
User Term Term Search
Index Collector Dict. System
Fields Query
13

15. Поиск по возрасту
• Стандартные решения:
– Добавление всех подходящих терминов
– Префиксные термины для снижения количества
терминов в запросе
– Запрос к FieldCache
– Фильтр результатов
• Наше решение:
– Возраст хранится ввиде даты: yyyymmdd
– Запрос по текстовым полям оборачивается в
фильтрующий запрос, который проверяет отбраные
документы по хранимому полю
14

16. Поиск музыки
• В базе есть:
– артисты; альбомы; композиции
– не сортированые музыкальные композиции
• Три точности совпадения:
точное; все слова из запроса; некоторые слова из запроса
• Поиск всегда идет по всем видам документов
• От точности совпадения зависит поведение UI
• На место в выдаче влияет рейтинг документа
• С индекса собираются всевозможные топы
15

17. Индексация музыки
• Все храним в одном индексе
• У каждого документа:
– в id зашит его тип (артист; альбом; композиция; файл)
– тип как отдельное поле
– рейтинг как параметр индексации
– рейтинг как хранимое поле
• Текстовые поля:
– по отдельности
– необходимые комбинации
– 2 представления текста: оригинал + фонетика
16

18. Поиск музыки
• Пробовали:
– Отдельный запросы для каждого типа
– Повторные запросы с меньшей точностью
– Настройка оценщика веса для результата
• Решение:
– Запрос состоит из комбинаций: точность + поле данных
– Для каждой комбинации есть интервал значений весов
– Вес из подзапроса нормализуется в интервал
комбинации
– Если документ отвечает запросу, сразу вычисляем его
тип и добавляем в соответствующий коллектор
17

19. Поисковые сервера
Группы
Пользователи Сообщества
8 серверов 2 сервера
7 000 МБ 600 МБ
20 мс Поисковая 3 мс
1100 з/c 2200 з/c
система
5 серверов
10 000 МБ
90 мс
Музыка 1500 з/c Видео
4 сервера 6 серверов
2700 МБ 400 МБ
50 мс 7 мс
200 з/c 30 з/c
18

20. Спасибо!
Алексей Шевчук
odnoklassniki.ru/aleksey.shevchuk
Разработчик поисковых систем
Одноклассники
hr@odnoklassniki.ru