Widerlegung der wichtigsten Mythen rund um MongoDB im Vergleich zu relationalen Datenbanken

Ich habe mich neulich mit einem Freund darüber unterhalten, welche Datenbank wir für ein bevorstehendes Projekt wählen sollen. Ich fragte ihn nach seiner Meinung zu MongoDB. Er sagte mir, dass er nicht glaube, dass es funktionieren würde, basierend auf dem, was er darüber wusste. Das einzige Problem war, dass alles, was er über MongoDB wusste, aus dem Jahr 2013 stammte. Er hatte die Verbesserungen und Updates von mehr als einem Jahrzehnt nicht mitverfolgt. Nach Gesprächen mit anderen Entwicklern scheint dies eine recht häufige Situation zu sein. Viele Entwickler haben 2012-2014 zum ersten Mal Berührung mit MongoDB gehabt und sich daraufhin ihre Meinung gebildet. In diesem Beitrag werden wir uns mit der Datenbankgeschichte befassen und untersuchen, wie sich MongoDB heute im Vergleich zu relationalen Datenbanken verhält.

Zur kurzen Auffrischung: Es gibt eine Reihe von Arten von Datenbanken, aber wir konzentrieren uns auf relationale Datenbanken und NoSQL-Dokumentendatenbanken, da dies zwei der heute am häufigsten verwendeten Typen sind. Relationale Datenbanken wurden in den 1970er Jahren eingeführt und speichern Daten in Tabellen. Während der Begriff NoSQL im Jahr 1998 von Carlo Strozzi geprägt wurde, dauerte es noch einige Jahre, bis NoSQL-Datenbanken und ihr flexiblerer Ansatz zur Datenspeicherung sich wirklich durchsetzten. Im Jahr 2009 startete MongoDB mit der Idee, Daten in Dokumenten zu speichern, die JSON-Objekten ähneln. Wenn ich meiner Familie den grundlegenden Unterschied zwischen relationalen Datenbanken und Dokumentendatenbanken erkläre, sage ich normalerweise, dass die eine wie eine Tabellenkalkulation und die andere wie ein Google Doc ist. Ich bin mir immer noch nicht sicher, wie viel meine Großmutter von meiner Arbeit versteht, aber zumindest kennt sie jetzt den Unterschied zwischen den Datenbanktypen.

Okay, nachdem wir nun die Grundlagen behandelt haben, schauen wir uns mal die Missverständnisse an, die beim Vergleich von MongoDB mit relationalen Datenbanken auftauchen.

Mythos 1: MongoDB hat kein Schema

Schemata definieren die Struktur von Daten in einer Datenbank. Bei relationalen Datenbanken entwerfen Sie Ihr Schema in der Regel auf der Grundlage der Normalisierung Ihrer Daten. Normalisierung bedeutet, dass Sie Ihre Daten in verschiedene Tabellen aufteilen, damit keine Daten dupliziert werden. Diese definierten Schemata sind großartig, wenn Sie alle Ihre zukünftigen Datenanforderungen vorhersehen und sie elegant im Voraus entwerfen können. Das Aktualisieren dieser Schemata, um neue Felder hinzuzufügen, kann für Ihre Anwendung zusätzlichen Arbeitsaufwand und Ausfallzeiten bedeuten.

Bei MongoDB hängt Ihr Schema von den Anforderungen Ihrer Anwendung ab. Dies ist ein flexiblerer Ansatz für das Schema-Design. Obwohl es Flexibilität gibt, gibt es immer noch Best-Practices wie die Regel, dass „Daten, die zusammen abgerufen werden, gemeinsam gespeichert werden sollten.“

Hier ist ein Beispiel für die oben genannten relationalen Daten, die in MongoDB gespeichert sind:

In diesem Beispiel sehen Sie, dass Sie alle Daten zu „Paul Miller“ abrufen können, ohne JOINS über drei verschiedene Tabellen ausführen zu müssen. Sie können in MongoDB JOINS ausführen, aber dazu später mehr.

Mit einem flexiblen Schema können Entwickler Anwendungen erstellen, ohne das definitive Schema im Voraus entwerfen und sich anschließend darauf festlegen zu müssen. Sie können Ihrem Schema ganz einfach neue Felder hinzufügen, wann immer die Anwendung es erfordert. Wenn Sie ein strukturierteres Schema benötigen, können Sie die Funktion zur Schemavalidierung von MongoDB verwenden. Wenn sich Ihr Schema im Laufe der Zeit weiterentwickeln muss, können Sie auch problemlos das Muster zur Schemaversionierung implementieren.

Letztendlich denke ich, dass dieser Mythos, dass MongoDB kein Schema hat, auf zwei Dinge zurückzuführen ist. Erstens gab es früher keine Schemavalidierung (sie wurde in Version 3.6 im Jahr 2017 hinzugefügt). Der zweite Grund ist die Flexibilität, die Entwickler bei der Erstellung ihres Schemas basierend auf den Anforderungen ihrer Anwendungen haben. Freiheit und Flexibilität bedeuten nicht, dass kein Schema vorhanden ist. Es bedeutet lediglich, dass es wichtig ist, bewährte Verfahren zu befolgen, um ein elegantes Schema zu erstellen, mit dem Ihre Anwendung optimal ausgeführt wird.

Mythos 2: MongoDB ist nicht ACID-konform

Datenbanken benötigen Wege, um sicherzustellen, dass Abläufe und die daraus resultierenden Daten zuverlässig sind, auch wenn Fehler auftreten oder Stromausfälle vorkommen. Der wichtigste Weg, dies zu erreichen, ist die Implementierung von vier Eigenschaften: Atomizität, Konsistenz, Isolation und Dauerhaftigkeit, auch als ACID bekannt.

MongoDB ist ACID-konform. Bei jeder Create-, Read-, Update- und Delete-Operation an einem einzelnen Dokument bleibt die Datenintegrität gewahrt. MongoDB verarbeitet Daten ein Dokument auf einmal. Andernfalls wäre es keine Dokumentendatenbank. Es wäre eine chaotische, unvorhersehbare Datenbank. Können Sie sich vorstellen, dass viele Autoren versuchen, dasselbe Dokument gleichzeitig zu überschreiben? Ich war schon in einigen Google Docs mit mehr als 10 Autoren, die alle gleichzeitig ihren Beitrag geleistet haben, und das fühlt sich sicherlich nicht wie eine ACID-Konformität an.

Das betrifft zwar einzelne Dokumente, aber was ist mit Transaktionen für mehrere Dokumente? Transaktionen mit mehreren Dokumenten werden häufig in relationalen Datenbanken verwendet, da Sie oft auf mehrere Tabellen zugreifen müssen, wenn Sie beispielsweise einen Kundendatensatz aktualisieren. MongoDB garantiert ACID-Transaktionen mit mehreren Dokumenten von und zu jedem Standort in Ihrem MongoDB-Cluster. Diese Garantie bietet es seit der Version 4.0 aus dem Jahr 2018.

Tatsächlich ist die Transaktionalität eine der größten Stärken von MongoDB. Viele Finanzdienstleistungsunternehmen vertrauen auf MongoDB-Transaktionen für Kernbanken- und Handelsanwendungsfälle. Die Alles-oder-Nichts-Garantie von MongoDB-Multidokumenttransaktionen ist auf Ihrer Seite.

Mythos 3: MongoDB kann keine JOINs durchführen, um relationale Daten zu verarbeiten

Zuvor haben wir dargelegt, wie relationale Datenbanken für ein effizientes Schema-Design auf die Verteilung von Daten auf mehrere Tabellen zurückgreifen. Um mit relationalen Daten zu arbeiten, müssen Sie oft Daten aus diesen Tabellen abrufen und sie mithilfe von JOINS kombinieren.

MongoDB kann JOINS mit dem $lookup-Befehl durchführen. Doch die Tatsache, dass man etwas tun kann, bedeutet nicht, dass man es tun sollte. MongoDB-Daten werden anders modelliert als relationale Daten. In MongoDB werden Daten, auf die zusammen zugegriffen wird, gemeinsam gespeichert. Da sich die meisten Daten in einem einzigen Dokument befinden und nicht auf mehrere Tabellen verteilt sind, müssen Sie keine JOINs durchführen, da die Daten bereits am richtigen Ort sind. Diese Umstellung vom relationalen Modell auf das Dokumentmodell erfordert ein Umdenken, aber sobald Sie die Vorteile erkannt haben, möchten Sie diese nicht mehr missen. Wenn Sie jedoch immer noch JOINS mit MongoDB durchführen müssen, ist der Befehl $lookup Ihr bester Verbündeter. Sie können sogar eine VIEW (hinzugefügt im Jahr 2016) erstellen, um zwei Sammlungen zu verbinden.

Der Mythos, dass JOINS nicht möglich sind, lässt sich letztlich auf den grundlegenden Unterschied zwischen den relationalen und den Dokumentmodellen zurückführen. Daten, auf die in Tabellen zugegriffen wird, und Daten, auf die in Dokumenten zugegriffen wird, erfordern unterschiedliche Ansätze, aber im Allgemeinen, auch wenn Sie JOINS in MongoDB durchführen können, benötigen Sie dies nicht, wenn Sie das Schema für Ihre Dokumente gut entworfen haben.