Azure DocumentDB vs. MongoDB

Ein synthetischer Vergleich

DocumentDB ist eine NoSQL-Datenbank als Dienst, die Teil der Microsoft Azure-Plattform ist. Als Dokumentenspeicher fällt er in dieselbe Kategorie wie MongoDB, CouchDB oder RethinkDB und verarbeitet wie diese Dokumente im JSON-Format.

Wenn man die Integration eines NoSQL-Dokumentenspeichers in ihre Systeme in Betracht zieht, entscheiden sich viele Unternehmen für MongoDB, da es zu den beliebtesten NoSQL-Engines überhaupt gehört und in den letzten Jahren sehr zuverlässig geworden ist. Ich bin der Meinung, dass DocumentDB bei dieser Entscheidung normalerweise nicht berücksichtigt wird, obwohl es aufgrund seiner Eigenschaften ein ernstzunehmender Konkurrent von MongoDB ist und in einigen Situationen sogar stärkere Vorteile bietet.

Da ich der Meinung bin, dass DocumentDB nicht die Liebe erhält, die es verdient, habe ich mich dazu entschlossen, diesen synthetischen und unvoreingenommenen Vergleich zwischen DocumentDB und MongoDB zu schreiben, der durch Verweise auf die jeweiligen Dokumentationen unterstützt wird. Ich hoffe, dies kann Ihnen als Leitfaden dienen, wenn Sie versuchen, die Vor- und Nachteile jeder Plattform zu gewichten.

Aktualisierungen für diesen Beitrag

[November 2016] Alle Erwähnungen des Fehlens eines lokalen Emulators für DocumentDB wurden entfernt, als Microsoft die allgemeine Verfügbarkeit einer solchen lokalen Entwicklungsversion ankündigte. Beachten Sie, dass der lokale Emulator derzeit nur für Windows verfügbar ist (danke David Mason für die vorgeschlagene Bearbeitung!).

[November 2016] Die Erwähnung von automatisch ablaufenden Dokumenten, die nur in DocumentDB verfügbar sind, wurde entfernt, da Bo Bendtsen freundlicherweise darauf hinwies, dass MongoDB über ähnliche Funktionen verfügt.

[Januar 2017] Es wurde ein Abschnitt über die integrierte Sicherheit von DocumentDB hinzugefügt, wie von Mary Branscombe vorgeschlagen.

Die Ähnlichkeiten

Konzeptionell gibt es einige grundlegende Ähnlichkeiten zwischen den beiden Datenbanken:

  • Dokumente werden im JSON-Format gespeichert und bereitgestellt
  • Dokumente können mit einer umfangreichen Abfragesprache abgerufen werden, die mit der JSON-Syntax gut kompatibel ist

Einzigartige Funktionen für MongoDB

Beginnen wir mit der Aufzählung der wichtigsten MongoDB-Funktionen, für die es kein (angemessen übereinstimmendes) Gegenstück zu DocumentDB gibt.

Umfangreiche Abfragefunktionen mit der Aggregationspipeline

Die Aggregationspipeline von MongoDB ist eine sehr leistungsstarke Funktion, mit der Sie eine Pipeline aus Datenverarbeitungsstufen erstellen können, die die aus einer Sammlung stammenden Dokumente filtern und transformieren. Die Möglichkeiten, die diese Pipeline bietet, sind nahezu unbegrenzt und ihre Flexibilität kann praktisch jede Art von Abfrage erfüllen.

Im Vergleich dazu ermöglicht die SQL-ähnliche Abfragesyntax von DocumentDB nur ein einfaches Filtern der Dokumente, selbst wenn „einfache“ Konstrukte wie count oder sum fehlen (obwohl sie daran arbeiten und Sie in der Zwischenzeit mit serverseitigem Javascript umgehen können). Ein praktisches Abfrage-Spickzettel finden Sie hier.

Karte verkleinern

Ähnlich wie bei der Aggregationspipeline werden die Dokumente einer Sammlung durch die Kartenreduzierungsfunktion von MongoDB in zwei separaten Schritten verarbeitet, die iterativ transformiert (oder projiziert) und anschließend gruppiert werden. Beide Stufen sind in Javascript definiert.

In DocumentDB gibt es kein solches Konzept, obwohl mit gespeicherten Prozeduren ähnliche Ergebnisse erzielt werden können (siehe unten).

Volltextindizes

Unter den verschiedenen in MongoDB verfügbaren Indextypen bietet der Textindex Volltextsuchfunktionen.

DocumentDB bietet keine Volltextindizierung. Die empfohlene Methode zum Hinzufügen der Volltextsuche zu einer DocumentDB-Datenbank besteht darin, sie mit einem Azure Search-Dienst zu koppeln. Es gibt eine gute Integrationsgeschichte zwischen den beiden.

Weitere Plattformen, die von clientseitigen Treibern unterstützt werden

Ich denke, es ist wichtig zu erwähnen, dass die Treiber von MongoDB ein sehr großes Spektrum an Plattformen unterstützen, während DocumentDB nur SDKs für .NET, Java, Python und Node.js enthält. Dank der Unterstützung können Sie jedoch versuchen, jeden MongoDB-Treiber mit DocumentDB zu verwenden für das MongoDB-Protokoll.

Funktionen, die nur in DocumentDB verfügbar sind

Führen Sie nun die umgekehrte Übung durch und listen Sie die Funktionen von DocumentDB auf, die in MongoDB nicht vorhanden sind.

Serverseitiges Javascript

Dies ist eine wichtige Funktion von DocumentDB. Es verfügt über eine umfangreiche serverseitige Javascript-API, mit der Sie Datenverarbeitungsfunktionen erstellen können. Diese serverseitigen Funktionen können drei verschiedene Formen annehmen:

  • gespeicherte Prozeduren, die so ziemlich alles können (Einfügen, Abfragen, Aktualisieren von Dokumenten) und über die SDKs oder die REST-API aufgerufen werden
  • Trigger (oder Hooks), die vor oder nach bestimmten Vorgängen ausgeführt werden (z. B. beim Einfügen eines Dokuments)
  • UDFs (benutzerdefinierte Funktionen), die in der SQL-Abfragesprache aufgerufen und erweitert werden können, verringern die Lücke zu den umfangreichen Abfragefunktionen von MongoDB

Jetzt kann MongoDB auch serverseitiges Javascript ausführen, aber ich verstehe, dass:

  • Map-Reduce und der $ where-Abfrageoperator können nur für Abfragen verwendet werden, nicht für Aktualisierungen
  • Die Javascript-Funktionen, die Sie in der speziellen Systemsammlung ablegen können, sind nur für Administrations- oder Wartungszwecke geeignet.

In der MongoDB-Dokumentation ist eindeutig angegeben, dass die Ausführung von serverseitigem Javascript Leistungseinschränkungen aufweist. Im Vergleich dazu ist DocumentDB wirklich für diesen Zweck konzipiert, da es Ihren Javascript-Code vorkompiliert, dann den resultierenden Bytecode speichert und ausführt.

Transaktionen

Dank der soeben erwähnten gespeicherten Javascript-Prozeduren ist es möglich, ACID-Transaktionen für eine DocumentDB-Auflistung auszuführen. Die Funktionsweise ist denkbar einfach: Wenn Ihre Javascript-Funktion abgeschlossen ist, werden alle von ihr ausgeführten Schreibvorgänge festgeschrieben. Wenn die Funktion eine Ausnahme auslöst, werden alle Vorgänge zurückgesetzt.

In MongoDB gibt es eigentlich kein Transaktionskonzept außer der Atomizität einzelner Dokumente. Das bedeutet, dass das Einfügen oder Aktualisieren eines Dokuments garantiert atomar ist, aber ein Schreibvorgang mit mehreren Dokumenten ist nicht atomar als Ganzes.

Standardmäßig vollständige Indizierung

DocumentDB geht bei der Indizierung ziemlich drastisch vor: Standardmäßig indiziert es alle Felder der Dokumente, die Sie speichern! Viele von Ihnen sehen dies möglicherweise als Verschwendung von Verarbeitungszeit und Speicherplatz an - was in gewissem Maße tatsächlich der Fall ist -, aber dies bietet den interessanten Vorteil, dass sofort eine hervorragende Abfrageleistung geboten wird. Für diejenigen, die eine bessere Kontrolle darüber haben möchten, was indiziert wird, ist es immer möglich, benutzerdefinierte Indizierungsrichtlinien zu definieren.

(Einfache) weltweite Verbreitung

Eine weitere ziemlich neue Erweiterung der Funktionen von DocumentDB ist die globale Verteilung. Grundsätzlich können Sie mit dieser Funktion Ihre DocumentDB-Instanz über verschiedene Regionen auf der ganzen Welt hinweg skalieren und definieren, welche Art von Konsistenz Sie zwischen den Regionen erwarten, von stark bis schließlich. Es ist sogar möglich, ein automatisches und transparentes Failover für die verschiedenen Regionen zu konfigurieren.

Natürlich ist die Bereitstellung eines weltweiten Clusters von MongoDB-Knoten durchaus möglich, aber ich möchte hier betonen, wie einfach es ist, einen solchen Cluster einzurichten. Dies geht offensichtlich über die Kernfunktionen von DocumentDB hinaus und hängt mit seiner PaaS-Natur zusammen, aber ich glaube nicht, dass es einen Dienstanbieter gibt, der ein solches geoverteiltes Setup für MongoDB anbietet (zu diesem Preis und mit dieser Benutzerfreundlichkeit).

Sicherheit

Erwähnenswert ist, dass DocumentDB als Dienst standardmäßig integrierte Sicherheits- und Zugriffssteuerungsfunktionen bietet. Kein passwortloser Administratorzugriff! Darüber hinaus besteht die Möglichkeit, den Zugriff auf Sammlungen und Dokumente detailliert zu steuern, indem Benutzer erstellt und über kennwortgeschützte Berechtigungen mit diesen Ressourcen verknüpft werden.

Preisgestaltung

Das letzte, aber nicht zuletzt zu berücksichtigende Vergleichskriterium sind die Kosten. Wir sollten jedoch darauf achten, hier keine Äpfel und Apfelsinen zu vergleichen: DocumentDB gehört zur PaaS-Familie, während MongoDB eine Datenbank und kein Service ist. Nehmen wir zum Vergleich mLab, ein MongoDB-PaaS-Angebot.

Zunächst sollte ich klären, wie DocumentDB abgerechnet wird. Jede Kollektion wird in 2 Dimensionen abgerechnet:

  • Speicherplatz verwendet, bei 0,25 USD pro GB / Monat
  • reserviert Anfrage Einheiten pro Sekunde, zu ~ 6 USD pro 100 RU / Monat

Die Anzahl der RU, die Sie reservieren, bestimmt die garantierte Bandbreite, die Sie erhalten (weitere Informationen zu Request Units finden Sie in meinem Posting!). Grundsätzlich steht ein RU für „die Verarbeitung, die zum Lesen eines einzelnen 1-KB-Dokuments mit 10 Eigenschaften erforderlich ist“. Abgesehen davon ist es nicht einfach, die tatsächlichen Kosten komplexer Vorgänge wie großer Abfragen oder komplexer gespeicherter Prozeduren zu ermitteln, obwohl dieser Leitfaden sehr hilfreich ist. Wir können jedoch die umgekehrte Übung durchführen, indem wir uns ansehen, wie viele RU wir für den Preis eines mlab-Plans erhalten könnten.

Was ich bisher nicht erwähnt habe, ist, dass DocumentDB auf lokaler SSD ausgeführt wird. Um einen fairen Vergleich zu ermöglichen, nehmen wir den Plan „High Performance M3“ von dieser Seite, der zum Zeitpunkt dieses Schreibens (September 2016) vorliegt Der Preis beträgt monatlich 1.390 USD für 80 GB Speicherplatz.

  • Diesen 80 GB würden 20 USD auf DocumentDB in Rechnung gestellt
  • Damit bleiben 1.370 USD oder mehr als 22.800 RU übrig

Ich habe bereits erwähnt, dass es schwierig ist, den „Wert“ eines EVU zu bewerten, aber meiner Erfahrung nach sind 22.800 viel, was im Bereich von 200 komplexen Abfragen pro Sekunde liegt. Und obwohl es ähnlich schwierig ist, die Fähigkeiten dieses „High Performance M3“ -Pakets zu bewerten, würde ich sagen, dass wir in einem ähnlichen Maßstab spielen oder zumindest nicht um Größenordnungen voneinander abweichen.

An der Elastizität von RU ist außerdem zu erwähnen, dass es sich um eine Maßeinheit handelt. Dies bedeutet, dass Sie mit einer bescheidenen Menge von RU beginnen und diese (nahtlos) skalieren können, wenn die Nutzung Ihrer Sammlungen zunimmt Von Anfang an die lokale SSD-Leistung nutzen.

Was ist mit den Kosten für die Lieferantenbindung?

Viele äußern sich besorgt über die Anbietersperre: Wenn ich DocumentDB verwende, bin ich nicht nur mit Microsoft, sondern auch mit Azure als Plattform gesperrt. Sie könnten sogar argumentieren, dass das Fehlen einer solchen Sperre in den Vorteilen von MongoDB gegenüber DocumentDB aufgeführt sein sollte. Genau. Aber wie hoch sind die tatsächlichen Kosten für diese Sperre?

DocumentDB speichert Dokumente im JSON-Format. Dies ist ein Standardformat, das von den meisten NoSQL-Datenbanken verwendet wird (hey, sogar SQL Server spricht JSON!). Daher sollte es kein Problem sein, Ihre Dokumente aus DocumentDB zu verschieben und sie in eine andere Datenbank einzufügen.

Das wichtigste technische Problem, mit dem Sie sich befassen müssen, ist die Abfrageschnittstelle: Jede Datenbank hat ihre eigene Art, Dokumente abzufragen. In den meisten Fällen führen Sie diese Abfragen über ein SDK oder einen Treiber aus. Aus Sicht Ihres Anwendungscodes erfolgt die Sperrung oder Einhaltung einer bestimmten Datenbank also hauptsächlich über die Schnittstelle dieses SDK. Wenn Ihre Entwickler es jedoch richtig machen, sollte diese Schnittstelle hinter einer Art Datenzugriffsschnittstelle gekapselt sein, die die Implementierungsdetails für den Rest der Anwendung verbirgt.

Wenn Sie befürchten, dass Sie zu einem späteren Zeitpunkt zu MongoDB migrieren möchten, denken Sie daran, dass DocumentDB mit MongoDB protokollkompatibel ist. Dies bedeutet, dass Sie einen beliebigen MongoDB-Treiber verwenden können, um auf DocumentDB zuzugreifen und die meisten CRUD-Vorgänge auszuführen.

Wie empfehle ich, um Ihre Entscheidung zu führen

Abschließend sind hier die ersten Fragen, die Sie sich stellen könnten, wenn Sie eine Auswahl zwischen diesen Datenbanken treffen müssen (in keiner bestimmten Reihenfolge):

  • Komplexität von Abfragen: Benötigen Ihre Abfragen die volle Leistungsfähigkeit der MongoDB-Aggregationspipeline oder können Sie sie mit DocumentDBs SQL und etwas serverseitigem Javascript implementieren?
  • Transaktionen: Erfordert Ihre Geschäftslogik sammlungsweite Transaktionen mit mehreren Dokumenten, oder ist MongoDBs Atomizität mit nur einem Dokument für Ihre Anforderungen ausreichend?

Anhand Ihrer Antworten und der allgemeinen Anweisungen können Sie dann Ihre Analyse verfeinern und die restlichen von mir erwähnten Funktionen (Volltextsuche, globale Verteilung usw.) berücksichtigen.

Bitte kommentieren!

Ich habe versucht, diesen Vergleich auf die ehrlichste und unvoreingenommenste Weise durchzuführen, aber in einigen Aspekten könnte ich mich irren. Wenden Sie sich an uns, wenn Sie das Gefühl haben, dass einige Funktionen fehlen oder über- oder unterschätzt wurden! Ich beabsichtige, diesen Beitrag im Laufe der Zeit weiterzuentwickeln und zu ergänzen, um eine gute Referenz für den Vergleich zwischen DocumentDB und MongoDB zu werden.

Danke fürs Lesen!