Base de données NoSQL (MongoDB) vs Lucene (ou Solr)

Question

Avec la croissance du mouvement NoSQL basé sur les bases de données documentaires, je me suis penché sur MongoDB dernièrement. J'ai remarqué une similitude frappante avec la façon de traiter les éléments comme des "documents", tout comme Lucene le fait (et les utilisateurs de Solr).

Donc, la question : Pourquoi voudriez-vous utiliser NoSQL (MongoDB, Cassandra, CouchDB, etc) plutôt que Lucene (ou Solr) comme "base de données" ?

Ce que je recherche (et je suis sûr que d'autres le font aussi) dans une réponse, c'est une comparaison approfondie de ces systèmes. Ne parlons pas des bases de données relationnelles, car elles ont un but différent.

Lucene offre de sérieux avantages, tels que des systèmes de recherche et de pondération puissants. Sans parler des facettes dans Solr (qui sera bientôt intégré à Lucene, youpi !). Vous pouvez utiliser les documents Lucene pour stocker les identifiants, et accéder aux documents en tant que tels, tout comme MongoDB. Mélangez le tout avec Solr, et vous obtenez une solution équilibrée en termes de charge, basée sur les services Web.

Vous pouvez même ajouter une comparaison des fournisseurs de cache hors-proc comme Velocity ou MemCached lorsque vous parlez du stockage de données et de l'évolutivité similaires de MongoDB.

Les restrictions autour de MongoDB me rappellent l'utilisation de MemCached, mais je peux utiliser Velocity de Microsoft et avoir plus de puissance de regroupement et de collecte de listes que MongoDB (je pense). Il n'y a rien de plus rapide ou de plus évolutif que la mise en cache des données en mémoire. Même Lucene a un fournisseur de mémoire.

MongoDB (et d'autres) ont quelques avantages, comme la facilité d'utilisation de leur API. Créez un document, créez un identifiant et stockez-le. C'est fait. C'est simple et facile.

Answer 1

C'est une excellente question, à laquelle j'ai beaucoup réfléchi. Je vais résumer les leçons que j'en ai tirées :

1. Vous pouvez facilement utiliser Lucene/Solr à la place de MongoDB dans presque toutes les situations, mais pas l'inverse. L'article de Grant Ingersoll résume la situation ici.

2. MongoDB, etc. semble servir un objectif pour lequel il n'est pas nécessaire d'effectuer des recherches et/ou des facettes. Il semble que ce soit une transition plus simple et sans doute plus facile pour les programmeurs qui se désintoxiquent du monde des SGBDR. À moins d'y être habitué, Lucene et Solr ont une courbe d'apprentissage plus raide.

3. Il n'y a pas beaucoup d'exemples d'utilisation de Lucene/Solr en tant que magasin de données, mais Guardian a fait quelques progrès et les résume dans un excellent article intitulé pont coulissant mais eux aussi ne sont pas décidés à prendre le train en marche de Solr et "étudient" la possibilité de combiner Solr et CouchDB.

4. Enfin, je vais vous faire part de notre expérience, qui ne peut malheureusement pas révéler grand-chose sur le business-case. Nous travaillons à l'échelle de plusieurs To de données, une application en temps quasi réel. Après avoir étudié diverses combinaisons, nous avons décidé de nous en tenir à Solr. Aucun regret jusqu'à présent (6 mois et plus) et je ne vois aucune raison de passer à une autre solution.

Résumé : si vous n'avez pas d'exigence en matière de recherche, Mongo offre une approche simple et puissante. Cependant, si la recherche est un élément clé de votre offre, vous feriez mieux de vous en tenir à une seule technologie (Solr/Lucene) et de l'optimiser au maximum - moins de pièces mobiles.

Mes deux centimes, j'espère que ça vous a aidé.

Answer 2

Vous ne pouvez pas mettre à jour partiellement un document dans Solr. Vous devez réafficher tous les champs afin de mettre à jour un document.

Et la performance compte. Si vous n'effectuez pas de validation, votre modification de solr ne prend pas effet. Si vous effectuez une validation à chaque fois, les performances en pâtissent.

Il n'y a pas de transaction dans Solr.

Comme Solr présente ces inconvénients, NoSQL est parfois un meilleur choix.

UPDATE : Solr 4+ a commencé à supporter les commit et soft-commits. Voir le dernier document https://lucene.apache.org/solr/guide/8_5/

Answer 3

Nous utilisons MongoDB et Solr ensemble et ils fonctionnent bien. Vous pouvez trouver mon article de blog ici où j'ai décrit comment nous utilisons ces technologies ensemble. En voici un extrait :

[...] Cependant, nous observons que la performance des requêtes de Solr diminue lorsque la taille de l'index augmente. augmente. Nous avons réalisé que la meilleure solution est d'utiliser à la fois Solr et Mongo DB ensemble. Ensuite, nous intégrons Solr à MongoDB en stockant MongoDB et en créant un index avec Solr pour la recherche plein texte. plein texte. Nous ne stockons que l'identifiant unique de chaque document dans l'index Solr et récupérons le contenu réel de MongoDB après une recherche sur Solr. L'obtention de documents à partir de MongoDB est plus rapide que Solr car il n'y a pas d'analyseurs, de notation, etc. d'analyseurs, de notation, etc. [...]

Answer 4

Veuillez également noter que certaines personnes ont intégré Solr/Lucene dans Mongo en stockant tous les index dans Solr et en surveillant les opérations d'oplog et les mises à jour pertinentes en cascade dans Solr.

Grâce à cette approche hybride, vous pouvez vraiment bénéficier du meilleur des deux mondes, avec des capacités telles que la recherche en texte intégral et les lectures rapides dans un datastore fiable qui peut également avoir une vitesse d'écriture fulgurante.

C'est un peu technique à mettre en place mais il y a beaucoup de tailers oplog qui peuvent s'intégrer à Solr. Voyez ce que rangespan a fait dans cet article.

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

Answer 5

Puisque personne d'autre ne l'a mentionné, permettez-moi d'ajouter que MongoDB est sans schéma, alors que Solr impose un schéma. Donc, si les champs de vos documents sont susceptibles de changer, c'est une raison de choisir MongoDB plutôt que Solr.