Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

DAXe modelli di coerenza DynamoDB

Amazon DynamoDB Accelerator DAX () è un servizio di scrittura nella cache progettato per semplificare il processo di aggiunta di una cache alle tabelle DynamoDB. Poiché DAX opera separatamente da DynamoDB, è importante comprendere i modelli di coerenza sia DAX di DynamoDB che di DynamoDB per garantire che le applicazioni si comportino come previsto.

In molti casi d'uso, il modo in cui l'applicazione utilizza DAX influisce sulla coerenza dei dati all'interno del DAX cluster e sulla coerenza dei dati tra DynamoDB DAX e DynamoDB.

Coerenza tra i DAX nodi del cluster

Per ottenere un'alta disponibilità dell'applicazione, ti consigliamo di effettuare il provisioning del cluster DAX con almeno tre nodi e di posizionare tali nodi in più zone di disponibilità all'interno di una regione.

Durante l'esecuzione, il cluster DAX replica i dati tra tutti i nodi del cluster (supponendo che sia stato effettuato il provisioning di più nodi). Consideriamo un'applicazione che esegue un'operazione UpdateItem tramite DAX. Tale operazione determina la modifica della cache degli elementi del nodo primario con il nuovo valore, il quale viene quindi replicato in tutti gli altri nodi nel cluster. Questa replica è di tipo consistente finale e richiede in genere meno di un secondo per il completamento.

In questo scenario, è possibile che due client leggano la stessa chiave dallo stesso cluster DAX ma ricevano valori diversi, a seconda del nodo a cui ciascun client accede. I nodi sono tutti consistenti dopo che l'aggiornamento è stato completamente replicato in tutti i nodi del cluster. Questo comportamento è simile alla natura di consistenza finale di DynamoDB.

Se stai creando un'applicazione che utilizza DAX, essa deve essere progettata in modo da poter tollerare dati consistenti finali.

DAXcomportamento della cache degli elementi

Ogni DAX cluster dispone di due cache distinte: una cache degli elementi e una cache delle query. Per ulteriori informazioni, consulta DAX: Come funziona.

In questa sezione vengono descritte le implicazioni di consistenza relative alla lettura e alla scrittura nella cache degli item DAX.

Consistenza delle letture

Con DynamoDB, l'operazione GetItem esegue una lettura a consistenza finale per impostazione predefinita. Si supponga di utilizzare UpdateItem con il client DynamoDB. Se tenti di leggere lo stesso item subito dopo, è possibile che i dati visualizzati siano quelli relativi a prima dell'aggiornamento. Ciò è dovuto al ritardo di propagazione all'interno di tutte le posizioni di archiviazione di DynamoDB. La consistenza si ottiene generalmente in pochi secondi. è probabile che l'item aggiornato venga visualizzato dopo un nuovo tentativo di lettura.

Quando utilizzi GetItem con il client DAX, l'operazione (in questo caso, una lettura consistente finale) procede come mostrato di seguito.

L'elemento rimane nella cache degli DAX elementi, soggetto all'impostazione Time to Live (TTL) e all'algoritmo (LRU) utilizzato meno di recente per la cache. Per ulteriori informazioni, consulta DAX: Come funziona.

Tuttavia, durante questo periodo, DAX non rilegge l'elemento da DynamoDB. Se qualcun altro aggiorna l'elemento utilizzando un client DynamoDB, DAX ignorandolo completamente, GetItem una richiesta che utilizza DAX il client produce risultati diversi dalla stessa GetItem richiesta utilizzando il client DynamoDB. In questo scenario, DAX DynamoDB mantiene valori incoerenti per la stessa chiave fino alla scadenza TTL dell'elemento. DAX

Se un'applicazione modifica i dati in una tabella DynamoDB sottostante, DAX ignorandola, l'applicazione deve anticipare e tollerare le eventuali incoerenze tra i dati.

Consistenza delle scritture

DAXè una cache write-through, che semplifica il processo di mantenere la cache degli DAX elementi coerente con le tabelle DynamoDB sottostanti.

Il DAX client supporta le stesse API operazioni di scrittura di DynamoDB PutItem (UpdateItem,, DeleteItemBatchWriteItem, e). TransactWriteItems Quando si utilizzano queste operazioni con il DAX client, gli elementi vengono modificati sia in DynamoDB che DAX in DynamoDB. DAXaggiorna gli elementi nella sua cache degli elementi, indipendentemente dal TTL valore di questi elementi.

Ad esempio, supponi di aver emesso una richiesta GetItem dal client DAX per leggere un item dalla tabella ProductCatalog. La chiave di partizione è Id; non è presente una chiave di ordinamento. Recupera l'item il cui Id è 101. Il QuantityOnHand valore di quell'elemento è42. DAXmemorizza l'elemento nella sua cache degli elementi con uno specificoTTL. Per questo esempio, supponiamo che TTL siano 10 minuti. Dopo tre minuti, un'altra applicazione utilizza il client DAX per aggiornare lo stesso item, pertanto il valore QuantityOnHand è ora 41. Ipotizzando che l'item non venga nuovamente aggiornato, tutte le letture successive dello stesso item nei 10 minuti successivi restituiscono il valore memorizzato nella cache di QuantityOnHand (41).

In che modo DAX i processi scrivono

DAX è destinato all'uso in applicazioni che richiedono letture ad alte prestazioni. Come cache di scrittura, DAX passa le scritture a DynamoDB in modo sincrono, quindi replica automaticamente e in modo asincrono gli aggiornamenti risultanti nella cache degli elementi su tutti i nodi del cluster. Non è necessario gestire la logica dell'invalidamento della cache perché verrà gestita automaticamente da DAX.

DAX supporta le operazioni di scrittura seguenti: PutItem, UpdateItem, DeleteItem, BatchWriteItem e TransactWriteItems.

Quando invii una richiesta PutItem, UpdateItem, DeleteItem o BatchWriteItem a DAX, si verifica quanto segue:

Quando invii una richiesta TransactWriteItems a DAX, si verifica quanto segue:

Se una scrittura su DynamoDB fallisce per qualsiasi motivo, inclusa la limitazione, l'elemento non viene memorizzato nella cache. DAX e il richiedente riceve un'eccezione relativa all'errore. Ciò garantisce che i dati non vengano scritti nella DAX cache a meno che non vengano prima scritti correttamente su DynamoDB.

DAXcomportamento della cache delle query

DAX memorizza nella cache i risultati delle richieste Query e Scan nella propria cache delle query. Tuttavia, questi risultati non influiscono sulla cache degli elementi. Quando l'applicazione invia una Scan richiesta Query o invia una richiestaDAX, il set di risultati viene salvato nella cache delle query, non nella cache degli elementi. Non puoi preparare la cache degli elementi eseguendo un'operazione Scan perché la cache degli elementi e la cache delle query sono entità separate.

Coerenza di query-update-query

Gli aggiornamenti della cache di elementi o della tabella DynamoDB sottostante non invalidano né modificano i risultati memorizzati nella cache di query.

A titolo illustrativo, considera il seguente scenario in cui un'applicazione utilizza la tabella DocumentRevisions, la cui chiave di partizione è DocId e la cui chiave di ordinamento è RevisionNumber.

In questo scenario, il set di risultati memorizzato nella cache per la richiesta Query emessa nella fase 3 è identico al set di risultati che è stato memorizzato nella cache nella fase 1. Il motivo è che DAX non invalida i set di risultati Query o Scan in base agli aggiornamenti dei singoli item. L'PutItemoperazione del passaggio 2 si riflette nella cache delle DAX query solo TTL alla Query scadenza del modulo.

L'applicazione deve considerare il TTL valore della cache delle query e per quanto tempo l'applicazione può tollerare risultati incoerenti tra la cache delle query e la cache degli elementi.

Letture fortemente consistenti e transazionali

Per eseguire una Scan richiestaGetItem,BatchGetItem, o fortemente coerenteQuery, impostate il ConsistentRead parametro su true. DAXpassa richieste di lettura fortemente coerenti a DynamoDB. Quando riceve una risposta da DynamoDBDAX, restituisce i risultati al client, ma non li memorizza nella cache. DAXnon può fornire letture fortemente coerenti da solo perché non è strettamente associato a DynamoDB. Per questo motivo, le eventuali letture successive di DAX devono essere letture consistenti finali. Inoltre, le eventuali letture fortemente consistenti successive devono essere trasferite a DynamoDB.

DAXgestisce TransactGetItems le richieste nello stesso modo in cui gestisce letture fortemente coerenti. DAXpassa tutte le TransactGetItems richieste a DynamoDB. Quando riceve una risposta da DynamoDBDAX, restituisce i risultati al client, ma non li memorizza nella cache.

Caching negativo

DAX supporta voci negative sia nella cache degli item sia nella cache delle query. Una voce negativa nella cache si verifica quando non è DAX possibile trovare gli elementi richiesti in una tabella DynamoDB sottostante. Anziché generare un errore, DAX memorizza nella cache un risultato vuoto e lo restituisce all'utente.

Ad esempio, supponiamo che un'applicazione invii una richiesta GetItem a un cluster DAX e che nella cache degli item DAX non esista un item corrispondente. Questo fa sì DAX che l'elemento corrispondente venga letto dalla tabella DynamoDB sottostante. Se l'elemento non esiste in DynamoDBDAX, memorizza un elemento vuoto nella sua cache degli elementi e restituisce l'elemento vuoto all'applicazione. Supponiamo ora che l'applicazione invii un'altra richiesta GetItem per lo stesso item. DAX individua l'item vuoto nella cache degli item e lo restituisce immediatamente all'applicazione Non consulta DynamoDB.

Una voce negativa della cache rimane nella cache degli DAX elementi finché l'elemento non è TTL scaduto, non LRU viene richiamato o l'elemento non viene modificato utilizzandoPutItem, o. UpdateItem DeleteItem

La cache delle query DAX gestisce i risultati di caching negativo in modo simile. Se un'applicazione esegue un Query o Scan e la cache delle DAX query non contiene un risultato memorizzato nella cache, DAX invia la richiesta a DynamoDB. Se non sono presenti item corrispondenti nel set di risultati, DAX archivia un set di risultati vuoto nella cache delle query e lo restituisce all'applicazione. ScanLe richieste Query o successive producono lo stesso set di risultati (vuoto), fino alla scadenza del set di risultati TTL per quel determinato set.

Strategie di scrittura

Il comportamento write-through di DAX è appropriato per molti modelli di applicazione. Tuttavia, il modello write-through potrebbe non essere appropriato per tutti i modelli di applicazione.

Nel caso di applicazioni sensibili alla latenza, la scrittura tramite DAX genera un hop di rete aggiuntivo. Quindi una scrittura su DAX è un po' più lenta di una scrittura diretta su DynamoDB. Se l'applicazione è sensibile alla latenza di scrittura, è possibile ridurre la latenza scrivendo direttamente in DynamoDB. Per ulteriori informazioni, consulta Write-Around.

Nel caso di applicazioni di scrittura intensiva (come quelle che eseguono il caricamento in blocco dei dati), è consigliabile non scrivere tutti i dati tramite DAX perché solo una piccola percentuale di tali dati viene letta dall'applicazione. Quando si scrivono grandi quantità di datiDAX, deve richiamare il suo LRU algoritmo per fare spazio nella cache ai nuovi elementi da leggere. Ciò riduce l'efficacia di DAX come cache di lettura.

Quando scrivi un item in DAX, lo stato della cache degli item viene modificato per ricevere il nuovo item. Ad esempio, DAX potrebbe dover eliminare i dati meno recenti dalla cache degli item per fare spazio al nuovo item. Il nuovo elemento rimane nella cache degli elementi, in base all'LRUalgoritmo della cache e alle TTL impostazioni della cache. Finché l'elemento persiste nella cache degli elementi, DAX non lo rilegge da DynamoDB.

Write-Through

La cache degli item DAX implementa un policy write-through. Per ulteriori informazioni, consulta In che modo DAX i processi scrivono.

Quando scrivi un elemento, DAX assicura che l'elemento memorizzato nella cache sia sincronizzato con l'elemento così come esiste in DynamoDB. Questo è utile per le applicazioni che devono leggere nuovamente un item subito dopo averlo scritto. Tuttavia, se altre applicazioni scrivono direttamente su una tabella DynamoDB, l'elemento nella DAX cache degli elementi non è più sincronizzato con DynamoDB.

A titolo illustrativo, considera due utenti (Alice e Bob) che utilizzano la tabella ProductCatalog. Alice accede alla tabella utilizzandoDAX, ma Bob ignora DAX e accede alla tabella direttamente in DynamoDB.

In questo scenario, Alice e Bob vedono rappresentazioni diverse dello stesso item ProductCatalog. Questa situazione persiste fino a quando DAX non rimuove l'item dalla cache degli item o finché un altro utente non aggiorna nuovamente lo stesso item tramite DAX.

Write-Around

Se l'applicazione deve scrivere grandi quantità di dati (ad esempio un caricamento di dati in blocco), potrebbe essere opportuno ignorare DAX e scrivere i dati direttamente su DynamoDB. Una strategia write-around (scrittura diretta) riduce la latenza di scrittura. Tuttavia, la cache di elementi non rimane sincronizzata con i dati in DynamoDB.

Se intendi utilizzare una strategia write-around, tieni presente che DAX popola la sua cache degli item ogni volta che le applicazioni utilizzano il client DAX per leggere i dati. In alcuni casi, ciò potrebbe rappresentare un vantaggio in quanto assicura che vengano memorizzati nella cache solo i dati letti più frequentemente (anziché i dati scritti più frequentemente).

Ad esempio, consideriamo un utente (Charlie) che desidera utilizzare una tabella diversa, la tabella GameScores, tramite DAX. La chiave di partizione per GameScores è UserId, quindi tutti i punteggi di Charlie hanno lo stesso UserId.

DAXnon aggiorna i set di risultati nella cache delle query con i dati più recenti di DynamoDB. Ogni set di risultati nella cache delle query è attuale al momento dell'esecuzione dell'operazione Query o Scan. Pertanto, i risultati della Query di Charlie non riflettono l'operazione PutItem. Questa situazione persiste fino a quando DAX non rimuove il set di risultati dalla cache delle query.