- PVSM.RU - https://www.pvsm.ru -
В рамках этой статьи я поделюсь опытом использования Elastic Search во внутренних продуктах 2ГИС, в частности, в собственной системе для организации Call-центра. А также расскажу, какие проблемы мы смогли решить, используя этот поисковый движок.
В недрах 2ГИС есть проект InfoRussia, с помощью которого операторы звонят и сверяют карточки организаций. В базе хранится 13 млн. карточек с данными об организациях России, общий размер которых более 150 ГБ. Данные хранятся в реляционной базе, частично разложенные в таблицы, частично — в xml-полях.
Список проблем и задач, которые требовалось решить:
1. Искать по большому количеству критериев.
2. Добавлять информацию в индекс без полной переиндексации.
3. Выгружать данные без блокировки таблиц.
4. Снизить нагрузки на базу, убрать большие join по таблицам.
5. Поддерживать мультиязычный поиск без серьезных инвестиций в разработку.
Проанализировав доступные решения, мы выбрали Elastic, так как он удовлетворял большинству требований.
Исходя из аналитики, требования были следующие.
Основные кандидаты на роль поискового движка — ElasticSearch, Solr и Sphinx.
Solr не подошел потому, что при онлайн-индексации, скорость поиска сильно падает (подробнее можно узнать из статьи [1]). Картинка ниже иллюстрирует данный факт. Кроме того, можно ознакомиться со статьей [2], которая разбирает Solr vs ElasticSearch в деталях.
Следующий кандидат, которого мы рассматривали — Sphinx. ElasticSearch выиграл за счет поддержки шардинга, репликации, возможности составлять сложные запросы и вытягивать из поиска оригинальные данные.
Первый же прототип, который был сделан для поиска на базе ES, оказался настолько хорош, что сразу же переехал в боевое приложение и живет там до сих пор.
Когда проект только начинался, в ES еще не было механизма River, поэтому мы написали свой job для переиндексации базы.
Сервис берет данные об измененных сущностях и складывает их в индекс ES, пока не обработает всю очередь. Для быстрой загрузки можно применить следующие оптимизации:
1. Использовать bulk операции.
2. Установить параметр refresh_interval в -1.
Этот параметр отвечает за время внутренней переиндексации в ES. После того, как все данные загружены в поиск, необходимо вернуть значение по умолчанию. При использовании данного метода, всё, что мы загружаем, не будет анализироваться и, соответственно, не будет доступно для поиска, пока не произойдет внутренняя переиндексация.
Поиск в нашем проекте индексируется онлайн, за раз мы индексируем 100 карточек.
После того как данные оказались в индексе, мы можем по ним искать.
Задачи, которые требуют быстрого поиска по различным параметрам мы решаем с использованием Elastic Search.
Например, имея 13 млн. карточек в базе, нужно просмотреть все телефоны карточки и найти такой же телефон (в нашей схеме данных телефоны хранятся внутри xml поля). Такой запрос к MS SQL базе занимает до 10-15 минут. Elastic Search справляется с этой задачей за несколько миллисекунд.
Итак, основные кейсы, которые мы решили с помощью Elastic Search:
При заведении новой карточки в здании, оператор видит, какие еще есть организации в этом здании, и может сверить информацию по организациям, которые находятся рядом.
Бывает и так, что по одному телефону можно сверить несколько организаций, поэтому мы показываем, какие еще карточки имеют такой же контакт.
Помимо всего прочего, в приложении есть форма поиска, которая позволяет искать по огромному количеству критериев. Данная форма используется для планирования выверки организаций, контроля качества и т.д.
В каждой вкладке еще по 4–5 параметров для запроса к поисковому движку.
Строить индексы в реляционной базе по такому количеству полей — довольно расточительно, поэтому Elastic помог нам в решении этой проблемы.
Одним из бизнес-кейсов приложения, является поддержка выгрузки данных в Excel. Выгрузки используются различными специалистами для анализа качества собранных данных, планирования работы специалистов по сбору информации.
Для выгрузки данных из поиска в Excel мы так же используем ES. Это очень удобно, так как Elastic поддерживает специальный режим для выборки данных — Scroll.
Режим Scroll позволяет «зафиксировать» результаты запроса к поиску и получать эти результаты небольшими порциями.
У данного режима есть ряд ограничений. Например, нельзя сортировать данные (на самом деле, можно, но с падением производительности и расходом памяти).
Наши испытания показали, что всю базу 2ГИС мы можем выгрузить в Excel-файл за сутки.
При организации выгрузок такого большого объема, большое значение имеет наличие всех необходимых данных в хранилище. Таким образом мы используем Elastic как NoSQL хранилище, в котором данные, необходимые только для выгрузки, хранятся в неиндексируемых полях.
На скриншоте видно, что в индексе лежат денормализованные данные, мы храним id города и его название вместе с карточкой.
Кроме того, можно сделать вложенные сущности, например, время работы и рубрики в которых размещается организация.
Должен отметить этот пункт отдельно. Не так давно, 2ГИС запустил несколько международных проектов. Для поддержки Праги [3], Лимасола [4], Падуи [5] нам не потребовалось дорабатывать поисковые запросы. Мы просто загрузили карточки в индекс и поиск сам заработал.
Недавно мы немного доработали запросы, для поддержки поиска с учетом диакритик, но, фактически, это встроенная функция Elastic.
Elastic поддерживает как шардинг, так и установку нескольких нод в кластер. Сейчас у нас собран кластер из двух нод, которые обслуживают 300 человек онлайн.
За 2 года эксплуатации проблемы с поисковой машиной случались только из-за падения виртуальных машин или иных проблем с инфраструктурой. Как и любой поисковый движок, Elastic любит хорошие диски и оперативную память, поэтому рекомендуется при проведении нагрузочного тестирования обратить особое внимание на эти параметры.
Elastic Search полностью соответствует нашим требованиям к поисковому движку и позволил в кратчайшие сроки реализовать важную бизнес-фичу. Надежность, скорость и простота использования — вот те слагаемые, комбинация которых позволила нам сделать выбор в его сторону. Безусловно, есть и другие решения на рынке, обзор которых находится за рамками этой статьи. Целью статьи было показать какие задачи в бизнес-приложениях можно закрыть с помощью бесплатного Elastic Search.
Учитывая наш позитивный опыт применения Elastic, другие внутренние команды начали использовать этот поисковый движок у себя в проектах.
Автор: DeManiaC
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/news/55842
Ссылки в тексте:
[1] статьи: http://blog.socialcast.com/realtime-search-solr-vs-elasticsearch/
[2] статьей: http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/
[3] Праги: http://2gis.cz/?utm_source=news&utm_medium=habr&utm_campaign=post_elastic
[4] Лимасола: http://www.2gis.com.cy/#!/limassol/?utm_source=news&utm_medium=habr&utm_campaign=post_elastic
[5] Падуи: http://maps.2gis.it/#!/padova/?utm_source=news&utm_medium=habr&utm_campaign=post_elastic
[6] Источник: http://habrahabr.ru/post/213765/
Нажмите здесь для печати.