DynamoDB decoded, Teil 2 Datentypen, Indizes und Datenkonsistenz bei DynamoDB

Anbieter zum Thema

adesso SE

PANDUIT

Rittal GmbH & Co. KG

Fsas Technologies GmbH

Um die grundlegenden Funktionen des NoSQL-Datenbank-Service DynamoDB kennenzulernen, müssen wir technisch in die Tiefe gehen. Der zweite Teil dieser Serie widmet sich den unterstützten Datentypen, sekundären Indizes und dem Konsistenzmodell.

AWS DynamoDB unterstützt eine Vielzahl von unterschiedlichen Datentypen, die in den Items gespeichert werden können. Diese Datentypen lassen sich grob in drei Kategorien einteilen: Skalare Typen, Dokumenten-Typen und Set-Typen.

Zu den Skalaren Typen zählen Zahlen (N), Zeichenfolgen (S), Binärwerte (B), Boolesche Werte (BOOL) sowie Null-Werte (NULL). Es ist wichtig zu beachten, dass Datum- oder Zeitstempel nicht nativ unterstützt werden. Um Zeitstempel zu verwenden, müssen diese zum Beispiel als Zeichenfolge im ISO-8601-Format abgelegt werden.

Die Dokumenten-Typen umfassen Listen (L) und Zuordnungen (M). Diese Typen ermöglichen eine flexible Strukturierung von Informationen. Listen und Zuordnungen lassen sich ineinander verschachteln, was die Darstellung komplexer Datenstrukturen bis zu 32 Ebenen tief ermöglicht. Auch hier darf das maximale Limit von 400 KB pro Item nicht überschritten werden.

Listen, dargestellt durch eckige Klammern […], fungieren als geordnete Sammlungen von Werten, ähnlich wie JSON-Arrays. Eine wichtige Eigenschaft von Listen ist ihre Vielseitigkeit, da sie keine Einschränkungen bezüglich der Datentypen der gespeicherten Elemente aufweisen. Die Elemente einer Liste müssen nicht vom selben Typ sein, was eine flexible Datenmodellierung ermöglicht.

Im vorangegangenen Use Case der Spielerdaten wird der Datentyp Liste beispielsweise zur Speicherung der Freunde eines Spielers verwendet. Hierbei entspricht jeder Eintrag in der Liste einem Freund des Spielers.

Zuordnungen (Maps), dargestellt durch geschweifte Klammern {...}, speichern eine ungeordnete Sammlung von Key-Value-Paaren, ähnlich einem JSON-Objekt. Auch hier gibt es keine Einschränkungen hinsichtlich der Datentypen der gespeicherten Elemente. In der Freundesliste eines Spielers finden wir zu jedem Freund eine geschachtelte Zuordnung. Jeder Freund besitzt gleiche Attribute wie FreundID oder Spitzname, die als Key-Value-Paare in dieser JSON-ähnlichen Struktur abgelegt sind.

Die dritte Kategorie sind die Sets (Mengen). Ein Set ist eine Sammlung von mehreren Elementen desselben Typs. Die Anzahl der Elemente in einem Set ist nicht beschränkt, solange das Limit von 400 KB pro Item eingehalten wird. Ein Set ist ungeordnet, und jedes Element muss eindeutig innerhalb des Sets sein. Unterstützt werden Zahlen-Sets (NS), Zeichenfolgen-Sets (SS) und Binär-Sets (BS).

Sekundäre Indizes

Amazon DynamoDB ermöglicht schnellen Zugriff auf Elemente in einer Tabelle durch die Verwendung von Primärschlüsseln. Allerdings gibt es Anforderungen, bei denen Abfragen und Filteroperationen über alternative Attribute ausgeführt werden müssen. Um dies effizient zu ermöglichen, können sekundäre Indizes auf einer Tabelle erstellt und Abfrage- oder Scan-Anfragen auf diesen Indizes ausgeführt werden.

Ein sekundärer Index ist eine Datenstruktur, die eine Teilmenge von Attributen einer Tabelle sowie einen alternativen Schlüssel zur Unterstützung von Abfrageoperationen enthält. Jeder sekundäre Index ist einer spezifischen Tabelle zugeordnet, aus der er seine Daten bezieht, die als Basistabelle bezeichnet wird. Änderungen an der Basistabelle – wie das Hinzufügen, Ändern oder Löschen von Elementen – werden automatisch in den zugehörigen Indizes reflektiert.

DynamoDB unterstützt zwei Arten von sekundären Indizes:

Local Secondary Index (LSI)

Ein LSI verwendet denselben Partitionsschlüssel wie der Primärschlüssel der Tabelle, hat jedoch einen unterschiedlichen Sortierschlüssel. Die Erstellung eines LSI ist auf bis zu fünf Indizes pro Tabelle beschränkt, und die Größe der indexierten Elemente darf 10 GB nicht überschreiten. LSIs müssen bei der Erstellung der Tabelle definiert werden und können nicht nachträglich hinzugefügt werden.

Global Secondary Index (GSI)

Im Gegensatz dazu erlaubt ein GSI die Verwendung eines anderen Partitionsschlüssels als der Primärschlüssel der Tabelle. Der GSI kann entweder ein einfacher oder zusammengesetzter Schlüssel sein. Jede Tabelle kann bis zu 20 GSIs haben, und es gibt keine Größenbeschränkungen für die indexierten Elemente. GSIs können jederzeit erstellt und gelöscht werden und ermöglichen Abfragen über Partitionen hinweg. Es ist wichtig zu beachten, dass GSIs nur eine eventuale Konsistenz bieten.

Ein Beispiel für einen sekundären Index im Kontext von Spielerprofilen ist die Verwendung des originalen Partitionsschlüssels zusammen mit dem Attribut AktivitätStartZeit aus der Kategorie der Aktivitäten. Durch die Sortierung der Aktivitäten nach Startzeiten innerhalb der Partition können Abfragen und Analysen hinsichtlich des Spielverhaltens eines Spielers schneller und kostengünstiger durchgeführt werden.

Backup

DynamoDB bietet native Funktionen zur Gewährleistung der Datensicherheit und zum Schutz vor Serverausfällen sowie Datenkorruption. Zum einen werden regelmäßige Snapshots der Datenbank in Amazon S3 abgelegt. Diese ermöglichen eine vollständige Wiederherstellung der Datenbank zu einem gewünschten Zeitpunkt in der Vergangenheit, bis maximal 35 Tage zurück. Diese Funktion wird als Point-in-Time Recovery (PITR) bezeichnet und erlaubt es, die Daten bis auf die Sekunde genau zurückzusetzen.

Zum Schutz vor Serverausfällen wird ein zusätzliches Backup-System verwendet. Alle Daten und Partitionen werden auf mehrere Nodes repliziert. In DynamoDB beträgt der Standard-Replikationsfaktor drei, was bedeutet, dass jedes Item auf drei unterschiedlichen physischen Nodes gespeichert ist. AWS garantiert zudem, dass diese drei Nodes sich stets in drei unterschiedlichen Verfügbarkeitszonen befinden. Dies gewährleistet eine hohe Datenverfügbarkeit, sodass selbst bei Ausfällen einzelner Rechenzentren, andere noch aktive Nodes zum Lesen und Schreiben genutzt werden können.

Datenkonsistenz

Wenn Daten über mehrere Nodes repliziert werden, entsteht das Problem der Konsistenzsicherung. Jede Schreib- oder Anpassungsaktion muss auf allen Nodes erfolgen, um Inkonsistenzen bei Abfragen zu vermeiden. Diese simultanen Operationen erhöhen jedoch Latenz und Overhead.

AWS setzt daher auf das Prinzip der eventuellen Konsistenz, was bedeutet, dass nach dem Schreiben von Daten keine sofortige Garantie besteht, dass alle Kopien der Daten in einem bestimmten Moment identisch sind. Dennoch ermöglicht DynamoDB die Anpassung des Konsistenzniveaus für Lese- und Schreibvorgänge je nach Anwendungsbedarf.

Leseoperation

• Bei starker Konsistenz wird auf die aktuellen Daten zugegriffen. Dies erfordert jedoch explizite Anfragen beim Lesen. Starke Konsistenz gewährleistet, dass die zurückgegebenen Daten die neuesten und konsistentesten sind.

• Eventuelle Konsistenz bietet keine Garantie dafür, dass die zurückgegebenen Daten die allerneuesten sind. Es handelt sich um das Standard-Konsistenzniveau und ist kostengünstiger, etwa 50 Prozent preiswerter als die starke Konsistenz.

• Transaktionale Konsistenz bietet ACID-Unterstützung über eine oder mehrere Tabellen innerhalb eines einzelnen AWS-Kontos und einer Region. Obwohl sie die zuverlässigste Konsistenz gewährleistet, ist sie mit dem doppelten Kostenfaktor im Vergleich zu stark konsistenten Lesevorgängen verbunden.

Schreiboperation

• Die Standard-Schreibkonsistenz ermöglicht einfache Schreibvorgänge, wobei die Daten kurzfristig inkonsistent erscheinen können, bevor sie von DynamoDB intern harmonisiert werden.

• Transaktionale Schreibkonsistenz bietet eine ACID-Unterstützung für Schreibvorgänge. Allerdings erfolgt dies zu einem doppelten Preis im Vergleich zur Standard-Schreibkonsistenz.

Nachdem die unterstützten Datentypen, sekundären Indizes und das Konsistenzmodell von AWS DynamoDB ausführlich behandelt wurden, richtet sich die Aufmerksamkeit im dritten Teil dieser Artikelserie nun auf die Partitionierung und die Nutzungs- sowie Preisstruktur der NoSQL-Datenbank.

(ID:50085528)