Каждый разработчик приложения рано или поздно сталкивается с таким важным вопросом, как выбор поискового движка. Можно сказать, что поисковый движок – это сердце 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), из-за чего практически полностью забыли об администрировании. Надеемся, что наш опыт будет полезным для других разработчиков.