DynamoDB decoded, Teil 3 Preisstruktur von AWS DynamoDB

Ein entscheidender Faktor bei der Auswahl des richtigen Datenbank-Service in der Cloud ist die Preisstruktur. Da DynamoDB ein verwalteter Dienst ist, beeinflussen verschiedene Faktoren die Kosten. Das sehen wir uns heute genauer an.

Einer der wichtigsten Aspekte ist die Kapazität, bei der zwischen den beiden Optionen „Provisioned“ und „On-Demand“ unterschieden wird. Das Kapazitätsmodell gilt jeweils für eine DynamoDB-Tabelle und darf alle 24 Stunden angepasst werden.

Die Kapazität richtet sich nach der Anzahl der durchgeführten Lese- und Schreiboperationen innerhalb eines bestimmten Zeitraums. Diese Operationen werden auch als Read/Write Capacity Units (RCU/WCU) bezeichnet, wobei eine Capacity Unit einer Anfrage pro Sekunde entspricht.

RCU (Read Capacity Unit) werden in Blöcken von vier Kilobyte (KB) gemessen, wobei der letzte Block immer aufgerundet wird. Ein RCU entspricht dabei einem stark konsistentem Lesevorgang, zwei „eventual consitency“ Lesevorgängen oder einem halben transaktionalen Lesevorgang pro Sekunde.

WCU (Write Capacity Unit) werden in 1-KB-Blöcken von gemessen, wobei auch hier der letzte Block immer aufgerundet wird. Ein WCU entspricht einem Standard-Schreibvorgang oder einem halben transaktionalen Schreibvorgang pro Sekunde.

Zur Verdeutlichung wird folgend ein Beispiel für die Berechnung der Anzahl der Capacity Units vom Schreiben und Lesen eines 15 KB großen Item von und in die Datenbank mit den verschiedenen Konsistenztypen gegeben.

Provisioned Capacity

Bei der Option der Provisioned Capacity handelt es sich um ein traditionelles Modell, bei dem im Voraus festgelegt wird, wie viel Kapazität dem Nutzer zur Verfügung steht. Die Kostenabrechnung erfolgt basierend auf der bereitgestellten Kapazität und nicht auf der Anzahl der tatsächlich durchgeführten Anfragen. Bei Überschreitung der vordefinierten Kapazität können Anfragen an Tabellen abgelehnt werden, was die Nutzererfahrung beeinträchtigt.

Dieser Modus erfordert grundsätzlich ein ausgewogenes Verhältnis zwischen der angemessenen Bereitstellung und den Kosten, um sowohl eine Überlastung als auch eine Unterbereitstellung der Tabelle zu vermeiden. Es ist daher ratsam, die erwartete Anzahl von Anfragen zu berücksichtigen, um eine Drosselung zu vermeiden.

Um die Ungenauigkeit bei der Schätzung abzumildern, kann die Funktion „Auto Scaling“ aktiviert werden. Dabei legt man sowohl die minimale als auch die maximale Anzahl von Capacity Units sowie eine Ziel-Auslastung in Prozent fest. Wenn diese Ziel-Auslastung überschritten wird, erhöht das System automatisch die provisionierten Capacity Units, bis die Ziel-Auslastung wieder erreicht ist.

On-Demand Capacity

Im Modell der On-Demand Capacity zahlen User pro Anfrage für Lese- und Schreibvorgänge, ohne dass eine vorherige Bereitstellung erforderlich ist. Die Kapazität passt sich dynamisch an die Workload an, wodurch sich diese Option besonders für Umgebungen mit unvorhersehbarem Datenverkehr wie Test- und Entwicklungsumgebungen eignet.

Optional ist es möglich, für einzelne On-Demand-Tabellen und globale sekundäre Indizes auch maximale Lese- oder Schreibdurchsätze (oder beides) pro Sekunde zu konfigurieren. Auf diesem Weg lassen sich Kosten und Nutzung kontrollieren. Zur Abrechnung werden hier Request Units verwendet, die in der Berechnung gleichwertig zu Capacity Units sind, jedoch Kosten-seitig höher ausfallen.

Partitionen

Ein entscheidender Aspekt für die hohe Performance und Skalierbarkeit von DynamoDB ist die zugrundeliegende Speicherstruktur. Die Daten, auch Items genannt, werden auf SSDs gespeichert, aber die Abfragen im Bereich von Millisekunden ermöglicht nicht allein das Speichermedium. Viel wichtiger ist, wie die Daten auf den SSDs organisiert sind. Hier kommt das Konzept der Partitionierung ins Spiel.

Partitionierung bezeichnet die Zuweisung von Datensätzen auf dem zugrunde liegenden Speichermedium. In DynamoDB ist eine Partition standardmäßig auf zehn Gigabyte (GB) begrenzt und diese Grenze ist unveränderbar. Um größere Datenmengen zu speichern, können weitere Partitionen hinzugefügt werden. Bei einer maximalen Item-Größe von 400 KB fasst eine Partition bis zu 25.000 Items. Pro Tabelle gibt es eine maximale Partitionsgrenze von 3.000, was bedeutet, dass pro Tabelle bis zu 30 TB Daten gespeichert werden können.

Um performante Abfragen über die Partitionen hinweg zu ermöglichen, sind drei Komponenten von hoher Bedeutung:

• 1. Der Partitionsschlüssel, der zur eindeutigen Identifizierung des Items sowie als Input für die Hashfunktion dient.

• 2. Der Request Router, der jede eingehende Anfrage, sei es zum Lesen oder Schreiben, bearbeitet. Er leitet den Partitionsschlüsselwert an eine Hashfunktion weiter, um die Partitionsnummer für die Anfrage zu bestimmen und um die Anfrage dann an die korrekte Partition zu übergeben. Dabei hat der Router eine Zeitkomplexität von O(1), was die Latenz bei der Bearbeitung der Anfrage nicht wesentlich erhöht.

• 3. Die Hashfunktion, die die verfügbare Anzahl von Partitionen kennt und Partitionsnummern basierend auf dem Partitionsschlüssel generiert. Die Partitionsnummer gibt an, auf welcher Partition das Item gespeichert oder gefunden wird.

DynamoDB beginnt mit nur wenigen Partitionen und kann mehrere Sammlungen von Items in einer einzelnen Partition halten. Mit zunehmender Datenmenge und wenn die Partitionsgröße über 10 GB wächst, teilt DynamoDB die Partition in zwei Hälften, wobei die Hälfte der Daten in eine andere Partition verschoben wird. Dieser Vorgang erfolgt im Hintergrund und beeinträchtigt die Latenz nicht.

Idealerweise enthalten alle Partitionsschlüsselwerte nahezu die gleiche Anzahl von Elementen. Dies kann jedoch in der Realität anders aussehen, insbesondere wenn einige Partitionsschlüsselwerte wesentlich mehr Daten enthalten. Dadurch ist es nicht immer möglich, Lese- und Schreibaktivitäten gleichmäßig zu verteilen.

Bei einem unausgeglichenen Datenzugriff kann eine „hot“ Partition entstehen. Das bedeutet, dass im Vergleich zu anderen, diese Partition einen höheren Anteil an Lese- und Schreibverkehr erhält. Da Lese- und Schreiboperationen auf einer Partition unabhängig voneinander verwaltet werden, tritt eine Drosselung auf, wenn eine einzelne Partition mehr als 3.000 Leseoperationen oder mehr als 1.000 Schreiboperationen erhält.

Um mit ungleichmäßigen Zugriffsmustern besser umzugehen, bietet DynamoDB Adaptive Kapazität an. Sie ermöglicht weiterhin das Lesen und Schreiben auf überlasteten Partitionen, ohne dass eine Drosselung erfolgt, vorausgesetzt, der Verkehr überschreitet nicht die gesamte provisionierte Kapazität Ihrer Tabelle. Die Adaptive Kapazität funktioniert, indem sie automatisch und sofort die Durchsatzkapazität für Partitionen erhöht, die eine höhere Anzahl an Anfragen erhalten.

Das vorangestellte Diagramm veranschaulicht, wie die Adaptive Kapazität funktioniert: Eine Beispiel-Tabelle ist mit 400 WCUs gleichmäßig auf vier Partitionen verteilt, wodurch jede Partition bis zu 100 WCUs pro Sekunde (WCU/s) aufrechterhalten kann. Die Partitionen 1, 2 und 3 erhalten jeweils Schreibverkehr von 50 WCU/s Partition 4 erhält 150 WCU/s.

Diese überlastete Partition kann Schreibverkehr aufnehmen, solange sie noch ungenutzte Burst-Kapazität hat, aber letztendlich drosselt sie den Verkehr, der 100 WCU/s überschreitet. Die Adaptive Kapazität von DynamoDB reagiert, indem sie die Kapazität von Partition 4 erhöht, damit sie die höhere Arbeitslast von 150 WCU/s aufrechterhalten kann, ohne gedrosselt zu werden.

Mit dem Verständnis der Preisstruktur und Partitionierung von AWS DynamoDB ist es nun bald an der Zeit, die praktischen Nutzungsmöglichkeiten für Entwickler zu beleuchten. Der vierte Teil der Reihe widmet sich den API-Schnittstellen und den besonderen Funktionalitäten von DynamoDB, die es Entwicklern und Entwicklerinnen ermöglichen, das volle Potenzial dieser Datenbanklösung auszuschöpfen.

(ID:50092656)