Skalierbare Anwendungen mit der richtigen Datenbank entwickeln: Azure Cosmos DB

Cloud-Technologien haben den Entwickleralltag in den letzten Jahren stark verändert und finden in immer mehr Anwendungen Einsatz. Eine besondere cloudbasierte Datenbanktechnologie, die ich in den letzten Wochen genauer unter die Lupe genommen habe, ist Azure Cosmos DB. In diesem Artikel möchte ich die Vorzüge dieser Technologie vorstellen und zeigen, warum sie für die Entwicklung von Web-Anwendungen besonders gut geeignet ist. Dazu werde ich auf die Funktionsweise eingehen zeigen, wie man die Cosmos DB konfiguriert.

Warum ist Azure Cosmos DB eine gute Wahl für die Entwicklung von Anwendungen?

Der von Microsoft bereitgestellte Azure Service ist durch seine Architektur sehr gut skalierbar. Die Daten lassen sich somit geografisch möglichst nah beim Nutzer speichern, damit der Datenzugriff ohne große Latenzen möglich ist. Bei Azure Cosmos DB handelt es sich um einen managed Service. Das bedeutet für die Nutzung muss kein Server inklusive Betriebssystem betrieben werden. Somit liegt der Fokus auf der Entwicklung mit Cosmos DB und die klassische Administration ist passé. Des Weiteren liegt die garantierte Verfügbarkeit bei 99,999%, wodurch sich die Datenbank hervorragend für den Einsatz in Anwendungen eignet, die auf eine hohe Verfügbarkeit ausgelegt sind.

Was ist die Azure Cosmos DB und wie unterscheidet sie sich von anderen Datenbanken?

In den meisten Fällen wird die Cosmos DB mit der NoSQL-API verwendet. Dadurch werden Entitäten in Form von JSON-Dokumenten abgelegt und nicht in tabellarischer Form, wie es beispielsweise bei SQL der Fall ist. Dieser Ansatz bietet die Möglichkeit die Daten flexibler auf Partitionen abzulegen, welche sich wiederum auf unterschiedlichen Servern befinden können. Die Speicherung der Entitäten in Form von Dokumenten ist schemalos. Anders gesagt gibt es Datenbank-seitig keine Möglichkeit festzulegen, welche Eigenschaft ein Eintrag beinhalten muss. Dies ist vor allem dann ungewohnt, wenn Sie vorher viel mit relationalen Datenbanken gearbeitet haben und die Strukturierung der Daten in diesen Umgebungen gewöhnt sind.

Von relationalen Datenbanksystemen kennt man die Option bei Spalten festzulegen, ob sie indiziert werden sollen. Durch die beschriebene Schemalosigkeit fällt diese Möglichkeit in der Cosmos DB weg. Damit die Abfragen schnell sind, werden alle Eigenschaften eines Dokuments indiziert. Kein Kopfzerbrechen mehr über primäre und sekundäre Indizes.

Beide Ansätze bieten einen großen Vorteil gegenüber herkömmlichen Datenbanksystemen: Flexibilität. Ohne Schema kann ein Objekt beliebig angepasst oder erweitert werden, ohne dass man sich um Datenbankmigrationen kümmern muss, um Code und Datenbanktabellen auf gleichen Stand zu bringen. Zudem wird kein OR-Mapper mehr benötigt, da die Objekte direkt als solche in der Datenbank gespeichert sind.

Welche Anwendungen profitieren von der Azure Cosmos DB?

Microsofts cloudbasierter Datenbankservice ist sehr vielseitig und lässt sich somit in diversen Anwendungsszenarien nutzen. Egal ob Web-Anwendungen, Apps, Spiele, KI-Software oder IoT Anwendungen - die Liste der Einsatzzwecke ist lang. Besonders profitieren die Anwendungen, welche sehr viele Daten verarbeiten oder die auf globaler Ebene viele Lese- und Schreibzugriffe verzeichnen. Durch die vertikale Skalierung kann sich die Azure Cosmos DB flexibel auf den aktuellen Bedarf anpassen.

Wie wird eine Azure Cosmos DB-Datenbank eingerichtet und konfiguriert?

Wie die zahlreichen anderen Azure Dienste lässt sich auch die Cosmos DB über das Azure Portal oder die Azure CLI einrichten und konfigurieren. Dabei sollte bei der Erstellung sollte auf einige Optionen geachtet werden, die sich zum Teil im Anschluss nicht mehr ändern lassen.

Auswahl der API

Die wohl wichtigste Entscheidung beim Anlegen einer Azure Cosmos DB Instanz ist die der genutzten API. Der Service bietet mehrere Schnitstellen an, über die die Daten transferiert und gespeichert werden.

• NoSQL: Microsofts eigene Implementierung eines Dokument-basierten Datenbanksystems. Dabei werden die Entitäten in Form von JSON-Dokumenten abgelegt. Wenn Sie Daten in Form von JSON-Dokumenten speichern möchten und keine starre Struktur benötigen, könnte die NoSQL-API die richtige Wahl sein. Sie eignet sich besonders für Anwendungen, die Flexibilität bei der Datenmodellierung benötigen.
• MongoDB: Open-Source Datenbanksystem für nicht relationale Entitäten. Legt die Daten im BSON Format ab. Wenn Sie bereits Erfahrung mit MongoDB haben oder eine Anwendung haben, die für diese Datenbank optimiert ist, könnte die MongoDB-API für Sie die beste Wahl sein.
• Apache Cassandra: Open-Source System, welches die Daten in einem sogenannten "wide-column store" speichert. Wenn Sie vor allem daran interessiert sind, große Datenmengen zu speichern und schnellen Zugriff darauf zu haben, könnte die Apache Cassandra-API für Sie geeignet sein.
• Table: Ein von Microsoft entwickelter Key-Value Store. Die Table-API ist besonders geeignet für Anwendungen, die auf Key-Value-Speicherung ausgelegt sind und schnellen Zugriff auf diese Daten benötigen.
• Apache Gremlin: Open Source Graph Datenbank. Basiert auf Apache TinkerPop. Wenn Sie Daten in Form von Graphen speichern und analysieren möchten, ist die Apache Gremlin-API die richtige Wahl.
• PostgreSQL: relationale Datenbank, die mit Hilfe von "Citus" verteilte Datenbanktabellen, verteile Abfragen usw. unterstützt. Wenn Sie bereits Erfahrung mit PostgreSQL haben oder eine Anwendung haben, die für diese Datenbank optimiert ist, könnte die PostgreSQL-API für Sie die beste Wahl sein. Sie eignet sich besonders für Anwendungen, die feste Datenstrukturen und die Möglichkeit zur Nutzung von SQL-Abfragen benötigen.

Es gibt nicht "die beste API". Die Entscheidung hängt von der beabsichtigten Verwendung und der bisher verwendeten Technologie ab.

Wahl des Capacity Modes

Bei der Erstellung einer Cosmos DB werden zwei Capacity Modes angeboten, zwischen denen man wählen kann. Ob man sich für Provisioned Throughput oder Serverless entscheidet, wirkt sich am stärksten bei der Abrechnung aus. Jeder Modus hat seine Vor- und Nachteile und welcher Modus zu der jeweiligen Anwendung passt, muss im Einzelfall entschieden werden. Dabei können folgendende Kriterien helfen:

Kriterium	Serverless	Provisioned Throughput
Geeignet für	Anwendungen, deren Nutzungsverhalten unvorhersehbar ist.	Anwendungen mit gleichbleibender, vorhersehbarer Auslastung.
Wie es funktioniert	Keine Konfiguration nötig; Datenbankabfragen können einfach gegen den Container ausgeführt werden.	Pro Container muss der Provisioned Throughput in Form von Request Units im Voraus festgelegt werden.
Speicherplatzbegrenzung	50 GB (zukünftig 1 TB)	Unbegrenzt
Bezahlung	Bezahlung pro Stunde; nur die RUs, die genutzt wurden	Bezahlung pro Stunde; alle RUs, die im Voraus bereitgestellt worden sind

Ausgaben limitieren und Kosten einsparen

Um die Kosten im Rahmen zu halten, bietet Microsoft beim Anlegen des Azure Services zwei Möglichkeiten an. Diese Optionen stehen nur im Capacity Mode "Provisioned throughput" zur Verfügung. Zum Einen bietet Microsoft einen "Free Tier Discount" an, der sich einmalig für einen Azure Cosmos DB Account pro Subscription aktivieren lässt. Dabei sind die ersten 1000 RU/s und 25 GB Speicher kostenfrei.

Zum Anderen gibt es die Option "Limit total account throughput". Diese ist standardmäßig aktiv und unterstützt die Kostenkontrolle, indem sie das festgelegte Durchsatzlimit nicht überschreitet.

Globale Verteilung der Daten

Je nach Region können unterschiedliche Optionen zur Verfügung stehen:

• Geo-Redundanz (nur für Provisioned Throughput): aktiviert die globale Verteilung der Daten, indem zwei Regionen miteinander gekoppelt werden (z. B. Westeuropa mit Nordeuropa)
• Multi-Region-Writes (nur für Provisioned Throughput): ermöglicht das weltweite Schreiben auf die Datenbank
• Availability Zones: erhöht die Verfügbarkeit der Anwendung durch die Verteilung der Datenbank auf mehrere Rechenzentren in der gleichen Region

Networking

Im Netzwerk-Bereich sollte die Einstellung zu den Verbindungsmöglichkeiten möglichst eng gefasst sein. Das bedeutet, dass man auf einen Zugriff aus allen Netzwerken heraus verzichten sollte und mittels Firewall oder den private Endpoints die Zugriffsmöglichkeiten festlegt.

Backup Policy

In der Azure Cosmos DB kann man sich zwischen zwei möglichen Backup-Modi entscheiden:

• Continuous: kontinuierliche Sicherung der Daten in jeder Region des Cosmos DB Accounts, Wiederherstellung über Azure Portal bzw. CLI eigenständig möglich
• Periodic: periodische Sicherung bis zu einem Monat, Wiederherstellung durch Kundenservice

Verschlüsselung

Standardmäßig werden Daten mit Hilfe eines Service-managed Keys verschlüsselt. Das bedeutet, dass die Daten, die in der Datenbank liegen ohne diesen Schlüssel nicht lesbar sind. Dieser Schutz lässt sich um eine zusätzliche Schicht erweitern, indem man einen Customer-managed Key (CMK) konfiguriert. Jedoch hat die Nutzung eines Customer-managed Keys Einfluss auf den Verbrauch von Request Units.

Fazit

Azure Cosmos DB hilft bei der Entwicklung skalierbarer, global verteilter Anwendungen, da die Technologie genau für dieses Szenario konzipiert wurde. Allerdings können die umfangreichen Konfigurationsoptionen anfangs überwältigend sein. Bisher habe ich die Cosmos DB mit der SQL-API verwendet und halte den Ansatz, Entitäten als JSON-Dokumente zu speichern, für sehr praktisch, wenn Sie programmatisch auf die Daten zugreifen. In diesem Szenario benötigen Sie keine OR-Mapper mehr, um den Datenzugriff zu steuern und die Datenbankmigrationen im Auge zu behalten. Allerdings müssen Sie darauf achten, dass Sie bei der Weiterentwicklung der Objekte weiterhin alte Konstellationen verarbeiten können, da es auf der Datenbankseite keine Validierung des Schemas gibt.