NoSQL (MongoDB) vs Lucene (ou Solr) comme base de données
Avec le développement croissant du mouvement NoSQL basé sur des bases de données documentaires, j'ai récemment étudié MongoDB. J'ai remarqué une similitude frappante avec la façon de traiter les éléments en tant que "documents", comme le fait Lucene (et les utilisateurs de Solr).
Donc, la question: Pourquoi voudriez-vous utiliser NoSQL (MongoDB, Cassandra, CouchDB, etc.) sur Lucene (ou Solr) comme "base de données"?
Ce que je recherche (et je suis sûr que d’autres sont) à la recherche d’une réponse, c’est une comparaison approfondie. Évitons les discussions sur les bases de données relationnelles, car elles servent un objectif différent.
Lucene présente de sérieux avantages, tels que des systèmes de recherche et de poids puissants. Sans parler des facettes de Solr (que Solr est en train d’intégrer à Lucene bientôt, yay!). Vous pouvez utiliser des documents Lucene pour stocker des identifiants et accéder aux documents en tant que tels, tout comme MongoDB. Mélangez-le avec Solr et vous obtenez maintenant une solution d'équilibrage de charge basée sur WebService.
Vous pouvez même faire une comparaison entre les fournisseurs de cache hors processus tels que Velocity ou MemCached lorsque vous parlez d'un stockage de données similaire et de l'évolutivité de MongoDB.
Les restrictions autour de MongoDB me rappellent l’utilisation de MemCached, mais je peux utiliser Velocity de Microsoft et avoir plus de pouvoir de regroupement et de collecte de listes par rapport à MongoDB (je pense). Impossible d'obtenir plus rapidement ou de manière évolutive que la mise en cache des données en mémoire. Même Lucene a un fournisseur de mémoire.
MongoDB (et d’autres) présentent certains avantages, tels que la facilité d’utilisation de leur API. Créer un document, créer un identifiant et le stocker. Terminé. Nice et facile.
C'est une excellente question à laquelle j'ai beaucoup réfléchi. Je vais résumer mes leçons apprises:
Vous pouvez facilement utiliser Lucene/Solr au lieu de MongoDB pour à peu près toutes les situations, mais pas l’inverse. Le message de Grant Ingersoll le résume ici.
MongoDB, etc., semblent servir un objectif où il n’est pas nécessaire de chercher et/ou de facetter. Cela semble être une transition plus simple et sans doute plus facile pour les programmeurs désintoxiqués du monde des SGBDR. À moins d'y être habitué, Lucene & Solr ont une courbe d'apprentissage plus abrupte.
Il n’ya pas beaucoup d’exemples d’utilisation de Lucene/Solr en tant que banque de données, mais Guardian a fait quelques progrès et résume cela en un excellent diaporama , mais eux aussi ne s'engagent pas à sauter totalement dans le train Solr et à "enquêter" en combinant Solr avec CouchDB.
Enfin, je vais offrir notre expérience, malheureusement, ne peut pas en dire beaucoup sur le business-case. Nous travaillons à l’échelle de plusieurs TB de données, une application presque en temps réel. Après avoir étudié diverses combinaisons, nous avons décidé de nous en tenir à Solr. Aucun regret à ce jour (6 mois et compter) et ne voit aucune raison de passer à un autre.
Résumé: si vous n’avez pas d’obligation de recherche, Mongo propose une approche simple et puissante. Toutefois, si la recherche est la clé de votre offre, vous ferez probablement mieux de vous en tenir à une technologie (Solr/Lucene) et d’optimiser son potentiel: moins de pièces mobiles.
Mes 2 centimes, espérons que cela a aidé.
Vous ne pouvez pas mettre à jour partiellement un document dans solr. Vous devez republier tous les champs pour mettre à jour un document.
Et la performance compte. Si vous ne vous engagez pas, votre modification en solution ne prend pas effet, si vous vous engagez à chaque fois, les performances en pâtissent.
Il n'y a pas de transaction en solr.
Comme nous avons ces inconvénients, il est parfois préférable de choisir.
Veuillez également noter que certaines personnes ont intégré Solr/Lucene à Mongo en enregistrant tous les index dans Solr, en surveillant également les opérations oplog et en mettant en cascade les mises à jour pertinentes dans Solr.
Avec cette approche hybride, vous pouvez vraiment avoir le meilleur des deux mondes avec des fonctionnalités telles que la recherche de texte intégral et des lectures rapides avec un magasin de données fiable pouvant également avoir une vitesse d'écriture fulgurante.
La configuration est un peu technique, mais il existe de nombreux opérateurs oplog pouvant s’intégrer à solr. Découvrez ce que la gamme a fait dans cet article.
http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html
Nous utilisons ensemble MongoDB et Solr et ils fonctionnent bien. Vous pouvez trouver mon billet de blog ici où j'ai décrit comment nous utilisons ces technologies ensemble. Voici un extrait:
[...] Cependant, nous observons que les performances de requête de Solr diminuent lorsque la taille de l'index augmente. Nous avons réalisé que la meilleure solution consiste à utiliser les solutions Solr et Mongo DB ensemble. Ensuite, nous intégrons Solr à MongoDB en enregistrant le contenu dans MongoDB et en créant un index utilisant Solr pour la recherche en texte intégral. Nous stockons uniquement l'identifiant unique de chaque document dans l'index Solr et récupérons le contenu actuel de MongoDB après une recherche sur Solr. Obtenir des documents à partir de MongoDB est plus rapide que Solr car il n'y a pas d'analyseurs, d'évaluation, etc. [...]
D'après mon expérience avec les deux, Mongo est idéal pour une utilisation simple et directe. Le principal inconvénient de Mongo dont nous avons été victimes est la piètre performance des requêtes imprévues (vous ne pouvez pas créer d’index mongo pour toutes les combinaisons filtre/tri possibles, vous ne pouvez pas le faire).
Et là où Lucene/Solr l'emporte, en particulier avec la mise en cache de FilterQuery, les performances sont exceptionnelles.
Puisque personne n’en a parlé, permettez-moi d’ajouter que MongoDB n’a pas de schéma, alors que Solr applique un schéma. Donc, si les champs de vos documents sont susceptibles de changer, c'est une des raisons pour choisir MongoDB sur Solr.
@ mauricio-scheffer a mentionné Solr 4 - pour ceux que cela intéresse, LucidWorks décrit Solr 4 comme "le serveur de recherche NoSQL" et une vidéo est disponible sur http://www.lucidworks.com/webinar-solr-4 -the-nosql-search-server / où ils détaillent les fonctionnalités de NoSQL (ish). (Le -ish est pour leur version de schemaless étant en fait un schéma dynamique.)
Si vous souhaitez simplement stocker des données au format clé-valeur, Lucene n’est pas recommandée car son index inversé gaspillera trop d’espace disque. Et avec la sauvegarde des données sur disque, ses performances sont bien inférieures à celles des bases de données NoSQL telles que redis, car redis enregistre les données dans la RAM. Le principal avantage pour Lucene est qu’il prend en charge un grand nombre de requêtes, ce qui permet de prendre en charge les requêtes floues.
MongoDB Atlas aura bientôt un moteur de recherche basé sur Lucene. La grande annonce a été faite à la conférence MongoDB World 2019 de cette semaine. C’est un excellent moyen d’encourager davantage l’utilisation de leur produit MongoDB Atlas à revenu élevé.
J'espérais le voir intégré à la version 4.2 de MongoDB Enterprise, mais rien ne lui permettait de l'intégrer à sa gamme de produits sur site.
Plus d'infos ici: https://www.mongodb.com/atlas/full-text-search
Les solutions tierces, comme une queue d'op-log mongo, sont attrayantes. Certaines réflexions ou questions subsistent quant à savoir si les solutions pourraient être étroitement intégrées, dans une perspective développement/architecture. Je ne m'attends pas à voir une solution étroitement intégrée pour ces fonctionnalités pour plusieurs raisons (quelque peu spéculative et sujette à clarification, sans être à la pointe des efforts de développement):
- mongo est c ++, lucene/solr est Java
- peut-être que lucene pourrait utiliser des libs mongo
- peut-être que mongo pourrait réécrire des algorithmes de lucene, voir aussi:
- lucene supporte divers formats de doc
- mongo est axé sur JSON (BSON)
- lucene utilise des documents immuables
- les mises à jour sur un seul champ sont un problème, si elles sont disponibles
- les indices lucene sont immuables avec des opérations de fusion complexes
- les requêtes mongo sont en javascript
- mongo n'a pas d'analyseurs de texte/tokenizers (autant que je sache)
- les formats de doc mongo sont limités, cela pourrait aller à contre-courant pour lucene
- les opérations d’agrégation de mongo n’ont peut-être pas leur place dans lucene
- lucene a des options pour stocker les champs dans la documentation, mais ce n'est pas la même chose
- solr fournit en quelque sorte une agrégation/statistique et des requêtes SQL/graphique