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.

DAX: Funktionsweise

Amazon DynamoDB Accelerator (DAX) ist für die Ausführung in einer Amazon Virtual Private Cloud (AmazonVPC) -Umgebung konzipiert. Der VPC Amazon-Service definiert ein virtuelles Netzwerk, das einem herkömmlichen Rechenzentrum sehr ähnlich ist. Mit a VPC haben Sie die Kontrolle über den IP-Adressbereich, die Subnetze, Routing-Tabellen, Netzwerk-Gateways und Sicherheitseinstellungen. Sie können einen DAX Cluster in Ihrem virtuellen Netzwerk starten und den Zugriff auf den Cluster mithilfe von VPC Amazon-Sicherheitsgruppen kontrollieren.

Das folgende Diagramm zeigt einen allgemeinen Überblick über. DAX

Um einen DAX Cluster zu erstellen, verwenden Sie den AWS Management Console. Sofern Sie nichts anderes angeben, läuft Ihr DAX Cluster innerhalb Ihrer StandardeinstellungVPC. Um Ihre Anwendung auszuführen, starten Sie eine EC2 Amazon-Instance in Ihrem AmazonVPC. Anschließend stellen Sie Ihre Anwendung (mit dem DAX Client) auf der EC2 Instance bereit.

Zur Laufzeit leitet der DAX Client alle API DynamoDB-Anfragen Ihrer Anwendung an den DAX Cluster weiter. Wenn er eine dieser API Anfragen direkt verarbeiten DAX kann, tut er dies auch. Andernfalls wird die Anforderung an DynamoDB übergeben.

Schließlich gibt der DAX Cluster die Ergebnisse an Ihre Anwendung zurück.

Wie DAX verarbeitet man Anfragen

Ein DAX Cluster besteht aus einem oder mehreren Knoten. Jeder Knoten führt seine eigene Instanz der DAX Caching-Software aus. 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 darauf zugreifen, DAX indem sie den Endpunkt für den DAX Cluster angibt. Die DAX Clientsoftware arbeitet mit dem Cluster-Endpunkt zusammen, um intelligenten Lastenausgleich und Routing durchzuführen.

Lesevorgänge

DAXkann auf die folgenden API Aufrufe antworten:

Wenn die Anfrage eventuell konsistente Lesevorgänge spezifiziert (das Standardverhalten), versucht sie, das Element aus folgenden Quellen zu lesenDAX:

Wenn die Anforderung stark konsistente Lesevorgänge spezifiziert, DAX wird die Anforderung an DynamoDB weitergeleitet. Die Ergebnisse von DynamoDB werden nicht zwischengespeichert. DAX Sie werden lediglich an die Anwendung zurückgegeben.

Schreibvorgänge

Die folgenden DAX API Operationen gelten als „Write-Through“:

Bei diesen Vorgängen werden Daten zuerst in die DynamoDB-Tabelle und dann in den DAX Cluster geschrieben. Der Vorgang ist nur erfolgreich, wenn die Daten erfolgreich sowohl in die Tabelle als auch in die Tabelle geschrieben wurden. DAX

Andere Operationen

DAXerkennt keine DynamoDB-Operationen zum Verwalten von Tabellen (wie CreateTableUpdateTable, usw.). Wenn Ihre Anwendung diese Operationen ausführen muss, muss sie direkt auf DynamoDB zugreifen, anstatt sie zu verwenden. DAX

Ausführliche Informationen DAX zur DynamoDB-Konsistenz finden Sie unter. DAXund DynamoDB-Konsistenzmodelle

Hinweise zur Funktionsweise von Transaktionen in finden Sie DAX unter. Verwenden von Transactional APIs in DynamoDB Accelerator () DAX

Anforderungsratenbegrenzung

Wenn die Anzahl der Anfragen, die an gesendet werden, die Kapazität eines Knotens DAX übersteigt, DAX begrenzt es die Rate, mit der er zusätzliche Anfragen akzeptiert, indem a zurückgegeben wird ThrottlingException. DAXbewertet kontinuierlich Ihre CPU Auslastung, um zu ermitteln, wie viele Anfragen er verarbeiten kann, ohne dass der Clusterstatus beeinträchtigt wird.

Sie können die ThrottledRequestCount Metrik überwachen, die auf Amazon DAX veröffentlicht wird CloudWatch. Wenn diese Ausnahmen regelmäßig angezeigt werden, sollten Sie die Skalierung des Clusters in Erwägung ziehen.

Element-Cache

DAXverwaltet einen Artikel-Cache, in dem die Ergebnisse GetItem und BatchGetItem Operationen gespeichert werden. Die Elemente im Cache stellen letztlich konsistente Daten von DynamoDB dar. Sie werden anhand ihrer Primärschlüsselwerte gespeichert.

Wenn eine Anwendung eine GetItem BatchGetItem Oder-Anfrage sendet, DAX versucht sie, die Elemente mithilfe der angegebenen Schlüsselwerte direkt aus dem Elementcache zu lesen. Wenn die Elemente gefunden werden (Cache-Treffer), werden sie sofort an die Anwendung DAX zurückgegeben. Wenn die Elemente nicht gefunden werden (Cache-Fehler), DAX sendet die Anfrage an DynamoDB. DynamoDB verarbeitet die Anfragen mithilfe von eventuell konsistenten Lesevorgängen und gibt die Elemente an zurück. DAX DAXspeichert sie im Element-Cache und gibt sie dann an die Anwendung zurück.

Der Elementcache hat die Einstellung Time to Live (TTL), die standardmäßig 5 Minuten beträgt. DAXweist jedem Element, das in den Elementcache geschrieben wird, einen Zeitstempel zu. Ein Element läuft ab, wenn es länger als die Einstellung im Cache verblieben ist. TTL Wenn Sie eine GetItem Anfrage für ein abgelaufenes Objekt stellen, wird dies als Cachefehler gewertet und die GetItem Anfrage wird an DynamoDB DAX gesendet.

DAXverwaltet auch eine Liste der zuletzt verwendeten Dateien (LRU) für den Element-Cache. In der LRU Liste wird nachverfolgt, wann ein Element zum ersten Mal in den Cache geschrieben wurde und wann das Element zuletzt aus dem Cache gelesen wurde. Wenn der Elementcache voll ist, DAX werden ältere Elemente (auch wenn sie noch nicht abgelaufen sind) entfernt, um Platz für neue Elemente zu schaffen. Der LRU Algorithmus ist für den Element-Cache immer aktiviert und kann nicht vom Benutzer konfiguriert werden.

Wenn Sie Null als TTL Einstellung für den Elementcache angeben, werden Elemente im Elementcache nur aktualisiert, wenn eine LRU Räumung oder ein „Write-Through“ -Vorgang erfolgt.

Ausführliche Informationen zur Konsistenz des Elementcaches in finden Sie unter. DAX DAXVerhalten des Element-Caches

Abfrage-Cache

DAXverwaltet außerdem einen Abfrage-Cache zum Speichern der Ergebnisse von Query und Scan Operationen. 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 Scan OR-Anforderung sendet, DAX versucht sie, mithilfe der angegebenen Parameterwerte eine passende Ergebnismenge aus dem Abfrage-Cache zu lesen. Wenn die Ergebnismenge gefunden wird (Cache-Treffer), wird sie sofort an die Anwendung DAX zurückgegeben. Wenn die Ergebnismenge nicht gefunden wird (Cache-Fehler), wird die Anforderung an DynamoDB DAX gesendet. DynamoDB verarbeitet die Anfragen mithilfe von eventuell konsistenten Lesevorgängen und gibt die Ergebnismenge auf zurück. DAX DAXspeichert es im Abfrage-Cache und gibt es dann an die Anwendung zurück.

DAXverwaltet auch eine LRU Liste 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, werden DAX ältere Ergebnissätze entfernt (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 und kann nicht vom Benutzer konfiguriert werden.

Wenn Sie Null als TTL Einstellung für den Abfrage-Cache angeben, wird die Abfrageantwort nicht zwischengespeichert.

Ausführliche Hinweise zur Konsistenz des Abfragecaches in finden Sie DAX unterDAXVerhalten des Abfrage-Caches.