elasticsearch vs MongoDB zum Filtern von Anwendungen [geschlossen]

Bei dieser Frage geht es darum, eine architektonische Entscheidung zu treffen, bevor die Details des Experimentierens und der Implementierung untersucht werden. Es geht um die Eignung von Elasticsearch gegenüber MongoDB in Bezug auf Skalierbarkeit und Leistung für einen bestimmten Zweck.

Hypothetisch gesehen speichern beide Datenobjekte mit Feldern und Werten und ermöglichen das Abfragen dieses Objektkörpers. Vermutlich ist es für beide geeignet, Teilmengen der Objekte nach ad-hoc ausgewählten Feldern herauszufiltern.

Meine Anwendung dreht sich um die Auswahl von Objekten nach Kriterien. Es würde Objekte auswählen, indem es gleichzeitig nach mehr als einem Feld filtert, anders ausgedrückt, seine Abfragefilterkriterien würden typischerweise irgendwo zwischen 1 und 5 Feldern umfassen, in einigen Fällen möglicherweise mehr. Während die als Filter ausgewählten Felder eine Teilmenge einer viel größeren Anzahl von Feldern wären. Stellen Sie sich etwa 20 vorhandene Feldnamen vor, und jede Abfrage ist ein Versuch, die Objekte nach wenigen Feldern aus diesen insgesamt 20 Feldern zu filtern (es können weniger oder mehr als 20 vorhandene Feldnamen vorhanden sein. Ich habe diese Zahl nur verwendet, um das Verhältnis von zu demonstrieren Felder zu Feldern, die in jeder diskreten Abfrage als Filter verwendet werden). Die Filterung kann durch das Vorhandensein der ausgewählten Felder sowie durch die Feldwerte erfolgen, z. B. durch Herausfiltern von Objekten mit Feld A, und ihr Feld B liegt zwischen x und y.

Meine Anwendung wird diese Art der Filterung kontinuierlich durchführen, während es keine oder nur eine sehr geringe Konstante dafür gibt, welche Felder zu irgendeinem Zeitpunkt für die Filterung verwendet werden. Vielleicht müssen in Elasticsearch Indizes definiert werden, aber vielleicht ist die Geschwindigkeit auch ohne Indizes mit der von MongoDB vergleichbar.

Laut den Daten, die in den Speicher gelangen, gibt es keine besonderen Details dazu. Die Objekte würden nach dem Einfügen fast nie geändert. Möglicherweise müssten alte Objekte gelöscht werden. Ich möchte davon ausgehen, dass beide Datenspeicher das Löschen von Inhalten intern oder durch eine von einer Anwendung vorgenommene Abfrage ablaufen lassen. (Weniger häufig müssen Objekte, die zu einer bestimmten Abfrage passen, ebenfalls gelöscht werden.)

Was denken Sie? Und haben Sie diesen Aspekt experimentiert?

Ich interessiere mich für die Leistung und Skalierbarkeit jedes der beiden Datenspeicher für diese Art von Aufgabe. Dies ist die Art einer architektonischen Entwurfsfrage, und Details zu geschäftsspezifischen Optionen oder Abfrage-Eckpfeilern, die eine gute Architektur ermöglichen sollen, sind als Demonstration eines vollständig durchdachten Vorschlags willkommen.

Vielen Dank!

Zunächst muss hier ein wichtiger Unterschied gemacht werden: MongoDB ist eine Allzweckdatenbank, Elasticsearch ist eine verteilte Textsuchmaschine, die von Lucene unterstützt wird. Die Leute haben darüber gesprochen, Elasticsearch als Allzweckdatenbank zu verwenden, wissen aber, dass es nicht das ursprüngliche Design war. Ich denke, dass Allzweck-NoSQL-Datenbanken und Suchmaschinen auf Konsolidierung ausgerichtet sind, aber derzeit stammen die beiden aus zwei sehr unterschiedlichen Lagern.

In meinem Unternehmen verwenden wir sowohl MongoDB als auch Elasticsearch. Wir speichern unsere Daten in MongoDB und verwenden Elasticsearch ausschließlich für die Volltextsuche. Wir senden nur eine Teilmenge der Mongo-Datenfelder, die wir abfragen müssen, an elastisch. Unser Anwendungsfall unterscheidet sich von Ihrem darin, dass sich unsere Mongo-Daten ständig ändern: Ein Datensatz oder eine Teilmenge der Felder eines Datensatzes kann mehrmals täglich aktualisiert werden, und dies kann eine Neuindizierung dieses Datensatzes auf elastisch erforderlich machen. Allein aus diesem Grund ist die Verwendung von Elastic als alleinigem Datenspeicher keine gute Option für uns, da wir ausgewählte Felder nicht aktualisieren können. Wir müssten ein Dokument in seiner Gesamtheit neu indizieren. Dies ist keine elastische Einschränkung. So funktioniert Lucene, die zugrunde liegende Suchmaschine hinter elastisch. In Ihrem Fall die Tatsache, dass Rekorde gewonnen haben ' Wenn Sie diese nach dem Speichern nicht mehr ändern, müssen Sie diese Auswahl nicht mehr treffen. Wenn es jedoch um Datensicherheit geht, würde ich zweimal darüber nachdenken, Elasticsearch als einzigen Speichermechanismus für Ihre Daten zu verwenden. Es kann irgendwann dort ankommen, aber ich bin mir nicht sicher, ob es noch da ist.

In Bezug auf die Geschwindigkeit ist Elastic / Lucene nicht nur mit der Abfragegeschwindigkeit von Mongo vergleichbar. In Ihrem Fall, in dem es "nur sehr wenig Konstanten gibt, welche Felder zu irgendeinem Zeitpunkt für die Filterung verwendet werden", kann dies auch in der Größenordnung liegen schneller, insbesondere wenn die Datensätze größer werden. Der Unterschied liegt in den zugrunde liegenden Abfrageimplementierungen:

• Elastic / Lucene verwenden das Vektorraummodell und invertierte Indizes für den Informationsabruf. Dies sind hocheffiziente Methoden zum Vergleichen der Datensatzähnlichkeit mit einer Abfrage. Wenn Sie Elastic / Lucene abfragen, kennt es die Antwort bereits. Der größte Teil seiner Arbeit besteht darin, die Ergebnisse für Sie nach den wahrscheinlichsten zu ordnen, die Ihren Abfragebegriffen entsprechen. Dies ist ein wichtiger Punkt: Suchmaschinen können im Gegensatz zu Datenbanken keine genauen Ergebnisse garantieren. Sie ordnen die Ergebnisse danach, wie nahe sie Ihrer Anfrage kommen. Es kommt einfach so vor, dass die Ergebnisse meistens nahezu exakt sind.
• Mongos Ansatz ist der eines allgemeineren Datenspeichers. Es vergleicht JSON-Dokumente miteinander. Sie können auf jeden Fall eine hervorragende Leistung erzielen, aber Sie müssen Ihre Indizes sorgfältig so gestalten, dass sie mit den Abfragen übereinstimmen, die Sie ausführen werden. Insbesondere wenn Sie mehrere Felder haben, nach denen Sie abfragen möchten, müssen Sie Ihre zusammengesetzten Schlüssel sorgfältig erstellendamit sie den Datensatz, der abgefragt wird, so schnell wie möglich reduzieren. ZB sollte Ihr erster Schlüssel den größten Teil Ihres Datensatzes herausfiltern, Ihr zweiter Schlüssel sollte weiter filtern, was noch übrig ist, und so weiter und so fort. Wenn Ihre Abfragen nicht mit den Schlüsseln und der Reihenfolge dieser Schlüssel in den definierten Indizes übereinstimmen, sinkt Ihre Leistung erheblich. Auf der anderen Seite ist Mongo eine echte Datenbank. Wenn Sie also Genauigkeit benötigen, sind die Antworten genau richtig.

Für das Ablaufen alter Datensätze verfügt Elastic über eine integrierte TTL-Funktion. Mongo hat es gerade ab Version 2.2 eingeführt, denke ich.

Da ich Ihre anderen Anforderungen wie erwartete Datengröße, Transaktionen, Genauigkeit oder das Aussehen Ihrer Filter nicht kenne, ist es schwierig, spezifische Empfehlungen abzugeben. Hoffentlich gibt es hier genug, um Ihnen den Einstieg zu erleichtern.