Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Amazon DynamoDB Accelerator (DAX) wurde für die Ausführung in einer Amazon-Virtual-Private-Cloud-(Amazon-VPC)-Umgebung entwickelt. Der Amazon-VPC-Service definiert ein virtuelles Netzwerk, das einem herkömmlichen Rechenzentrum sehr ähnlich ist. Mit einer VPC können Sie den zugehörigen IP-Adressbereich, die Subnetze, Routing-Tabellen, Netzwerk-Gateways und Sicherheitseinstellungen steuern. Sie können einen DAX-Cluster in Ihrem virtuellen Netzwerk starten und den Zugriff auf den Cluster über Amazon-VPC-Sicherheitsgruppen steuern.
Anmerkung
Wenn Sie Ihr AWS Konto nach dem 4. Dezember 2013 erstellt haben, haben Sie in jeder AWS Region bereits eine Standard-VPC. Die VPC kann sofort verwendet werden – ohne zusätzliche Konfigurationsschritte ausführen zu müssen.
Weitere Informationen finden Sie unter Standard-VPC und Standard-Subnetze im Amazon-VPC-Benutzerhandbuch.
Das folgende Diagramm zeigt einen allgemeinen Überblick über DAX.
Für die Erstellung eines DAX-Clusters verwenden Sie AWS Management Console. Sofern nicht anders von Ihnen festgelegt, wird Ihr DAX-Cluster in Ihrer Standard-VPC ausgeführt. Um Ihre Anwendung auszuführen, starten Sie eine EC2 Amazon-Instance in Ihrer Amazon VPC. Anschließend stellen Sie Ihre Anwendung (mit dem DAX-Client) auf der EC2 Instance bereit.
Der DAX-Client leitet zur Laufzeit alle DynamoDB-API-Anforderungen der Anwendung an den DAX-Cluster weiter. Wenn DAX eine dieser API-Anforderungen direkt verarbeiten kann, erfolgt die Verarbeitung auch direkt. Andernfalls wird die Anforderung an DynamoDB übergeben.
Schließlich gibt der DAX-Cluster die Ergebnisse an Ihre Anwendung zurück.
Wie DAX-Anforderungen verarbeitet
Ein DAX-Cluster besteht aus einem oder mehreren Knoten. Auf jedem Knoten wird eine eigene Instance der DAX-Caching-Software ausgeführt. Einer der Knoten dient als primärer Knoten für den Cluster. Weitere Knoten (sofern vorhanden) dienen als Read Replicas. Weitere Informationen finden Sie unter Knoten.
Ihre Anwendung kann auf DAX zugreifen, wenn der Endpunkt für den DAX-Cluster angegeben wird. Die DAX-Client-Software arbeitet mit dem Cluster-Endpunkt zusammen, um einen intelligenten Lastausgleich und intelligentes Routing zu erreichen.
Lesevorgänge
DAX kann auf die folgenden API-Aufrufe antworten:
-
GetItem -
BatchGetItem -
Query -
Scan
Wenn die Anforderung Eventually-Consistent-Lesevorgänge (Standardverhalten) angibt, versucht sie, das Element in DAX zu lesen:
-
Wenn DAX das Element verfügbar hat (Cache-Treffer), gibt DAX das Element an die Anwendung ohne Zugriff auf DynamoDB zurück.
-
Wenn DAX nicht über das Element verfügt (Cache-Fehlschlag), leitet DAX die Anforderung an DynamoDB weiter. Wenn die Antwort von DynamoDB eingeht, gibt DAX die Ergebnisse an die Anwendung zurück. Die Ergebnisse werden jedoch auch in den Cache auf dem primären Knoten geschrieben.
Anmerkung
Wenn im Cluster Lesereplikate vorhanden sind, sorgt DAX automatisch dafür, dass die Replikate mit dem primären Knoten synchron sind. Weitere Informationen finden Sie unter Cluster.
Wenn die Anforderung Strongly-Consistent-Lesevorgänge angibt, leitet DAX die Anforderung an DynamoDB weiter. Die Ergebnisse von DynamoDB werden nicht im Cache von DAX gespeichert. Sie werden lediglich an die Anwendung zurückgegeben.
Schreibvorgänge
Die folgenden DAX-API-Operationen werden als „Write-Through“ bezeichnet:
-
BatchWriteItem -
UpdateItem -
DeleteItem -
PutItem
Mit diesen Operationen werden die Daten zuerst in die DynamoDB-Tabelle geschrieben und anschließend in den DAX-Cluster. Die Operation ist nur erfolgreich, wenn die Daten erfolgreich in die Tabelle und in DAX geschrieben werden.
Andere Operationen
DAX erkennt keine DynamoDB-Operationen für die Verwaltung von Tabellen (z. B. CreateTable, UpdateTable und usw.). Wenn die Anwendung diese Operationen ausführen muss, muss sie direkt auf DynamoDB zugreifen, anstatt DAX zu verwenden.
Ausführliche Informationen zu DAX und DynamoDB-Konsistenz finden Sie unter DAX- und DynamoDB-Konsistenzmodelle.
Hinweise zur Funktionsweise von Transaktionen in DAX finden Sie unter Verwenden von Transactional APIs in DynamoDB Accelerator (DAX).
Anforderungsratenbegrenzung
Wenn die Anzahl der an DAX gesendeten Anfragen die Kapazität eines Knotens übersteigt, begrenzt DAX die Rate, mit der zusätzliche Anfragen akzeptiert werden, indem es a zurückgibt ThrottlingException. Zur Bestimmung der Menge der Anforderungen, die verarbeitet werden können, wertet DAX Ihre CPU-Auslastung kontinuierlich aus, während ein fehlerfreier Clusterstatus beibehalten wird.
Sie können die ThrottledRequestCount Metrik überwachen, die DAX auf Amazon veröffentlicht CloudWatch. Wenn diese Ausnahmen regelmäßig angezeigt werden, sollten Sie die Skalierung des Clusters in Erwägung ziehen.
Element-Cache
DAX pflegt einen Element-Cache, um die Ergebnisse von GetItem- und BatchGetItem-Operationen zu speichern. Die Elemente im Cache stellen letztlich konsistente Daten von DynamoDB dar. Sie werden anhand ihrer Primärschlüsselwerte gespeichert.
Wenn eine Anwendung eine GetItem- oder BatchGetItem-Anforderung sendet, versucht DAX, die Elemente unter Verwendung der angegebenen Schlüsselwerte direkt aus dem Element-Cache zu lesen. Werden die Elemente gefunden (Cache-Treffer), gibt DAX sie umgehend an die Anwendung zurück. Wenn die Elemente nicht gefunden werden (Cache-Fehler), sendet DAX die Anforderung an DynamoDB. DynamoDB verarbeitet die Anforderungen mithilfe von Eventually-Consistent-Lesevorgängen und gibt die Elemente an DAX zurück. DAX speichert sie im Element-Cache und gibt sie dann an die Anwendung zurück.
Der Element-Cache verfügt über eine Time-to-Live-Einstellung (TTL), die standardmäßig auf 5 Minuten festgelegt ist. DAX weist jedem Element einen Zeitstempel zu, das in den Element-Cache geschrieben wird. Ein Element läuft ab, wenn es im Cache länger als wie in der TTL-Einstellung angegeben vorhanden ist. Wenn Sie eine GetItem-Anforderung für ein abgelaufenes Element ausgeben, wird dies als Cache-Fehler betrachtet und DAX sendet die GetItem-Anforderung an DynamoDB.
Anmerkung
Sie können die TTL-Einstellung für den Element-Cache beim Erstellen des neuen DAX-Clusters festlegen. Weitere Informationen finden Sie unter Verwalten von DAX-Clustern .
DAX verwaltet auch eine LRU-Liste (Least Recently Used) für den Element-Cache. Mit der LRU-Liste wird verfolgt, wann ein Element zuerst in den Cache geschrieben und wann es zuletzt aus dem Cache gelesen wurde. Wenn der Element-Cache voll wird, bereinigt DAX ältere Elemente (auch wenn sie noch nicht abgelaufen sind), um Platz für neue Elemente zu schaffen. Der LRU-Algorithmus ist für den Element-Cache immer aktiviert. Er ist vom Benutzer nicht konfigurierbar.
Wenn Sie Null als Element-Cache-TTL-Einstellung angeben, werden Elemente im Element-Cache nur aufgrund einer LRU-Bereinigung oder einer „Write-Through“-Operation aktualisiert.
Ausführliche Hinweise zur Konsistenz des Element-Caches in DAX finden Sie unter Verhalten des DAX-Element-Caches.
Abfrage-Cache
DAX pflegt auch einen Abfrage-Cache, um die Ergebnisse von Query- und Scan-Operationen zu speichern. Die Elemente in diesem Cache stellen die Ergebnissätze von Abfragen und Scans auf DynamoDB-Tabellen dar. Diese Ergebnissätze werden anhand ihrer Parameterwerte gespeichert.
Wenn eine Anwendung eine Query- oder Scan-Anforderung sendet, versucht DAX unter Verwendung der angegebenen Parameterwerte, einen übereinstimmenden Ergebnissatz aus dem Abfrage-Cache zu lesen. Wird der Ergebnissatz gefunden (Cache Hit), gibt DAX ihn umgehend an die Anwendung zurück. Wenn der Ergebnissatz nicht gefunden wird (Cache-Fehler), sendet DAX die Anforderung an DynamoDB. DynamoDB verarbeitet die Anforderungen mit Eventually-Consistent-Lesevorgängen und gibt den Ergebnissatz an DAX zurück. DAX speichert ihn im Abfrage-Cache und gibt ihn dann an die Anwendung zurück.
Anmerkung
Sie können die TTL-Einstellung für den Abfrage-Cache beim Erstellen eines neuen DAX-Clusters festlegen. Weitere Informationen finden Sie unter Verwalten von DAX-Clustern .
DAX verwaltet auch eine LRU-Liste (Least Recently Used) für den Abfrage-Cache. Mit der LRU-Liste wird verfolgt, wann ein Ergebnissatz zuerst in den Cache geschrieben und wann das Ergebnis zuletzt aus dem Cache gelesen wurde. Wenn der Abfrage-Cache voll wird, bereinigt DAX ältere Ergebnissätze (auch wenn sie noch nicht abgelaufen sind), um Platz für neue Ergebnissätze zu schaffen. Der LRU-Algorithmus ist für den Abfrage-Cache immer aktiviert. Er ist vom Benutzer nicht konfigurierbar.
Wenn Sie Null als Abfrage-Cache TTL-Einstellung, wird die Abfrageantwort nicht zwischengespeichert.
Ausführliche Hinweise zur Konsistenz des Abfrage-Caches in DAX finden Sie unter Verhalten des DAX-Abfrage-Caches.
