API пошуку проти пошуку Apache Solr

Я використовував модуль пошуку 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 роки і йому вдалося скористатися своїм конкурентом.

Крім того, API пошуку забезпечує дуже іншу і гнучку архітектуру, і вона підтримується активніше. Що важливіше, він вже підтримує новітні Drupal 8 та Solr 5.x, яких у Apachesolr ще немає.

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

По-друге, щоб уникнути проблем, які спільнота двічі вирішує через відмінності в архітектурі цих модулів, в даний час між цими двома проектами є деякі об'єднані зусилля, такі як:

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

^{Джерело: План бою для пошуку та вирішення проблеми в Drupal 8 в Акквії}

Зауважте, не рекомендується використовувати обидва модулі в одному середовищі.

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

API пошуку

Огляд API:

• Рамка для легкого створення пошукових запитів
• Тези з джерел даних та реалізованих програм
• Велика екосистема з розширеннями, наприклад, мікстури
• Інтеграція API Facet

• Сильно заснована на Entity API

  • Надає метадані
  • Використовується для конфігурацій індексу та сервера

Особливості розширення:

• Автозавершення API пошуку
• Вкладення
• Збережені пошукові запити
• Місцезнаходження
• Досить грані шляхи
• Слайдер (діапазони API пошуку)
• і багато іншого.

Основна структура:

Особливості індексу:

• Різні джерела даних
• Один джерело даних: сутності

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

  • Кожна власність може бути проіндексована
  • Властивості пов'язаних суб'єктів можуть бути проіндексовані

Як налаштувати свій індекс - поля:

Перегляди API пошуку:

• Повна підтримка переглядів
• Відобразити будь-яку власність суб'єкта господарювання
• Використовуйте будь-яке індексоване поле як фільтр, аргумент або сортування
• Більшість кодів заснований на інтеграції поглядів Entity API

• За замовчуванням: дані, отримані за допомогою завантаження сутності

  • Можна обійти (налаштування "Витягнути дані з Solr" на сервері)
• Альтернатива: Сторінки API пошуку

Рецепти пошуку API:

• CRUD гачки для індексів та серверів

• Гачки для додавання

  • джерела даних
  • мікстури
  • зміни даних
  • процесори

• Гак стріляв при індексації предметів

• Гак вистрілив під час пошуку

Апачесолр

Особливості розширення:

• Вкладені файли (відсутність підтримки медіа, спеціальне кодування для вкладених файлів до інших об'єктів)
• Розташування (Apachesolr geo, розташування Apachesolr)

Рецепти Апачесола:

• Платформа пошуку з відкритим кодом для підприємств
• Фонд Apache
• Повнотекстовий пошук, виділення, гранічний пошук, кластеризація, обробка багатим документом
• Поширений
• Реплікація / масштабування
• Java
• REST HTTP та відповіді в XML / JSON та деяких інших
• Не реляційний

Джерело: API пошуку проти слайд-шоу Apachesolr

Дивись також:

• Коли варто використовувати основний модуль пошуку Drupal?
• Які переваги використання Apache Solr над основним модулем пошуку?

Я спробував використовувати обидва, і можу це сказати: це залежить від вашої ситуації.

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

Пошуковий API робить індекси та в ньому написано багато чудових матеріалів. Однак API пошуку вибирає лише ідентифікатор даних, які ви шукаєте. Це означає, що для завантаження будь-яких інших даних, окрім ідентифікатора, знадобиться entit_load, натискання на вашу базу даних або будь-який шар кешування, який ви поставите на місце. Для важких для пошуку сайтів це може бути не найбільш оптимізованим рішенням.

Ось чудова презентація, проведена в drupalcon chicago про модуль інтеграції ApacheSolr, 16 хвилин для згадок про пошуковий API.

Я думаю, що вам справді потрібно спробувати і те, і прийняти зважене рішення. Але врахуйте, що апашсолр все ще не має бета-версії для Drupal 8.

У API пошуку ви не можете комбінувати об'єкти в одному індексі SearchAPI. Тож профілі, користувачі, вузли знаходяться на різних індексах. Є модуль, який дозволяє здійснювати багатоіндексні пошуки, він не охоплював моїх потреб, але YMMV. Якщо у вас є багато типів вмісту і багато полів на одному індексі, визначення індексу може стати досить невмілим. (Звіти NB SearchAPI D8 для підтримки багатопоказного пошуку)

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

Ідея пошуку ідентифікаторів сутності та подальшого рендерингу кожного окремо (може використовуватися обома модулями) могла б виглядати кошмаром продуктивності, але, якщо ви кешуєте відображення вашої сутності, це може бути ефективнішим, ніж виведення з відповіді solr.