57 votes

Utiliser l'index de recherche Solr comme base de données - est-ce "mal" ?

Mon équipe travaille avec un CMS tiers qui utilise Solr comme index de recherche. J'ai remarqué qu'il semble que les auteurs utilisent Solr comme une sorte de base de données dans la mesure où chaque document renvoyé contient deux champs :

  1. L'identifiant du document Solr (essentiellement un nom de classe et un identifiant de base de données).
  2. Une représentation XML de l'objet entier

En gros, il effectue une recherche dans Solr, télécharge la représentation XML de l'objet, puis instancie l'objet à partir du XML plutôt que de le rechercher dans la base de données à l'aide de l'identifiant.

Mon intuition me dit que c'est une mauvaise pratique. Solr est un index de recherche, pas une base de données... Il me semble donc plus logique d'exécuter nos recherches complexes dans Solr, d'obtenir les identifiants des documents, puis d'extraire les lignes correspondantes de la base de données.

L'implémentation actuelle est-elle parfaitement saine, ou existe-t-il des données permettant d'étayer l'idée qu'il est temps de la remanier ?

EDITAR: Quand je dis "représentation XML", je veux dire un champ stocké qui contient une chaîne XML de toutes les propriétés de l'objet, et non plusieurs champs stockés.

1 votes

Juste par curiosité, de quel CMS s'agit-il ?

0voto

ksl Points 1

J'ai eu une idée similaire, dans mon cas pour stocker quelques données json simples dans Solr, en utilisant Solr comme une base de données. Cependant, une GROSSE réserve m'a fait changer d'avis : le processus de mise à niveau de Solr.

Veuillez consulter https://issues.apache.org/jira/browse/LUCENE-9127 .

Apparemment, il y avait dans le passé (avant la v6) la recommandation de réindexer les documents après les mises à jour majeures de la version (et pas seulement d'utiliser IndexUpdater) bien que vous ne deviez pas le faire pour maintenir la fonctionnalité (je ne peux pas en témoigner moi-même, c'est ce que j'ai lu). Maintenant, après avoir mis à jour 2 versions majeures mais sans réindexer (en fait, en supprimant complètement les documents puis les fichiers d'index eux-mêmes) après la première mise à jour majeure, votre noyau n'est plus reconnu.

Dans mon cas précis, j'ai commencé avec Solr v6. Après la mise à niveau vers la v7, j'ai exécuté IndexUpdater, de sorte que l'index est maintenant à la v7. Après la mise à niveau vers la v8, le noyau ne se chargeait pas. Je n'avais aucune idée de la raison : mon index était à la version 7, ce qui répondait à la déclaration de compatibilité version moins 1 de Solr, non ? Eh bien, non, c'est faux.

J'ai fait une expérience. Je suis reparti de la v6.6, j'ai créé un noyau et ajouté quelques documents. J'ai fait une mise à jour vers la version 7.7.3 et j'ai lancé IndexUpdater, de sorte que l'index de ce noyau est maintenant en version 7.7.3. J'ai effectué une mise à jour vers la version 8.6.0, après quoi le noyau ne s'est pas chargé. J'ai ensuite répété les mêmes étapes, sauf qu'après avoir exécuté IndexUpdater, j'ai également réindexé les documents. Même problème. Ensuite, j'ai à nouveau tout répété, sauf que je n'ai pas simplement réindexé, j'ai supprimé les documents de l'index et supprimé les fichiers d'index, puis j'ai réindexé. Maintenant, quand je suis arrivé dans la v8.6.0, mon noyau était là et tout était OK.

Ainsi, le point à retenir pour le PO ou toute autre personne envisageant cette idée (utilisation de Solr comme base de données) est que vous devez vous attendre à réindexer vos documents/données de temps en temps, ce qui signifie que vous devez les stocker ailleurs de toute façon (un poster précédent a fait allusion à cette idée), ce qui va à l'encontre du concept de base de données. À moins, bien sûr, que votre noyau/index Solr soit de courte durée (il ne durera pas plus d'une mise à jour majeure de Solr), que vous n'ayez jamais l'intention de mettre à jour Solr de plus d'une version, ou que les développeurs de Solr modifient cette limitation de mise à jour. Ainsi, en tant qu'index pour des données stockées ailleurs (et facilement disponibles pour une réindexation si nécessaire), Solr est excellent. En tant que base de données pour les données elles-mêmes, cela dépend fortement.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X