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

пользователей онлайн;
В секунду:
250. тыс. страниц, 50мс, 70Гбит/с;
6 тыс. сообщений и комментариев;
1.5 тыс. поисковых запросов.

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

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

best to forget the great sky and to retire from every wind

Under blue sky, in bright sunlight, one need not search around

Tokenizers & Filters & IndexWriter

Index Reader & Searcher & Query parser

дополнительной информации перед индексацией
Возможность анализа готового индекса

на bash-скриптах
http - это дорого и медленно
сложно модифицировать
Но Lucene нас устраивает, поэтому пишем свой сервер

по пользователям
Высокая пропускная способность

()
waitFor (queries complete)
waitAtLeast (result items)

FSDirectory и NIODirectory
RamDrive с FSDirectory и NIODirectory
Lucene RamDirectory
Собственный UnsafeDirectory
Победил:
HeapDirectоry файлы как byte[] в хипе

ThreadLocal кэши для некоторых объектов
Jboss Remoting на каждое соединение содает поток, а их тысячи
Первое решение:
Пул для выполнения запросов
Второе решение:
Делая другую оптимизацию, убрали эти кэши

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

интервал возростов
Друга можно искать, вводя известные данные: «илья широков 30» «илья широков москва» «илья широков 25-30 россия»

Term
Collector

User
Index

Term
Dict.

Search System

Query Line

Fields Query

терминов в запросе
Запрос к FieldCache
Фильтр результатов
Наше решение:
Возраст хранится ввиде даты: yyyymmdd
Запрос по текстовым полям оборачивается в фильтрующий запрос, который проверяет отбраные документы по хранимому полю

все слова из запроса; некоторые слова из запроса
Поиск всегда идет по всем видам документов
От точности совпадения зависит поведение UI
На место в выдаче влияет рейтинг документа
С индекса собираются всевозможные топы

тип (артист; альбом; композиция; файл)
тип как отдельное поле
рейтинг как параметр индексации
рейтинг как хранимое поле
Текстовые поля:
по отдельности
необходимые комбинации
2 представления текста: оригинал + фонетика

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

серверов
400 МБ
7 мс
30 з/c

4 сервера
2700 МБ
50 мс
200 з/c

5 серверов
10 000 МБ
90 мс
1500 з/c

Поисковая
система

Пользователи

Музыка

Группы
Сообщества

Видео