Comportamento di scrittura nella cache

Questa guida descrive una cache di lettura in cui gli elementi vengono memorizzati nella cache alla prima lettura. Una cache di scrittura inserirebbe le voci nella cache durante l'operazione di scrittura, ma questa guida non suggerisce di farlo per due motivi:

• Quando un elemento viene scritto, non c'è alcuna indicazione che verrà letto a breve, ed è uno spreco scrivere voci della cache che non vengono utilizzate.

• Un elemento memorizzato nella cache potrebbe essere memorizzato più volte nella cache con chiavi di firma diverse. Ad esempio, espressioni di proiezione diverse generano voci di cache diverse. Pertanto, non è chiaro in quale chiave di firma memorizzare la voce prima che arrivi una richiesta. Potresti considerare più elegante memorizzare nella cache l'elemento solo una volta nella sua interezza e, se la richiesta specifica un ProjectionExpression parametro, applicare la proiezione in tempo reale all'interno del wrapper di memorizzazione nella cache. Sfortunatamente, ciò aggiunge una complessità significativa perché richiede l'implementazione di una grammatica non banale. ProjectionExpression È più facile mantenere il wrapper di memorizzazione nella cache molto semplice, in modo che memorizzi nella cache solo le richieste avvenute in precedenza e cerchi di evitare il più possibile di inventare una nuova risposta. Lascia che il database sia l'unico posto in cui un venga mai interpretato. ProjectionExpression Ciò elimina un semplice modello di cache di scrittura tramite scrittura.

Tuttavia, le operazioni di scrittura possono essere intelligenti e possono invalidare in modo proattivo tutte le voci della cache degli elementi memorizzate in precedenza che sono rilevanti per l'elemento scritto. Ciò mantiene aggiornata la cache degli elementi senza dover attendere la scadenza del TTL. La voce della cache viene ripopolata alla lettura successiva.

Nota

Un vantaggio chiave di questa integrazione con DynamoDB, rispetto a un'integrazione della cache del database relazionale progettata in modo simile, è che ogni scrittura su DynamoDB specifica sempre le chiavi primarie degli elementi che vengono scritti. Una cache di lettura può controllare le chiamate di scrittura ed eseguire l'invalidazione esatta e immediata della cache degli elementi. Quando si utilizza un database relazionale, un'UPDATEistruzione non identifica gli elementi che potrebbero essere interessati e non esiste un modo passivo per invalidare le voci di riga memorizzate nella cache se non tramite TTL.

Le chiamate di scrittura implementano questo flusso logico:

• Esegue l'operazione di scrittura sul database.

• Se l'operazione ha esito positivo, estrai la tabella e le chiavi primarie per la scrittura.

• Invalidate tutte le voci della cache degli elementi che sono rilevanti per le chiavi primarie.

È necessario un po' di pulizia per rendere possibile quest'ultimo passaggio. Le voci della cache degli elementi sono memorizzate in un hash della loro firma, quindi è necessario sapere quali chiavi invalidare. È possibile farlo mantenendo all'interno della cache una mappatura tra le chiavi primarie degli elementi e l'elenco delle firme memorizzate associate a quella chiave primaria. È quell'elenco di elementi che devono essere invalidati.

Ecco la tabella precedente:

Pseudocodice	ElastiCache calcolo chiave	ElastiCache valore
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': … }

E la precedente tabella delle pulizie:

Operazione	ElastiCache calcolo chiave	ElastiCache valore
Tieni traccia dell'elenco delle voci per tabellat1, chiave k1	hash('list', t1, k1)	( 0xad4c812a, 0x045deaab )
Traccia l'elenco delle voci per tabellat1, chiave k2	hash('list', t1, k2)	( 0x9cda78af )

Supponiamo che ci sia un'operazione di scrittura sulla tabella t1 e che l'elemento abbia la chiave primariak1. Il passaggio successivo consiste nell'invalidare le voci pertinenti a quell'elemento.

Ecco la logica completa:

• Esegui l'operazione di scrittura sul database.

• Se l'operazione ha esito positivo, estrai la tabella e la chiave primaria per la scrittura.

• Estrai dalla cache l'elenco delle firme hash memorizzate associate a quella chiave primaria.

• Invalida le voci della cache degli elementi.

• Elimina l'elenco delle pulizie per quella chiave primaria.

Sarebbe fantastico avere un modo per invalidare in modo proattivo le voci della cache delle query come parte delle operazioni di scrittura degli elementi. Tuttavia, inventare un design per questo scopo è estremamente difficile perché è quasi impossibile determinare, in modo efficiente e affidabile, quali risultati delle query memorizzate nella cache sarebbero influenzati da un elemento aggiornato. Per questo motivo, le voci della cache delle query non hanno altra scelta che scadere tramite le impostazioni TTL.