Эта статья суммирует части релевантного поиска . Используйте код скидки turnbullmu, чтобы получить скидку 38%!
Solr против Elasticsearch! Там было тонна постов. Но кто-нибудь когда-либо сравнивал их, когда дело доходит до традиционных — вы знаете — контроля обычных результатов поиска?
В своей работе я провожу много времени, помогая людям улучшить релевантность результатов поиска Solr / Elasticsearch (я пишу книгу на эту тему!). В этой первой серии статей я хочу помочь вам увидеть лес за деревьями, когда дело доходит до выбора между этими двумя технологиями для традиционных задач поиска. Проблемы, при которых вам может понадобиться настроить релевантность результатов для ваших нужд. Честно говоря, вам, вероятно, нужно сделать это, даже если вы не думаете, что делаете. Все стремятся к этой строке поиска, собирается ли ваш поиск «получить» их или просто вернуть случайный набор из 10 результатов?
В любом случае, оценка Solr против Elasticsearch с точки зрения релевантности сводится к сравнению их по трем критериям:
- Возможность контроля соответствия — какие результаты можно сказать, чтобы соответствовать / не соответствовать поиску?
- Способность контролировать ранжирование — какие результаты наиболее актуальны в пределах набора совпадающих результатов?
- Возможность создавать плагины — насколько глубоко вы можете манипулировать сопоставлением / ранжированием результатов за пределами API?
В этой статье блога я собираюсь начать с пункта 1: сравнение того, как эти поисковые системы позволяют вам управлять соответствием.
Больше похожих, чем разных
Прежде чем мы начнем погружаться, важно отметить, что Solr и Elasticsearch во многом похожи, а не различны. Обе поисковые системы дают вам огромное количество возможностей управлять релевантностью поиска на очень фундаментальном уровне. Будучи поисковыми системами с открытым исходным кодом, основанными на Lucene, они находятся в стороне от коммерческих предложений «черного ящика», которые ограничивают возможности настройки релевантности. Они оба поддерживают чрезвычайно широкий спектр вариантов использования: от традиционного поиска на основе документов до гео-ориентированного поиска по графику, и так далее. Оба предоставляют DSL с расширенными запросами и DSL для анализа текста, которые позволяют жестко контролировать процесс сопоставления и ранжирования. Вот почему вы можете почти полностью применить нашу книгу « Релевантный поиск» к любой поисковой системе!
При этом, хотя основные функции одинаковы, эргономика и API могут сделать ваше поисковое решение простым или сложным! Давайте погрузимся в сопоставление, чтобы увидеть, как одна поисковая система делает управление сопоставлением довольно простым, а другая требует более глубокого мышления и инженерной работы.
Solr против Elasticsearch, контролирующий соответствие
Управление соответствием сводится к тонкой настройке преобразования текста в отдельные токены. Поисковая система рассматривает токены как фундаментальную атомарную сущность, которая должна точно сравниваться для объявления «совпадения». Вам нужен процесс нормализации, чтобы получить токены из поиска, чтобы соответствовать токенам из документа. Например, поиск всех заглавных букв «CAT» не будет соответствовать заглавным буквам «cat» без соответствующих шагов манипулирования текстом для строчных букв обеих сторон. Менее глупый пример — решить, следует ли вам рассматривать «котенка» как синоним «кота». Должен ли поисковый термин «котенок» быть нормирован на «кот»? Когда вы думаете обо всех формах английских слов (бег, бег,побежал?) вы можете видеть, насколько важен этот процесс нормализации для точного решения, когда сопоставлять, а когда — нет.
Эта задача нормализации контролируется вами с помощью функции, известной как анализ ( как мы уже обсуждали ). Анализ управляет процессом манипулирования текстом из документов / поисков преобразуется в токены. Искусство релевантности поиска часто сводится к контролю этого процесса, чтобы тщательно различать совпадения / несоответствия.
И Solr, и Elasticsearch поддерживают базовую библиотеку анализаторов Lucene. Эргономика создания анализатора отличается лишь поверхностно. Solr (до недавнего времени) рекомендует вам работать в файле конфигурации XML (schema.xml) для управления этим процессом. Elasticsearch, с другой стороны, предоставляет вам RESTful JSON API для выполнения той же работы.
Обе поисковые системы предоставляют вам одни и те же ингредиенты для работы по созданию анализаторов. Вы управляете исходным потоком символов через несколько фильтров символов . Вы разбиваете поток символов на токены, используя токенизатор . Наконец, вы применяете настраиваемую последовательность фильтров токенов, чтобы обрезать, склеивать, удалять, генерировать и иным образом манипулировать токенами.
Чтобы жестко контролировать этот процесс, помимо анализа содержимого, размещенного в поисковой системе, и Solr, и Elasticsearch позволяют указать отдельный анализатор запросов. Напомним, анализаторы запросов преобразуют строку поиска в токены, чтобы контролировать их соответствие токенам, сгенерированным из текста, помещенного в индекс. Это хорошо, например, если вы хотите расширить свой поиск, включив в него список дополнительных синонимов для поиска в дополнение к исходному поисковому запросу.
Однако у Solr есть два серьезных недостатка в анализе запросов. Самый большой источник душевной боли — это так называемая проблема морского печенья . Короче говоря, синтаксический анализатор запросов Solr разбивает текст по пробелам, а затем передает его анализатору времени запроса. Так что если у вас есть правило синонимов, которое сопоставляет фразу «морское печенье» с одним словом «морское печенье», это не сработает!
Причина в том, что каждый термин запроса, разделенный пробелами, анализируется отдельно, не обращая внимания на оставшийся текст в строке запроса. Анализатор времени запроса принимает в качестве входных данных одно слово [sea]. Фильтр синонимов не видит [biscuit]следующий токен . Проблема не ограничивается только синонимами, она затрагивает любой процесс, который должен манипулировать более чем одним токеном одновременно. Это может быть довольно ограничивающим и удивительным при попытке контролировать процесс сопоставления. Очередь грустный тромбон.
Эта проблема постоянно является источником неожиданностей, ошибок актуальности и обсуждения в группах пользователей. Такое поведение удивляет даже пользователей со средним уровнем квалификации. Ситуация не совсем безнадежна. Для этой проблемы существует множество плагинов Solr . Solr также дает вам много возможностей, чтобы написать практически любой плагин, чтобы глубоко контролировать это самостоятельно. Не все, однако, хотят выяснить чей-либо плагин или иметь дело с написанием Java.
Другая проблема Solr заключается в том, что он позволяет управлять анализатором на стороне запроса только в конфигурации поля. Elasticsearch позволяет вам управлять анализатором на любом уровне, включая передачу анализатора для использования при выполнении самого запроса! Варианты Elasticsearch довольно широки .
At search time, the sequence is slightly different:
* The analyzer defined in the query itself, else
* The analyzer defined in the field mapping, else
* The default analyzer for the type, which defaults to
* The analyzer named default in the index settings, which defaults to
* The analyzer named default at node level, which defaults to
* The standard analyzer
Это очень удобно. Скажем, например, вы бы хотели иногда запрашивать одно поле, используя синонимы, а другой — без синонимов. Elasticsearch позволяет запрашивать одно и то же поле различными способами, просто передавая analyzerаргумент с запросом. Иногда вы можете передать анализатор синонимов, в других случаях вы можете просто использовать значение по умолчанию. Solr, с другой стороны, попросил бы вас скопировать содержимое в другое поле, чтобы выбрать другой анализатор запросов.
В заключение, Elasticsearch — явный победитель, когда дело доходит до соответствия. Elasticsearch дает вам наименьшее количество сюрпризов и большую глубину конфигурируемости, когда дело доходит до манипулирования соответствием. Вы можете сделать довольно много, не прибегая к написанию плагинов.
Победитель:
В следующий раз! Рейтинг!
В следующий раз мы обсудим соответствие API запросов Solr и Elasticsearch. Будет ли Elasticsearch доминировать и здесь? Для завершения трилогии мы также сравним, насколько подключаема каждая поисковая система. Какая поисковая система победит? ?
И, конечно же, если вам нужна помощь в сложной проблеме поиска, не стесняйтесь обращаться к нам !