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

Question

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.

Answer 1

Oui, vous pouvez utiliser le SOLR comme base de données, mais il y a de sérieuses réserves à ce sujet :

1. Le modèle d'accès le plus courant de SOLR, qui passe par http, ne répond pas particulièrement bien aux requêtes par lots. En outre, SOLR ne diffuse PAS de données en continu --- il n'est donc pas possible de parcourir paresseusement des millions d'enregistrements à la fois. Cela signifie que vous devez être très attentif lorsque vous concevez des modèles d'accès aux données à grande échelle avec le SOLR.

2. Bien que les performances de SOLR évoluent horizontalement (plus de machines, plus de cœurs, etc.) ainsi que verticalement (plus de RAM, meilleures machines, etc.), ses capacités d'interrogation sont très limitées par rapport à celles d'un SGBDR mature. . Cela dit, il existe d'excellentes fonctions, comme les requêtes de statistiques sur les champs, qui sont très pratiques.

3. Les développeurs qui ont l'habitude d'utiliser des bases de données relationnelles rencontrent souvent des problèmes lorsqu'ils utilisent les mêmes modèles de conception DAO dans un paradigme SOLR, en raison de la manière dont SOLR utilise les filtres dans les requêtes. Il y aura une courbe d'apprentissage pour développer la bonne approche pour construire une application qui utilise SOLR pour une partie de ses grandes requêtes ou de ses modifications d'état. .

4. Les outils "d'entreprise" qui permettent de la gestion avancée des sessions et des entités étatiques que proposent de nombreux cadres Web avancés (Ruby, Hibernate, ...) devra être complètement abandonnée. .

5. Les bases de données relationnelles sont conçues pour traiter des données et des relations complexes - et elles sont donc accompagnées de métriques de pointe et d'outils d'analyse automatisés. En SOLR, je me suis retrouvé à écrire de tels outils et à effectuer manuellement de nombreux tests de résistance, ce qui peut représenter un véritable gouffre à étranglement. .

6. Adhésion : c'est le gros problème. Les bases de données relationnelles supportent des méthodes pour construire et optimiser des vues et des requêtes qui joignent des tuples basés sur des prédicats simples. Dans le SOLR, il n'existe pas de méthodes robustes pour joindre des données entre indices.

7. Résilience : pour la haute disponibilité, SolrCloud utilise un système de fichiers distribué en dessous (c'est-à-dire HCFS). Ce modèle est très différent de celui d'une base de données relationnelle, qui assure généralement la résilience en utilisant des esclaves et des maîtres, ou RAID, etc. Vous devez donc être prêt à fournir l'infrastructure de résilience requise par SOLR si vous voulez qu'il soit évolutif et résistant dans le nuage.

Cela dit, il y a beaucoup d'avantages évidents à SOLR pour certaines tâches : (cf. http://wiki.apache.org/solr/WhyUseSolr ) - les requêtes en vrac sont beaucoup plus faciles à exécuter et renvoient des résultats significatifs. L'indexation est effectuée par défaut, de sorte que la plupart des requêtes arbitraires s'exécutent assez efficacement (contrairement à un SGBDR, où il faut souvent optimiser et dé-normaliser après coup).

Conclusion : Même si vous pouvez utiliser SOLR comme SGBDR, vous constaterez (comme je l'ai fait) qu'en fin de compte, il n'y a pas de "repas gratuit" - et que les économies réalisées grâce aux recherches de texte lucene super cool et à l'indexation en mémoire haute performance sont souvent payées par un manque de flexibilité et l'adoption de nouveaux flux d'accès aux données.

Answer 2

Il est parfaitement raisonnable d'utiliser Solr comme une base de données, en fonction de votre application. En fait, c'est à peu près ce que guardian.co.uk fait .

C'est définitivement no une mauvaise pratique en soi. C'est seulement mauvais si vous l'utilisez de la mauvaise façon, comme n'importe quel autre outil à n'importe quel niveau, même les GOTO.

Quand vous dites "Une représentation XML..." Je suppose que vous parlez d'avoir plusieurs champs Solr stockés et de les récupérer en utilisant le format XML de Solr, et pas seulement un grand champ de contenu XML (ce qui serait une utilisation terrible de Solr). Le fait que Solr utilise le format XML comme format de réponse par défaut n'est pas pertinent. protocole binaire Il est donc tout à fait comparable aux bases de données relationnelles traditionnelles à cet égard.

En définitive, tout dépend des besoins de votre application. Solr es est avant tout un moteur de recherche de texte, mais il peut également faire office de base de données NoSQL pour de nombreuses applications.

Answer 3

Cela a probablement été fait pour des raisons de performance, si cela ne pose pas de problème, je laisserais faire. Il y a une grande zone grise entre ce qui devrait être dans une base de données traditionnelle et un index Solr. J'ai vu des gens faire des choses similaires (généralement des paires clé-valeur ou du json au lieu du xml) pour la présentation de l'interface utilisateur et ne récupérer le véritable objet de la base de données que si nécessaire pour les mises à jour/suppressions. Mais toutes les lectures vont simplement à Solr.

Answer 4

J'ai vu des choses similaires faites parce que cela permet une recherche très rapide. Nous déplaçons les données de nos index Lucene vers un magasin clé-valeur rapide afin de respecter les principes DRY et de réduire la taille de l'index. Il n'y a pas de règle absolue pour ce genre de choses.

Answer 5

Pour compléter la réponse de @Jayunit100, en utilisant le solaire comme base de données, vous obtenez la disponibilité et la tolérance de partition au prix d'une certaine cohérence. Il y aura un décalage configurable entre ce que vous écrivez et le moment où vous pouvez le relire.