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.
Der DAX-Cluster ist ein verwalteter Cluster, aber Sie können seine Konfigurationen an Ihre Anwendungsanforderungen anpassen. Aufgrund der engen Integration mit den DynamoDB-API-Vorgängen sollten Sie bei der Integration Ihrer Anwendung in DAX die folgenden Aspekte berücksichtigen.
In diesem Abschnitt
DAX-Preisgestaltung
Die Kosten eines Clusters hängen von der Anzahl und Größe der bereitgestellten Knoten ab. Jedem Knoten wird jede Stunde in Rechnung gestellt, die er im Cluster ausgeführt hat. Weitere Informationen finden Sie unter Amazon DynamoDB – Preise
Cache-Treffer verursachen keine DynamoDB-Kosten, wirken sich jedoch auf die DAX-Clusterressourcen aus. Cachefehler verursachen DynamoDB-Lesekosten und erfordern DAX-Ressourcen. Schreibvorgänge verursachen DynamoDB-Schreibkosten und wirken sich auf die DAX-Clusterressourcen aus, die den Schreibvorgang als Proxy ausführen.
Element-Cache und Abfrage-Cache
DAX verwaltet einen Element-Cache und einen Abfrage-Cache. Wenn Sie die Unterschiede zwischen diesen Caches verstehen, können Sie besser bestimmen, welche Leistungs- und Konsistenzmerkmale sie Ihrer Anwendung bieten.
| Cache-Merkmal | Element-Cache | Abfrage-Cache |
|---|---|---|
|
Zweck |
Speichert die Ergebnisse von GetItemund BatchGetItemAPI-Operationen. |
Speichert die Ergebnisse von Query - und Scan-API-Vorgängen. Bei diesen Vorgängen können mehrere Elemente zurückgegeben werden, die auf Abfragebedingungen und nicht auf bestimmten Elementschlüsseln basieren. |
|
Art des Zugriffs |
Verwendet schlüsselbasierten Zugriff. Wenn eine Anwendung Daten mit |
Verwendet parameterbasierten Zugriff. DAX speichert die Ergebnismenge von |
|
Invalidierung des Caches |
DAX repliziert in den folgenden Szenarien automatisch aktualisierte Elemente in den Elementcache der Knoten im DAX-Cluster:
|
Der Abfrage-Cache ist schwieriger zu ungültig zu machen als der Element-Cache. Elementaktualisierungen werden möglicherweise nicht direkt zwischengespeicherten Abfragen oder Scans zugeordnet. Sie müssen die TTL des Abfrage-Caches sorgfältig anpassen, um die Datenkonsistenz zu gewährleisten. Schreibvorgänge über DAX oder Basistabelle werden erst im Abfrage-Cache wiedergegeben, wenn die TTL die zuvor zwischengespeicherte Antwort abläuft und DAX eine neue Abfrage für DynamoDB durchführt. |
|
Globaler sekundärer Index |
Da der GetItem API-Vorgang für lokale Sekundärindizes oder globale Sekundärindizes nicht unterstützt wird, speichert der Elementcache nur Lesevorgänge aus der Basistabelle im Cache. |
Im Abfrage-Cache werden Abfragen sowohl für Tabellen als auch für Indizes zwischengespeichert. |
TTL-Einstellung für die Caches auswählen
TTL bestimmt den Zeitraum, für den Daten im Cache gespeichert werden, bevor sie veraltet sind. Nach diesem Zeitraum werden die Daten bei der nächsten Anfrage automatisch aktualisiert. Die Auswahl der richtigen TTL-Einstellung für Ihre DAX-Caches erfordert ein ausgewogenes Verhältnis zwischen der Optimierung der Anwendungsleistung und der Datenkonsistenz. Da es keine universelle TTL-Einstellung gibt, die für alle Anwendungen funktioniert, hängt die optimale TTL-Einstellung von den spezifischen Eigenschaften und Anforderungen Ihrer Anwendung ab. Wir empfehlen, mit einer konservativen TTL-Einstellung zu beginnen und dabei diese präskriptiven Leitlinien zu verwenden. Passen Sie dann Ihre TTL-Einstellung iterativ auf der Grundlage der Leistungsdaten und Erkenntnisse Ihrer Anwendung an.
DAX verwaltet eine Liste der zuletzt verwendeten Dateien (LRU) für den Elementcache. Die LRU-Liste verfolgt, wann Elemente zum ersten Mal in den Cache geschrieben oder zuletzt aus dem Cache gelesen wurden. Wenn der Speicher des DAX-Knotens voll ist, entfernt DAX ältere Elemente, auch wenn sie noch nicht abgelaufen sind, um Platz für neue Elemente zu schaffen. Der LRU-Algorithmus ist immer aktiviert und nicht vom Benutzer konfigurierbar.
Beachten Sie die folgenden Punkte, um eine TTL-Dauer festzulegen, die für Ihre Anwendungen geeignet ist:
Machen Sie sich mit Ihren Datenzugriffsmustern vertraut
-
Leseintensive Workloads — Für Anwendungen mit leseintensiven Workloads und seltenen Datenaktualisierungen sollten Sie eine längere TTL-Dauer festlegen, um die Anzahl der Cache-Fehlschläge zu reduzieren. Eine längere TTL-Dauer reduziert auch die Notwendigkeit, auf die zugrunde liegende DynamoDB-Tabelle zuzugreifen.
-
Schreibintensive Workloads — Für Anwendungen mit häufigen Updates, die nicht über DAX geschrieben werden, sollten Sie eine kürzere TTL-Dauer festlegen, um sicherzustellen, dass der Cache mit der Datenbank konsistent bleibt. Eine kürzere TTL-Dauer verringert auch das Risiko, dass veraltete Daten bereitgestellt werden.
Bewerten Sie die Leistungsanforderungen Ihrer Anwendung
-
Latenzempfindlichkeit — Wenn für Ihre Anwendung eine geringe Latenz im Hinblick auf die Datenaktualität erforderlich ist, sollten Sie eine längere TTL-Dauer verwenden. Eine längere TTL-Dauer maximiert die Cache-Treffer, wodurch die durchschnittliche Leselatenz reduziert wird.
-
Durchsatz und Skalierbarkeit — Eine längere TTL-Dauer reduziert die Belastung von DynamoDB-Tabellen und verbessert den Durchsatz und die Skalierbarkeit. Sie sollten dies jedoch mit dem Datenbedarf abwägen. up-to-date
Analysieren Sie die Cache-Entfernung und die Speichernutzung
-
Cache-Speicherlimits — Überwachen Sie die Speichernutzung Ihres DAX-Clusters. Bei einer längeren TTL-Dauer können mehr Daten im Cache gespeichert werden, wodurch die Speichergrenzen erreicht und LRU-basierte Löschungen zur Folge haben können.
Verwenden Sie Metriken und Überwachung, um TTL anzupassen
Überprüfen Sie regelmäßig Messwerte, z. B. Cache-Treffer und Fehlschläge sowie CPU- und Speicherauslastung. Passen Sie Ihre TTL-Einstellung auf der Grundlage dieser Messwerte an, um ein optimales Gleichgewicht zwischen Leistung und Datenaktualität zu finden. Wenn die Anzahl der Cache-Fehler hoch und die Speicherauslastung gering ist, erhöhen Sie die TTL-Dauer, um die Cache-Trefferquote zu erhöhen.
Berücksichtigen Sie die Geschäftsanforderungen und die Einhaltung von Vorschriften
Richtlinien zur Datenspeicherung schreiben möglicherweise die maximale TTL-Dauer vor, die Sie für sensible oder persönliche Informationen festlegen können.
Verhalten im Cache, wenn Sie TTL auf Null setzen
Wenn Sie TTL auf 0 setzen, zeigen der Element-Cache und der Abfrage-Cache das folgende Verhalten:
-
Element-Cache — Elemente im Cache werden nur aktualisiert, wenn eine LRU-Löschung oder ein Write-Through-Vorgang stattfindet.
-
Abfrage-Cache — Abfrageantworten werden nicht zwischengespeichert.
Zwischenspeichern mehrerer Tabellen mit einem DAX-Cluster
Für Workloads mit mehreren kleinen DynamoDB-Tabellen, die keine einzelnen Caches benötigen, speichert ein einzelner DAX-Cluster Anfragen für diese Tabellen zwischen. Dies ermöglicht eine flexiblere und effizientere Nutzung von DAX, insbesondere für Anwendungen, die auf mehrere Tabellen zugreifen und leistungsstarke Lesevorgänge erfordern.
Ähnlich wie bei der DynamoDB-Datenebene APIs benötigen DAX-Anfragen einen Tabellennamen. Wenn Sie mehrere Tabellen im selben DAX-Cluster verwenden, benötigen Sie keine spezielle Konfiguration. Sie müssen jedoch sicherstellen, dass die Sicherheitsberechtigungen des Clusters den Zugriff auf alle zwischengespeicherten Tabellen ermöglichen.
Überlegungen zur Verwendung von DAX mit mehreren Tabellen
Wenn Sie DAX mit mehreren DynamoDB-Tabellen verwenden, sollten Sie die folgenden Punkte berücksichtigen:
-
Speicherverwaltung — Wenn Sie DAX mit mehreren Tabellen verwenden, sollten Sie die Gesamtgröße Ihres Arbeitsdatensatzes berücksichtigen. Alle Tabellen in Ihrem Datensatz teilen sich den gleichen Speicherplatz des von Ihnen ausgewählten Knotentyps.
-
Ressourcenzuweisung — Die Ressourcen des DAX-Clusters werden von allen zwischengespeicherten Tabellen gemeinsam genutzt. Eine Tabelle mit hohem Datenaufkommen kann jedoch dazu führen, dass Daten aus den benachbarten kleineren Tabellen entfernt werden.
-
Skaleneffekte — Gruppieren Sie kleinere Ressourcen zu einem größeren DAX-Cluster, um den Durchschnitt des Datenverkehrs auf ein stabileres Muster zu reduzieren. Für die Gesamtzahl der Leseressourcen, die der DAX-Cluster benötigt, ist es auch wirtschaftlich, drei oder mehr Knoten zu haben. Dies erhöht auch die Verfügbarkeit aller zwischengespeicherten Tabellen im Cluster.
Datenreplikation in globalen DAX- und DynamoDB-Tabellen
DAX ist ein regionsbasierter Dienst, sodass ein Cluster nur den Datenverkehr innerhalb seiner Region kennt. AWS-Region Globale Tabellen umgehen den Cache, wenn sie Daten aus einer anderen Region replizieren.
Eine längere TTL-Dauer kann dazu führen, dass veraltete Daten länger in Ihrer sekundären Region verbleiben als in der primären Region. Dies kann zu Cache-Fehlern im lokalen Cache der sekundären Region führen.
Das folgende Diagramm zeigt die Datenreplikation auf globaler Tabellenebene in der Quellregion A. Der DAX-Cluster in Region B erkennt die neu replizierten Daten aus der Quellregion A nicht sofort.
Verfügbarkeit in der DAX-Region
Nicht alle Regionen, die DynamoDB-Tabellen unterstützen, unterstützen die Bereitstellung von DAX-Clustern. Wenn Ihre Anwendung eine geringe Leselatenz über DAX erfordert, überprüfen Sie zunächst die Liste der Regionen, die DAX unterstützen. Wählen Sie dann eine Region für Ihre DynamoDB-Tabelle aus.
Verhalten beim DAX-Caching
DAX führt Metadaten und negatives Caching durch. Wenn Sie sich mit diesen Caching-Verhaltensweisen vertraut machen, können Sie die Attributmetadaten von zwischengespeicherten Elementen und negativen Cache-Einträgen effektiv verwalten.
-
Zwischenspeichern von Metadaten — DAX-Cluster speichern auf unbestimmte Zeit Metadaten zu den Attributnamen zwischengespeicherter Elemente. Diese Metadaten bleiben auch dann bestehen, wenn das Element abläuft oder aus dem Cache entfernt wurde.
Im Laufe der Zeit können Anwendungen, die eine unbegrenzte Anzahl von Attributnamen verwenden, zu einer Speichererschöpfung im DAX-Cluster führen. Diese Einschränkung gilt nur für Attributnamen der obersten Ebene, nicht jedoch für verschachtelte Attributnamen. Beispiele für unbegrenzte Attributnamen sind Zeitstempel und Sitzung. UUIDs IDs Sie können zwar Zeitstempel und Sitzung IDs als Attributwerte verwenden, wir empfehlen jedoch, kürzere und besser vorhersehbare Attributnamen zu verwenden.
-
Negatives Caching — Wenn ein Cache-Fehler auftritt und der Lesevorgang aus einer DynamoDB-Tabelle keine passenden Elemente ergibt, fügt DAX dem entsprechenden Element- oder Abfrage-Cache einen negativen Cache-Eintrag hinzu. Dieser Eintrag bleibt bestehen, bis die Cache-TTL-Dauer abläuft oder ein Write-Through erfolgt. DAX gibt diesen negativen Cache-Eintrag weiterhin für future Anfragen zurück.
Wenn das negative Caching-Verhalten nicht zu Ihrem Anwendungsmuster passt, lesen Sie die DynamoDB-Tabelle direkt, wenn DAX ein leeres Ergebnis zurückgibt. Wir empfehlen außerdem, eine kürzere TTL-Cachedauer festzulegen, um langanhaltende leere Ergebnisse im Cache zu vermeiden und die Konsistenz mit der Tabelle zu verbessern.
