Apache Solr Search API de recherche

J'utilise le module Apache Solr Search dans Drupal 6 et je regarde l' API de recherche pour une installation de Drupal 7. J'ai vu des discussions ici mais je cherche des raisons de choisir l'une ou l'autre.

Y a-t-il une raison de choisir l'un par rapport à l'autre? Si oui, pourquoi ou pourquoi pas? J'ai entendu dire que des problèmes de complexité et / ou de performances pouvaient survenir avec l'API de recherche. Est-ce vrai?

— hross
source

Je ne suggérerais pas solr pour la recherche multilingue. Cela dépend de l'importance de la recherche en plusieurs langues. La recherche peut prendre beaucoup de temps. La configuration peut être douloureuse. Pour une recherche multilingue, votre langue doit être prise en charge par solr. Des règles grammaticales doivent être définies pour votre langue. Aussi, vous devez installer java et solr afin que vous ne puissiez pas utiliser l'hébergement mutualisé bon marché. Si vous développez un moteur de recherche, vous voudrez peut-être l'utiliser. Si vous calculez les ressources de développement, la recherche de site Payd sur Google pourrait être une meilleure option! Je suis même un co-responsable de gss modulep

— ram4nd

Pourquoi donc? Des repères?

— giorgio79

Ou je suis désolé, je pense que la configuration peut être pénible. Pour une recherche multilingue, votre langue doit être prise en charge par solr. Des règles grammaticales doivent être définies pour votre langue. De plus, lorsque je me suis renseigné sur les modules, ils étaient dans l’état de développement et avaient besoin de plus de travail pour que les choses fonctionnent. Mais c'est le moteur de recherche le plus rapide. Vous devez donc vous demander quelle est l'importance de la fonction de recherche pour vous. Aussi, vous devez installer java et solr afin que vous ne puissiez pas utiliser l'hébergement mutualisé bon marché.

— ram4nd

Une des choses que je devais faire venir à Apache Solr par rapport à l'API de recherche était le fait d'avoir une recherche de filtre à sélection multiple. Avec Search API, cela semblait impossible. Solr semblait avoir cette option.

— user219492

Je mentionnerais le support multi-site: SearchAPI n’a pas de support multi-site (utilisant le même index SOLR pour stocker le contenu de plusieurs sites). Apachesolr permet à la place de: 1. indexer plusieurs contenus de sites dans le même index SOLR 2. filtrer les résultats en fonction d'un site particulier 3. effectuer une recherche uniquement sur le site local en filtrant les résultats d'autres sites

— thePanz

Réponses:

À partir de 2015, nous pouvons comparer les modules de recherche de l'API de recherche avec Apache Solr avec les chiffres suivants:

                   | 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

qui indique le choix clair. L'API de recherche a été développée trois ans après et a réussi à tirer parti de son concurrent.

De plus, l'API de recherche fournit une architecture très différente et plus flexible, qui est maintenue plus activement. Plus important encore, il prend déjà en charge les versions les plus récentes de Drupal 8 et de Solr 5.x qu'Apachesolr n’a pas encore.

L'API de recherche a commencé à neuf et sa configuration est plus souple, notamment avec le support de Views (pour Apachesolr, vous avez besoin du module supplémentaire). Il existe également de nombreux modules qui étendent ses fonctionnalités.

Deuxièmement, pour éviter que la communauté ne résolve deux fois les problèmes liés à l’architecture différente de ces modules, il existe actuellement des efforts combinés entre ces deux projets, tels que:

créer le moyen courant d'afficher les blocs de facettes via l' API de facette (également appelés filtres),
un schéma commun et des fichiers de configuration solrconfig.xml,
les deux responsables ont travaillé ensemble et ont migré les classes de connexion du module Apache Solr Search vers l'API de recherche.

^{Source: Plan de bataille de Search & Solr dans Drupal 8 chez Acquia}

Notez qu'il n'est pas conseillé d'utiliser les deux modules dans le même environnement.

Pour une analyse technique plus poussée des différences, veuillez vérifier les détails ci-dessous.

API de recherche

Vue d'ensemble de l'API:

Cadre pour créer facilement des recherches
Résumés de sources de données et d'implémentations dorsales
Grand écosystème avec des extensions, par exemple des backends
Intégration API de facettes
Fortement basé sur l'entité API
- Fournit des métadonnées
- Utilisé pour les configurations d'index et de serveur

Caractéristiques d'extension:

API de recherche de saisie semi-automatique
Les pièces jointes
Recherches sauvegardées
Emplacement
Jolis chemins de facettes
Curseur (plages d'API de recherche)
et beaucoup plus.

Structure basique:

Structure de base du module Search API Solr

Caractéristiques d'index:

Différentes sources de données
Une source de données: entités
Basé sur l'entité API:
- Chaque propriété peut être indexée
- Les propriétés des entités associées peuvent être indexées

Comment configurer votre index - champs:

Comment configurer votre index - champs dans Search API Solr

API de recherche:

Prise en charge de Full Views
Afficher une propriété d'une entité
Utilisez n'importe quel champ indexé comme filtre, argument ou tri
La plupart du code basé sur l'intégration des vues de l'API Entity
Par défaut: données récupérées via le chargement d'une entité
- Peut être ignoré (paramètre "Extraire les données de Solr" sur le serveur)
Alternative: pages API de recherche

Recettes API de recherche:

Crochets CRUD pour les index et les serveurs
Crochets pour ajouter
- source d'information
- backends
- altérations de données
- processeurs
Crochet déclenché lors de l'indexation d'éléments
Crochet tiré lors de l'exécution d'une recherche

Apachesolr

Caractéristiques d'extension:

Pièces jointes (pas de support multimédia, codage personnalisé pour les pièces jointes à d'autres entités)
Localisation (Apachesolr geo, Apachesolr location)

Recettes Apachesolr:

Plateforme Open Source Enterprise Search
Fondation Apache
Recherche en texte intégral, surbrillance, recherche par facettes, mise en cluster, gestion de documents enrichis
Distribué
Réplication / évolutive
Java
REST HTTP et réponses dans XML / JSON et quelques autres
Non relationnel

Source: Search API vs Apachesolr diaporama

Voir également:

— Kenorb
source

Superbe rédaction, merci! Question 1: pourquoi est-il conseillé de ne pas utiliser les deux modules dans le même environnement? Question 2: Les différences de performances entre les modules sont-elles négligeables à ce stade (je comprends que l'API de recherche avec solr puisse désormais indexer plusieurs champs, de sorte qu'un chargement d'entité n'est plus nécessaire pour afficher, par exemple, une image miniature avec les résultats de la recherche)?

— Jordan Magnuson

@ JordanMagnuson 1. Vous n'utilisez pas les deux modules en même temps, car ils sont peu compatibles et que la plupart des sites Web ne traitent qu'avec une seule instance de recherche Solr. Il n'est donc pas logique de les utiliser, sauf si vous ne me dérange pas de dupliquer le travail. Par exemple, lorsque vous devez créer une vue de recherche, les deux modules offrent une intégration séparée avec le module de vues. Vous devez donc créer deux vues.

— Kenorb

@JordanMagnuson 2. Je ne suis pas sûr des performances, je n'en ai jamais eu de particulier et cela change probablement toutes les versions (j'utilisais Apachesolr il y a très longtemps). Si vous utilisez des vues et des facettes, vous utilisez généralement le mécanisme de cache de vues, de sorte que le temps de traitement ne vous préoccupe pas beaucoup et bien sûr, memcached, APC / XCache, etc. Les performances dépendent vraiment de la structure du site et de la façon dont les modules interagissent. autre.

— Kenorb

C'est drôle que l'API de recherche soit plus utilisée, mais Acquia recommande d'utiliser le module Apache Solr. Docs.acquia.com/acquia-search/search-api#animated

— AlxVallejo

@AlxVallejo, je pense qu'ils le recommandent pour la production, car ils ont des fichiers de configuration Apachesolr stables et bien écrits pour prendre en charge leurs instances Solqu Acquia Cloud (partagées) (c'est la seule raison pour laquelle je suppose) et étant donné que l'API de recherche était activement à l'état de développement, donc le risque impliqué incluait que les fichiers de configuration devraient être mis à jour plus souvent. Ils l'ont également recommandé pour notre (grand) projet, mais après une courte période de vérification et de vérification de nos exigences, nous avons changé leur recommandation en API de recherche. Ils n'avaient pas de fichiers de configuration stables, mais nous avons fourni les nôtres.

— Kenorb

J'ai essayé d'utiliser les deux et je peux dire ceci: cela dépend de votre situation.

Actuellement, la version 7 stable du module d’intégration ApacheSolr ne peut indexer que des nœuds. Par conséquent, si vous devez indexer des entités autres que des nœuds, vous devez utiliser le correctif de multicritité toujours en cours . ApacheSolr Integration peut stocker beaucoup de données différentes de contenu lorsqu'il est configuré correctement.

L'API de recherche indexe les entités et contient beaucoup de choses merveilleuses. Cependant, l'API de recherche ne récupère que l'id des données que vous recherchez. Cela signifie que charger plus de données que l'ID nécessitera un entity_load, frappant votre base de données ou n'importe quelle couche de mise en cache que vous avez mise en place. Pour les sites de recherche lourds, cette solution n'est peut-être pas la plus optimisée.

Voici une excellente présentation donnée à drupalcon chicago sur le module d’intégration ApacheSolr, minute 16 pour les mentions relatives à l’API de recherche.

— LSU_JBob
source

aperçu génial. exactement ce que je voulais savoir. Merci!

— hross

Si cela répond à votre question, pouvez-vous la signaler? Merci!

— LSU_JBob

Pour ceux d'entre vous qui se demandent, la multientité est maintenant dans la branche dev de l'intégration d'Apache Solr, elle devrait donc sortir avec la prochaine version bêta.

— LSU_JBob

Pour ceux qui liront ce fil de discussion. Un des facteurs atténuant les performances est que l’API de recherche autorise l’indexation et la récupération des données de nœud. Il y a une discussion de performance ici .

— hross

Cette réponse est obsolète, consultez drupal.org/node/1999392 search_api_solr a maintenant des options multisites, permet également de retourner non seulement le NID. Croissance massive de la base d'installation de search_api_solr en 2014, dépassant l'utilisation de Apachesolr en D7.

— Duncanmoo

Je pense que vous devez vraiment essayer les deux et prendre une décision éclairée. Mais considérez fortement qu’apachesolr n’a toujours pas de version bêta pour Drupal 8.

Dans l'API de recherche, vous ne pouvez pas combiner des entités sur le même index SearchAPI. Ainsi, les profils, les utilisateurs, les nœuds sont sur des index différents. Il y a un module pour permettre les recherches multi-index, il ne couvrait pas mes besoins, mais YMMV. Si vous avez plusieurs types de contenu et plusieurs champs sur le même index, la définition de l'index peut devenir assez lourde. (NB: les rapports SearchAPI D8 prennent en charge la recherche multi-index)

Apachesolr permet l'édition de champs sur une base de contenu, ce qui peut être plus facile, mais n'a pas la possibilité d'ajouter du contenu associé à un document. En fait, vous devez vous attendre à devoir écrire du code personnalisé pour inclure des informations provenant de collections de champs, de références et autres. des champs. Apachesolr D7 ne supporte pas ajax, sauf si vous utilisez des vues, mais si vous utilisez des vues, vous perdez des facettes. Cela dit ... il est assez facile de modifier les informations stockées dans l'index si vous voulez coder avec des points d'ancrage.

L'idée de rechercher des identifiants d'entité, puis de les rendre individuellement (peut être utilisée par les deux modules) semblerait être un cauchemar de performances, mais si vous mettez en cache les affichages de vos entités, cela pourrait bien être plus efficace que de le faire à partir de la réponse de solr.

— dmcg
source