Konfigurieren Ihres DAX-Clusters
Der DAX-Cluster ist ein verwalteter Cluster, dessen Konfiguration Sie jedoch an Ihre Anwendungsanforderungen anpassen können. Aufgrund der engen Integration in DynamoDB-API-Operationen 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. Für jeden Knoten wird jede Stunde, die er im Cluster ausgeführt wird, in Rechnung gestellt. Weitere Informationen finden Sie unter Amazon DynamoDB – Preise
Cache-Treffer verursachen keine DynamoDB-Kosten, wirken sich jedoch auf die DAX-Cluster-Ressourcen aus. Cache-Fehler verursachen DynamoDB-Lesekosten und benötigen DAX-Ressourcen. Schreibvorgänge verursachen DynamoDB-Schreibkosten und wirken sich auf die DAX-Cluster-Ressourcen 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-Merkmale | Element-Cache | Abfrage-Cache |
|---|---|---|
|
Zweck |
Speichert die Ergebnisse der GetItem- und BatchGetItemAPI-Operationen. |
Speichert die Ergebnisse der Query- und Scan-API-Operationen. Bei diesen Operationen können mehrere Elemente zurückgegeben werden, die auf Abfragebedingungen und nicht auf bestimmten Elementschlüsseln basieren. |
|
Art des Zugriffs |
Verwendet einen schlüsselbasierten Zugriff. Wenn eine Anwendung Daten mit |
Nutzt einen parameterbasierten Zugriff. DAX speichert den Ergebnissatz von |
|
Cache-Invalidierung |
DAX repliziert in den folgenden Szenarien automatisch aktualisierte Elemente in den Element-Cache der Knoten im DAX-Cluster:
|
Der Abfrage-Cache ist schwieriger zu invalidieren 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 die Basistabelle werden erst im Abfrage-Cache wiedergegeben, wenn die TTL die zuvor zwischengespeicherte Antwort ablaufen lässt und DAX eine neue Abfrage in DynamoDB durchführt. |
|
Globaler sekundärer Index |
Da die GetItem-API-Operation für lokale sekundäre Indizes oder globale sekundäre Indizes nicht unterstützt wird, speichert der Element-Cache nur Lesevorgänge aus der Basistabelle im Cache. |
Im Abfrage-Cache werden Abfragen sowohl für Tabellen als auch für Indizes zwischengespeichert. |
Auswahl der TTL-Einstellung für die Caches
Die 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 geeignet ist, 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 vorgeschriebenen Anleitungen zu verwenden. Passen Sie dann Ihre TTL-Einstellung iterativ auf der Grundlage der Leistungsdaten und Erkenntnisse Ihrer Anwendung an.
DAX verwaltet eine LRU-Liste (Least Recently Used) für den Element-Cache. In der LRU-Liste wird nachverfolgt, wann Elemente zum ersten Mal in den Cache geschrieben oder zuletzt aus dem Cache gelesen wurden. Wenn der Arbeitsspeicher des DAX-Knotens voll ist, bereinigt 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 kann nicht vom Benutzer konfiguriert werden.
Berücksichtigen Sie bei der Festlegung einer TTL-Dauer, die für Ihre Anwendungen geeignet ist, die folgenden Punkte:
Verstehen Ihrer Datenzugriffsmuster
-
Leseintensive Workloads – Legen Sie für Anwendungen mit leseintensiven Workloads und seltenen Datenaktualisierungen eine längere TTL-Dauer fest, um die Anzahl der Cache-Fehler zu reduzieren. Eine längere TTL-Dauer reduziert außerdem die Notwendigkeit, auf die zugrunde liegende DynamoDB-Tabelle zuzugreifen.
-
Schreibintensive Workloads – Legen Sie für Anwendungen mit häufigen Aktualisierungen, die nicht über DAX geschrieben werden, eine kürzere TTL-Dauer fest, um sicherzustellen, dass der Cache mit der Datenbank konsistent bleibt. Eine kürzere TTL-Dauer verringert außerdem das Risiko, dass veraltete Daten bereitgestellt werden.
Bewerten der Leistungsanforderungen Ihrer Anwendung
-
Latenzempfindlichkeit – Wenn für Ihre Anwendung eher eine geringe Latenz als 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 für DynamoDB-Tabellen und verbessert den Durchsatz und die Skalierbarkeit. Sie sollten dies jedoch mit der Notwendigkeit aktueller Daten in Einklang bringen.
Analysieren der Cache-Bereinigung und 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 möglicherweise die Speicherlimits erreicht und LRU-basierte Bereinigungen durchgeführt werden.
Verwenden von Metriken und Überwachung, um die TTL anzupassen
Überprüfen Sie regelmäßig Metriken, z. B. Cache-Treffer und -Fehler sowie die CPU- und Speicherauslastung. Passen Sie Ihre TTL-Einstellung auf der Grundlage dieser Metriken 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-Trefferrate zu erhöhen.
Berücksichtigen der Geschäftsanforderungen und Compliance
Richtlinien für die Datenaufbewahrung schreiben möglicherweise die maximale TTL-Dauer vor, die Sie für sensible oder personenbezogene Daten festlegen können.
Verhalten im Cache bei Festlegung der TTL auf Null
Wenn Sie die 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-Bereinigung oder eine Write-Through-Operation stattfindet.
-
Abfrage-Cache – Abfrageantworten werden nicht zwischengespeichert.
Caching 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 die DynamoDB-Datenebenen-APIs erfordern 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 denselben Speicherplatz des von Ihnen ausgewählten Knotentyps.
-
Ressourcenzuweisung – Die Ressourcen des DAX-Clusters werden von allen zwischengespeicherten Tabellen gemeinsam genutzt. Eine Tabelle mit hohem Datenverkehrsaufkommen kann jedoch dazu führen, dass Daten aus den benachbarten kleineren Tabellen bereinigt werden.
-
Skaleneffekte – Gruppieren Sie kleinere Ressourcen zu einem größeren DAX-Cluster, um den durchschnittlichen Datenverkehr auf ein stabileres Muster zu reduzieren. Für die Gesamtzahl der Leseressourcen, die der DAX-Cluster benötigt, ist es außerdem wirtschaftlich, drei oder mehr Knoten zu haben. Dadurch wird auch die Verfügbarkeit aller zwischengespeicherten Tabellen im Cluster erhöht.
Datenreplikation in DAX und globalen DynamoDB-Tabellen
DAX ist ein regionsbasierter Service, sodass ein Cluster nur den Datenverkehr innerhalb seiner AWS-Region kennt. 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 von DAX in Regionen
Nicht alle Regionen, die DynamoDB-Tabellen unterstützen, bieten Unterstützung für 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.
DAX-Caching-Verhalten
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.
-
Metadaten-Caching – DAX-Cluster behalten auf unbestimmte Zeit Metadaten zu den Attributnamen zwischengespeicherter Elemente bei. Diese Metadaten bleiben auch dann bestehen, wenn das Element abläuft oder aus dem Cache bereinigt wird.
Anwendungen, die eine unbegrenzte Anzahl von Attributnamen verwenden, können im Laufe der Zeit zu einer Erschöpfung des Speichers im DAX-Cluster führen. Diese Einschränkung gilt nur für Attributnamen auf oberster Ebene, aber nicht für verschachtelte Attributnamen. Beispiele für unbegrenzte Attributnamen sind Zeitstempel, UUIDs und Sitzungs-IDs. Sie können Zeitstempel und Sitzungs-IDs zwar als Attributwerte verwenden, wir empfehlen jedoch, kürzere und besser vorhersehbare Attributnamen zu nutzen.
-
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 künftige Anforderungen 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.
