Сравнение эффективности поиска: Elasticsearch и конкуренты
В области поисковых систем с открытым исходным кодом появилось несколько новых интересных игроков. Мы решили внимательно изучить некоторые из них, чтобы узнать, насколько они сравнимы с Elasticsearch - как по набору функций, так и по производительности.
Кандидаты
- Elasticsearch - “взрослая” полнотекстовая поисковая система, основанная на Lucene.
- RediSearch - полнотекстовый поиск поверх Redis от RedisLabs
- Postgres FTS - полнотекстовые индексы для Postgres
- TypeSense - альтернатива Algolia с открытым исходным кодом
- MeiliSearch - альтернатива Algolia с открытым исходным кодом
Функциональное сравнение
| Функция | 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
Elasticsearch, PostgreSQL и Typesense показывают здесь очень похожую производительность, в то время как RediSearch примерно в 2 раза медленнее; этот результат странным образом противоречит результатам тестов RedisLabs, так что наши настройки тут могу быть неоптимальны.
В то же время, Meilisearch блещет, будучи почти в 7 раз быстрее остальных.
Тайминги запросов
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 |
Неплохие показатели по поиску, но скорость индексации оставляет желать лучшего.