Solr Merging Résultats de 2 noyaux dans Seuls les résultats qui ont un champ correspondant

Question

J'essaie de savoir si ce que je peux accomplir ce qui suit et aucune des réponses que j'ai trouvé semblent si loin pour s'adapter:

I J'ai un ensemble de ressources assez statique et important que j'ai besoin d'indexer et de rechercher. Solr semble être parfait pour cela. De plus, je dois permettre à mes utilisateurs d'ajouter des ressources de l'ensemble de données principal à un dossier «Favoris» (qui peut inclure quelques autres balises ajoutées par eux). Les favoris doivent pouvoir être interrogés de la même manière que l'ensemble de données principal, dans tous les mêmes champs et les champs supplémentaires.

Ma première pensée était d'avoir deux schémas distincts - la première pour l'ensemble de données principal et ses métadonnées - la seconde pour le dossier Favoris avec toutes les métadonnées de l'ensemble principal copié sur, puis en ajoutant les champs supplémentaires . Puis j'ai pensé que cela perdrait probablement un peu d'espace (le nombre d'utilisateurs est beaucoup plus grand que le nombre de ressources principales). Alors j'ai pensé que je pourrais avoir l'ensemble de données principal avec ses métadonnées (Core0), comme ci-dessus avec le resourceId comme identifiant unique. Ensuite, il y aurait un second (Core1) pour le dossier Favoris avec l'identifiant unique du resourceId, userId, grade, dossier tous concaténés. Le resourceId serait aussi un champ séparé. De plus, je créerais un autre schéma/core (Core3) avec tous les champs des deux autres et aurais un gestionnaire de requêtes qui recherche les 2 autres cœurs et retourne les résultats via ce core.

Ce troisième noyau aurait des recherches exécutées contre celui-ci où les résultats ne devraient être renvoyés que pour un seul utilisateur. Par exemple, un utilisateur recherche dans son dossier Favoris tous les éléments avec Foo. Le résultat est uniquement les éléments que l'utilisateur a ajoutés à ses favoris avec Foo quelque part dans les métadonnées de son jeu de données principal. Je suppose que le gestionnaire de résultats de Core3 décomposerait la recherche en recherche de tous les documents avec Foo dans Core0, une recherche sur Core1 pour userId et folder, puis ferait correspondre les resourceIds des deux et éliminerait ceux qui ne sont pas dans les deux. Ou lancez une recherche sur Core1 avec l'userId et le dossier, puis récupérez ce résultat, extrayez tous les resourceIds et ajoutez un AND sur la requête de recherche à Core0 comme: AND (resourceId = 1232232312 OR resourceId = 838388383 OR resourceId = 8637626491) .

Pourrait-on que ça marche? Ou est-il un mécanisme plus simple est Solr pour résoudre la fusion de 2 recherches à travers 2 cœurs et ne renvoie que les résultats qui correspondent sur (pas nécessairement un champ unique) dans les deux?

Merci.

Answer 1

Le problème ressemble à une jointure de base de données de 2 tables avec l'ID de ressource en tant que clé étrangère. Ignorer le message si ce que j'ai compris est faux. D'abord, je vais probablement le faire avec un seul noyau, avec un champ userid (indexé, mais pas stocké), réindexer un document chaque fois qu'un nouvel utilisateur le préfère en ajoutant son identifiant (délimité par quelque chose que l'analyseur ignore) . Donc, la recherche devient plus facile (userId: "l'ID de kaka va chercher tous mes favoris) Je pense qu'il faut du travail pour cela et aussi si le nombre d'utilisateurs qui peuvent aimer un document augmente, le champ utilisateur devient vraiment long.

Donc dans ce cas, je vais passer à ma prochaine idée qui est similaire à la vôtre, avoir un deuxième noyau avec (ID utilisateur, ressource ID) .Écrire un emballage qui recherche d'abord ce noyau pour tous les favoris, puis les recherches un autre noyau pour toutes les ressources dans une condition où, mais encore une fois .. si un utilisateur préfère plus de ressources, la requête pourrait dépasser la limite de taille de la méthode GET ..

Si les deux ne semblent pas fonctionner, il est temps de penser à quelque chose de plus évolutif, ce qui nous laisse la même option de gaspillage d'espace.

Ai-je raté quelque chose ??