Oui, vous pouvez utiliser SOLR comme base de données mais il y a quelques mises en garde vraiment 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 paresseusement 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 de 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 RDBMS 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 créer une application qui utilise SOLR pour une partie de ses grandes requêtes ou modifications avec état .
-
Les outils "d'entreprise" qui permettent la gestion avancée des sessions et les entités avec état que de nombreux frameworks Web avancés (Ruby, Hibernate, ...) proposent devront être complètement jetés par la fenêtre .
-
Les bases de données relationnelles sont destinées à 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. Dans SOLR, je me suis retrouvé à écrire de tels outils et à tester manuellement beaucoup de contraintes, ce qui peut être une perte de temps .
-
Joindre :c'est le grand tueur. Les bases de données relationnelles prennent en charge des méthodes de création et d'optimisation de vues et de requêtes qui joignent des tuples sur la base de prédicats simples. Dans SOLR, il n'existe pas de méthodes robustes pour joindre les données entre les 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 en utilisant des esclaves et des maîtres, ou RAID, etc. Vous devez donc être prêt à fournir l'infrastructure de résilience dont SOLR a besoin si vous voulez qu'elle soit évolutive et résistante dans le cloud.
Cela dit - il y a beaucoup d'avantages évidents à SOLR pour certaines tâches :(voir http://wiki. apache.org/solr/WhyUseSolr ) :les requêtes lâches 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ù vous devez souvent optimiser et dénormaliser après coup).
Conclusion : Même si vous POUVEZ utiliser SOLR comme SGBDR, vous constaterez peut-être (comme moi) qu'il n'y a finalement "pas de repas gratuit" - et les économies de coûts des recherches de texte lucene super cool et de l'indexation haute performance en mémoire, sont souvent payés par moins de flexibilité et l'adoption de nouveaux workflows d'accès aux données.
