Utilisation de l'index de recherche Solr comme base de données - est-ce "faux"?
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:
- L'ID du document Solr (essentiellement un nom de classe et un identifiant de base de données)
- Une représentation XML de l'objet entier
Donc, fondamentalement, il exécute une recherche contre 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 en utilisant l'ID.
Mon instinct me dit que c'est une mauvaise pratique. Solr est un index de recherche, pas une base de données ... il est donc plus logique pour moi d'exécuter nos recherches complexes contre 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 solide, ou existe-t-il des données pour soutenir l'idée que cela est mûr pour une refactorisation?
EDIT: 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, pas plusieurs champs stockés.
Oui, vous pouvez utiliser SOLR comme base de données mais il y a quelques mises en garde très sérieuses:
Le modèle d'accès le plus courant de SOLR, qui est sur http, ne répond pas particulièrement bien aux requêtes par lots. De plus, SOLR ne diffuse PAS de données --- vous ne pouvez donc pas parcourir par millions des millions d'enregistrements à la fois. Cela signifie que vous devez être très réfléchi lorsque vous concevez des modèles d'accès aux données à grande échelle avec SOLR.
Bien que les performances SOLR évoluent horizontalement (plus de machines, plus de cœurs, etc.) ainsi que verticalement (plus de RAM, de meilleures machines, etc.), ses capacités d'interrogation sont sévèrement limitées par rapport à celles d'un SGBDR mature . Cela dit, il existe d'excellentes fonctions, comme les requêtes de statistiques sur le terrain, qui sont assez pratiques.
Les développeurs habitués à 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 façon 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 des modifications d'état .
Les outils "entreprenants" qui permettent la gestion de session avancée et les entités étatiques qu'offrent de nombreux frameworks web avancés (Ruby, Hibernate, ...) devront être complètement jetés par la fenêtre .
Les bases de données relationnelles sont conçues pour traiter des données et des relations complexes - et sont donc accompagnées de métriques de pointe et d'outils d'analyse automatisés. Dans SOLR, je me suis retrouvé à écrire de tels outils et à tester manuellement beaucoup de stress, ce qui peut être un puits de temps .
Rejoindre: c'est le grand tueur. Les bases de données relationnelles prennent en charge les méthodes de création et d'optimisation des vues et des requêtes qui joignent des tuples en fonction de prédicats simples. Dans SOLR, il n'y a pas de méthode robuste pour joindre des données à travers des indices.
Résilience: pour une haute disponibilité, SolrCloud utilise un système de fichiers distribué en dessous (c'est-à-dire HCFS). Ce modèle est assez différent de celui d'une base de données relationnelle, qui fait généralement de la résilience à l'aide d'esclaves et de maîtres, ou RAID, etc. Vous devez donc être prêt à fournir l'infrastructure de résilience requise par SOLR si vous voulez qu'elle soit évolutive et résistante dans le cloud.
Cela dit - SOLR offre de nombreux avantages évidents pour certaines tâches: (voir http://wiki.Apache.org/solr/WhyUseSolr ) - les requêtes lâches sont beaucoup plus faciles à exécuter et à rendre significatives résultats. 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ù vous devez souvent optimiser et dénormaliser après coup).
Conclusion: Même si vous POUVEZ utiliser SOLR comme SGBDR, vous pouvez constater (comme moi) qu'il n'y a finalement "pas de déjeuner gratuit" - et le les économies de coût des recherches de texte lucene super-cool et l'indexation en mémoire haute performance, sont souvent payées par moins de flexibilité et l'adoption de nouveaux flux de travail d'accès aux données.
Il est parfaitement raisonnable d'utiliser Solr comme base de données, selon votre application. En fait, c'est à peu près ce que guardian.co.uk fait .
Ce n'est certainement pas une mauvaise pratique en soi. Ce n'est mauvais que si vous l'utilisez de la mauvaise façon, tout comme n'importe quel autre outil à n'importe quel niveau, même GOTO.
Lorsque 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 terrible utilisation de Solr) . Le fait que Solr utilise XML comme format de réponse par défaut est largement hors de propos, vous pouvez également utiliser un protocole binaire , il est donc assez comparable aux bases de données relationnelles traditionnelles à cet égard.
En fin de compte, cela dépend des besoins de votre application. Solr est principalement un moteur de recherche de texte, mais peut également servir de base de données NoSQL pour de nombreuses applications.
Cela a probablement été fait pour des raisons de performances, si cela ne pose aucun problème, je le laisserais tranquille. Il y a une grande zone grise de ce qui devrait être dans une base de données traditionnelle vs un index solr. J'ai l'impression que les gens font des choses similaires à cela (généralement des paires de valeurs clés ou json au lieu de xml) pour la présentation de l'interface utilisateur et n'obtiennent le véritable objet de la base de données que si nécessaire pour les mises à jour/suppressions. Mais toutes les lectures vont à Solr.
J'ai vu des choses similaires faites car cela permet une recherche très rapide. Nous déplaçons les données de nos index Lucene dans un magasin de valeurs-clés rapide pour suivre les principes DRY et également diminuer la taille de l'index. Il n'y a pas de règle stricte pour cela genre de chose.