Bewerten der Eignung von DAX für Ihre Anwendungsfälle
In diesem Abschnitt wird erklärt, wann und warum DAX verwendet werden sollte. Anhand dieser Anleitung können Sie feststellen, ob die Integration von DAX in DynamoDB für die Workload-Muster, Leistungsanforderungen und Datenkonsistenzanforderungen Ihrer Anwendung von Vorteil ist. Sie behandelt auch Szenarien, in denen DAX möglicherweise nicht geeignet ist, z. B. für schreibintensive Workloads und selten abgerufene Daten.
In diesem Abschnitt
Wann und warum Sie sich für DAX entscheiden sollten
Sie können in verschiedenen Szenarien erwägen, DAX zu Ihrem Anwendungs-Stack hinzuzufügen. Verwenden Sie DAX beispielsweise, um die Gesamtlatenz von Leseanforderungen an DynamoDB zu reduzieren oder um wiederholte Lesevorgänge derselben Daten aus einer Tabelle zu minimieren. Die folgende Liste enthält Beispiele für Szenarien, in denen Sie die Vorteile der Integration von DAX in DynamoDB nutzen können:
-
Hohe Leistungsanforderungen
-
Lesevorgänge mit geringer Latenz – Sie sollten die Verwendung von DAX in Betracht ziehen, wenn Ihre Anwendung Reaktionszeiten in Mikrosekunden für letztendlich konsistente Lesevorgänge benötigt. DAX kann außerdem die Reaktionszeit für den Zugriff auf häufig gelesene Daten drastisch reduzieren.
-
-
Leseintensive Workloads
-
Leseintensive Anwendungen – Bei Anwendungen mit einem hohen Lese-/Schreibverhältnis, z. B. 10:1 oder mehr, führt DAX zu mehr Cache-Treffern und weniger veralteten Daten. Dadurch werden Lesevorgänge in einer Tabelle reduziert. Um zu verhindern, dass veraltete Daten aus dem Cache gelesen werden, wenn Ihre Anwendung schreibintensiv ist, stellen Sie sicher, dass Sie einen niedrigeren Verwenden von Time to Live (TTL) in DynamoDB-Wert für den Cache festlegen.
-
Caching häufiger Abfragen – Wenn Ihre Anwendung häufig dieselben Daten liest, z. B. beliebte Produkte auf einer E-Commerce-Plattform, kann DAX diese Anfragen direkt aus dem Cache heraus bearbeiten.
-
-
Stoßweise Datenverkehrsmuster
-
Reibungslosere Tabellenskalierung – DAX hilft dabei, die Auswirkungen plötzlicher Datenverkehrsspitzen auszugleichen. DAX bietet einen Puffer, mit dem die Kapazität von DynamoDB-Tabellen ordnungsgemäß hochskaliert werden kann, wodurch das Risiko einer Drosselung beim Lesen verringert wird.
-
Höherer Lesedurchsatz für jedes Element – DynamoDB weist jedem Element individuelle Partitionen zu. Eine Partition beginnt jedoch, Lesevorgänge eines Elements zu drosseln, wenn 3 000 Lesekapazitätseinheiten (RCU) erreicht werden. Mit DAX können Sie die Anzahl der Lesevorgänge eines einzelnen Elements auf mehr als 3 000 RCU skalieren.
-
-
Kostenoptimierung
-
Reduzierung der DynamoDB-Kosten – Durch das Lesen aus DAX können die an eine DynamoDB-Tabelle gesendeten Lesevorgänge reduziert werden, was sich dann direkt auf die Kosten auswirken kann. Bei einer hohen Cache-Trefferrate können die reduzierten Lesekosten für Tabellen die Kosten eines DAX-Clusters übersteigen, was zu einer Reduzierung der Nettokosten führt.
-
-
Anforderungen für Datenkonsistenz.
-
Letztendliche Konsistenz – DAX unterstützt letztendlich konsistente Lesevorgänge. Dadurch eignet sich DAX für Anwendungsfälle, in denen eine sofortige Konsistenz nicht entscheidend ist.
-
Write-Through-Caching – Schreibvorgänge, die Sie in DAX vornehmen, werden als Write-Through bezeichnet Sobald DAX bestätigt hat, dass ein Element in DynamoDB geschrieben wurde, speichert es diese Elementversion im Element-Cache. Dieser Write-Through-Mechanismus trägt dazu bei, eine engere Datenkonsistenz zwischen Cache und Datenbank aufrechtzuerhalten, verwendet jedoch zusätzliche DAX-Cluster-Ressourcen.
-
Wann Sie DAX nicht verwenden sollten
DAX ist zwar leistungsstark, aber nicht für alle Szenarien geeignet. Die folgende Liste enthält Beispiele für Szenarien, in denen die Integration von DAX in DynamoDB nicht geeignet ist:
-
Schreibintensive Workloads – Der Hauptvorteil von DAX ist die Beschleunigung von Lesevorgängen, aber Schreibvorgänge verbrauchen mehr DAX-Ressourcen als Lesevorgänge. Wenn Ihre Anwendung überwiegend schreibintensiv ist, sind die Vorteile von DAX möglicherweise begrenzt.
-
Selten gelesene Daten – Wenn Ihre Anwendung selten auf Daten oder auf eine Vielzahl selten wiederverwendeter Daten (kalte Daten) zugreift, wird es wahrscheinlich zu einer niedrigen cache hit ratio kommen. In diesem Fall rechtfertigt der Aufwand für die Wartung des Caches die Leistungssteigerung möglicherweise nicht.
-
Massenlese- oder -schreibvorgänge – Wenn Ihre Anwendung mehr Massenschreibvorgänge als einzelne Schreibvorgänge durchführt, sollten Sie DAX umgehen. Darüber hinaus sollten Sie für Massenlesevorgänge vollständige Tabellenscans direkt für eine DynamoDB-Tabelle ausführen.
-
Hohe Konsistenz- oder Transaktionsanforderungen – DAX leitet strikt konsistente Lesevorgänge und TransactGetItems-Aufrufe an eine DynamoDB-Tabelle weiter. Sie sollten diese Lesevorgänge rund um den DAX-Cluster durchführen, um die Nutzung von Cluster-Ressourcen zu vermeiden. Auf diese Weise gelesene Elemente werden nicht zwischengespeichert. Daher hat das Routing solcher Elemente über DAX keinen Sinn.
-
Einfache Anwendungen mit geringen Leistungsanforderungen – Für Anwendungen mit geringen Leistungsanforderungen und Toleranz gegenüber direkter DynamoDB-Latenz sind die Komplexität und die Kosten von DAX möglicherweise nicht notwendig. DynamoDB bewältigt einen hohen Durchsatz allein und bietet eine Leistung im einstelligen Millisekundenbereich.
-
Komplexe Abfrageanforderungen, die über den Schlüssel-Wert-Zugriff hinausgehen – DAX ist für Schlüssel-Wert-Zugriffsmuster optimiert. Wenn Ihre Anwendung komplexe Abfragefunktionen mit komplexer Filterung erfordert, z. B. für Abfrage- und Scan-Operationen, sind die Vorteile des DAX-Cachings möglicherweise begrenzt.
Verwenden Sie in diesen Situationen Amazon ElastiCache (Redis OSS) als Alternative. ElastiCache (Redis OSS) unterstützt erweiterte Datenstrukturen wie Listen, Sets und Hashes. Es bietet außerdem Funktionen wie Pub/Sub, Geodatenindizes und Skripting.
-
Compliance-Anforderungen – DAX bietet derzeit nicht dieselben Compliance-Akkreditierungen wie DynamoDB. Beispielsweise hat DAX die SOC-Akkreditierung noch nicht erhalten.
