wake-up-neo.net

NoSQL (MongoDB) vs Lucene (oder Solr) als Ihre Datenbank

Mit der wachsenden NoSQL-Bewegung, die auf dokumentbasierten Datenbanken basiert, habe ich mir in letzter Zeit MongoDB angesehen. Ich habe eine bemerkenswerte Ähnlichkeit mit der Behandlung von Elementen als "Dokumente" festgestellt, genau wie Lucene (und Benutzer von Solr).

Also die Frage: Warum sollten Sie NoSQL (MongoDB, Cassandra, CouchDB, etc.) über Lucene (oder Solr) als Ihre "Datenbank" verwenden?

Was ich (und ich bin sicher, dass andere) in einer Antwort suche, sind einige tiefgreifende Vergleiche von ihnen. Lassen Sie uns alle relationalen Datenbankdiskussionen zusammen überspringen, da sie einem anderen Zweck dienen.

Lucene bietet einige gravierende Vorteile, wie leistungsstarke Such- und Gewichtssysteme. Ganz zu schweigen von den Facetten in Solr (welche Solr bald in Lucene integriert wird, yay!). Sie können Lucene-Dokumente verwenden, um IDs zu speichern und wie MongoDB auf die Dokumente als solche zuzugreifen. Wenn Sie es mit Solr mischen, erhalten Sie eine WebService-basierte Lösung mit Lastenausgleich.

Sie können sogar einen Vergleich von Out-of-Proc-Cache-Anbietern wie Velocity oder MemCached anstellen, wenn Sie über ähnliche Datenspeicherung und Skalierbarkeit von MongoDB sprechen.

Die Einschränkungen in Bezug auf MongoDB erinnern mich an die Verwendung von MemCached, aber ich kann Microsofts Velocity verwenden und mehr Gruppierungs- und Listenerfassungsmöglichkeiten über MongoDB haben (glaube ich). Schneller oder skalierbarer kann es nicht sein, als Daten im Speicher zwischenzuspeichern. Auch Lucene hat einen Speicheranbieter.

MongoDB (und andere) haben einige Vorteile, wie zum Beispiel die Benutzerfreundlichkeit ihrer API. Ein Dokument neu anlegen, eine ID erstellen und speichern. Getan. Schön und leicht.

269
eduncan911

Dies ist eine großartige Frage, über die ich schon viel nachgedacht habe. Ich werde meine Lektionen zusammenfassen:

  1. Sie können Lucene/Solr problemlos anstelle von MongoDB für so ziemlich alle Situationen verwenden, aber nicht umgekehrt. Grant Ingersoll's fasst es hier zusammen.

  2. MongoDB usw. scheinen einen Zweck zu erfüllen, bei dem keine Suche und/oder Facettierung erforderlich ist. Es scheint für Programmierer, die sich von der RDBMS-Welt lösen, ein einfacherer und wohl einfacherer Übergang zu sein. Wenn man es nicht gewohnt ist, haben Lucene & Solr eine steilere Lernkurve.

  3. Es gibt nicht viele Beispiele für die Verwendung von Lucene/Solr als Datenspeicher, aber Guardian hat einige Fortschritte erzielt und dies in einem hervorragenden Slide-Deck zusammengefasst, aber auch sie sind nicht verpflichtend, wenn es darum geht, ganz auf Solr zu springen bandwagon und "investigating" kombiniert Solr mit CouchDB.

  4. Abschließend werde ich Ihnen unsere Erfahrungen vorstellen, die leider nicht viel über den Business-Case verraten können. Wir arbeiten auf der Skala von mehreren TB von Daten, eine Fast-Echtzeit-Anwendung. Nachdem wir verschiedene Kombinationen untersucht haben, haben wir beschlossen, bei Solr zu bleiben. Bisher kein Bedauern (6 Monate & Zählen) und sehe keinen Grund, zu einem anderen zu wechseln.

Zusammenfassung: Wenn Sie keine Suchanforderung haben, bietet Mongo einen einfachen und leistungsstarken Ansatz. Wenn jedoch die Suche der Schlüssel zu Ihrem Angebot ist, sollten Sie sich wahrscheinlich besser an eine Technologie (Solr/Lucene) halten und das Beste daraus machen - weniger bewegliche Teile.

Meine 2 Cent, hoffe das hat geholfen.

240
Mikos

Sie können ein Dokument in solr nicht teilweise aktualisieren. Sie müssen alle Felder erneut buchen, um ein Dokument zu aktualisieren.

Und Leistung zählt. Wenn Sie kein Commit durchführen, wird Ihre Änderung an solr nicht wirksam. Wenn Sie jedes Mal ein Commit durchführen, leidet die Leistung.

Es gibt keine Transaktion in solr.

Da solr diese Nachteile hat, ist nosql manchmal die bessere Wahl.

34
Peter Long

Beachten Sie auch, dass einige Leute Solr/Lucene in Mongo integriert haben, indem sie alle Indizes in Solr gespeichert haben und auch Oplog-Vorgänge überwachen und relevante Aktualisierungen in Solr kaskadieren.

Mit diesem hybriden Ansatz können Sie wirklich das Beste aus beiden Welten mit Funktionen wie Volltextsuche und schnellem Lesen mit einem zuverlässigen Datenspeicher erzielen, der auch überragende Schreibgeschwindigkeit verfügt.

Das Setup ist ein bisschen technisch, aber es gibt viele Oplog-Tailer, die sich in solr integrieren lassen. Sehen Sie sich in diesem Artikel an, was die Reichweite bewirkt hat.

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

24
Prasith Govin

Wir verwenden MongoDB und Solr zusammen und sie arbeiten gut. Sie finden mein Blogpost hier wo ich beschrieben habe, wie wir diese Technologien zusammen nutzen. Hier ist ein Auszug:

[...] Wir stellen jedoch fest, dass die Abfrageleistung von Solr abnimmt, wenn die Indexgröße zunimmt. Wir haben erkannt, dass die beste Lösung darin besteht, sowohl Solr als auch Mongo DB zusammen zu verwenden. Anschließend integrieren wir Solr in MongoDB, indem wir Inhalte in MongoDB speichern und mit Solr einen Index für die Volltextsuche erstellen. Wir speichern nur die eindeutige ID für jedes Dokument im Solr-Index und rufen nach der Suche in Solr den tatsächlichen Inhalt aus MongoDB ab. Das Abrufen von Dokumenten aus MongoDB ist schneller als Solr, da es keine Analysatoren, Scoring usw. gibt. [...]

23

Aus meiner Erfahrung mit beiden ist Mongo ideal für die einfache, unkomplizierte Verwendung. Der Hauptnachteil von Mongo ist die schlechte Leistung bei unerwarteten Abfragen (Sie können nicht für alle möglichen Filter-/Sortierkombinationen Mongo-Indizes erstellen, Sie können es einfach nicht).

Und hier, wo Lucene/Solr sich besonders beim FilterQuery-Caching durchsetzen, ist die Leistung hervorragend.

12
mjalajel

Da es sonst niemand erwähnte, möchte ich hinzufügen, dass MongoDB schemafrei ist, während Solr ein Schema erzwingt. Wenn sich also wahrscheinlich die Felder Ihrer Dokumente ändern, ist dies ein Grund, MongoDB anstelle von Solr zu wählen.

11
Aquarelle

@ mauricio-scheffer erwähnte Solr 4 - für diejenigen, die daran interessiert sind, beschreibt LucidWorks Solr 4 als "den NoSQL-Suchserver" und es gibt ein Video unter http://www.lucidworks.com/webinar-solr-4) -the-nosql-search-server / wo sie detailliert auf die NoSQL (ish) -Funktionen eingehen. (Das -ish steht für die Version von schemaless, bei der es sich tatsächlich um ein dynamisches Schema handelt.)

4
Beth

Wenn Sie nur Daten im Schlüsselwertformat speichern möchten, wird Lucene nicht empfohlen, da der invertierte Index zu viel Speicherplatz verschwendet. Da die Daten auf der Festplatte gespeichert werden, ist ihre Leistung viel langsamer als bei NoSQL-Datenbanken wie Redis, da Redis Daten im RAM speichern. Der größte Vorteil für Lucene ist, dass es viele Abfragen unterstützt, sodass Fuzzy-Abfragen unterstützt werden können.

1
张洪岩

MongoDB Atlas wird in Kürze eine Lucene-basierte Suchmaschine haben. Die große Ankündigung erfolgte auf der dieswöchigen MongoDB World 2019-Konferenz. Dies ist eine großartige Möglichkeit, um die Verwendung des MongoDB Atlas-Produkts mit hohem Umsatz zu fördern.

Ich hatte gehofft, dass es in der MongoDB Enterprise-Version 4.2 eingeführt wird, aber es gab keine Neuigkeiten darüber, dass es in die On-Prem-Produktlinie aufgenommen wurde.

Weitere Informationen hier: https://www.mongodb.com/atlas/full-text-search

0
Gary Russo

Die Lösungen von Drittanbietern, wie ein Mongo-Op-Log-Tail, sind attraktiv. Es bleiben einige Überlegungen oder Fragen offen, ob die Lösungen unter der Annahme einer Entwicklungs-/Architekturperspektive eng integriert werden könnten. Ich erwarte aus einigen Gründen keine eng integrierte Lösung für diese Funktionen (etwas spekulativ und klärungsbedürftig und nicht auf dem neuesten Stand der Entwicklungsbemühungen):

  • mongo ist c ++, lucene/solr sind Java
  • lucene unterstützt verschiedene doc-formate
    • mongo konzentriert sich auf JSON (BSON)
  • lucene benutzt unveränderliche Dokumente
    • aktualisierungen einzelner Felder sind ein Problem, sofern sie verfügbar sind
  • lucene-Indizes sind bei komplexen Merge-Operationen unveränderlich
  • mongo-Abfragen sind Javascript
  • mongo hat keine Textanalysatoren/Tokenizer (AFAIK)
  • mongo doc größen sind begrenzt, das könnte für lucene gegen den strich gehen
  • mongo aggregation ops haben möglicherweise keinen platz in lucene
    • lucene verfügt über Optionen zum Speichern von Feldern in allen Dokumenten, aber das ist nicht dasselbe
    • solr bietet irgendwie Aggregation/Statistiken und SQL/Graph-Abfragen
0
Darren Weber