Поисковая машина

Чтобы реализовать на сайте интернет-магазина или каталога товаров/услуг полноценные интерактивные навигационные интерфейсы, средства персонализации и адаптивной навигации, функции поиска или сложные выборки данных, нужен источник данных, возможность выполнять поиск (выборку) по нему и возможность осуществлять обработку и анализ полученных данных (для формирования пользовательских интерфейсов, сортировки результатов и т.п.). В e-commerce системах источником данных, как правило, выступает реляционная СУБД из числа тех, что упомянуты в разделе Организация данных и выбор СУБД. Все эти СУБД имеют собственные встроенные возможности поиска (обычные и полнотекстовые индексы, конструкции WHERE в SQL). Однако некоторые виды поиска и сортировки могут быть слишком затратными и сложными для базы данных, а связанные с ними SQL-операторы будут выполняться слишком медленно. Это становится особенно заметным при попытке реализации любых решений на основе BigData (персонализация, предсказательная навигация, целевые предложения в реальном времени и т.п.), при увеличении посещаемости и объема каталога, по которому производится поиск (выборка).

Для ускорения поиска применяются различные приемы – изменение структуры таблиц, оптимизация индексов и пр. Но все эти способы пригодны только до определенного предела, который, даже с учетом высокой производительности используемого оборудования, на действительно крупных и популярных e-commerce площадках перекрывается многократно. Поэтому все платформы enterprise-класса (да и почти все остальные) предлагают использование специализированной поисковой машины, которая реализует механизм глубокой индексации и быстрого поиска (выборки) данных на основе специализированных индексов. 

Разработка собственной высокопроизводительной и надежной поисковой машины – весьма непростое занятие. К ней предъявляется много специфических требований в части функциональности и масштабируемости. Так что даже некоторые компании «большой тройки» вынуждены предлагать «чужие» продукты в составе своей e-commerce платформы (полноценное собственное решение есть только у Oracle).

В целом на рынке получили распространение следующие поисковые машины:

• Oracle Endeca Commerce – является очень многофункциональным продуктом, обеспечивая не только поиск, но и интерактивные интерфейсы для фасетной навигации, персонализованные инструменты маркетинга. Endeca разрабатывалась с 1999 года компанией из Кембриджа (США), а в 2011 году эту компанию поглотила корпорация Oracle. Endeca является несомненным лидером среди рассматриваемых поисковых машин и используется большинством крупнейших мировых ретейлеров. Во избежание путаницы следует отличать Endeca Commerce от другого продукта компании Oracle – Endeca Information Discovery, который построен на таком же ядре, но предназначен для использования в качестве инструмента бизнес-аналитики (BI).
• Apache Solr – бесплатная система с открытым исходным кодом, разрабатываемая Apache Software Foundation. Создана на базе популярной Lucene search engine, впервые получившей известность в 1999г. Именно Apache Solr предпочитают использовать в качестве основы для поисковых модулей в составе своих e-commerce платформ такие компании, как IBM и SAP.
• Sphinx – бесплатная система с открытым исходным кодом, разрабатывается компанией Sphinx Technologies Inc. Впервые Sphinx был выпущен в 2001 году как дополнение к MySQL. В настоящее время система развилась и поддерживает разные СУБД и языки программирования, однако, именно сязку MySQL-PHP можно считать основой, вокруг которой идут доработки.
• ElasticSearch – бесплатная система с открытым исходным кодом, разрабатываемая компанией ElasticSearch BV. Первая версия ElasticSearch была опубликована в 2010 году.  Так же, как и Apache Solr, эта система создана на базе Lucene search engine. По своим параметрам и пользовательским характеристикам ElasticSearch превосходит Apache Solr и в последнее время составляет ему серьезную конкуренцию.

Из этого ряда следует особо отметить Oracle Endeca Commerce (входит в состав платформы Oracle Commerce, но может использоваться и отдельно в интеграции с другими платформами). Этот продукт не только является полноценной широко масштабируемой поисковой машиной, но и содержит ряд функций, которые, по сути, нацелены на автоматизацию различных бизнес-процессов электронного (и обычного) ретейла. В первую очередь, это функции управления цифровым маркетингом с возможностями обычной и предсказательной персонализации. Также Oracle Endeca Commerce содержит все необходимое для быстрого построения интерактивных навигационных интерфейсов с фасетной или иерархической навигацией и интегрированными поисковыми возможностями.

Для остальных из рассматриваемых поисковых машин характерна ориентация на решение узких задач поиска, и они не содержат внутри себя каких-то средств для построения навигационных интерфейсов или визуализации маркетинговых предложений. Так что на них правильнее смотреть как на один из «кирпичиков», с которыми имеют дело разработчики при конструировании сложных систем. А вот Endeca – это уже, скорее, «набор» или «конструктор», на базе которого можно построить e-commerce систему даже целиком (хотя тут следует понимать, что в этом наборе нет таких, не менее важных для крупной площадки, функций, как управление ценами или репозиториями товаров).

Поисковые машины в составе разных e-commerce платформ

¹ IBM WebSphere Commerce содержит в своем составе модуль WebSphere Commerce search. Этот модуль работает поверх поисковой машины Apache Solr, интегрируется с другими компонентами Websphere Commerce и поддерживает ряд API, которые могут использовать разработчики e-commerce систем.

² SAP hybris содержит в своем составе hybris Search and Navigation Module. Этот модуль работает поверх поисковой машины Apache Solr, интегрируется с другими компонентами SAP hybris и позволяет реализовать интерактивные интерфейсы фасетного поиска и навигации.

³ Платформы «нижнего» уровня не содержат в своем составе встроенного поискового модуля, непосредственно интегрирующего какую-либо поисковую машину. Но для них существует достаточно большой выбор платных и бесплатных расширений, которые позволяют интегрировать разные поисковые машины. 

Наличие встроенного решения принципиально упрощает внедрение любой поисковой машины при ее совместном использовании с e-commerce платформой. Это, впрочем, не значит, что с этой же платформой нельзя использовать и другие поисковые машины. К примеру, Oracle Endeca Commerce довольно часто используется и в паре с IBM WebSphere Commerce, и в паре с SAP hybris, и даже с Magento. В целом можно заметить, что разработчики разных e-commerce платформ тяготеют к тем решениям, для которых уже есть готовые библиотеки с открытым исходным кодом. Так для Solr существуют Solrj (Java-клиент) и Solarium (PHP-клиент). А вот для Shinx нет качественной и активно развиваемой Java-библиотеки, поэтому его использование обычно ограничивается PHP-платформами.

У каждой поисковой машины есть свои требования к инфраструктуре развертывания. Учитывая тот факт, что при определенных сценариях использования именно на поисковую машину может лечь основная вычислительная нагрузка, сама эта инфраструктура может оказаться больше и дороже всего остального, что потребовалось для развертывания e-commerce системы. И тут, для выработки правильного архитектурного решения следует понимать, что есть два основных компонента поисковой системы, нагрузку на которые нужно оценивать индивидуально:

• подсистема подготовки и генерации индексов (indexer, indexing engine);
• подсистема исполнения запросов (query processor, search engine, ...).

Подсистема подготовки и генерации индексов отвечает за выборку информации из определенных источников данных, ее правильную компоновку и построение индексов, которые затем будут использованы подсистемой исполнения запросов. Для этой подсистемы основное значение имеет сам состав источников данных, их объем и частота обновления. Чем больше данных, чем чаще они меняются (подлежат индексации/переиндексации), тем выше нагрузка на подсистему и выше требования к используемому оборудованию.

Для систем с большими объемами данных и сложными связями между ними при проектировании данного звена важно не только обеспечить надлежащие характеристики оборудования, но и грамотно сконфигурировать сами параметры доступа к данным и состав генерируемых индексов. Ошибка в структуре индексов может повлиять на общую производительность системы настолько сильно, что все прочие усилия можно будет считать пустыми и никчемными.

Разные поисковые машины в этом звене предлагают довольно сильно отличающиеся подходы и имеют разные характеристики. Так, для Oracle Endeca Commerce в качестве источников данных могут выступать как разнообразные базы данных, так и любые другие структурированные или неструктурированные данные из файлов различного формата, http-источников, различных CMS и систем управления документооборотом. Выборку и подготовку данных к индексации можно возложить на специальный модуль CAS (Content Acquisition System), входящий в состав Endeca. В других поисковых машинах нет специального отдельного модуля выборки и подготовки данных, но, к примеру, в составе IBM WebSphere Commerce Search реализована специальная утилита для предварительного импорта данных прямо в таблицы СУБД, откуда их впоследствии извлекает модуль Solr Data Import Handler (DIH).

На практике в звене выборки, подготовки и индексации данных присутствует множество критичных участков, ради которых при внедрении даже приходится дописывать кастомизированные модули. Такие модули могут обеспечивать импорт данных из специфических систем или форматов, а также иметь возможности мультипроцессорной и мультипотоковой (multithreaded) обработки данных, что не всегда и не во всех конфигурациях и версиях есть у штатных компонентов поисковых машин (о какой бы машине ни шла речь).

Еще одним важнейшим параметром индексатора выступает возможность частичного обновления индексов без их полной перестройки. При большом объеме данных и их частом обновлении отсутствие такой функции в принципе делает невозможной нормальную эксплуатацию поисковой машины, т.к. система просто не будет успевать перестраивать полные индексы с надлежащей частотой. А вот такая функция есть только в Endeca. В других же системах приходится либо решать проблему «в лоб», перестраивая индексы целиком, либо просто исключать часто изменяемые данные из индексации.

Подсистема исполнения запросов отвечает собственно за сам поиск по индексам. Именно с этой подсистемой взаимодействует приложение, которое отвечает за отображение данных на страницах e-commerce сайта. И чем больше пользователей посещает сайт и использует на нем функцию поиска, тем больше запросов получает данная подсистема, и тем выше требования к используемому ей оборудованию.

В архитектуре Oracle Endeca Commerce соответствующий компонент носит название MDEX engine. Это отдельный сервис, который может инсталлироваться на выделенные или разделяемые сервера под разными операционными системами, поддерживаемыми платформой Oracle Commerce. Причем, в состав решения может входить несколько MDEX-серверов, если производительность одного сервера оказывается недостаточной или требуется повышенная надежность и непрерывность функционирования системы.

Похожим образом можно масштабировать и другие поисковые машины, но стоит только иметь ввиду, что в ряде случаев возможны только конфигурации типа Master-Slave, в которых запросы пользователей обрабатывают только Slave-машины, а Master выполняет балансировку нагрузки и маршрутизацию.

Как уже отмечалось выше, характеристики встроенной поисковой машины значительно влияют на характеристики всей e-commerce платформы. И речь идет не только об архитектурных особенностях и требованиях к оборудованию. В ряде случаев разные поисковые машины отличаются и своей функциональностью. То есть сами функциональные возможности всей e-commerce платформы в чем-то определяются функциональными возможностями поисковой машины. В качестве примера можно привести поддержку разных языков, стемминг или ранжирование результатов поиска.