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?

À 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:

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:

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:

• Quand vaut-il la peine d'utiliser le module de recherche Drupal?
• Quels sont les avantages d'utiliser Apache Solr sur le module de recherche principal?

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.

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.