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'elevata disponibilità dell'applicazione, si consiglia di effettuare il provisioning DAX del cluster con almeno tre nodi. e di posizionare tali nodi in più zone di disponibilità all'interno di una regione.

Quando il DAX cluster è in esecuzione, replica i dati tra tutti i nodi del cluster (supponendo che sia stato eseguito il provisioning di più di un nodo). Si consideri un'applicazione che esegue un utilizzo corretto. UpdateItem 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 DAX cluster ma ricevano valori diversi, a seconda del nodo a cui ciascun client ha avuto accesso. 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 state creando un'applicazione che utilizzaDAX, tale applicazione deve essere progettata in modo che possa tollerare alla fine dati coerenti.

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.

Questa sezione affronta le implicazioni di coerenza della lettura e della scrittura nella cache degli elementi. 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 si utilizza GetItem con il DAX client, l'operazione (in questo caso, una lettura eventualmente coerente) procede come illustrato 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, supponiamo di inviare una GetItem richiesta dal DAX client per leggere un elemento dalla ProductCatalog tabella. La chiave di partizione è Id; non è presente una chiave di ordinamento. Recupera l'item il cui Id è 101. Il valore QuantityOnHand per quell'elemento è 42. DAXmemorizza l'elemento nella sua cache degli elementi con uno specificoTTL. Per questo esempio, supponiamo che TTL siano 10 minuti. Quindi, 3 minuti dopo, un'altra applicazione utilizza il DAX client per aggiornare lo stesso elemento in modo che il suo QuantityOnHand valore sia ora41. 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 ad 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 di invalidazione della cache perché la gestisce al posto tuo. DAX

DAXsupporta le seguenti operazioni di scrittura:PutItem,, UpdateItem DeleteItemBatchWriteItem, e. TransactWriteItems

Quando si invia unPutItem, UpdateItemDeleteItem, o una BatchWriteItem richiesta aDAX, si verifica quanto segue:

Quando si invia una TransactWriteItems richiesta aDAX, 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

DAXmemorizza nella cache i risultati Query e Scan le richieste nella 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 Query i set di Scan risultati in base agli aggiornamenti dei singoli elementi. L'PutItemoperazione del passaggio 2 si riflette nella cache delle DAX query solo alla scadenza del TTL Query 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 richiesta GetItem, BatchGetItem, Query o Scan fortemente consistente, impostare il parametro ConsistentRead 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, tutte le letture successive DAX dovrebbero essere alla fine letture coerenti. 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

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

Ad esempio, supponiamo che un'applicazione invii una GetItem richiesta a un DAX cluster e che non vi sia alcun elemento corrispondente nella cache degli DAX elementi. 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. Ora supponiamo che l'applicazione invii un'altra richiesta GetItem per lo stesso articolo. DAXtrova l'elemento vuoto nella cache degli elementi 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 utilizzando PutItemUpdateItem, o. DeleteItem

La cache delle DAX query gestisce i risultati negativi della cache 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 ci sono elementi corrispondenti nel set di risultati, DAX memorizza un set di risultati vuoto nella cache delle query e restituisce il set di risultati vuoto all'applicazione. ScanLe richieste Query o le richieste successive producono lo stesso set di risultati (vuoto), fino alla scadenza del set TTL di risultati relativo a tale set.

Strategie di scrittura

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

Per le applicazioni sensibili alla latenza, la scrittura DAX comporta 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.

Per le applicazioni che richiedono un uso intensivo di scrittura (come quelle che eseguono il caricamento di grandi quantità di dati), potresti non voler scrivere tutti i dati DAX perché solo una piccola percentuale di tali dati viene letta dall'applicazione. Quando si scrivono grandi quantità di datiDAX, è necessario richiamare il proprio LRU algoritmo per liberare spazio nella cache per la lettura dei nuovi elementi. Ciò riduce l'efficacia della cache DAX di lettura.

Quando si scrive un elemento inDAX, lo stato della cache degli elementi viene modificato per adattarsi al nuovo elemento. (Ad esempio, DAX potrebbe essere necessario rimuovere i dati più vecchi dalla cache degli elementi per fare spazio al nuovo elemento.) Il nuovo elemento rimane nella cache degli elementi, soggetto all'LRUalgoritmo della cache e alle TTL impostazioni per la cache. Finché l'elemento persiste nella cache degli elementi, DAX non lo rilegge da DynamoDB.

Write-Through

La cache degli DAX elementi implementa una politica di scrittura. 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. Questo vale fino a quando non DAX rimuove l'elemento dalla cache degli elementi o finché un altro utente non aggiorna nuovamente lo stesso elemento utilizzando. 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 decidete di utilizzare una strategia di scrittura, ricordate che la cache degli elementi DAX viene compilata ogni volta che le applicazioni utilizzano il client per leggere i dati. DAX 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 lavorare con una tabella diversa, la GameScores tabella, utilizzando. 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. Questo è il caso finché non rimuove DAX il set di risultati dalla cache delle query.