Schreibverhalten im Cache - AWS Präskriptive Leitlinien

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.

Schreibverhalten im Cache

In diesem Handbuch wird ein Lesecache beschrieben, in dem Elemente beim ersten Lesen zwischengespeichert werden. Ein Write-Through-Cache würde während des Schreibvorgangs Einträge in den Cache verschieben. In diesem Handbuch wird jedoch aus zwei Gründen davon abgeraten, dies zu tun:

  • Wenn ein Element geschrieben wird, gibt es keinen Hinweis darauf, dass es in absehbarer Zeit gelesen wird, und es ist verschwenderisch, Cache-Einträge zu schreiben, die nicht verwendet werden.

  • Ein zwischengespeichertes Element kann mehrfach unter verschiedenen Signaturschlüsseln zwischengespeichert werden. Beispielsweise führen unterschiedliche Projektionsausdrücke zu unterschiedlichen Cache-Einträgen. Daher ist nicht klar, unter welchem Signaturschlüssel Sie den Eintrag speichern sollten, bevor eine Anfrage eingeht. Sie könnten es für eleganter halten, das Element nur einmal in seiner Gesamtheit zwischenzuspeichern und, wenn die Anforderung einen ProjectionExpression Parameter angibt, die Projektion live innerhalb des Caching-Wrappers anzuwenden. Leider erhöht dies die Komplexität erheblich, da die Implementierung der nicht trivialen Grammatik erforderlich ist. ProjectionExpression Es ist einfacher, den Caching-Wrapper sehr einfach zu halten, sodass er nur Anfragen zwischenspeichert, die zuvor aufgetreten sind, und versucht, so weit wie möglich zu vermeiden, eine neue Antwort zu erfinden. Lass die Datenbank der einzige Ort sein, an dem a ProjectionExpression jemals interpretiert wird. Dadurch entfällt ein einfaches Cache-Modell mit Schreibzugriff.

Schreibvorgänge können jedoch intelligent sein und alle zuvor gespeicherten Elementcacheeinträge, die für das geschriebene Element relevant sind, proaktiv ungültig machen. Dadurch bleibt der Element-Cache auf dem neuesten Stand, ohne dass auf den Ablauf der TTL gewartet werden muss. Der Cache-Eintrag wird beim nächsten Lesevorgang wieder aufgefüllt.

Anmerkung

Ein entscheidender Vorteil dieser DynamoDB-Integration im Vergleich zu einer ähnlich gestalteten relationalen Datenbank-Cache-Integration besteht darin, dass bei jedem Schreibvorgang in DynamoDB immer die Primärschlüssel der Elemente angegeben werden, die geschrieben werden. Ein Lese-Through-Cache kann die Schreibaufrufe überwachen und eine exakte, sofortige Invalidierung des Element-Caches durchführen. Wenn Sie eine relationale Datenbank verwenden, identifiziert eine UPDATE Anweisung nicht die Elemente, die betroffen sein könnten, und es gibt keine passive Methode, zwischengespeicherte Zeileneinträge außer durch TTL ungültig zu machen.

Schreibaufrufe implementieren diesen Logikfluss:

  • Führen Sie den Schreibvorgang für die Datenbank aus.

  • Wenn der Vorgang erfolgreich ist, extrahieren Sie die Tabelle und die Primärschlüssel für den Schreibvorgang.

  • Machen Sie alle Element-Cache-Einträge ungültig, die für die Primärschlüssel relevant sind.

Um diesen letzten Schritt zu ermöglichen, ist ein gewisses Maß an Reinigungsaufwand erforderlich. Einträge im Element-Cache werden unter dem Hashwert ihrer Signatur gespeichert. Daher ist es wichtig zu wissen, welche Schlüssel für ungültig erklärt werden sollen. Sie können dies tun, indem Sie im Cache eine Zuordnung zwischen den Primärschlüsseln von Elementen und der Liste der gespeicherten Signaturen, die diesem Primärschlüssel zugeordnet sind, verwalten. Es ist diese Liste von Elementen, die für ungültig erklärt werden müssen.

Hier ist die Tabelle von vorhin:

Pseudocode

ElastiCache Schlüsselberechnung

ElastiCache Wert

get_item(t1, k1, p1)

hash('get', t1, k1, p1) = 0xad4c812a

{ 'Item': … }

get_item(t1, k1, p2)

hash('get', t1, k2, p2) = 0x045deaab

{ 'Item': … }

get_item(t1, k2, p1)

hash('get', t1, k2, p1) = 0x9cda78af

{ 'Item': … }

Und die frühere Haushaltstabelle:

Operation

ElastiCache Schlüsselberechnung

ElastiCache Wert

Titelliste der Einträge für Tabellet1, Schlüssel k1

hash('list', t1, k1)

( 0xad4c812a, 0x045deaab )

Titelliste der Einträge für Tabellet1, Schlüssel k2

hash('list', t1, k2)

( 0x9cda78af )

Nehmen wir an, es gibt einen Schreibvorgang für die Tabelle t1 und das Element hat den Primärschlüsselk1. Der nächste Schritt besteht darin, die Einträge, die für dieses Element relevant sind, für ungültig zu erklären.

Hier ist die vollständige Logik:

  • Führen Sie den Schreibvorgang für die Datenbank aus.

  • Wenn der Vorgang erfolgreich ist, extrahieren Sie die Tabelle und den Primärschlüssel für den Schreibvorgang.

  • Rufen Sie die Liste der gespeicherten Hash-Signaturen, die diesem Primärschlüssel zugeordnet sind, aus dem Cache ab.

  • Machen Sie diese Element-Cache-Einträge ungültig.

  • Löschen Sie die Housekeeping-Liste für diesen Primärschlüssel.

Es wäre fantastisch, eine Möglichkeit zu haben, Abfrage-Cache-Einträge im Rahmen von Elementschreibvorgängen proaktiv für ungültig zu erklären. Es ist jedoch äußerst schwierig, dafür ein Design zu entwickeln, da es fast unmöglich ist, effizient und zuverlässig zu bestimmen, welche zwischengespeicherten Abfrageergebnisse von einem aktualisierten Element betroffen wären. Aus diesem Grund gibt es für Abfrage-Cache-Einträge keine bessere Option, als das Ablaufen über die TTL-Einstellungen zu aktivieren.