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


34

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

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


Я бы не предложил solr для многоязычного поиска. Зависит от того, насколько важен многоязычный поиск. Поиск может быть очень трудоемким. Установка может быть болезненной. Для многоязычного поиска ваш язык должен поддерживаться Solr. Есть грамматические правила, которые должны быть установлены для вашего языка. Также вам нужно установить Java и Solr, чтобы вы не могли использовать дешевый виртуальный хостинг. Если вы разрабатываете поисковую систему, вы можете использовать ее. Если вы рассчитываете ресурсы разработки, то поиск Payd на сайте Google может быть лучшим вариантом! Я даже являюсь со-сопровождающим для gss modulep
ram4nd

Почему это? Какие-нибудь критерии?
giorgio79

Извините, установка может быть болезненной. Для многоязычного поиска ваш язык должен поддерживаться Solr. Есть грамматические правила, которые должны быть установлены для вашего языка. Также, когда я посмотрел на него, модули находились в состоянии разработки и нуждались в дополнительной работе, чтобы все заработало. Но это самый быстрый поисковик. Поэтому вы должны спросить себя, насколько важна для вас функция поиска. Также вам нужно установить Java и Solr, чтобы вы не могли использовать дешевый виртуальный хостинг.
ram4nd

Одна из вещей, которые мне приходилось использовать в Apache Solr по сравнению с Search API, - это поиск с несколькими фильтрами. С API поиска это казалось невозможным. Солр, казалось, имел эту возможность.
user219492

Я хотел бы упомянуть поддержку нескольких сайтов: SearchAPI не поддерживает несколько сайтов (используя один и тот же индекс SOLR для хранения содержимого нескольких сайтов). Вместо этого Apachesolr позволяет: 1. индексировать несколько содержаний в одном и том же индексе SOLR 2. фильтровать результаты по определенному сайту 3. выполнять поиск только на локальном сайте, отфильтровывая результаты с других сайтов
thePanz

Ответы:


19

С 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 поиска)
  • и многое другое.

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

Базовая структура модуля поиска API Solr

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

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

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

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

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

Search API Views:

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

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

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

  • CRUD-хуки для индексов и серверов
  • Крючки для добавления

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

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

Apachesolr

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

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

Рецепты Apachesolr:

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

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


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


Потрясающая статья, спасибо! Вопрос 1: почему не рекомендуется использовать оба модуля в одной среде? Вопрос 2: На данный момент различия в производительности между модулями незначительны (насколько я понимаю, API поиска с / solr теперь может индексировать несколько полей, поэтому загрузка объекта больше не требуется для отображения, например, миниатюрного изображения с результатами поиска)?
Джордан Магнусон

@JordanMagnuson 1. Вы не используете оба модуля одновременно, потому что они не очень совместимы, и большинство сайтов имеют дело только с одним экземпляром поиска Solr, поэтому нет смысла использовать оба, если только вы не против дублировать работу. Например, когда вам нужно создать какое-то поисковое представление, оба модуля предлагают отдельную интеграцию с модулем представлений, поэтому вам нужно создать два представления.
Кенорб

@JordanMagnuson 2. Я не уверен в производительности, у меня никогда не было какой-либо конкретной, и, вероятно, она меняет каждую версию (я использовал Apachesolr довольно давно). Если вы используете представления и аспекты, вы обычно используете механизм кэширования представлений, поэтому вам не нужно много времени для обработки и, конечно, memcached, APC / XCache и т. Д. Производительность действительно зависит от структуры сайта и от того, как модули взаимодействуют друг с другом. Другие.
Кенорб

Забавно, что API поиска более используется, но сама Acquia рекомендует использовать модуль Apache Solr docs.acquia.com/acquia-search/search-api#animated
AlxVallejo

@AlxVallejo Я думаю, что они рекомендуют его для производства, потому что у них есть стабильные и хорошо написанные конфигурационные файлы Apachesolr для поддержки их экземпляров Acquia Cloud (совместно используемых) Solr (это единственная причина, я думаю) и учитывая, что API поиска активно находился в состоянии разработки, таким образом, связанный с этим риск включал необходимость частого обновления конфигурационных файлов. Они также порекомендовали его нашему (большому) проекту, но после короткого перебора и проверки наших требований мы изменили их рекомендацию на Search API. У них не было стабильных конфигурационных файлов, однако мы предоставили свои собственные.
Кенорб

24

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

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

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

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


потрясающий обзор. именно то, что я хотел знать. Благодарность!
hross

Если вы успешно ответили на ваш вопрос, можете ли вы отметить его как ответ? Благодарность!
LSU_JBob

1
Для тех из вас, кто интересуется, многопрофильность теперь входит в ветку разработки Apache Solr интеграции, поэтому она должна быть в следующей бета-версии.
LSU_JBob

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

1
Этот ответ устарел, посмотрите на drupal.org/node/1999392 search_api_solr теперь имеет многоузловые опции, а также позволяет возвращать не только NID. Массовый рост инсталляционной базы search_api_solr в 2014 году обогнал использование Apacheolr D7.
Дунканмоо

2

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.