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




memcached (7)

@ mauricio-scheffer erwähnt 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 auf die NoSQL (ish) -Funktionen eingehen. (Das -ish ist für ihre Version von schemaless tatsächlich ein dynamisches Schema.)

Da die NoSQL-Bewegung auf dokumentenbasierten Datenbanken basiert, habe ich mich in letzter Zeit mit MongoDB beschäftigt. Ich habe eine auffallende Ähnlichkeit mit der Behandlung von Gegenständen 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 mir sicher, dass andere es sind) in einer Antwort suchen, sind einige tiefgreifende Vergleiche von ihnen. Lassen Sie uns alle über relationale Datenbank-Diskussionen hinweggehen, da sie einem anderen Zweck dienen.

Lucene bietet einige ernsthafte Vorteile, wie zum Beispiel leistungsfähige Such- und Gewichtssysteme. Ganz zu schweigen von Facetten in Solr (die Solr wird bald in Lucene integriert, yay!). Sie können Lucene-Dokumente zum Speichern von IDs verwenden und genauso wie MongoDB auf die Dokumente zugreifen. Mischen Sie es mit Solr, und Sie erhalten jetzt eine WebService-basierte, Load-Balanced-Lösung.

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

Die Einschränkungen um MongoDB erinnern mich an die Verwendung von MemCached, aber ich kann Microsofts Velocity verwenden und habe mehr Gruppierungs- und Listensammelmöglichkeiten gegenüber MongoDB (denke ich). Es kann nicht schneller oder skalierbarer sein, als Daten im Speicher zwischenzuspeichern. Selbst 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 sie. Erledigt. Schön und einfach.


Aus meiner Erfahrung mit beiden ist Mongo ideal für einfache, unkomplizierte Nutzung. Der Hauptmongo-Nachteil, den wir erleiden mussten, ist die schlechte Leistung bei unerwarteten Abfragen (Sie können keine Mongo-Indizes für alle möglichen Filter / Sortier-Kombinationen erstellen, was Sie einfach nicht können).

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


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


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

  1. Sie können Lucene / Solr anstelle von MongoDB für fast alle Situationen verwenden, aber nicht umgekehrt. Grant Ingersolls Post fasst es hier zusammen.

  2. MongoDB usw. scheinen einem Zweck zu dienen, bei dem keine Suche und / oder Facettierung erforderlich ist. Es scheint ein einfacherer und zweifellos einfacherer Übergang für Programmierer zu sein, die aus der RDBMS-Welt entgiften. Wenn man es nicht gewohnt ist, haben Lucene & Solr eine steilere Lernkurve.

  3. Es gibt nicht viele Beispiele, Lucene / Solr als Datenspeicher zu verwenden, aber Guardian hat einige Fortschritte gemacht und dies in einem exzellenten slide-deck , aber sie sind auch nicht verpflichtet, auf Solr-Zug zu springen und Solr zu "untersuchen" mit CouchDB.

  4. Zum Schluss werde ich unsere Erfahrung anbieten, leider kann ich nicht viel über den Business-Case preisgeben. Wir arbeiten im Umfang von mehreren TB Daten, einer nahezu Echtzeitanwendung. Nach Untersuchung verschiedener Kombinationen entschied man sich, bei Solr zu bleiben. Bisher keine Reue (6 Monate & Zählen) und keinen Grund, auf etwas anderes zu wechseln.

Zusammenfassung: Wenn Sie keine Suchanforderungen haben, bietet Mongo einen einfachen und leistungsfähigen Ansatz. Wenn jedoch die Suche der Schlüssel zu Ihrem Angebot ist, ist es wahrscheinlich besser, wenn Sie an einer Technologie (Solr / Lucene) festhalten und das Ganze optimieren - weniger bewegliche Teile.

Meine 2 Cent, hoffe das hat geholfen.


NoSQL funktioniert als Multi-Node-Datenbanken, die große Skalierbarkeitsfunktionen bieten. Heutzutage unterstützen viele NoSQL-Datenbanken die Datenpartitionierung auf verschiedenen Knoten. Dies hilft, große Datenmengen zu skalieren und unnötige Duplizierungen zu vermeiden. Die Effektivität der zu erstellenden App hängt nicht nur von den Datenmodellen ab, sondern auch von der Effizienz neuer Funktionen. Datenmodelle arbeiten als Brücke zwischen den Problemen der realen Welt und der Software. NoSQL-Datenbanklösungen entwickeln moderne Softwareanwendungen.


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

Und Leistung ist wichtig. Wenn Sie sich nicht verpflichten, wird Ihre Änderung zu solr nicht wirksam, wenn Sie jedes Mal verpflichten, leidet die Leistung.

Es gibt keine Transaktion in solr.

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


Wir verwenden MongoDB und Solr zusammen und sie funktionieren gut. Sie können meinen Blog hier finden, wo ich beschrieben habe, wie wir diese Technologien zusammen verwenden. Hier ist ein Auszug:

[...] Allerdings beobachten wir, dass die Abfrageleistung von Solr abnimmt, wenn die Indexgröße zunimmt. Wir haben festgestellt, dass die beste Lösung darin besteht, sowohl Solr als auch Mongo DB zusammen zu verwenden. Dann integrieren wir Solr mit MongoDB, indem wir Inhalte in MongoDB speichern und einen Index mit Solr für die Volltextsuche erstellen. Wir speichern nur die eindeutige ID für jedes Dokument im Solr-Index und rufen den tatsächlichen Inhalt von MongoDB nach der Suche auf Solr ab. Dokumente von MongoDB zu bekommen ist schneller als Solr, weil es keine Analysatoren, Scoring usw. gibt [...]







nosql