9
votes

Indexation de différents types d'entités / objets avec Solr Lucene

Disons que je veux indexer mon magasin en utilisant Solr Lucene.

J'ai de nombreux types d'entités: produits, critiques de produits, articles

Comment puis-je obtenir mon Lucene d'indexer ces types, mais chaque type avec un schéma différent?

php solr lucene search-engine

0 commentaires

4 Réponses :

1
votes

Avec Lucene / Solr, chaque document n'a pas besoin de définir une valeur pour chaque champ. Dans le même schéma, vous pouvez avoir un ensemble de champs pour l'entité A et un autre ensemble de champs pour l'entité B et simplement peupler le champ approprié en fonction de l'entité.

Avec SOLR, vous avez également la possibilité d'aller multi-noyau. Chaque noyau a son propre schéma. Vous pouvez définir un noyau pour chaque entité.

0 commentaires

1
votes

Vous voudrez peut-être avoir 3 index appelés produits, productReviews et articles. Chaque index peut avoir son propre schéma. La différence entre Lucene et une approche relationnelle relationnelle est qu'une ligne d'une dB, grossièrement se traduit par un document à Lucene. Remarque: chaque document peut avoir son propre schéma (qui est une autre différence d'un dB relationnel).

0 commentaires

4
votes

Je recommande de créer votre index de manière à ce que toutes les entités ont plus ou moins les mêmes champs de base: Titre, contenu, URL, UUID, entité_type, entité_sourcename etc. Si chacune de vos entités A un ensemble unique de champ d'index correspondant, vous aurez du mal à construire une requête pour rechercher simultanément toutes les entités et que votre vue sur les résultats peut devenir un énorme désordre. Si vous avez besoin de champs spécifiques pour une entité spécifique, ajoutez-le et effectuez une logique spéciale pour cette entité basée sur son entité_type.
Je parle d'expérience: nous gérons un index avec plus de 10 entités différentes et cette approche fonctionne comme le charme.
P.s. Quelques autres conseils simples.
Assurez-vous que votre document Lucene contient toutes les données nécessaires pour construire le résultat et le montrer à l'utilisateur (afin que vous n'ayez pas besoin d'accéder à la base de données pour construire le résultat). Les requêtes Lucene sont généralement beaucoup plus rapides que les requêtes de base de données. Si vous avez absolument besoin d'utiliser une base de données pour construire votre jeu de résultats (par exemple pour appliquer des autorisations), utilisez la requête Lucene d'abord pour réduire les résultats, la requête de la base de données seconde pour les filtrer. N'ayez pas peur d'ajouter des champs personnalisés à certains de vos documents si vous en avez besoin: Pensez à Lucene Document à la valeur de magasin de données clé.
0 commentaires
2 votes Multi-Core est une approche à utiliser avec soin. Avec un simple schéma comme le vôtre, c'est une meilleure façon de le faire comme Buru Recommander. Cela signifie trouver des champs communs entre vos différentes entités, puis les champs qui ne seront utilisés que par ou plusieurs d'entre eux. Vous pouvez ensuite ajouter un champ "Type" ou "Type_ID" qui dira si votre entité est produit, une critique de produit ... Cela vous permettra d'avoir un index unique et de traiter rapidement les requêtes. 0 commentaires

Articles qui pourrait vous intéresser : Pourquoi est-ce que j'obtiens une erreur laravel lors de la création d'un nouveau projet? Select2 ne s'affiche pas correctement dans le mode bootstrap Laravel Echo n'écoute pas La validation de la demande de formulaire ne fonctionne pas. Il charge juste la page d'accueil dans Postman