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.
Konfiguration Ihres DAX Clusters
Der DAX Cluster ist ein verwalteter Cluster, aber Sie können seine Konfigurationen an Ihre Anwendungsanforderungen anpassen. Aufgrund der engen Integration mit API DynamoDB-Vorgängen sollten Sie bei der Integration Ihrer Anwendung die folgenden Aspekte berücksichtigen. DAX
In diesem Abschnitt
DAXPreisgestaltung
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 DAX Clusterressourcen aus. Cachefehler verursachen DynamoDB-Lesekosten und erfordern Ressourcen. DAX 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
DAXverwaltet 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.
| Element-Cache | Abfrage-Cache |
|---|---|
| Purpose | |
|
Speichert die Ergebnisse von GetItemund BatchGetItemAPIVorgängen. |
Speichert die Ergebnisse von Abfrage - und APIScanvorgängen. Bei diesen Vorgängen können mehrere Elemente zurückgegeben werden, die auf Abfragebedingungen und nicht auf bestimmten Elementschlüsseln basieren. |
| Access type | |
|
Verwendet schlüsselbasierten Zugriff. Wenn eine Anwendung Daten mit |
Verwendet parameterbasierten Zugriff. DAXspeichert die Ergebnismenge von |
| Cache invalidation | |
|
DAXrepliziert in den folgenden Szenarien automatisch aktualisierte Elemente in den Element-Cache 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 den Abfrage-Cache sorgfältig optimierenTTL, um die Datenkonsistenz zu gewährleisten. Schreibvorgänge durch die DAX Basistabelle werden erst im Abfrage-Cache wiedergegeben, wenn die zuvor zwischengespeicherte Antwort TTL abläuft und eine neue Abfrage für DynamoDB DAX ausgeführt wird. |
| Global secondary 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 zwischen. |
Im Abfrage-Cache werden Abfragen sowohl für Tabellen als auch für Indizes zwischengespeichert. |
TTLEinstellung für die Caches auswählen
TTLbestimmt 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 Merkmalen und Anforderungen Ihrer Anwendung ab. Wir empfehlen, mit einer konservativen TTL Einstellung zu beginnen und dabei diese präskriptiven Leitlinien zu verwenden. Passen Sie Ihre TTL Einstellung dann iterativ auf der Grundlage der Leistungsdaten und Erkenntnisse Ihrer Anwendung an.
DAXverwaltet eine Liste, die zuletzt verwendet wurde (LRU) 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 DAX Knotenspeicher voll ist, werden ältere DAX Objekte entfernt, 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 — Legen Sie für Anwendungen mit häufigen Updates, die nicht geschrieben werden, eine kürzere TTL Dauer festDAX, 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 wählen. Bei einer längeren TTL Dauer werden die Cache-Zugriffe maximiert, wodurch die durchschnittliche Leselatenz reduziert wird.
-
Durchsatz und Skalierbarkeit — Eine längere TTL Dauer reduziert die Belastung der DynamoDB-Tabellen und verbessert den Durchsatz und die Skalierbarkeit. Sie sollten dies jedoch mit dem Datenbedarf in Einklang bringen. up-to-date
Analysieren Sie die Cache-Entfernung und die Speichernutzung
-
Cache-Speicherlimits — Überwachen Sie die DAX Speichernutzung Ihres Clusters. Bei einer längeren TTL Dauer können mehr Daten im Cache gespeichert werden, wodurch die Speichergrenzen erreicht werden können und es zu LRU Speicherlöschungen kommen kann.
Verwenden Sie Metriken und Überwachung, um Anpassungen vorzunehmen TTL
Überprüfen Sie regelmäßig Metriken, z. B. Cache-Treffer und Fehlschläge sowie CPU die Speicherauslastung. Passen Sie Ihre TTL Einstellung auf der Grundlage dieser Kennzahlen 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 den Wert TTL auf Null setzen
Wenn Sie den Wert TTL auf 0 setzen, weisen der Element-Cache und der Abfrage-Cache das folgende Verhalten auf:
-
Element-Cache — Elemente im Cache werden nur aktualisiert, wenn ein LRU Entfernungs- oder Write-Through-Vorgang stattfindet.
-
Abfrage-Cache — Abfrageantworten werden nicht zwischengespeichert.
Zwischenspeichern mehrerer Tabellen mit einem Cluster DAX
Für Workloads mit mehreren kleinen DynamoDB-Tabellen, die keine einzelnen Caches benötigen, werden Anfragen für diese Tabellen von einem einzelnen DAX Cluster zwischengespeichert. Dies ermöglicht eine flexiblere und effizientere Nutzung vonDAX, 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 DAX mit mehreren Tabellen
Bei der Verwendung DAX mit mehreren DynamoDB-Tabellen sollten Sie die folgenden Punkte berücksichtigen:
-
Speicherverwaltung — Wenn Sie DAX mit mehreren Tabellen arbeiten, 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 gelöscht werden.
-
Skaleneffekte — Gruppieren Sie kleinere Ressourcen zu einem größeren DAX Cluster, um den Durchschnitt des Datenverkehrs nach einem stabileren Muster zu berechnen. Für die Gesamtzahl der Leseressourcen, die der DAX Cluster benötigt, ist es auch wirtschaftlich, drei oder mehr Knoten zu haben. Dadurch wird auch die Verfügbarkeit aller zwischengespeicherten Tabellen im Cluster erhöht.
Datenreplikation in globalen DAX Tabellen und DynamoDB-Tabellen
DAXist 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.
DAX-Verfügbarkeit in Regionen
Nicht alle Regionen, die DynamoDB-Tabellen unterstützen, unterstützen die Bereitstellung von DAX Clustern. Wenn für Ihre Anwendung eine geringe Leselatenz erforderlich istDAX, überprüfen Sie zunächst die Liste der Regionen, die diese Unterstützung bieten. DAX Wählen Sie dann eine Region für Ihre DynamoDB-Tabelle aus.
DAXVerhalten beim Zwischenspeichern
DAXfü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 — In DAX Clustern werden Metadaten zu den Attributnamen zwischengespeicherter Elemente auf unbestimmte Zeit gespeichert. 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 Cluster führen. DAX 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 das Lesen aus einer DynamoDB-Tabelle keine passenden Elemente ergibt, wird ein negativer Cache-Eintrag im entsprechenden Element- oder Abfrage-Cache DAX hinzugefügt. Dieser Eintrag bleibt bestehen, bis die TTL Cachedauer abläuft oder ein Write-Through erfolgt. DAXgibt diesen negativen Cache-Eintrag für future Anfragen weiterhin zurück.
Wenn das negative Caching-Verhalten nicht zu Ihrem Anwendungsmuster passt, lesen Sie die DynamoDB-Tabelle direkt, wenn ein leeres Ergebnis DAX zurückgegeben wird. 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.
