Comportamento di lettura della cache

Lo shim dovrebbe memorizzare nella cache solo eventuali chiamate di lettura coerenti effettuate a DynamoDB. Sono inclusi get_item, batch_get_item, query e scan. Non dovrebbe memorizzare nella cache le chiamate di lettura fortemente coerenti o le chiamate di lettura transazionali, perché intrinsecamente tali chiamate non vogliono vedere una versione dei dati memorizzata nella cache.

Le voci della cache devono comprendere la firma della richiesta per identificare le richieste successive ed equivalenti. La firma di ogni chiamata è costituita da tutti i parametri della richiesta che influiscono sul risultato. Per una get_item chiamata, la firma include i ExpressionAttributeNames parametri TableName KeyProjectionExpression,, e. Per una chiamata di interrogazione, include i TableName Limit parametri IndexNameKeyConditions,FilterExpression,ScanIndexForward,, e. Se due chiamate alla stessa funzione hanno la stessa firma, si tratta di un possibile errore nella cache.

Ecco un esempio di flusso logico per una get_item chiamata:

Ad esempio, supponiamo di avere questo codice:

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

All'internocache_client, il codice calcola la firma hash della chiamata. La firma deriva dall'hashing della concatenazione dei parametri,, e. TableName Key ProjectionExpression ExpressionAttributeNames È possibile utilizzare qualsiasi sistema di hash purché sia deterministico e produca un singolo valore di stringa. In questo caso, supponiamo che si riduca a. 0xad4c812a Questo hash identifica questo set di parametri.

Cosa succede se viene effettuata un'altra chiamata uguale, tranne che #attr1 viene rinominata? #attribute1 Si deve ritenere che quella chiamata abbia la stessa firma? Idealmente sì, perché è semanticamente identica, ma il sovraccarico di calcolare l'equivalenza semantica su ogni chiamata semplicemente non è pratico. È molto più veloce eseguire l'hash dei valori dei parametri alla cieca e richiedere corrispondenze esatte. La regola è: le chiamate sono idonee a ricevere un accesso alla cache se si tratta effettivamente della stessa chiamata, ma non se si tratta fondamentalmente della stessa chiamata.

All'internocache_client, il codice ElastiCache cerca quindi una voce nella cache degli elementi in cui è memorizzata0xad4c812a. Se la voce esiste, si tratta di un errore nella cache. In caso contrario, il valore viene recuperato dal database e memorizzato ElastiCache per un successivo accesso alla cache.

Ecco come appare la cache per tre get_item chiamate che hanno tre diversi set di parametri di tabella, chiave e proiezione.

Le altre chiamate, ad esempio query andscan, funzionano allo stesso modo, ma le relative firme sono costituite da parametri diversi.

Questo design potrebbe ricordarti come funziona un proxy di caching HTTP. Se vede nuovamente la stessa richiesta, può restituire la risposta della richiesta precedente. La definizione della stessa richiesta in HTTP si basa principalmente sulla stringa di query. Con DynamoDB, il tipo di chiamata e l'insieme di parametri passati alla funzione ne influenzano i risultati.

C'è ancora un passaggio. È importante che la memorizzazione nella cache degli elementi mantenga una mappatura tra la chiave primaria di ciascun elemento e l'elenco degli hash utilizzati attivamente per memorizzare tale elemento. Questo entrerà in gioco durante le operazioni di scrittura, come descritto nella sezione successiva. Quindi, oltre alle chiavi e ai valori precedenti, ci saranno voci di cache aggiuntive come queste: