DynamoDB decoded, Teil 5 Best Practices für AWS DynamoDB

Anbieter zum Thema

adesso SE

Rittal GmbH & Co. KG

PQ Plus GmbH

Angefangen beim Partitionsschlüssel über effiziente Datenbankabfragen bis hin zum DynamoDB Accelerator Service: Um die Leistung, Skalierbarkeit und Effizienz von AWS DynamoDB optimal zu nutzen, gibt es in vielen Bereichen bestimmte Best Practices.

Partitionsschlüssel

Der Partitionsschlüssel ist entscheidend für die Leistung von DynamoDB, da er die Verteilung der Daten auf Partitionen bestimmt. Um eine gleichmäßige Verteilung zu erreichen, sollte der Partitionsschlüssel viele eindeutige Werte besitzen. Zudem muss das Potenzial für Datenwachstum berücksichtigt werden, damit der Partitionsschlüssel auch bei wachsendem Datensatz weiterhin eine gleichmäßige Verteilung ermöglicht.

Ein gründliches Verständnis der erwarteten Abfragemuster vor der Datenbankerstellung hilft bei der optimalen Gestaltung von Sortierschlüsseln und Indizes.

Beispiel: In einer Tabelle mit Spieldaten ist der Partitionsschlüssel pro Spieler eindeutig, was eine hohe Kardinalität gewährleistet. Wenn bestimmte Daten, wie die Freundesliste oder Metadaten, weniger häufig abgerufen werden als Aktivitätsdaten, ist es ratsam, diese Informationen in separate Tabellen auszulagern, um eine bessere Auslastung der Partitionen zu gewährleisten.

Item-Größe

Die sorgfältige Verwaltung der Item-Größe ist von hoher Relevanz. Große Werte sollten vor der Speicherung komprimiert werden. Für sehr große Attributwerte ist die Auslagerung in alternative Speicher wie Amazon S3 empfehlenswert, wobei im DynamoDB-Item nur ein Identifier wie der S3-Pfad gespeichert wird. Darüber hinaus können große Attribute auf mehrere Items verteilt werden, indem virtuelle Item-Teile verwendet werden.

Beispiel: Profilbilder der Spieler werden nur als S3-Pfad gespeichert, um die Grenze von 400 KB pro Item einzuhalten und dennoch einen schnellen Zugriff mithilfe der Referenz zu gewährleisten.

Abfragen

Effiziente Lesevorgänge sind ebenfalls von großer Bedeutung. DynamoDB ist am performantesten bei gezielten GetItem-Abfragen auf einem oder mehreren Partitionsschlüsseln oder Indizes. Scans und Filter können die Ressourcen stark belasten und zu hohen Kosten führen. Große Scan-Operationen sollten in kleine, ressourcensparende, parallele Operationen aufgeteilt werden, um eine Drosselung zu verhindern. Um die Kosten bei Lesevorgängen zu reduzieren, bei denen Echtzeitkonsistenz nicht kritisch ist, kann die eventuale Konsistenz genutzt werden.

Batch-Prozessierung

Batch-Verarbeitung in DynamoDB ermöglicht das gleichzeitige Schreiben und Lesen mehrerer Elemente, was die Leistung deutlich verbessern und die Kosten senken kann. Durch das Bündeln von Operationen in einem einzigen Netzwerkaufruf reduziert Batch-Verarbeitung die Latenz und die Anzahl der erforderlichen API-Aufrufe, was zu einer insgesamt besseren Ressourcennutzung und Kosteneffizienz führt.

Sekundäre Indizes

Indizes auf Tabellen mit schreibintensiven Workloads sollte man tunlichst vermeiden, da diese die Schreibleistung erheblich beeinträchtigen können. Indizes sollten so klein wie möglich gehalten werden, um Speicher- und Durchsatzkosten zu minimieren.

Des Weiteren sollte man globale sekundäre Indizes (GSIs) verwenden, sofern keine stark konsistenten Lesevorgänge erforderlich sind. Bei lokalen sekundären Indizes (LSIs) ist es sinnvoll, nicht projizierte Attribute in den Index zu projizieren, wenn die Mehrheit der Lesevorgänge diese Attribute benötigt. Obwohl dies zusätzliche Speicherkosten verursacht, kann es die Abfrageleistung erheblich verbessern und somit die Gesamtleistung der Anwendung steigern.

DAX – DynamoDB Accelerator

DynamoDB liefert bei Datenanfragen Ergebnisse im einstelligen Millisekunden-Bereich. Es gibt jedoch Anwendungen, die noch schnellere Antwortzeiten benötigen. Hierbei kann der DynamoDB Accelerator Service, auch DAX genannt, unterstützen.

DAX ist eine In-Memory-Cache-Erweiterung für die DynamoDB. Er sitzt zwischen der abfragenden Anwendung und der Datenbank und speichert häufig abgerufene Daten im In-Memory-Speicher zwischen. Dadurch wird die Notwendigkeit reduziert, Daten von der Festplatte zu lesen. Der Accelerator ermöglicht eine bis zu zehnfache Performance-Steigerung, auch bei Millionen von Anfragen pro Sekunde. Damit lassen sich Abfragezeiten im zweistelligen Mikrosekundenbereich erreichen.

DAX ist mit den vorhandenen DynamoDB-API-Aufrufen kompatibel, sodass der Anwendungscode nicht geändert werden muss, um DAX zu verwenden. Dadurch lässt sich DAX einfach in bestehende Anwendungen integrieren.

DAX-Architektur

Ein DAX-Cluster besteht aus einem oder mehreren Knoten, wobei jeder Knoten eine dedizierte Cache-Instanz darstellt. Die Knoten kommunizieren untereinander über ein proprietäres Protokoll, um eine konsistente Sicht auf die Daten im Cluster sicherzustellen. Um das Cluster bei steigender Last zu skalieren, können entweder zusätzliche Knoten hinzugefügt oder leistungsstärkere Knotentypen verwendet werden.

Ein DAX-Cluster kann nur mit DynamoDB-Tabellen in derselben Region kommunizieren. Es ist jedoch möglich, mehrere Cluster in verschiedenen Verfügbarkeitszonen für eine Tabelle zu erstellen. Durch die Replikation verwaltet DAX eine Kopie Ihrer Daten in jeder Verfügbarkeitszone.

Zur Verwaltung der Daten im Cache verwendet der DynamoDB Accelerator drei Caching-Strategien. Für Lesevorgänge wird das Read-Through-Caching verwendet, bei dem zunächst im Cache nachgeschaut wird. Bei einem Cache-Hit werden die Daten sofort zurückgegeben. Sind die Daten noch nicht im Cache, werden sie nachgeladen und für zukünftige Abfragen bereitgestellt.

Beim Schreiben der Daten wird eine Kombination aus Write-Through- und Write-Back-Caching genutzt. Beim Write-Through-Caching werden Daten, die in DynamoDB geschrieben werden, auch im DAX-Cache gespeichert. Beim Write-Back-Caching werden Daten, die im DAX-Cache aktualisiert werden, schließlich in DynamoDB zurückgeschrieben.

Der DynamoDB Accelerator eignet sich besonders für Anwendungen, die eine schnelle Reaktionszeit für Lesevorgänge benötigen. Des Weiteren können durch die Auslagerung der Lesevorgänge in den DAX-Cache die Kosten der DynamoDB reduziert werden. Allerdings sollte DAX nicht verwendet werden, wenn die Anwendung schreibintensiv ist oder bereits eine andere Cache-Lösung mit eigener client-seitiger Logik verwendet wird.

Fazit

DynamoDB von Amazon Web Services bietet eine solide NoSQL-Datenbanklösung mit einem flexiblen Datenmodell, effizienter Partitionierung und Anpassungsmöglichkeiten bei der Provisionierung. Die Implementierung des DynamoDB Accelerator (DAX) Service ermöglicht eine verbesserte Leistung durch einen verwalteten In-Memory-Cache für DynamoDB-Tabellen.

Die Schnelligkeit und Reaktionsfähigkeit von DynamoDB machen es zu einer attraktiven Option für Anwendungen, die eine hohe Leistung benötigen. Die Möglichkeit zur nahtlosen Integration über SDKs und APIs erleichtert die Entwicklung und den Einsatz von Anwendungen, die auf DynamoDB basieren.

Es ist jedoch wichtig, die potenziellen Herausforderungen zu beachten, insbesondere den Vendor Lock-in zu AWS. Durch die Verwendung einer proprietären Technologie wie DynamoDB entsteht eine enge Bindung an die AWS-Plattform, was möglicherweise die Portabilität und Flexibilität von Anwendungen beeinträchtigen kann. Unternehmen sollten daher eine gründliche Analyse durchführen und alternative Lösungen in Betracht ziehen, um die langfristige Nachhaltigkeit ihrer Architekturen sicherzustellen.

Insgesamt bietet DynamoDB eine fortschrittliche NoSQL-Lösung, die mit ihren Funktionen und Integrationsoptionen viele Vorteile bietet. Durch eine sorgfältige Bewertung der technischen Anforderungen und eine strategische Planung können Organisationen die Potenziale von DynamoDB ausschöpfen und gleichzeitig die Risiken im Zusammenhang mit dem Vendor Lock-in proaktiv angehen.

(ID:50096230)