Serverlose Datenbanken: Ein tiefer Einblick in DynamoDB und Cosmos DB

Der Aufstieg des Serverless Computing hat die Art und Weise, wie Unternehmen Anwendungen erstellen und bereitstellen, grundlegend verändert. Durch die Abstraktion des Servermanagements können sich Entwickler auf das Schreiben von Code und die Bereitstellung von Funktionen konzentrieren, anstatt Hardware bereitzustellen. Zu den wichtigsten Komponenten in diesem Paradigma gehören serverlose Datenbanken, die On-Demand-Skalierung, Pay-per-Use-Preise und Hochverfügbarkeit ohne operativen Overhead bieten. Zwei führende Cloud-Anbieter bieten leistungsstarke serverlose Datenbanklösungen: Amazon DynamoDB (AWS) und Azure Cosmos DB (Microsoft). Beide sind vollständig verwaltete, global verteilte NoSQL-Datenbanken, aber sie unterscheiden sich in Architektur, Konsistenzmodellen, Indexierung und Integrationsökosystemen. Dieser tiefe Tauchgang untersucht jeden Dienst im Detail, vergleicht ihre Stärken und Kompromisse und bietet Anleitung für die Auswahl des richtigen Tools für Ihre Workload.

Was sind serverlose Datenbanken?

Serverlose Datenbanken sind Datenbankdienste, die automatisch Infrastrukturaufgaben wie Provisioning, Skalierung, Patching und Backups erledigen. Der Begriff "serverlos" bedeutet nicht, dass Server nicht existieren; vielmehr verwaltet der Cloud-Anbieter sie vollständig, indem er nur einen Datenbankendpunkt für die Anwendung ausstellt. Ressourcen skalieren automatisch nach Bedarf auf und ab und die Abrechnung erfolgt verbrauchsabhängig - in der Regel zahlen Sie für den verwendeten Speicher und die Anzahl der ausgeführten Lese- / Schreibvorgänge.

Dieses Modell ist besonders vorteilhaft für Anwendungen mit variablem oder unvorhersehbarem Datenverkehr, wie E-Commerce-Flash-Vertrieb, IoT-Sensoraufnahme, mobile Backend-Services und ereignisgesteuerte Architekturen. Serverlose Datenbanken eliminieren die Kapazitätsplanung, reduzieren Leerlaufkosten und vereinfachen die Entwicklung durch latenzoptimierte APIs und integrierte Replikation. Sie führen jedoch auch Kompromisse ein: Kosten können bei sehr hohem Durchsatz schwer vorherzusagen sein und die mangelnde Kontrolle über die zugrunde liegende Hardware kann bestimmte Leistungsoptimierungen oder Migrationspfade erschweren.

Amazon DynamoDB – Eine Säule von AWS Serverless

Amazon DynamoDB ist eine vollständig verwaltete NoSQL-Schlüsselwert- und Dokumentendatenbank, die eine einstellige Millisekundenlatenz in jeder Größenordnung bietet. Gestartet im Jahr 2012 ist es die Standarddatenbank für viele AWS-serverlose Anwendungen geworden, die nahtlos mit Lambda, API Gateway, Step Functions und Kinesis zusammenarbeitet. DynamoDB unterstützt sowohl konsistente als auch stark konsistente Lesevorgänge und bietet Funktionen wie globale Tabellen, Auto-Skalierung, On-Demand-Kapazität, DynamoDB-Streams für die Erfassung von Change-Daten und globale Sekundärindizes (GSIs).

Hauptmerkmale von DynamoDB

  • Flexible Datenmodelle: Unterstützt Schlüsselwert-Schemata (einfacher Primärschlüssel) und Dokument-Schemata (Komposit-Primärschlüssel mit Sortierschlüssel). Elemente können unterschiedliche Attribute haben, so dass sie sich ohne Schemamigrationen leicht entwickeln lassen.
  • Automatische Skalierung: Sie können zwischen Provisioned-Throughput (mit Auto-Skalierung) oder On-Demand-Kapazität wählen. On-Demand passt sich automatisch an Traffic-Spikes, aber Gebühren pro Anfrage an; Provisioned ist kostengünstiger für stabile, vorhersehbare Workloads.
  • Global Tables: Multi-Region, Multi-Leader Replikation mit eventueller Konsistenz. Ideal für Disaster Recovery und niedrige Latenz liest/schreibt weltweit.
  • DynamoDB Accelerator (DAX): Ein In-Memory-Cache, der die Leselatenz von einstelligen Millisekunden auf Mikrosekunden reduzieren kann.
  • Sicherheit: Verschlüsselung im Ruhezustand (AWS KMS) und Intransit (TLS), feinkörnige IAM-Richtlinien, VPC-Endpunkte und Integration mit AWS CloudTrail für Audit-Logs.
  • Streams und Triggers: DynamoDB Streams erfassen Änderungen auf Elementebene in nahezu Echtzeit und ermöglichen ereignisgesteuerte Architekturen (z. B. Replizieren mit Elasticsearch, Aktualisieren von Sekundärindizes, Auslösen von Lambda-Funktionen).
  • Transaktionen: ACID-Transaktionen über bis zu 25 Elemente oder 4 MB Daten, nützlich für Finanzanwendungen und Multi-Item-Operationen.

Preismodell

DynamoDB-Preise basieren auf dem Kapazitätsmodus. Vorgesehene Kapazität erfordert, dass Sie Lese- und Schreibkapazitätseinheiten angeben (RCUs/WCUs). Sie zahlen einen Stundensatz pro Einheit zuzüglich Speicherkosten ($0,25 GB/Monat). Auto-Skalierung passt sich innerhalb der von Ihnen festgelegten Grenzen an. On-Demand-Kapazität Gebühren pro Million Lese-/Schreibanforderungseinheiten (RRUs/WRUs) und beinhaltet eine Prämie für Elastizität. Speicher, Datenübertragung, Global Tables Replikation, DAX, Streams und Backup werden separat abgerechnet. Für spiky Workloads kann On-Demand einfacher sein; für stetige Flüsse ist Provisioned normalerweise billiger. AWS bietet eine kostenlose Ebene von 25 GB Speicher und 200 Millionen Anfragen pro Monat (für neue Konten).

Gemeinsame Anwendungsfälle

  • Session state: Low-Latenz liest/schreibt es hervorragend für die Speicherung von Benutzersitzungen in Web- und mobilen Anwendungen.
  • Gaming: Spielerprofile, Ranglisten und Spielzustand mit hoher Gleichzeitigkeit und unvorhersehbarer Last.
  • IoT: Aufnahme von Sensordaten mit automatischer Skalierung, um Millionen von Schreibvorgängen pro Sekunde zu verarbeiten.
  • E‐commerce: Warenkorb und Auftragsverarbeitung mit Transaktionen zur Gewährleistung der Konsistenz.
  • Event-driven microservices: In Kombination mit Lambda und EventBridge bildet DynamoDB das Rückgrat vieler serverloser Backends.

Einschränkungen und Überlegungen

DynamoDB ist zwar leistungsfähig, aber keine Einheitslösung. Die Abfragemöglichkeiten sind begrenzt: Sie können nur nach Primärschlüsseln (oder GSI) und optionalen Bereichsbedingungen abfragen. Komplexe Verknüpfungen, Aggregationen und Volltextsuche erfordern externe Dienste wie Elasticsearch oder Aurora. Die maximale Objektgröße von 400 KB kann für große Dokumente restriktiv sein. Global Tables replizieren sich schließlich (keine starke Konsistenz über Regionen hinweg). Die Bereitstellung kann schwierig sein: Die Unterschätzung des Durchsatzes führt zu Drosselung, während Überbereitung Geld verschwendet. Stark konsistente Lesevorgänge sind auf die Primärkopie beschränkt (nicht in sekundären Regionen verfügbar). Das Fehlen einer nativen serverlosen SQL-Schnittstelle (wie PartiQL von DynamoDB) wird manchmal als Lernkurve für Teams angesehen, die an relationale Datenbanken gewöhnt sind.

Amazon DynamoDB offizielle Dokumentation

Azure Cosmos DB – Global verteilte Multimodell-Datenbank

Microsoft Azure Cosmos DB ist eine vollständig verwaltete NoSQL-Datenbank, die für unternehmenskritische Anwendungen entwickelt wurde, die globale Verteilung, elastische Skalierung und mehrere Konsistenzmodelle erfordern. Im Gegensatz zu DynamoDB ist Cosmos DB ein Multimodell out of the box: Es unterstützt Dokument (SQL API), Schlüsselwert (Table API), Graph (Gremlin API), Kolumnenfamilie (Cassandra API) und MongoDB API. Diese Flexibilität ermöglicht es Entwicklern, vertraute Abfragesprachen zu verwenden und gleichzeitig von der zugrunde liegenden globalen Replikation und den schlüsselfertigen SLA-Garantien von Cosmos DB zu profitieren.

Hauptmerkmale von Cosmos DB

  • Multi-Modell und Multi-API: Sie können zwischen NoSQL (Dokument), MongoDB, Cassandra, Gremlin (Grafik) und Table-APIs wählen. Alle APIs befinden sich auf demselben Kern - der Cosmos DB-Engine -, so dass sie den Durchsatz, die Indexierung und die globale Verteilung teilen.
  • Globale Verteilung (schlüsselfertig): Mit wenigen Klicks oder Codezeilen können Sie Daten in eine beliebige Anzahl von Azure-Regionen replizieren. Cosmos DB unterstützt Multi-Region-Schreiben (aktiv-aktiv) mit automatischer Konfliktlösung.
  • Fünf klar definierte Konsistenzstufen: Stark, Gefesselte Abgestandenheit, Sitzung, Konsistentes Präfix und Eventual. Sie können das Niveau pro Anfrage auswählen, wobei die Leistung mit Konsistenzgarantien verglichen wird.
  • Automatische Indexierung: Standardmäßig werden alle Objekteigenschaften ohne manuelle Schemadefinition indexiert. Dies beschleunigt willkürliche Abfragen, aber Sie können Indexierungsrichtlinien anpassen, um den RU-Verbrauch zu reduzieren.
  • Request Units (RUs): Cosmos DB verwendet eine einheitliche Durchsatzwährung, die in Request Units pro Sekunde gemessen wird. 1 RU entspricht einem Lesevorgang von 1 KB. Lesevorgänge sind schneller (1 RU pro Lesevorgang) als Schreibvorgänge (5 RU pro 1 KB Schreibvorgang). Sie liefern den Durchsatz pro Container oder Datenbank oder verwenden den serverlosen (Autoscale-) Modus.
  • SLA garantiert: 99,999% Leseverfügbarkeit, 99,999% Schreibe für Multi-Region und <10 ms Latenz für Lese- und Schreibe bei P99 (innerhalb derselben Region). Starke Konsistenz hat eine etwas höhere Latenz.
  • Wechsel-Feed: Ein persistentes, geordnetes Protokoll von Elementänderungen, das von Azure Functions oder anderen Prozessoren für ereignisgesteuerte Architekturen verwendet werden kann.
  • Analytischer Speicher: Eingebauter Kolumnenspeicher zum Ausführen groß angelegter analytischer Abfragen ohne Auswirkungen auf Transaktions-Workloads (mit Synapse Link).

Preismodell

Cosmos DB-Preise basieren auf Provisioned Throughput (RUs) und verbrauchtem Speicher. Sie können auch den Serverless-Modus (Vorschau zum Zeitpunkt des Schreibens) verwenden, in dem Sie für verbrauchte EVUs und Speicher bezahlen, wobei der Skalierungsmodus im Leerlauf auf Null gesetzt wird - ideal für kleine Workloads. Provisioned Throughput kann pro Container oder pro Datenbank eingestellt werden. Autoscale ermöglicht es Ihnen, ein maximales EVU-Limit festzulegen und das System passt sich innerhalb dieses Bereichs an. Die Speicherung kostet ungefähr 0,25 GB / Monat (ähnlich wie DynamoDB). Die Datentransferkosten für die Multi-Region-Replikation sind extra. Cosmos DB bietet eine kostenlose Stufe von 1000 EVU / s und 25 GB Speicherplatz für das erste Konto pro Abonnement.

Im Vergleich zu DynamoDB ist die EVU-Modellierung von Cosmos DB granularer und kann komplexer zu schätzen sein, insbesondere für Multimodell-Workloads. Allerdings können automatische Indexierung und abstimmbare Konsistenz den gesamten EVU-Bedarf reduzieren, insbesondere für leselastige Anwendungen, die eine eventuelle Konsistenz tolerieren können.

Gemeinsame Anwendungsfälle

  • Enterprise SaaS-Anwendungen: Mehrmietersysteme, die geoverteilten Zugriff mit niedriger Latenz und starke SLAs erfordern.
  • IoT und Zeitreihen: Aufnahme von Hochgeschwindigkeitssensordaten mit globalen Ansichten.
  • E‐Commerce-Plattformen: Produktkataloge, Warenkörbe, Auftragsverwaltung, mit multi‐regionalen aktiven‐aktiven Bereitstellungen.
  • Real-time analytics: Using change feed and Synapse Link to drive dashboards and machine learning models.
  • Grafikanwendungen: Soziale Netzwerke, Empfehlungsmaschinen und Wissensgraphen über Gremlin API.

Einschränkungen und Überlegungen

Die Breite der Cosmos DB ist mit einer Lernkurve ausgestattet. Das RU-Modell erfordert eine sorgfältige Planung: Sie bezahlen für zugewiesene Kapazität, auch wenn sie im Leerlauf ist (es sei denn, Sie verwenden serverless). Das effiziente Erstellen beliebiger Abfragen beruht oft auf der automatischen Indexierung, aber schlecht gestaltete Indizes können die RU-Kosten explodieren. Partitionsübergreifende Abfragen sind weniger effizient, weil sie jede Partition berühren. Stark konsistente Lese- und Multi-Region-Schreiben erhöhen Latenz und Kosten. Der analytische Speicher ist nur für SQL API und MongoDB API verfügbar. Cosmos DB ist an das Azure-Ökosystem gebunden; Die Integration mit anderen Clouds oder On-Premises kann komplexer sein. Die Größe des Elements ist 2 MB (gegenüber DynamoDB 400 KB). Als Managed Service haben Sie keine direkte Kontrolle über OS, Datenbankversion oder Hardware.

Azure Cosmos DB offizielle Dokumentation

Head-to-Head-Vergleich: DynamoDB vs. Cosmos DB

Die Wahl zwischen diesen beiden serverlosen Datenbanken hängt von Ihrem bestehenden Cloud-Anbieter, den Workload-Eigenschaften und den spezifischen Funktionsanforderungen ab.

Datenmodell und API

DynamoDB ist in erster Linie Key-Value und Dokument. Es verwendet eine proprietäre API (AWS SDK) zusammen mit PartiQL (SQL-kompatible Abfragesprache). Cosmos DB bietet fünf APIs: SQL (Dokument), MongoDB, Cassandra, Gremlin (Grafik) und Table. Dies gibt Cosmos DB einen klaren Vorteil für Teams, die bestehende Treiber verwenden oder aus anderen NoSQL-Datenbanken migrieren möchten, ohne Abfragen neu zu schreiben.

Weltweite Verteilung

Beide unterstützen die Multi-Regionen-Replikation. DynamoDB verwendet Global Tables mit eventueller Konsistenz (oder nur innerhalb einer einzigen Region stark). Cosmos DB bietet Multi-Regionen-Schreiben mit mehreren Konsistenzstufen, einschließlich starker regionenübergreifender (wenn auch mit Latenzkosten).

Konsistenzmodelle

DynamoDB bietet zwei: Eventual und Strong. Cosmos DB bietet fünf: Eventual, konsistentes Präfix, Session, Bounded Stalness und Strong. Die feinere Granularität ermöglicht Cosmos DB, Kosten und Performance für spezifische Anwendungsfälle zu optimieren (z. B. Session-Level-Konsistenz für E-Commerce-Körbe ist sehr beliebt).

Abfrage und Indexierung

DynamoDB erfordert die Definition eines Primärschlüssels und optionalen Sortierschlüssels; er indiziert automatisch Primärschlüssel und GSIs. Sie können auch spärliche Indizes erstellen. Ad-hoc-Abfragen sind begrenzt. Cosmos DB indiziert standardmäßig automatisch alle Eigenschaften, wodurch willkürliche Abfragen ohne Vorab-Schemadefinition ermöglicht werden. Dies macht Cosmos DB flexibler für explorative Abfragen, kann aber die Kosten für EVUs für hohe Schreibauslastungen erhöhen.

Durchsatz und Preis Granularität

DynamoDB verwendet RCU/WCU – Reads sind die Hälfte der Schreibkosten (1 RCU für 4 KB, 1 WCU für 1 KB). Cosmos DB verwendet EVUs – 1 RU = 1 KB read, 5 EVU pro 1 KB write. Cosmos DBs EVU-Kosten variieren je nach Konsistenzstufe und indexierten Eigenschaften. DynamoDBs On-Demand-Gebühren pro Anfrageeinheit, während Cosmos DBs serverlose (Vorschau-)Gebühren pro verbrauchtem EVU. Im Allgemeinen ist DynamoDB für einfache Key-Value-Workloads billiger, während Cosmos DB aufgrund der automatischen Indexierung kostengünstiger für komplexe Abfragen und globale Verteilung sein kann reduziert die Notwendigkeit von Sekundärindizes.

Integration von Ökosystemen

DynamoDB ist tief in AWS integriert (Lambda, API Gateway, Kinesis, CloudWatch, CloudTrail, IAM). Cosmos DB integriert sich natürlich in Azure (Funktionen, Logic Apps, Event Hubs, Synapse, Power BI). Beide bieten Change Feeds und ereignisgesteuerte Trigger. Oft hängt es davon ab, in welchen Cloud-Anbieter Ihre Organisation investiert ist.

SLAs und Einschränkungen

Cosmos DB bietet umfassende SLAs für Latenz (P99 <10 ms liest/schreibt unter 1 KB), Durchsatz (hohe Verfügbarkeit) und Konsistenz (für stark). DynamoDB wirbt für eine einstellige Millisekundenlatenz und 99,999% Verfügbarkeit für globale Tabellen, bietet aber keine formale Latenz SLA. Cosmos DB hat auch einen maximalen Speicherplatz pro Container von 20 TB (oder unbegrenzt mit Partitionsaufteilung), während DynamoDB eine 400 KB Artikelgrößenbegrenzung und 10 GB pro Partitions-Hardlimit hat (obwohl Sie Partitionen skalieren können).

Wann soll man wählen, welche?

  • Wählen Sie DynamoDB, wenn: Sie bauen auf AWS auf, benötigen einen einfachen Key-Value- oder Dokumentenspeicher mit vorhersagbar niedriger Latenz, haben ein klares Zugriffsmuster (Abfrage primär nach Primärschlüsseln) und möchten die Kosten in hohem Maße niedrig halten. Es ist ideal für Spiele, IoT, Session Stores und Lambda-zentrierte serverlose Backends.
  • Wählen Sie Cosmos DB, wenn: Sie benötigen Multimodell-Unterstützung (insbesondere MongoDB oder Cassandra API für Migration), erfordern mehrere Konsistenzstufen, benötigen aktive aktive Multiregion-Schreiben oder benötigen umfangreiche Abfragefunktionen ohne Vorab-Indexdesign. Es eignet sich hervorragend für globale Unternehmens-Apps, Echtzeit-Analysen und polyglotte Persistenzarchitekturen.

DynamoDB Developer Guide | Cosmos DB Introduction

Best Practices für die Annahme von Serverless-Datenbanken

Unabhängig davon, welche Datenbank Sie wählen, werden die folgenden bewährten Muster Ihnen helfen, häufige Fallstricke zu vermeiden:

Design für Partitionierung

Sowohl in DynamoDB als auch in Cosmos DB ist das Partitionsschlüsseldesign von entscheidender Bedeutung. Heiße Partitionen (bei denen ein einzelner Schlüssel unverhältnismäßigen Datenverkehr erhält) drosseln den Durchsatz. Verwenden Sie hochkardinale Schlüssel (z. B. Benutzer-ID, Geräte-ID) und ziehen Sie das Schreibsharding für sequentielle Identifikatoren in Betracht. In Cosmos DB können Sie auf dem Pfad /partitionKey partitionieren; in DynamoDB wird der Partitionsschlüssel bei der Erstellung der Tabelle ausgewählt.

Leverage Change Data Capture

Sowohl DynamoDB Streams als auch Cosmos DB Change Feed ermöglichen ereignisgesteuerte Muster, die Daten in Suchmaschinen replizieren (Elasticsearch), materialisierte Ansichten erstellen, mit Data Warehouses synchronisieren oder nachgelagerte Prozesse auslösen.

Verstehen Sie Ihre Konsistenzbedürfnisse

Serverlose Datenbanken berechnen weniger für eventuelle Konsistenz. Bewerten Sie, ob Ihre Anwendung eine starke Konsistenz erfordert. Wenn eine solche akzeptabel ist, können Sie die Kosten senken und die Latenzzeit verbessern. Verwenden Sie für Cosmos DB die Sitzungskonsistenz für viele E-Commerce- oder Social-Media-Apps - sie bietet Lese-Schreibgarantien pro Kundensitzung zu niedrigeren EVU-Kosten als stark.

Verwenden Sie den geeigneten Kapazitätsmodus

Für DynamoDB sollten Sie Provisioned Capacity mit Auto-Scaling für stetige Workloads und On-Demand für unvorhersehbare Spikes wählen. Für Cosmos DB ist Provisioned Throughput mit Autoscale gut für die meisten Produktions-Workloads; betrachten Sie Serverless (Preview) für Dev/Test- oder Leichtbau-Apps. Überwachen Sie verbrauchte EVUs und setzen Sie Alarme für Drosselereignisse.

Plan für Backup und Disaster Recovery

Beide Dienste bieten Point-in-Time-Recovery (PITR) an, aktivieren sie für alle Produktionsdatenbanken. DynamoDB-Backup ist kontinuierlich und stellt eine neue Tabelle wieder her; Cosmos DB-Backup kann kontinuierlich oder periodisch sein. Testen Sie periodisch. Für globale DR konfigurieren Sie die Multi-Region-Replikation (Global Tables oder Cosmos DB Multi-Region schreibt) und haben einen Failover-Plan.

Kostenmanagement

Die Nutzung mit Cloud-Kostenmanagement-Tools (AWS Cost Explorer, Azure Cost Management) verfolgen. Bei DynamoDB die reservierte Kapazität für einen vorhersagbaren Durchsatz verwenden. Bei Cosmos DB die Verwendung von Serverless oder Autoscale in Betracht ziehen, um die Zahlung für im Leerlauf befindliche EVUs zu vermeiden. Nicht verwendete Indizes und Tabellen entfernen. Komprimierung verwenden, sofern unterstützt (z. B. Komprimierung im Analysespeicher von Cosmos DB).

Schlussfolgerung

Serverlose Datenbanken wie Amazon DynamoDB und Azure Cosmos DB sind zu unternehmensweiten Plattformen gereift, die es Entwicklern ermöglichen, global skalierbare Anwendungen ohne Betriebsaufwand zu erstellen. DynamoDB zeichnet sich durch Einfachheit, enge Abfragemuster und tiefe AWS-Integration aus, was es für viele serverlose Microservices zur Standardwahl macht. Cosmos DB bietet überlegene Flexibilität mit Multimodell-Unterstützung, abstimmbarer Konsistenz und umfassenden SLAs, die komplexen globalen Anwendungen und polyglotten Persistenzanforderungen gerecht werden. Die richtige Wahl hängt letztendlich von Ihrer Cloud-Strategie, Datenzugriffsmustern und Toleranz für die operative Komplexität ab. Durch das Verständnis der Stärken, Einschränkungen und Preismodelle jeder Datenbank können Sie robuste, kostengünstige Systeme entwerfen, die nahtlos mit Ihrem Unternehmen skalieren.

AWS Serverless Database Resource Hub | Azure Cosmos DB Product Page