API поиска против Apache Solr Search

Я использовал модуль поиска Apache Solr в Drupal 6 и смотрю на API поиска для установки Drupal 7. Я видел некоторое обсуждение здесь, но я ищу какие-либо причины для выбора одного или другого.

Есть ли причина выбирать один над другим? Если так, то почему или нет? Я слышал, что могут быть проблемы со сложностью и / или проблемы с производительностью API поиска. Это правда?

С 2015 года мы можем сравнивать API поиска с модулями поиска Apache Solr по номерам:

                   | Apache Solr Search  | Search API
Posted in:         | 2007                | 2010
Downloads:         | >2k                 | >20k
Reported installs: | >21k                | >64k
Total bugs:        | >1200               | >600
Active bugs:       | >200                | >170
Commits:           | >1.3k               | >1.5k

что указывает на четкий выбор. API поиска был разработан спустя 3 года, и ему удалось воспользоваться преимуществами своего конкурента.

Более того, Search API предоставляет совершенно другую и более гибкую архитектуру и поддерживается более активно. Что еще более важно, он уже поддерживает новейшие Drupal 8 и Solr 5.x, которых у Apachesolr пока нет.

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

Во-вторых, чтобы избежать некоторых проблем, решаемых сообществом дважды из-за различий в архитектуре этих модулей, в настоящее время предпринимаются некоторые совместные усилия между этими двумя проектами, такие как:

• создание общего способа отображения блоков фасетов через Facet API (также известный как фильтры),
• общая схема и файлы конфигурации solrconfig.xml,
• оба сопровождающих работали вместе и перенесли классы соединений из модуля поиска Apache Solr в API поиска.

^{Источник: Battleplan for Search & Solr в Drupal 8 в Acquia}

Обратите внимание, что не рекомендуется использовать оба модуля в одной среде.

Для дальнейшего технического анализа различий, пожалуйста, проверьте детали ниже.

API поиска

Обзор API:

• Фреймворк для удобного создания поисковых запросов
• Тезисы из источников данных и внутренних реализаций
• Большая экосистема с расширениями, например, бэкэндами
• Интеграция Facet API

• Основано на Entity API

  • Предоставляет метаданные
  • Используется для конфигурации индекса и сервера

Особенности расширения:

• Автозаполнение API поиска
• Вложения
• Сохраненные поиски
• Место расположения
• Симпатичные Пути Граней
• Слайдер (диапазоны API поиска)
• и многое другое.

Базовая структура:

Особенности индекса:

• Различные источники данных
• Один источник данных: сущности

• На основе Entity API:

  • Каждое свойство может быть проиндексировано
  • Свойства связанных объектов могут быть проиндексированы

Как настроить свой индекс - поля:

Search API Views:

• Полная поддержка просмотров
• Показать любое свойство объекта
• Используйте любое индексированное поле в качестве фильтра, аргумента или сортировки
• Большая часть кода основана на интеграции представлений Entity API

• По умолчанию: данные, полученные с помощью загрузки объекта

  • Можно обойти (настройка «Извлекать данные из Solr» на сервере)
• Альтернатива: поиск страниц API

Поиск рецептов API:

• CRUD-хуки для индексов и серверов

• Крючки для добавления

  • источники данных
  • бэкэнды
  • изменения данных
  • процессоры

• Крюк срабатывает при индексации предметов

• Крюк срабатывает при выполнении поиска

Apachesolr

Особенности расширения:

• Вложения (без поддержки мультимедиа, пользовательское кодирование для вложений в другие объекты)
• Расположение (Apachesolr Geo, расположение Apachesolr)

Рецепты Apachesolr:

• Корпоративная поисковая платформа с открытым исходным кодом
• Apache Foundation
• Полнотекстовый поиск, выделение, граненый поиск, кластеризация, расширенная обработка документов
• распределенный
• Репликация / масштабируемые
• Джава
• REST HTTP и ответы в XML / JSON и некоторые другие
• Не реляционный

Источник: Search API против Apachesolr слайд-шоу

Смотрите также:

• Когда стоит использовать основной поисковый модуль Drupal?
• Каковы преимущества использования Apache Solr по сравнению с модулем основного поиска?

Я пытался использовать оба, и я могу сказать следующее: это зависит от вашей ситуации.

В настоящее время стабильная версия 7 модуля интеграции ApacheSolr может индексировать только узлы. Поэтому, если у вас есть неузловые сущности, которые вам нужно проиндексировать, вы должны использовать для этого многозадачный патч, который еще не завершен . При правильной настройке ApacheSolr Integration может хранить много разных данных контента.

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

Вот отличная презентация на drupalcon chicago о модуле интеграции ApacheSolr, минута 16 для упоминания в Search API.

Я думаю, что вы действительно должны попробовать оба и принять обоснованное решение. Но учтите, что у apachesolr до сих пор нет бета-версии для Drupal 8.

В API поиска вы не можете объединять объекты в одном индексе SearchAPI. Так что Профили, Пользователи, Узлы находятся на разных индексах. Есть модуль, позволяющий выполнять многоиндексный поиск, он не покрывал мои потребности, но YMMV. Если у вас много типов контента и много полей в одном индексе, определение индекса может стать довольно громоздким. (NB SearchAPI D8 отчеты для поддержки многоиндексного поиска)

Apachesolr позволяет редактировать поля для каждого контента, что может быть проще, но не имеет возможности добавлять связанный контент в документ, фактически нужно написать собственный код для включения информации из коллекций полей, ссылок и некоторых других поля. Apachesolr D7 не поддерживает ajax, если вы не используете представления, но при использовании представлений вы теряете фасеты. Тем не менее, изменение информации, хранящейся в индексе, довольно легко, если вы довольны кодированием в хуках.

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