Leseverhalten im Cache

Das Shim sollte nur eventuell konsistente Leseaufrufe zwischenspeichern, die an DynamoDB gesendet werden. Dazu zählen get_item, batch_get_item, query und scan. Es sollte keine stark konsistenten Leseaufrufe oder transaktionale Leseaufrufe zwischenspeichern, da bei diesen Aufrufen grundsätzlich keine zwischengespeicherte Version der Daten angezeigt werden soll.

Die Cache-Einträge müssen die Signatur der Anfrage verstehen, um nachfolgende, äquivalente Anfragen identifizieren zu können. Die Signatur jedes Aufrufs besteht aus allen Parametern der Anfrage, die sich auf das Ergebnis auswirken. Bei einem get_item Aufruf umfasst die Signatur die ExpressionAttributeNames Parameter TableName KeyProjectionExpression,, und. Bei einem Abfrageaufruf umfasst sie die Limit Parameter TableName IndexNameKeyConditions,FilterExpression,ScanIndexForward,, und. Wenn zwei Aufrufe derselben Funktion dieselbe Signatur haben, ist das ein möglicher Cache-Treffer.

Hier ist ein Beispiel für einen Logikfluss für einen get_item Aufruf:

Gehen Sie beispielsweise davon aus, dass Sie diesen Code haben:

cache_client.get_item(
  TableName='test',
  Key={ 'PK': { 'S': '123' } },
  ProjectionExpression='#attr1, #attr2',
  ExpressionAttributeNames={
    '#attr1': 'agent',
    '#attr2': 'count'
  },
  ConsistentRead=False
)

Im Inneren cache_client berechnet der Code die Hash-Signatur des Anrufs. Die Signatur wird durch das Hashing der Verkettung der ParameterTableName,, Key und abgeleitet. ProjectionExpression ExpressionAttributeNames Jedes Hash-System kann verwendet werden, solange es deterministisch ist und einen einzelnen Zeichenkettenwert erzeugt. Gehen wir in diesem Fall davon aus, dass es bis herunter gehackt wird. 0xad4c812a Dieser Hash identifiziert diesen Parametersatz.

Was ist, wenn ein weiterer Anruf getätigt wird, der derselbe ist, außer dass er umbenannt #attr1 wird#attribute1? Sollte davon ausgegangen werden, dass dieser Anruf dieselbe Signatur hat? Im Idealfall ja, weil es semantisch identisch ist, aber der Aufwand, bei jedem einzelnen Aufruf die semantische Äquivalenz herauszufinden, ist einfach nicht praktikabel. Es ist viel schneller, Parameterwerte blind zu hashen und exakte Übereinstimmungen zu erfordern. Die Regel lautet: Aufrufe kommen für einen Cache-Treffer in Frage, wenn es sich tatsächlich um denselben Anruf handelt, aber nicht, wenn es sich im Grunde um denselben Aufruf handelt.

cache_clientIm Inneren sucht der Code dann ElastiCache nach einem Eintrag im Item-Cache, der unter gespeichert ist0xad4c812a. Wenn der Eintrag existiert, ist das ein Cache-Treffer. Wenn nicht, wird der Wert aus der Datenbank abgerufen und ElastiCache für einen späteren Cache-Treffer gespeichert.

So sieht der Cache für drei get_item Aufrufe aus, die drei verschiedene Gruppen von Tabellen-, Schlüssel- und Projektionsparametern haben.

Andere Aufrufe, wie query undscan, funktionieren genauso, aber ihre Signaturen bestehen aus unterschiedlichen Parametern.

Dieses Design erinnert Sie möglicherweise daran, wie ein HTTP-Caching-Proxy funktioniert. Wenn dieselbe Anfrage erneut angezeigt wird, kann sie die Antwort der früheren Anfrage zurückgeben. Die Definition derselben Anfrage in HTTP basiert hauptsächlich auf der Abfragezeichenfolge. Bei DynamoDB beeinflussen der Aufruftyp und der Satz von Parametern, die an die Funktion übergeben werden, ihre Ergebnisse.

Es gibt noch einen Schritt. Für das Zwischenspeichern von Elementen ist es wichtig, eine Zuordnung zwischen dem Primärschlüssel jedes Elements und der Liste der Hashes beizubehalten, die aktiv zum Zwischenspeichern dieses Elements verwendet werden. Dies wird bei Schreibvorgängen zum Tragen kommen, wie im nächsten Abschnitt beschrieben. Zusätzlich zu den vorherigen Schlüsseln und Werten wird es also zusätzliche Cache-Einträge wie diese geben: