Pourquoi les magasins de documents comme Lucene/Solr ne sont-ils pas inclus dans les conversations NoSQL?
Nous avons tous récemment été confrontés au battage publicitaire des solutions sans SQL. MongoDB, CouchDB, BigTable, Cassandra et autres ont été répertoriés comme options non SQL. Voici un exemple:
http://architects.dzone.com/articles/what-nosql-store-should-i-use
Cependant, il y a trois ans, un collègue et moi utilisions Lucene.NET comme ce qui semble correspondre à la description de no-SQL. Nous ne l'avons pas utilisé uniquement pour les requêtes de recherche entrées par l'utilisateur; nous l'avons utilisé pour rendre quelques données de table de SGBDR réindexées extrêmement performantes. Nous avons mis en place notre propre service .NET de type-équivalent-à-Solr pour gérer ces index et les rendre appelables. Lorsque j'ai quitté l'entreprise, l'équipe est passée à Solr. (Pour ceux qui ne sont pas au courant, Solr est un service Web qui englobe Lucene avec des requêtes appelables REST et des sauvegardes d'index.)
Ce que je ne comprends pas, c'est pourquoi Solr n'est pas compté dans les listes types d'options de solutions non-SQL. Est-ce que j'ai râté quelque chose? Je suppose qu'il y a des raisons techniques pour lesquelles Solr n'est pas comparable à CouchDB, etc., et je comprends en fait que CouchDB utilise Lucene comme magasin de données (oui?), Mais qu'est-ce qui disqualifie Solr?
Je ne demande pas en tant que fanboy de Solr ou quoi que ce soit, je ne comprends tout simplement pas pourquoi Solr et les autres ne correspondent pas à la définition de no-SQL, et si Solr correspond techniquement à la définition, qu’en est-il ainsi les gens caca-caca il? Je pose la question parce que j'ai du mal à déterminer si je devrais continuer à utiliser des solutions basées sur Lucene (comme Solr) pour les solutions que je construis ou si je devais vraiment faire plus de recherche avec ces autres options.
Une fois, j'ai écouté une interview avec l'auteur Ursula K. LeGuin à propos de l'écriture de fiction. L'intervieweur lui a posé des questions sur les auteurs qui travaillent dans différents genres d'écriture. Qu'est-ce qui fait qu'un auteur est un écrivain de romance, un autre un écrivain de mystère et un autre un écrivain de science fiction? LeGuin a répondu en expliquant:
Le genre concerne le marketing, pas le contenu.
C'était une déclaration révélatrice.
Je pense que la même chose s'applique aux solutions technologiques. Le mouvement NoSQL attire l'attention parce qu'il déborde d'énergie marketing en ce moment. Les magasins de données NoSQL tels que Hadoop, CouchDB, MongoDB ont des entreprises commerciales qui les soutiennent, en proposant des solutions nouvelles, innovantes et stimulantes leur permettant de développer leur activité. Le terme "NoSQL" est une marque marketing qui les aide à expliquer leur valeur.
Vous avez raison de dire que Lucene/Solr est techniquement très similaire à un magasin de documents NoSQL: c'est un sac dénormalisé de documents (leur terme) avec des champs qui ne sont pas nécessairement cohérents dans la collection de documents. Il est indexé de manière sophistiquée pour vous permettre d'effectuer une recherche dans tous les champs ou par champs spécifiques.
Mais ce n'est pas le genre utilisé par Lucene pour expliquer sa valeur. Ils n'ont pas la même mission de développer un marché et une entreprise, car ils sont gérés par la Fondation Apache. Ils sont heureux de se concentrer sur le cas d'utilisation de la recherche en texte intégral, même si la technologie pourrait être utilisée d'une autre manière. Ils suivent un principe de succès logiciel: faire une chose et bien le faire.
Après avoir effectué plus de recherches sur Google, je pense que ce document résume assez bien la situation:
À titre d’exemple, Lucene/Solr est NoSql et pourrait être considéré comme l’un des "ancêtres" les plus matures de NoSql. Il n’obtient tout simplement pas le battage médiatique NoSql qu’il mérite parce qu’il n’a pas inventé le terme "no-SQL" et que ses utilisateurs n’utilisent pas ce terme, de sorte que la machine à battage médiatique l’a oublié.
Je pense que la caractéristique la plus pertinente de solr/lucene qui sort de la liste de nosql c’est parce que jusqu’à récemment, faire fonctionner lucene en tant que système temps réel était pénible. Le flux de travail habituel de toute application performante consistait à indexer les mises à jour incrémentielles par lots et à mettre à jour l'index toutes les 5 minutes, par exemple.
Je pense que stimpy77 a en partie raison sur NoSQL en tant qu’objet de marque . Mais aussi, NoSQL signifie que c'est une plate-forme de stockage de données plus simple/plus facile que les solutions basées sur SQL. Et je pense que bien que Solr/Lucene partage certains aspects (ils stockent des données), il ne manque vraiment pas l’idée de penser que Solr/Lucene pourrait être utilisé comme stockage de données primaire pour tout ce qui a des relations. Bien sûr, de nombreux documents peuvent y être jetés et une recherche puissante les retire. Mais dès que vous voulez des relations, d'autres, comme CouchDB et d'autres, font beaucoup mieux avec une syntaxe de requête quelconque. La recherche est une solution de pansement dans ce cas. Pensez au cas d'utilisation "rechercher tous les documents marqués avec Word" voiture "". Si j'ai des structures dans mes données, il est alors facile pour moi d'obtenir le document pour tag car et de retirer tout le monde. Versus s'appuyant sur une requête de recherche incluant fq = tag: 'car'. La recherche est de plus en plus puissante, moins vous avez de relations, mais plus il y en a, meilleur sera un magasin de données comme CouchDB et ses frères. C’est pourquoi vous voyez toujours CouchDB et ses amis associés à Solr, et vice versa! Laissez chacun faire ce qu’il fait le mieux.
Bien sûr, cela ne veut pas dire que vous ne pouvez pas exploiter le stockage de vos données source dans Solr, cela peut être un outil puissant à utiliser!
Les principales différences entre un no sql et solr du point de vue opérationnel sont les suivantes à mon avis.
- Solr nécessite un magasin de données intermédiaire (base de données ou fichiers XML), alors que nosql est lui-même un magasin de données simple.
- Vous ne pouvez pas faire une écriture constante dans solr (Solr 4.0 semble apporter ce support) et vous ne pouvez indexer que toutes les 2 minutes et tous les 200 enregistrements maximum (ce qui est très lent pour les écritures à haut débit et vous êtes obligé pour un stockage intermédiaire) .
- Vous devez modifier/définir le schéma lorsque vous modifiez ce qui est stocké dans le document. NoSQL n'a pas de telles définitions.
- Les index Solr ont une incidence sur les performances lorsque la taille de celui-ci augmente alors que NoSQL est optimisé pour celui-ci (ou prétend l'être :))
- Solr contient des algorithmes de recherche lucene sous-jacents, mais dans NoSQL, vous devez les construire. Cela s’applique à la magnifique recherche par facettes ou à la recherche rapide de documents flamboyante fournie par solr.
Dernier point mais quelques points, C’est la différence, pas celle mentionnée ici en tant que stratégie marketing dans laquelle Solr sort de NoSQL
Lucene/Solr - Je vais utiliser Solr, puisque Solr utilise lucene en interne et possède des fonctionnalités supplémentaires. Donc, Solr est fondamentalement une mise à niveau de Lucene avec un nouveau constume.
Solr est principalement utilisé dans le but de créer des facettes et d’indexer des textes simples pour les moteurs de recherche.
Solr peut utiliser la plupart des bases de données pour stocker ses données. Il est incohérent de conserver les données dans solr car elles utilisent directement des disques.
Les bases de données NoSQL sont faciles à apprendre par rapport à Solr. Solr a plus ou moins beaucoup de configurations et de concepts (par exemple: champs).
La performance est quelque chose que nous devons considérer b/w. Solr offre des performances élevées par rapport aux autres bases de données NoSQL.
Remarque: La combinaison de Solr avec certaines bases de données offre les meilleures performances.
Résumé: Solr est également un magasin de données NoSQL qui est un prédécesseur de toutes les bases de données NoSQL. Ce qui n'a pas eu le battage médiatique des autres. Mais toujours sur le terrain en raison de ses performances et de sa puissance.