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


280

Avec le mouvement NoSQL se développant basé sur des bases de données basées sur des documents, j'ai regardé MongoDB récemment. J'ai remarqué une similitude frappante avec la façon de traiter les éléments comme des "documents", tout comme Lucene (et les utilisateurs de Solr).

Alors, 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 le souhaitent) dans une réponse, ce sont des comparaisons approfondies. Sautons ensemble les discussions sur les bases de données relationnelles, car elles servent un objectif différent.

Lucene offre de sérieux avantages, tels que des systèmes de recherche et de poids puissants. Sans parler des facettes de Solr (dont Solr sera bientôt intégré à Lucene, yay!). Vous pouvez utiliser des documents Lucene pour stocker des ID et accéder aux documents en tant que tels, tout comme MongoDB. Mélangez-le avec Solr et vous obtenez maintenant une solution basée sur WebService et à charge équilibrée.

Vous pouvez même ajouter une comparaison de fournisseurs de cache hors processus tels que Velocity ou MemCached lorsque vous parlez de stockage de données similaire et d'évolutivité de MongoDB.

Les restrictions autour de MongoDB me rappellent d'utiliser MemCached, mais je peux utiliser Velocity de Microsoft et avoir plus de pouvoir de regroupement et de collecte de liste sur MongoDB (je pense). Ne peut pas être plus rapide ou é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) présente certains avantages, tels que la facilité d'utilisation de son API. Créez un document, créez un identifiant et stockez-le. Terminé. Agréable et facile.



4
Merci, mais cela ne répond pas à ma question: qui est, pourquoi utiliser MongoDB au lieu de Lucene pour ma base de données? Ils traitent tous les deux des documents, mais Lucene a des options de recherche très puissantes. +1 cependant pour trouver réellement une question connexe. J'ai recherché plusieurs fois sur Stackoverflow, et je n'ai pas trouvé de comparaison proche.
eduncan911

Comment utilisez-vous Lucene pour qu'il offre des fonctionnalités similaires à MongoDB? Le liez-vous à une base de données relationnelle pour le stockage?
Philip Tinney

1
@Philip: C'est une question hypothétique. Pourquoi ne pas utiliser Lucene comme stockage de documents? Vous obtenez beaucoup plus de puissance de recherche et d'évolutivité (lorsqu'il est mélangé avec Solr, ce qui rend Lucene encore plus facile à utiliser).
eduncan911

Réponses:


250

C'est une excellente question, quelque chose que j'ai longuement réfléchi. Je vais résumer mes leçons apprises:

  1. Vous pouvez facilement utiliser Lucene / Solr à la place de MongoDB pour à peu près toutes les situations, mais pas l'inverse. Le post de Grant Ingersoll le résume ici.

  2. MongoDB etc. semble servir un objectif où il n'y a aucune exigence de recherche et / ou de facettage. Il semble que ce soit une transition plus simple et sans doute plus facile pour les programmeurs qui se désintoxiquent du monde du SGBDR. À moins que l'on ne s'y habitue, Lucene & Solr ont une courbe d'apprentissage plus abrupte.

  3. Il n'y a pas beaucoup d'exemples d'utilisation de Lucene / Solr comme magasin de données, mais Guardian a fait des progrès et résume cela dans un excellent diaporama , mais ils ne sont pas non plus contraignants à sauter totalement sur le train de Solr et à "enquêter" sur la combinaison de Solr avec CouchDB.

  4. Enfin, je proposerai notre expérience, mais je ne peux malheureusement pas en dire grand-chose sur l'analyse de rentabilisation. Nous travaillons à l'échelle de plusieurs To de données, une application en temps quasi réel. Après avoir étudié diverses combinaisons, a décidé de s'en tenir à Solr. Aucun regret jusqu'à présent (6 mois & comptage) et ne voyez aucune raison de passer à un autre.

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

Mes 2 cents, j'espère que ça a aidé.


10
Solr n'a pas de fonctionnalité de réduction de carte. Par conséquent, les rapports, les statistiques, le calcul des scores, etc. ne sont pas possibles! N'utilisez Solr que si vous avez / pouvez menacer vos données sous forme de données texte
Roland Kofler

8
Solr n'a pas de carte de réduction intégrée, mais vous pouvez le combiner avec Hadoop. architects.dzone.com/articles/solr-hadoop-big-data-love
Mikos

6
Carte-réduire non, mais il a la possibilité d'exécuter une requête en parallèle sur plusieurs serveurs solr et d'agréger ces résultats. Ainsi, bien qu'il n'ait pas de réduction de carte à usage général, il a déjà écrit ce que vous écririez avec la réduction de carte qui est des requêtes de recherche parallèles.
chubbsondubs

@Roo: Serait-ce une option pour utiliser Lucene comme base de données principale et créer des index agrégés avec MongoDB d'une manière ou d'une autre? Ou cela n'a-t-il pas de sens? Et Mikos: excellente réponse et +1 pour la mention d'expérience dans le monde réel.
Grimace of Despair

2
de solr6 il prend en charge la fonctionnalité de réduction de carte avec des expressions parallèles
Divyang Shah

36

Vous ne pouvez pas mettre à jour partiellement un document dans solr. Vous devez republier tous les champs afin de mettre à jour un document.

Et la performance compte. Si vous ne vous engagez pas, votre passage à solr ne prend pas effet, si vous vous engagez à chaque fois, les performances en souffrent.

Il n'y a aucune transaction dans solr.

Comme solr a ces inconvénients, nosql est parfois un meilleur choix.


13
MongoDB n'a pas non plus de transactions.
user183037

1
Solr ou Lucene ont une recherche en temps réel, donc la validation n'est pas un problème.
mihaicc

1
@ user183037 dans MongoDB toutes les mises à jour dans un document sont atomiques. Et pour info, Lucene n'a pas non plus de transactions (dans votre sens)
Aravind Yarram

48
Cette réponse est devenue incorrecte. Solr 4+ prend en charge les mises à jour partielles, et les validations logicielles / en temps quasi réel suppriment la plupart des problèmes de validations "à l'ancienne" de Solr.
Mauricio Scheffer

1
Ils ont ajouté le support pour les transactions sur MongoDB 4.
Jonas

26

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 ensemble ces technologies. Voici un extrait:

[...] Cependant, nous observons que les performances des requêtes de Solr diminuent lorsque la taille de l'index augmente. Nous avons réalisé que la meilleure solution était d'utiliser à la fois Solr et Mongo DB ensemble. Ensuite, nous intégrons Solr à MongoDB en stockant le contenu dans MongoDB et en créant un index à l'aide de 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 réel de MongoDB après une recherche sur Solr. Obtenir des documents de MongoDB est plus rapide que Solr car il n'y a pas d'analyseurs, de notation, etc. [...]


3
Bon article de blog. Oui, c'est exactement la façon dont j'ai utilisé Lucene dans le passé avec des banques de données SQL et MySql plus anciennes (stockage d'ID dans Lucene et récupération des types complexes de la banque de données). Techniquement cependant, cette question était d'explorer les différences entre les deux - pas exactement comment utiliser le "meilleur des deux mondes". +1 pour l'utiliser de cette façon, car c'est vraiment le seul véritable moyen d'utiliser d'énormes quantités de données.
eduncan911

Merci pour votre réponse. Je sais que la question est de choisir Nosql plutôt que Lucene mais ici je veux montrer qu'au lieu de choisir l'un plutôt que l'autre, les utiliser de manière hybride donnera le meilleur résultat.
Parvin Gasimzade

2
Vous rappelez-vous (maintenant 1,5 ans plus tard) à peu près la taille de la base de données Solr lorsque les performances des requêtes avaient tellement diminué que vous avez commencé à penser à ajouter MongoDB? (Était-ce 10 000 documents ou 10 000 000 documents?)
KajMagnus

Très utile. Je travaille dans le SIG et donc pouvoir combiner le texte intégral avec la recherche spatiale de cette manière est très intrigant. Nous utilisons déjà MongoDB et Postgres, et je pense à Solr depuis un certain temps.
John Powell

2
@ParvinGasimzade le lien de l'article de blog ne fonctionne pas. Pourriez-vous s'il vous plaît fournir un autre lien ou source?
oubli

24

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

Avec cette approche hybride, vous pouvez vraiment avoir le meilleur des deux mondes avec des capacités telles que la recherche en texte intégral et des lectures rapides avec une banque de données fiable qui peut également avoir une vitesse d'écriture fulgurante.

C'est un peu technique à configurer mais il y a beaucoup de tailleurs d'oplog qui peuvent s'intégrer dans solr. Découvrez ce que la portée a fait dans cet article.

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


Si je vous ai bien compris, la raison pour laquelle vous utilisez MongoDB (en plus de Solr) est que MongoDB a une vitesse d'insertion + de lecture plus rapide? Avez-vous également indiqué que MongoDB possède une banque de données plus fiable? (Ou faisiez-vous référence à Solr?) - Par quoi avez-vous commencé au début? Seulement MongoDB, seulement Solr, ou les deux Mongo + Solr?
KajMagnus

12

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 que nous avons subi est la mauvaise performance des requêtes imprévues (vous ne pouvez pas créer d'index mongo pour toutes les combinaisons possibles de filtre / tri, vous ne pouvez tout simplement pas).

Et ici où Lucene / Solr prédomine, surtout avec la mise en cache FilterQuery, les performances sont exceptionnelles.


10

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


6
que mon humble avis n'est pas tout à fait vrai. Solr a un schéma tel que défini dans schema.xml, MAIS il a également des «champs dynamiques», c'est-à-dire des champs dont les types sont déterminés via des caractères génériques, de sorte que vous pouvez avoir tous les champs correspondant, disons, *_iindexés en tant que champs entiers. lors de l' ajout de documents, vous pouvez avoir des documents conaining domaines tels que count_i, foo_i, bar_iqui sont tous compris comme des champs entiers sans apparaître dans la schema.xmllettre. assez sans schéma, je dirais. voir youtube.com/watch?v=WYVM6Wz-XTw pour en savoir plus.
flow

Je dois revenir et augmenter cela avec un +1 parce que c'est vrai - les changements de schéma dans Solr ont toujours été dans un PITA pour rester synchronisés avec d'autres magasins de données.
eduncan911

4
Solr a une fonctionnalité qui prend en charge le schéma ou sans schéma!
Krunal

5

@ mauricio-scheffer a mentionné Solr 4 - pour ceux qui sont intéressés, LucidWorks décrit Solr 4 comme "le serveur de recherche NoSQL" et il y a une vidéo sur http://www.lucidworks.com/webinar-solr-4-the-nosql -search-server / où ils vont en détail sur les fonctionnalités de NoSQL (ish). (Le -ish est pour leur version de schemaless étant en fait un schéma dynamique.)


1

Si vous voulez simplement stocker des données en utilisant le format de valeur-clé, Lucene n'est pas recommandé car son index inversé gaspillera trop d'espace disque. Et avec la sauvegarde des données sur le disque, ses performances sont beaucoup plus lentes que celles des bases de données NoSQL telles que redis car redis enregistre les données en RAM. L'avantage le plus important pour Lucene est qu'il prend en charge la plupart des requêtes, donc les requêtes floues peuvent être prises en charge.


1

Les solutions tierces, comme une queue mongo op-log, sont attrayantes. Certaines réflexions ou questions demeurent quant à savoir si les solutions pourraient être étroitement intégrées, en supposant une perspective de 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éculatives et sujettes à clarification et pas à jour avec les efforts de développement):

  • mongo est c ++, lucene / solr sont java
  • lucene prend en charge divers formats de doc
    • mongo se concentre sur JSON (BSON)
  • lucene utilise des documents immuables
    • les mises à jour sur un seul champ sont un problème, si elles sont disponibles
  • les index lucene sont immuables avec les opérations de fusion complexes
  • les requêtes mongo sont en javascript
  • mongo n'a pas d'analyseurs / tokeniseurs de texte (AFAIK)
  • mongo doc tailles sont limitées, ce qui pourrait aller à contre-courant pour lucene
  • les opérations d'agrégation de mongo peuvent ne pas avoir leur place dans lucene
    • lucene a des options pour stocker des champs sur plusieurs documents, mais ce n'est pas la même chose
    • solr fournit en quelque sorte l'agrégation / statistiques et les requêtes SQL / graphique

0

MongoDB Atlas aura bientôt un moteur de recherche basé sur lucene. La grande annonce a été faite lors de la conférence MongoDB World 2019 de cette semaine. C'est un excellent moyen d'encourager une plus grande utilisation de leur produit MongoDB Atlas à revenus élevés.

J'espérais le voir intégré dans la version 4.2 de MongoDB Enterprise, mais il n'y a pas eu de nouvelles concernant son introduction sur sa gamme de produits sur site.

Plus d'informations ici: https://www.mongodb.com/atlas/full-text-search

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.