So entscheiden Sie, ob MongoDB für Sie geeignet ist

In den letzten Jahren habe ich Webanwendungen rund um MongoDB erstellt. In diesem kurzen Artikel möchte ich einige der wiederkehrenden Fragen oder Missverständnisse beantworten, die die meisten Entwickler bei der Bewertung haben:

  • Was ist die Lizenzierung?
  • Was bedeutet es, dass MongoDB eine NoSQL-Datenbank ist?
  • Was ist mit MongoDB-Auftritten?

Lizenzierung

Ja, MongoDB ist unter der GNU AGPL v3.0 der Free Software Foundation lizenziert . In der Praxis bedeutet dies, dass Verbesserungen, die Sie an MongoDB vornehmen, für die Community freigegeben werden müssen. Der Quellcode aller abgeleiteten Arbeiten muss ebenfalls verteilt werden.

Sie fragen sich vielleicht, ob Ihre Anwendung eine abgeleitete Arbeit ist. Ich muss gestehen, dass ich nie eine einfache Definition eines solchen Begriffs gefunden habe. Im speziellen Fall von MongoDB erkennen sie jedoch einfach, dass Anwendungen, die ihre Datenbank verwenden, eine separate Arbeit sind. Darüber hinaus werden die unterstützten Treiber unter Apache License v2.0 veröffentlicht. Dies ist eine zulässige Lizenz. Sie müssen Ihren Quellcode nicht veröffentlichen, und Ihre Anwendung kommuniziert normalerweise nur mit MongoDB über einen Treiber.

Infolgedessen müssen Sie sich nicht um die Lizenzierung von MongoDB kümmern, um Ihre App darauf aufzubauen. Sie senden sogar unterschriebene Briefe, in denen sie das Versprechen bestätigen, an die Rechtsabteilungen, wenn es Fragen gibt. Sie bieten auch kommerzielle Lizenzen an, wenn der unterschriebene Brief nicht ausreicht.

Hinweis: Obwohl ich aufgrund dieser großen Erfahrung dieser Analyse vertraue, bin ich kein Anwalt. Die hier vorgestellte Ansicht ist mein persönliches Verständnis und keine offizielle.

NoSQL

Ja, MongoDB ist eine NoSQL-Datenbank. Dieses Wort kann ziemlich verwirrend sein. Ich werde versuchen, die gängigsten Ideen zu analysieren, wobei ich mich darauf konzentriere, wie dies für MongoDB gilt.

Dokumentorientiert

In herkömmlichen SQL-Datenbanken sind Daten in Form von Tabellen und Zeilen angeordnet. Jede Zeile hat eine feste Anzahl von Spalten, in denen nur Daten eines bestimmten Typs gespeichert werden können (z. B. Integer, Text, Datetime). Dies definiert das Schema Ihrer Daten.

In MongoDB werden Daten in Form von BSON-Objekten gespeichert, die in Sammlungen organisiert sind . Daten sindnormalerweise in Form von JSON-Objekten behandelt. Dies macht das Zuordnen von Objekten in die Datenbank zu einer einfachen Aufgabe, bei der normalerweise alles eliminiert wird, was einer objektrelationalen Zuordnung ähnelt .

Transaktion

Vor Version 4 stellte MongoDB nur dokumentweite Transaktionen bereit. Schreibvorgänge wurden niemals teilweise auf ein eingefügtes oder aktualisiertes Dokument angewendet. Die Operation war atomar in dem Sinne, dass sie entweder fehlschlägt oder erfolgreich ist. Für das gesamte Dokument wurde auf Dokumentebene ACID angegeben. Infolgedessen gab es keine Möglichkeit für atomare Änderungen, die mehrere Dokumente umfassen. Sie mussten die erforderlichen Datenbanktransaktionen emulieren (z. B. mit 2-Phasen-Commit).

Seit Version 4 unterstützt MongoDB ACID-Transaktionen mit mehreren Dokumenten. Damit ist es die einzige Open-Source-Datenbank, die das Dokumentmodell mit ACID-Garantien kombiniert.

Schema-frei (wirklich?)

Dies bedeutet, dass Sie der Datenbank nicht die Struktur Ihrer Daten und die zu verwendenden primitiven Typen mitteilen müssen, bevor Sie sie verwalten können. Dies bedeutet auch, dass Sie Dokumente mit unterschiedlichen Strukturen in derselben Datensammlung mischen können.

Einer der großen Vorteile besteht darin, dass Schemamigrationen einfacher werden (die meisten Anpassungen an der Datenbank sind transparent und automatisch). Es ist unwahrscheinlich, dass ein Rollback Probleme verursacht. Ein weiterer Vorteil besteht darin, dass die dynamische Erweiterung vorhandener Datenmodelle mit benutzerdefinierten Attributen zur Laufzeit unkompliziert ist .

AberAll dies bedeutet nicht, dass Sie überhaupt kein Schema haben. Wenn es nicht explizit deklariert ist, leuchtet es implizit aus Ihrer Anwendungslogik. Es kann auf andere Weise deklariert werden, um die Formular- / Datenüberprüfung durchzuführen. Auf jeden Fall müssen Sie der Datenbank noch explizit mitteilen, wie Indizes erstellt werden sollen, um eine gute Leistung sicherzustellen.

In der Tat ist das Schemadesign der Grundstein für die Erstellung großartiger Datenbanken, egal ob SQL oder nicht. Wenn Sie Ihre Daten und die Einschränkungen von Hardware und Software nicht verstehen, können Sie ein Schema nicht effektiv entwerfen.

Nicht relational (wirklich?)

Dies bedeutet, dass Sie nicht immer eine Beziehung zwischen zwei Dokumenten erstellen müssen, um aggregierte Datenstrukturen zu verarbeiten.

In relationalen Datenbanken können Sie mit der SQL JOIN-Klausel Zeilen aus zwei oder mehr Tabellen mithilfe eines gemeinsamen Felds kombinieren. Dokumentorientierte Datenbanken wie MongoDB dienen zum Speichern denormalisierter Daten. Im Idealfall sollte keine Beziehung zwischen Sammlungen bestehen: Wenn dieselben Daten in zwei oder mehr Dokumenten erforderlich sind, müssen sie wiederholt werden. Einer der großen Vorteile besteht darin, dass ein einziger Lesevorgang erforderlich ist, um alle Daten abzurufen.

Sie können jedoch weiterhin Beziehungen erstellen und auf ein anderes Dokument verweisen, wenn Sie möchten oder benötigen:

  • Nach ID können Sie es dann manuell mit einer zweiten Abfrage oder mithilfe von DBRefs „füllen“
  • In jedem anderen Feld können Sie den $lookupOperator verwenden

Dies macht MongoDB sehr flexibel und ermöglicht es Ihnen, von Fall zu Fall zu entscheiden, wie die Beziehungen zwischen Ihren Objekten behandelt werden sollen .

Performance

Lesen Schreiben

Ja, MongoDB ist wie jede andere „echte“ Datenbank für die Verarbeitung eines großen Datenvolumens ausgelegt. Kurz gesagt, Hunderte oder Tausende von Objekten sind nichts für eine Datenbank, sodass Sie sich keine Sorgen machen müssen, wenn Sie über solche Zahlen verfügen. Sie können viele Benchmarks finden. Hier ist eine einfache, um Ihnen eine grobe Größenordnung zu geben. Die gespeicherten Dokumente sind sehr einfach und stellen normalerweise eine Messung mit Zeitstempel dar:

{ value: random(0,100), timestamp: date}

Aufgrund der Art und Weise, wie MongoDB die Speicherverwaltung an das Betriebssystem delegiert, wirken sich komplexere Dokumente (die normalerweise mehrere zehn Attribute enthalten) nicht wesentlich auf die Ergebnisse aus

Beide Attribute wurden indiziert. MongoDB fügt die eindeutige ID des Dokuments automatisch hinzu und indiziert sie. Ich habe drei Anfragen getestet:

  • Ermitteln Sie den Maximalwert der Sammlung mithilfe des Aggregationsframeworks
  • Finden Sie die 100 größten Werte größer als 99,9
  • Holen Sie sich ein einzelnes Dokument per ID

Die "maximale Anforderung" profitiert aufgrund der Aggregation nicht von Indizes, während die Anforderungen "größer als" und "nach ID" sie verwenden können. Sie werden sehen, wie wichtig dies für die Leistung ist.

Die Testkonfiguration war MongoDB 3.4.1 64 Bit - Betriebssystem Windows 7 Pro SP1 - CPU Core i7–4712HQ 2,3 GHz - 16 GB RAM - SSD HD. Die Testergebnisse waren die folgenden:

Wenn Sie also die richtigen Indizes erstellen, die eine Milliarde Dokumente abfragen, ist diese für die meisten Anwendungen auf einem einzelnen Server immer noch leistungsfähig genug. Bei Bedarf können Sie die Leistung mithilfe von Sharding steigern.

Here are the scripts used to create/query the database for this test:

And the run commands:

// Launch server./mongod --dbpath "C:\Program Files\MongoDB\Server\3.4\data" --port 27018// Insertion exemple for 10e7./mongo --port 27018 --eval "var arg1=10000000" create_collection.js// Requests./mongo --port 27018 --eval "" query_collection.js

Memory

Yes, MongoDB often looks like it uses all available RAM. It actually relies on different storage engines. WiredTiger is the default starting in MongoDB 3.2, and MMAPv1 is the default for MongoDB versions before 3.2. However, they work pretty similarly. Via the file system cache, they automatically use all free memory that is not used by the engine cache or by other processes. And this is coherent if you’d like to have maximum performances.

So system resource monitors often show that MongoDB uses a lot of memory, but its usage is dynamic. If another process suddenly needs half the server’s RAM, MongoDB will yield cached memory to the other process.

As a consequence, the single parameter you can tune to optimize memory usage is the engine cache size. For example, by default, the WiredTiger engine uses 50% of RAM minus 1 GB, which can be pretty large on servers with a lot of memory. This can even cause some trouble if you use containers with limited memory, so simply find out the right balance for your use case.

Conclusion

I hope you know have a more precise idea of the benefits provided by MongoDB if it suits your needs. Recently, MongoDB has started a Database as a Service offer called MongoDB Atlas that might be useful for you to test out.

If you liked this article feel free to have a look at our Open Source solutions, the Kalisio team !