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

280

Da die NoSQL-Bewegung basierend auf dokumentbasierten Datenbanken wächst, 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).

Die Frage: Warum sollten Sie NoSQL (MongoDB, Cassandra, CouchDB usw.) über Lucene (oder Solr) als "Datenbank" verwenden?

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

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

Sie können sogar einen Vergleich von Out-of-Proc-Cache-Anbietern wie Velocity oder MemCached durchführen, 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 Microsoft Velocity verwenden und über MongoDB mehr Möglichkeiten zum Gruppieren und Sammeln von Listen verfügen (glaube ich). Schneller oder skalierbarer kann es nicht sein, Daten im Speicher zwischenzuspeichern. Sogar Lucene hat einen Speicheranbieter.

MongoDB (und andere) haben einige Vorteile, wie zum Beispiel die Benutzerfreundlichkeit ihrer API. Erstellen Sie ein neues Dokument, erstellen Sie eine ID und speichern Sie es. Getan. Schön und einfach.

mongodb  solr  lucene  memcached  nosql 
— eduncan911
quelle
8
— bajafresh4life
4
Vielen Dank, aber das beantwortet meine Frage nicht: Warum sollte ich MongoDB anstelle von Lucene für meine Datenbank verwenden? Beide verarbeiten Dokumente, aber Lucene verfügt über einige sehr leistungsstarke Suchoptionen. +1, um tatsächlich eine verwandte Frage zu finden. Ich habe mehrmals nach Stackoverflow gesucht und keinen Vergleich gefunden.
— eduncan911
Wie verwenden Sie Lucene, das ähnliche Funktionen wie MongoDB bietet? Binden Sie es zur Speicherung an eine relationale Datenbank?
— Philip Tinney
1
@Philip: Es ist eine hypothetische Frage. Warum nicht Lucene als Dokumentenspeicher verwenden? Sie erhalten viel mehr Suchleistung und Skalierbarkeit (in Kombination mit Solr wird die Verwendung von Lucene noch einfacher).
— eduncan911

Antworten:

250

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

  1. Sie können Lucene / Solr anstelle von MongoDB problemlos für nahezu alle Situationen verwenden, jedoch nicht umgekehrt. Grant Ingersolls Beitrag fasst es hier zusammen.

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

  3. Es gibt nicht viele Beispiele für die Verwendung Lucene / Solr als Datenspeicher, sondern Hüter hat einige Fortschritte gemacht und fassen diese in einem ausgezeichneten Dia-Deck , aber sie sind auch nicht verbindlich auf völlig Springen auf Solr fahrenden Zug und „Untersuchung“ die Kombination von Solr mit CouchDB.

  4. Schließlich werde ich unsere Erfahrung anbieten, kann leider nicht viel über den Business-Case verraten. Wir arbeiten auf der Skala von mehreren TB Daten, eine nahezu Echtzeitanwendung. Nachdem ich verschiedene Kombinationen untersucht hatte, entschied ich mich, bei Solr zu bleiben. Bisher kein Bedauern (6 Monate & Zählen) und kein 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, ist es wahrscheinlich besser, sich an eine Technologie (Solr / Lucene) zu halten und das Beste daraus zu machen - weniger bewegliche Teile.

Meine 2 Cent, hoffe das hat geholfen.

— Mikos
quelle
10
Solr hat keine Kartenreduzierungsfunktion. Daher sind Berichterstattung, Statistiken, Berechnung von Punktzahlen usw. nicht möglich! Verwenden Sie Solr nur, wenn Sie Ihre Daten als Textdaten haben / bedrohen können
— Roland Kofler
8
Solr verfügt nicht über eine integrierte Kartenreduzierung, die Sie jedoch mit Hadoop kombinieren können. Architects.dzone.com/articles/solr-hadoop-big-data-love
— Mikos
6
Map-Reduce Nein, aber es kann eine Abfrage parallel über mehrere Solr-Server ausgeführt und diese Ergebnisse aggregiert werden. Obwohl es keine allgemeine Kartenreduzierung gibt, hat es bereits geschrieben, was Sie mit Kartenreduzierung schreiben würden, bei der es sich um parallele Suchanfragen handelt.
— Chubbsondubs
@Roo: Wäre es eine Option, Lucene als Hauptdatenbank zu verwenden und mit MongoDB irgendwie aggregierte Indizes zu erstellen? Oder macht das keinen Sinn? Und Mikos: tolle Antwort und +1 für die reale Erfahrung erwähnen.
— Grimasse der Verzweiflung
2
von solr6 unterstützt es Map Reduction Funktionalität mit parallelen Ausdrücken
— Divyang Shah
36

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

Und Leistung ist wichtig. 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 manchmal nosql die bessere Wahl.

— Peter Long
quelle
13
MongoDB hat auch keine Transaktionen.
— user183037
1
Solr oder Lucene haben eine Echtzeitsuche, daher ist das Festschreiben kein Problem.
— Mihaicc
1
@ user183037 In MongoDB sind alle Aktualisierungen in einem Dokument Atomic. Und zu Ihrer Information, Lucene hat auch keine Transaktionen (in Ihrem Sinne)
— Aravind Yarram
48
Diese Antwort ist falsch geworden. Solr 4+ unterstützt Teilaktualisierungen, und Soft Commits / nahezu Echtzeit beseitigen die meisten Probleme von Solr-Commits im "alten Stil".
— Mauricio Scheffer
1
Sie fügten Unterstützung für Transaktionen auf MongoDB 4 hinzu.
— Jonas
26

Wir verwenden MongoDB und Solr zusammen und sie arbeiten gut. Sie finden meinen Blog-Beitrag hier, in dem ich beschrieben habe, wie wir diese Technologien gemeinsam einsetzen. Hier ist ein Auszug:

[...] Wir stellen jedoch fest, dass die Abfrageleistung von Solr mit zunehmender Indexgröße abnimmt. Wir haben festgestellt, 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 der 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 das von Solr, da es keine Analysatoren, Scoring usw. gibt. [...]

— Parvin Gasimzade
quelle
3
Guter Blogbeitrag. Ja, genau so habe ich Lucene in der Vergangenheit mit älteren SQL- und MySQL-Datenspeichern verwendet (Speichern von IDs in Lucene und Abrufen der komplexen Typen aus dem Datenspeicher). Technisch gesehen sollte diese Frage die Unterschiede zwischen den beiden untersuchen - nicht genau, wie man das "Beste aus beiden Welten" nutzt. +1 für die Verwendung auf diese Weise, da dies wirklich die einzige echte Möglichkeit ist, große Datenmengen zu verwenden.
— eduncan911
Vielen Dank für Ihre Antwort. Ich weiß, dass es bei der Frage darum geht, Nosql gegenüber Lucene zu wählen, aber hier möchte ich zeigen, dass eine hybride Verwendung das beste Ergebnis liefert, anstatt eines über das andere zu wählen.
— Parvin Gasimzade
2
Erinnern Sie sich (jetzt 1,5 Jahre später) ungefähr an die Größe der Solr-Datenbank, als die Abfrageleistung so stark abgenommen hatte, dass Sie über das Hinzufügen von MongoDB nachdachten? (War es 10.000 Dokumente oder 10.000.000 Dokumente?)
— KajMagnus
Sehr hilfreich. Ich arbeite in GIS und daher ist es sehr faszinierend, auf diese Weise Volltext mit räumlicher Suche kombinieren zu können. Wir verwenden bereits MongoDB und Postgres, und ich habe eine Weile über Solr nachgedacht.
— John Powell
2
@ParvinGasimzade Der Blog-Post-Link funktioniert nicht. Könnten Sie bitte einen anderen Link oder eine andere Quelle angeben?
— Vergessenheit
24

Bitte beachten Sie auch, dass einige Leute Solr / Lucene in Mongo integriert haben, indem sie alle Indizes in Solr gespeichert haben und auch Oplog-Operationen überwachen und relevante Updates in Solr kaskadieren.

Mit diesem hybriden Ansatz können Sie das Beste aus beiden Welten mit Funktionen wie Volltextsuche und schnellem Lesen mit einem zuverlässigen Datenspeicher erzielen, der auch eine hervorragende Schreibgeschwindigkeit aufweisen kann.

Das Einrichten ist etwas technisch, aber es gibt viele Oplog-Tailer, die sich in solr integrieren lassen. Lesen Sie in diesem Artikel, was Rangespan getan hat.

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

— Prasith Govin
quelle
Wenn ich Sie richtig verstanden habe, ist der Grund, warum Sie MongoDB (zusätzlich zu Solr) verwenden, dass MongoDB eine schnellere Einfügung + Lesegeschwindigkeit hat? Haben Sie auch angegeben, dass MongoDB über einen zuverlässigeren Datenspeicher verfügt? (Oder haben Sie sich auf Solr bezogen?) - Womit haben Sie ursprünglich begonnen? Nur MongoDB, nur Solr oder beide Mongo + Solr?
— KajMagnus
12

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

Und hier, wo Lucene / Solr besonders beim FilterQuery-Caching eine große Rolle spielt, ist die Leistung hervorragend.

— mjalajel
quelle
10

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

— Aquarelle
quelle
6
dass IMHO nicht ganz wahr ist. Solr hat ein Schema wie in definiert schema.xml, ABER es hat auch 'dynamische Felder', dh Felder, deren Typen über Platzhalter bestimmt werden, so dass Sie alle Felder, die übereinstimmen, beispielsweise *_ials ganzzahlige Felder indizieren lassen können. wenn Dokumente hinzufügen, können Sie dann Dokumente conaining Felder wie count_i, foo_i, bar_idie ohne erscheinen in allen verstanden als Integer - Felder sind schema.xmlbuchstäblich. ziemlich schemalos, würde ich sagen. Weitere Informationen finden Sie unter youtube.com/watch?v=WYVM6Wz-XTw .
— Flow
Ich muss zurückkommen und dies mit +1 erhöhen, da dies wahr ist - Schemaänderungen in Solr wurden immer in einer PITA durchgeführt, um mit anderen Datenspeichern synchron zu bleiben.
— eduncan911
4
Solr hat eine Funktion, die Schema oder No-Schema unterstützt!
— Krunal
5

@ mauricio-scheffer erwähnte Solr 4 - für diejenigen, die daran interessiert sind, beschreibt LucidWorks Solr 4 als "NoSQL Search Server" 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. (Die -ish ist für ihre Version von schemaless tatsächlich ein dynamisches Schema.)

— Beth
quelle
1

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

— 张洪岩
quelle
1

Die Lösungen von Drittanbietern wie ein Mongo-Op-Log-Schwanz sind attraktiv. Es bleiben einige Gedanken oder Fragen darüber offen, ob die Lösungen unter der Perspektive einer Entwicklung / Architektur 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 Dokumentformate
    • Mongo konzentriert sich auf JSON (BSON)
  • Lucene verwendet unveränderliche Dokumente
    • Aktualisierungen einzelner Felder sind ein Problem, sofern sie verfügbar sind
  • Lucene-Indizes sind bei komplexen Zusammenführungsoperationen unveränderlich
  • Mongo-Abfragen sind Javascript
  • Mongo hat keine Textanalysatoren / Tokenizer (AFAIK)
  • Die Größe der Mongo Docs ist begrenzt, was für Lucene möglicherweise gegen den Strich geht
  • Mongo Aggregation Ops haben möglicherweise keinen Platz in Lucene
    • Lucene bietet Optionen zum Speichern von Feldern in verschiedenen Dokumenten, aber das ist nicht dasselbe
    • solr bietet irgendwie Aggregations- / Statistik- und SQL- / Grafikabfragen
— Darren Weber
quelle
0

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

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

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

— Gary Russo
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.