Table Storage ist eine zentrale Windows Azure-Speicherfunktion, die skalierbar ist (100 TB 200 TB 500 TB pro Konto), dauerhaft (dreifach im Rechenzentrum repliziert, optional in einem anderen Rechenzentrum georepliziert) und schemalos (jede Zeile kann beliebige Eigenschaften enthalten). Eine Zeile wird durch Partitionsschlüssel + Zeilenschlüssel lokalisiert, was eine sehr schnelle Suche ermöglicht. Der gesamte Zugriff auf den Tabellenspeicher erfolgt über eine klar definierte REST-API, die in jeder Sprache verwendet werden kann (mit SDKs, die auf den REST-APIs aufbauen und bereits für .NET, PHP, Java, Python und Ruby vorhanden sind).
MongoDB ist eine dokumentenorientierte Datenbank. Um es in Azure auszuführen, müssen Sie MongoDB auf einer Web-/Worker-Rolle oder einer virtuellen Maschine installieren, es auf ein Cloud-Laufwerk verweisen (wodurch ein Laufwerksbuchstabe bereitgestellt wird) oder eine angeschlossene Festplatte (für virtuelle Windows/Linux-Maschinen) und optional Journaling aktivieren (was ich empfehlen würde) und optional einen externen Endpunkt für Ihre Verwendung definieren (oder über ein virtuelles Netzwerk darauf zugreifen). Das Cloud-Laufwerk/der angeschlossene Datenträger wird übrigens tatsächlich in einem Azure-Blob gespeichert, wodurch Sie die gleiche Dauerhaftigkeit und Georeplikation wie Azure Tables erhalten.
Denken Sie beim Vergleich der beiden daran, dass Table Storage Storage-as-a-Service ist:Sie greifen einfach auf einen bekannten REST-Endpunkt zu. Bei MongoDB sind Sie für die Wartung der Datenbank verantwortlich (z. B. wenn MongoDB Inc (ehemals 10gen) eine neue Version von MongoDB veröffentlicht, müssen Sie Ihren Server entsprechend aktualisieren).
In Bezug auf die Alpha-Version von MongoDB Inc., auf die jtoberon verweist:Wenn Sie sie sich genau ansehen, werden Sie einige wichtige Dinge erkennen:
- Die Einrichtung gilt für eine eigenständige Mongodb-Instanz ohne Replikatsätze oder Shards. In Bezug auf Replikatsätze erhalten Sie aufgrund der Funktionsweise von Blob-Speicher immer noch mehrere Vorteile, wenn Sie die Standalone-Version verwenden.
- Um Hochverfügbarkeit bereitzustellen, können Sie mehrere Instanzen ausführen. In diesem Fall bedient nur eine Instanz die Datenbank, und eine ist ein „Warm-Standby“, das den Mongod-Prozess startet, sobald die andere Instanz ausfällt (für Wartungsneustart, Hardwarefehler usw.).
Während der Windows Azure-Wrapper von 10gen immer noch als „Alpha“ gilt, gilt dies für mongod.exe nicht. Sie können die Mongod-Exe genauso starten wie jede andere Windows-Exe. Es ist nur der Verwaltungscode rund um den Start, und das demonstriert die Alpha-Implementierung.
EDIT 2011-12-8:Dies ist kein Alpha-Stadium mehr. Sie können das neueste MongoDB+Windows Azure-Projekt hier herunterladen, das Unterstützung für Replikatsätze bietet.
Für die Leistung müssen Sie meiner Meinung nach ein Benchmarking durchführen. Beachten Sie jedoch Folgendes:
- Wenn Sie beispielsweise von einer Webrolle aus auf Table Storage oder MongoDB zugreifen, greifen Sie immer noch auf das Windows Azure Storage-System zu.
- MongoDB verwendet viel Arbeitsspeicher für seinen eigenen Cache. Aus diesem Grund werden viele hochskalierte MongoDB-Systeme in größeren Instanzgrößen bereitgestellt. Für den Zugriff auf den Tabellenspeicher müssen Sie nicht die gleiche Speichergröße berücksichtigen.
BEARBEITEN 7. April 2015 Wenn Sie eine dokumentenbasierte Datenbank as-a-Service nutzen möchten, bietet Azure jetzt DocumentDB an.
