Сравнение эффективности поиска: Elasticsearch и конкуренты

Перевод для Хабра, оригинал

В области поисковых систем с открытым исходным кодом появилось несколько новых интересных игроков. Мы решили внимательно изучить некоторые из них, чтобы узнать, насколько они сравнимы с Elasticsearch - как по набору функций, так и по производительности.

Кандидаты

Функциональное сравнение

Функция Elastic RediSearch PostgreSQL TypeSense MeiliSearch
Хранилище Диск RAM + снэпшоты Диск RAM + снэпшоты RAM + снэпшоты
Распределенная работа Мастер-реплика RAFT Мастер-реплика RAFT НЕТ
Репликация + НЕТ + НЕТ НЕТ
Поддерживаемые языки латиница + cjk + кириллица + арабский + еще 10 латиница + арабский, русский, китайский латиница + арабский с пробелами с пробелами + кандзи
Исправление опечаток да, но медленно + НЕТ + +
Бустинг + + + + НЕТ
Точный поиск + + + НЕТ НЕТ
Синонимы + + + + +

Известные ограничения

Elasticsearch: Нестабильность, если в кластере больше ~1000 индексов (или 20 тыс. шардов)

TypeSense: Размер хранилища ограничен доступной оперативной памятью. Источник

Meilisearch: Максимальное количество слов, учитываемых для каждого поискового запроса - 10. Максимальный размер базы данных - 100 ГБ (может быть изменен в конфиге). Максимум 200 индексов. Максимум 1000 слов в одном поле. Источник

Тест

Набор данных: дамп выжимок из английской Википедии enwiki-20210720-abstract.xml Дата: 20 июля 2021 г. Документов: 6,3 млн Размер XML: 6,0 ГБ

Слова запроса выбираются случайным образом из 1000 самых распространенных английских слов.

Конфигурация системы

2 General Purpose / 32 ГБ / 8 vCPU инстанса DigitalOcean (один для генерации нагрузки + один для тестируемой системы).

Полученные результаты

Время индексации

Для индексации мы учитывали только время, которое индексатор потратил на запросы к серверу.

Indexing time

Indexing time

Indexing time

Elasticsearch, PostgreSQL и Typesense показывают здесь очень похожую производительность, в то время как RediSearch примерно в 2 раза медленнее; этот результат странным образом противоречит результатам тестов RedisLabs, так что наши настройки тут могу быть неоптимальны.

В то же время, Meilisearch блещет, будучи почти в 7 раз быстрее остальных.

Тайминги запросов

Query time

Query time

Query time

RediSearch оказался в среднем довольно медленным, и снова RedisLabs получили другие результаты. Еще один неожиданно медленный результат показал запрос из трех слов в Typesense.

Meilisearch показал довольно хорошую производительность, особенно для запросов с префиксами и опечатками.

Мы использовали нули для отображения неподдерживаемых типов запросов на графиках, но если приглядеться, видно, что RediSearch показал результат менее 1 мс (!) для запросов «точная фраза» и «три слова И».

Результаты в числах

Тест Elasticsearch RediSearch PostgreSQL TypeSense MeiliSearch
Индексация
- общее время 268 516 290 272 42
- пропускная способность 23644 12267 21827 23258 150284
Запрос 1 слово 16.14 16.81 69.89 16.04 6.73
Запрос 3 слова И 4.07 0.95 2.61 224.36 11.57
Запрос 3 слова ИЛИ 20.69 45.86 2.48 N/A N/A
Точная фраза 3.16 0.64 9.85 N/A N/A
Автокомплит 7.76 36.98 9.22 6.75 6.18
Опечатка 19.81 58.17 N/A 14.61 5.84

Выводы

Elasticsearch по-прежнему остается королем поиска, он выдает стабильную производительность и для индексирования, и для всех типов запросов.

RediSearch имеет посредственную производительность индексации; также RedisLabs изо всех сил стараются продать свое облачное решение, поэтому документация не на высоте. Но эта система показывает минимальную задержку (менее миллисекунды) для некоторых типов запросов.

PostgreSQL показал странную “яму” производительности для простых запросов из одного слова, и интерфейс поиска довольно сложен. Хотя, если у вас уже есть база данных Postgres, встроенный поиск может быть неплохим решением для простых случаев.

У TypeSense неплохой набор функций, и производительность в целом тоже на высоте, за исключением странного провала при запросах из нескольких слов.

Кажущаяся высокая производительность MeiliSearch была вызвана ориентацией теста только на время ответа при индексировании, но Meili больше других полагается на асинхронную обработку. Мы не смогли провести тест с ожиданием индексации каждой порции данных, т.к. в таком режиме система оказалась мучительно медленной.

Дополнение: результаты Meilisearch и Typesense

Джейсон Боско из Typesense обратился к нам по поводу странных медленных выбросов с запросами из 3 слов и рекомендовал повторно запустить этот тест с параметром drop_tokens_threshold = 1, но мы получили в этом режиме похожие результаты (200+ мс). Мы также попробовали drop_tokens_threshold = 0 (по сути, превратив запрос в “ИЛИ”), это дало более высокую производительность.

То есть, по-видимому, замедление вызвано тем, что мы выбираем 3 случайных английских слова для запроса, и при отсутствии в индексе документов, содержащих все три слова Typesense начинает отбрасывать слова, пока не получает результат, и этот процесс не очень быстр.

Джейсон также отметил, что кажущаяся быстрая индексация Meilisearch на самом деле была вызвана асинхронностью запросов индексации. Мы обновили тест, чтобы он дожидался завершения индексирования каждой порции, но в таком режиме индексация занимает как-то невероятно много времени, так что, видимо, нам нужно повнимательнее изучить, как Meilisearch работает под капотом.

Дополнение для Хабра :)

Раз уж все скрипты были готовы, я в свободное время погонял те же тесты для более экзотических систем.

Sonic

Ужасно медленная индексация. Не дождался окончания теста, хоть он и работал всю ночь.

Toshi

Индексация: 273 док/сек (настройки по умолчанию), 37631 док/сек с использованием недокументированного эндпоинта _bulk для пакетной работы

Запрос 1 слово: 372 з/сек, 2.68 мс Запрос 3 слова: 357 з/сек, 2.79 мс Запрос 3 слова с опечатками: 325 з/сек, 3.07 мс

Неплохие в целом показатели, но для индексации обязательно нужно использовать _bulk.

Quickwit

Индексация (из отдельно подготовленного файла с ndjson): 37085 док/сек

Запрос 1 слово: 324 з/сек, 3.08 мс Запрос 3 слова: 324 з/сек, 3.08 мс ¯_(ツ)_/¯

Неплохие показатели, но для индексации нужно заранее готовить данные.

Groonga

Индексация: 77372 док/сек

Запрос 1 слово: 0.56 з/сек, 1782 мс Запрос 3 слова: 0.50 з/сек, 1982 мс

Очень быстрая индексация, но ОЧЕНЬ медленный поиск.

Дополнение 2

Reindexer:

Индексация - 30664 док/сек (правда, асинхронно)

Query QPS latency 50%% 90%% 99%% 100%%
Single Word 59.08 16.93 ms 14.04 ms 31.24 ms 63.49 ms 246.68 ms
3 Word 41.74 23.96 ms 21.51 ms 38.55 ms 73.75 ms 152.33 ms

Документация выстроена неочевидно для человека со стороны и сильно “заточена” под использование как библиотеки для golang. Также в процессе “поймал” баг, когда невалидный utf-8 на входе прекрасно индексируется, но валится при поиске.

Также, это in-memory storage, т.е. объем данный жестко ограничен размером памяти (на моем тесте процесс потреблял около 9 Гб).

Manticore:

Индексация - 4481 док/сек

Query QPS latency 50%% 90%% 99%% 100%%
Single Word 128.41 7.79 ms 6.52 ms 10.12 ms 23.86 ms 334.15 ms
3 Word AND 313.55 3.19 ms 2.76 ms 3.76 ms 8.36 ms 84.96 ms
3 Word OR 73.05 13.69 ms 9.94 ms 17.78 ms 106.00 ms 274.99 ms
3 Word Phrase 318.31 3.14 ms 2.48 ms 3.25 ms 7.15 ms 90.85 ms

Неплохие показатели по поиску, но скорость индексации оставляет желать лучшего.

comments powered by Disqus