Каждый разработчик приложения рано или поздно сталкивается с таким важным вопросом, как выбор поискового движка. Можно сказать, что поисковый движок – это сердце API и главный элемент системы доступности контента, благодаря ему поиск и фильтрация происходят в разы быстрее, чем в реляционных базах данных.
Такие системы позволяют юзать много полезных функций поиска. К примеру, учитывают морфологию языка, осуществляют фасетный поиск, работают со стоп-словами, а также позволяют настраивать формулы определения релевантности документов.
Но на каком остановиться? В блогах разработчиков нет единого мнения. Мы рассмотрим два популярных, но принципиально разных поисковых движка – Sphinx и Elasticsearch – и объясним, почему сделали выбор в пользу первого при разработке приложения ЯRUS, и к чему это в итоге привело. Но сначала составим портрет каждого движка.
Sphinx – система полнотекстового поиска. Из плюсов – наличие лемматизаторов ru, en, du, большое количество стеммеров индексации и поиска: full-text, фасетный, geo. Нет ничего лишнего, лишь поисковый движок с быстрой индексацией и своим индексером. При правильной конфигурации RT индексов можно достичь real time indexing. В отличие от Elasticsearch наблюдаем умеренное использование памяти.
Что касается минусов, то главный из них – необходимость самому просчитывать всю структуру индексов, а значит, масштабирование проходит не так просто. Также у системы скудный API, нет возможности для визуализации, отсутствует fuzzy-поиск по дефолту (но можно реализовать свой) и скудное community.
Sphinx написан на C++. Им пользуются такие мастодонты, как Habr, Викимапия, Craigslist, поддерживается 1С-Битрикс.
Теперь несколько слов про Elasticsearch. Поисковая система проводит всю индексацию внутри себя, при этом управление индексами через RESTful API. Плюсы ElasticSearch – это фасетный поиск, легкое и мощное API, большое количество стеммеров, гибкая структура индексов и создание индексов постфактум. С техниками поиска тут тоже все хорошо: Full-text search, а также алгоритмы Geo и Fuzzy.
В Elasticsearch тоже много готовых реализованных модулей для ES, есть возможность хранить данные, Real Time индексация, достаточно легко масштабируется, ETL-механизмы, и что немаловажно – обширное community. Elasticsearch написан на Java и используется в Wikimedia, Mozilla, SoundCloud, GitHub и других площадках.
Что касается минусов Elasticsearch, то в их числе отсутствие своего индексера (необходимо реализовать свой или logstash в ELK), съедает много памяти, а лемматизаторы русского текста ставятся отдельно плагином.
Если бы нас попросили описать Sphinx и Elasticsearch одним выражением, то первую систему поиска мы бы охарактеризовали словами «быстрая индексация», а вторую – «мощный API».
При разработке приложения ЯRUS мы отдали предпочтение Sphinx. Требования к поиску были ниже, а поисковый движок подкупил прозрачной настройкой индексов в виде конфигурационных файлов и быстротой индексации. Но в последнее время мы задумываемся о смене Sphinx на Elasticsearch. Объясним, почему.
Сейчас запрос в API по поиску проходит в несколько этапов: сначала идет запрос в поисковый движок, после полученный результат поискового движка обогащается данными из баз данных. Нам бы хотелось перестать дергать БД (использовать лишь как холодное хранилище) и отдавать готовый модели напрямую из поискового движка. Elasticsearch (как мы уже писали ранее в плюсах) может в Data storage, поэтому ничего не мешает хранить нужные поля в Elastic.
Кроме того, объемы данных в приложении растут, а управление поиском на Sphinx через конфигурационные файлы усложняется (необходимо самому думать о шардах и репликах, на каждую ноду раскидывать свой конфиг), поэтому необходимо упростить управление поиском (отдать все управление данными и индексами сервису). Кроме того, для нас необходима Near Real Time индексация из коробки.
Что касается преимуществ, то мы отгородили разработчиков от сложного управления конфигурациями индексов like Sphinx, а также использовали облачное решение (MCS), из-за чего практически полностью забыли об администрировании. Надеемся, что наш опыт будет полезным для других разработчиков.
Создавая eventscanner. ru, мы выбрали Lucene. Это то, что внутри
elasticsearch.
Мы хотим получить чуть больше, чем просто голую библиотеку, чтобы работать уже со всем готовым. Если задачи бизнеса изменятся и нужно будет лезть в ядро движка, тогда будем отталкиваться от новых требований.
Большинство разработчиков sphinxengine ушла несколько лет назад в форкнутый проект manticore search и активно его развивает.
Manticore нам не очень подходит. Слишком много возни при создании кластера, так как при добавлении новых нод нужно обновлять все конфиги или заранее просчитывать, сколько записей для шарда положить в одну ноду, где-то хранить эту схему шардирования и репликации. Для Elastic нам достаточно добавить новые ноды и подключить их к существующему кластеру без обновления всех конфигов. Кроме того, Elastic предоставляется облачным решением, благодаря которому можно разгрузить разработчиков, отдав всю работу по настройке железных нод с готовым движком на сторону.
Melisearch модный и современный
Да, но Elastic надежнее и проверен временем. Нет уверенности, что MeiliSearch лучше справится с нашим объемом.