Комментарии 22
А почему в тесте нет сфинкса/мантикоры? Довольно часто ведь используется
... и Яндекс.Сервера тоже нет. Пусть и не поддерживается он уже давно, но местами всё ещё используется.
Докеризованный есть где-нибудь? Не смог нагуглить
К сожалению он не доступен в докеризированном виде. Но я могу загрузить эти пакеты на файлообменник и сбросить вам ссылку, если пожелаете.
Yandex_Server-2010.9.0-Linux-i686.deb
Yandex_Server-2010.9.0-Linux-i686.rpm
Yandex_Server-2010.9.0-Linux-x86_64.deb
Yandex_Server-2010.9.0-Linux-x86_64.rpm
Yandex_Server-2010.9.0-Windows-i386.exe
Yandex_Server-2010.9.0-Windows-x86_64.exe
Сюда из лички скопирую, вдруг кому пригодится:
Посмотрел, в итоге решил не ковырять глубоко: софт давно не поддерживается, лицензия распространять не разрешает, и какого-то внешнего API, который бы подошел для докеризации, я не нашел.
Вот нашел на хабре статью, где человек с русским индексом работает.
Я всегда считал что эффективность в случае поисковых движков должна быть двух-компонентной: перформанс собственно хранения, индексирования и выборки данных (скажем "техническая" производительность) и качество результатов поиска ("софтовая" производительность - как быстро человек может найти искомый ресурс).
И если мне не изменяет память, что Lucene, что Sphinx (который раньше на Хабре был) хорошо работают с одним поисковым термом. Но когда дело доходит до фраз - хоть выборка происходит моментально, субъективно результаты преимущественно бесполезные.
Любопытно, почему насколько редко люди делятся как раз таки второй метрикой.
Вы правильно заметили, что вторая метрика - субъективна отчасти. Собственно, я неоднократно слышал от коллег недовольство современными поисковиками, которые "додумывают" за пользователя, что же он имел в виду, а для кейса "тупо найти максимально близкое совпадение" нужно использовать язык запросов, да и на тот иной раз система плюёт. Поэтому я, например, пользуюсь Searx с пачкой кастомных "колдунщиков", но я также понимаю, что мой кейс - очень маргинальный.
Т.е. чтобы сделать такую метрику, нужно сначала составить несколько сот эталонных пар "запрос - результаты", причем, для нескольких для разных "персон". По-моему, это тема для немаленького исследовательского проекта.
З.Ы. Кстати, тот же Elasticsearch, хоть и работает поверх Lucene, но даёт гораздо лучшие результаты. Если правильно составить запрос, конечно же :)
Очень интересно было бы еще увидеть в сравнении https://github.com/Restream/reindexer
Странная статья. Где описание методологии? Сделали непонятно что, получили какие-то результаты - толку от них кому-то?
(ниже акцент на Postgres, т.к. с ним я хорошо знаком, но сами вопросы, думаю, актуальны для более-менее всех движков)
Версии ПО? (ссылка на postgres fts в англ версии ведет на доки от 9.5, что наводит на подозрения)
Как конфигурировали? Конкретно по postgres: основные параметры postgresql.conf? Какого типа индексы (gist/gin)? Конфигурация FTS?
(вообще, некоторые утверждения ваши вызывают недоумение, например, про поддержку языков: вы точно отличаете языки от кодировок? Вы же дочитали в документации postgres до раздела про словари FTS?)Запросы - код, плз. Какие именно ключевые слова использовались и в каком количестве? Надеюсь, хотя бы одинаковые для всех движков? Запросы выдают хотя бы примерно одинаковый результат? Ранжирование было?
Техническая достоверность: БД в память помещается? прогревали кеш? запросы one term / 3 term OR - с одними ключевиками (очень большие сомнения конкретно для postgres вызывают именно эти результаты - хотелось бы видеть конкретику)?
Статистическая достоверность - сколько раз прогоняли? дисперсия какая?
Оценка результатов поиска (выше уже про качество писали, но хотя бы количественно - если один нашел 100 документов, а другой 10000 по одному и тому же запросу - сравнивать как-то некорректно).
Postgres - 13, Эластик - 7.14, Typesense - 0.21, meilisearch - 0.21, redisearch - 2.0.11
Настройки по умолчанию у всех, индекс у постгрес - GIN.
Для запросов слова рандомно выбирались из списка (в т.ч. потому, что задача была оценить только производительность, а не "качество" поиска).
Данные помещаются в память, да. Кэш не грели, слова для запросов каждый раз брали рандомом, обычно по 1000 запросов (если они работали слишком медленно - уменьшали до 100).
Для показа юзеру что 1000, что 100000 документов это одинаковое количество - "слишком много", поэтому для оценки качества нужны таки промаркированные запросы.
В целом, к Postgres у меня одна главная претензия в рамках этого теста: его нужно "уметь готовить", когда тот же Elastic в принципе выдаст достойные результаты без конфигурирования вовсе.
Для показа юзеру что 1000, что 100000 документов это одинаковое количество - "слишком много", поэтому для оценки качества нужны таки промаркированные запросы.
Лимиты делали?
Кэш не грели, слова для запросов каждый раз брали рандомом, обычно по 1000 запросов (если они работали слишком медленно - уменьшали до 100)
можно все-таки дисперсию или min-max время увидеть?
И попробуйте на каком-то одном списке тестировать все движки (а то мало ли, вдруг кто-то не стал парсить xml и названия тегов стали словами, причем супер частыми, и такое слово попалось в запросе).
Так и не смог понять как выполнялся тест. Единственное что сказано "Слова запроса выбираются случайным образом из 1000 самых распространенных английских слов."
Но в этом датасете поиск по слову 'and' дает 1.3М статей. И что с этим делать? Показать первые 20? или все? или сделать по ним count()? Это все влияет на летенси.
У вас есть ссылка на репозитарий с тестами? Или это закрытый код?
Спасибо за статью, вот еще очень интересно как будут обстоять дела с изменением данных. На сколько я знаю в PostgreSql - это достаточно дорогая операция. Если наши данные часто подвержены изменением наверное используя PostgreSql можно столкнутся с трудностями.
Я знаю, что Эластик очень плохо работает с изменениями. Во-первых, на низком уровне там хранилище append-only, т.е. при изменении любого поля записывается новый документ целиком. Во-вторых, из-за этого данные оказываются фрагментированы, а дефрагментация aka merge - очень дорогой процесс.
Про прочих кандидатов - не знаю.
Сравнение эффективности поиска: Elasticsearch и конкуренты