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à.

Modalità di scrittura con tabelle globali DynamoDB

Le tabelle globali utilizzano sempre un modello di replica attivo-attivo a livello di tabella. Tuttavia, è possibile considerarle basate su un modello attivo-passivo mediante il controllo della modalità di instradamento delle richieste di scrittura. Ad esempio, è possibile decidere di instradare le richieste di scrittura a un'unica regione per evitare potenziali conflitti di scrittura.

Esistono tre categorie principali dei modelli di scrittura gestiti:

È consigliabile valutare il modello di scrittura più adatto a uno specifico caso d'uso. Questa scelta influisce sulle modalità di instradamento delle richieste, evacuazione di una regione e gestione del ripristino di emergenza. Le best practice generali possono variare a seconda della modalità di scrittura dell'applicazione.

Modalità di scrittura in qualsiasi regione (non primaria)

La modalità di scrittura in qualsiasi regione si basa su un modello di replica attivo-attivo e non impone restrizioni su dove può avvenire la scrittura. Qualsiasi regione può accettare un'operazione di scrittura in qualsiasi momento. Questo è il modo più semplice. Questa modalità può essere utilizzata solo con alcuni tipi di applicazioni. È adatta quando tutte le istanze di scrittura sono idempotenti e quindi ripetibili in modo sicuro in modo che le operazioni di scrittura simultanee o ripetute tra regioni non siano in conflitto. Ad esempio, quando un utente aggiorna i propri dati di contatto. Questa modalità è adatta anche per un caso speciale di idempotenza, ovvero un set di dati di tipo "solo accodamento", in cui tutte le scritture sono inserimenti univoci sotto una chiave primaria deterministica. Infine, questa modalità è adatta anche nei casi in cui il rischio di scritture in conflitto sia accettabile.

La modalità scrittura in qualsiasi regione rappresenta l'architettura più semplice da implementare. L'instradamento è più semplice perché qualsiasi regione può essere la destinazione delle operazioni di scrittura in qualsiasi momento. Il failover è più semplice, perché qualsiasi scrittura recente può essere riprodotta un numero qualsiasi di volte in qualsiasi regione secondaria. Laddove possibile, è consigliabile usare questa modalità di scrittura nella fase di progettazione.

Ad esempio, i servizi di streaming video utilizzano spesso tabelle globali per tenere traccia di segnalibri, recensioni, flag relativi allo stato di visualizzazione e così via. Queste implementazioni possono utilizzare la modalità di scrittura in qualsiasi regione purché assicurino che ogni scrittura sia idempotente e che il successivo valore corretto per un elemento non dipenda dal suo valore corrente. Questo sarà il caso degli aggiornamenti utente che assegnano direttamente il nuovo stato dell'utente, come l'impostazione di un nuovo timecode più aggiornato, l'assegnazione di una nuova recensione o l'impostazione di un nuovo stato di visualizzazione. Se le richieste di scrittura dell'utente vengono instradate a regioni diverse, l'ultima operazione di scrittura risulterà persistente e lo stato globale verrà adeguato in base all'ultima assegnazione. Le operazioni di lettura in questa modalità saranno alla fine coerenti, dopo essere state ritardate in base al valore ReplicationLatency più recente.

In un altro esempio, una società di servizi finanziari utilizza tabelle globali come parte di un sistema per il conteggio continuo degli acquisti con carta di debito per ogni cliente, per calcolare il valore del cashback per il cliente specifico. Nuove transazioni arrivano da tutto il mondo e vengono instradate in più regioni. Per il loro design attuale, che non sfrutta le tabelle globali, utilizzano un solo elemento Running Balance per cliente. Le azioni del cliente aggiornano la bilancia con un'ADDespressione, che non è idempotente perché il nuovo valore corretto dipende dal valore corrente. Ciò significa che il saldo non è più sincronizzato in presenza di due operazioni di scrittura sullo stesso saldo all'incirca nello stesso momento in regioni diverse.

Questa stessa azienda potrebbe basarsi sulla modalità scrittura in qualsiasi regione mediante un'attenta riprogettazione con le tabelle globali DynamoDB. La nuova progettazione potrebbe basarsi su un modello di "streaming di eventi", ovvero un registro con un flusso di lavoro di tipo "solo accodamento". Ogni azione del cliente aggiunge un nuovo elemento alla raccolta di elementi gestita per tale cliente. La raccolta di elementi è l'insieme di elementi che condividono una chiave primaria, con chiavi di ordinamento diverse. Ogni azione di scrittura che aggiunge l'azione del cliente è un inserto idempotente, che utilizza l'ID cliente come chiave di partizione e l'ID della transazione come chiave di ordinamento. Questo modello rende più complesso il calcolo del saldo, perché l'istruzione Query deve estrarre gli elementi seguiti da alcuni calcoli sul lato client. Tuttavia, il vantaggio è rappresentato dal fatto che tutte le operazioni di scrittura sono idempotenti, il che fornisce significative semplificazioni a livello di instradamento e failover. Per ulteriori informazioni, consulta Routing delle richieste con tabelle globali DynamoDB.

Per un terzo esempio, si supponga che un cliente definisca il posizionamento degli annunci online. Il cliente ha deciso che è accettabile un basso rischio di perdita di dati per ottenere le semplificazioni di progettazione della modalità di scrittura in qualsiasi regione. Quando pubblica gli annunci, dispone solo di pochi millisecondi per recuperare metadati sufficienti per determinare l'annuncio da mostrare e quindi registrare l'impression di tale annuncio in modo che quest'ultimo non venga rivisualizzato allo stesso utente. Con le tabelle globali è possibile ottenere sia letture a bassa latenza per gli utenti finali di tutto il mondo che scritture a bassa latenza. È possibile registrare tutte le impression degli annunci di un utente all'interno di un singolo elemento e rappresentare il valore corrispondente come un elenco crescente. È possibile utilizzare un elemento anziché accodarlo a una raccolta di elementi, perché in questo modo le impression meno recenti possono essere rimosse come parte di ogni scrittura senza dover pagare l'eliminazione. Questa operazione di scrittura è NOT idempotente, quindi se lo stesso utente finale vede annunci pubblicati da più regioni all'incirca nello stesso momento, c'è la possibilità che la scrittura di un'impressione dell'annuncio possa sovrascrivere l'altra. Per quanto riguarda il posizionamento degli annunci online, vale la pena utilizzare questo modello più semplice ed efficiente in quanto si evita il rischio che un utente veda occasionalmente un annuncio più volte.

Unica primaria (modalità di "scrittura in una regione")

La modalità di scrittura in una regione si basa su un modello di replica attivo-passivo e instrada tutte le scritture a livello di tabelle in un'unica regione attiva. Si noti che DynamoDB non ha "percezione" del concetto di regione attiva; l'instradamento delle applicazioni esternamente a DynamoDB gestisce questo scenario. La modalità di scrittura in una regione evita i conflitti di scrittura assicurando che le scritture vengano instradate verso solo una regione alla volta. Questa modalità di scrittura è utile quando si desidera utilizzare espressioni o transazioni condizionali, perché queste ultime funzioneranno solo in caso di interazione con i dati più recenti. Pertanto, l'utilizzo di espressioni e transazioni condizionali richiede l'invio di tutte le richieste di scrittura alla regione che dispone dei dati più recenti.

Le letture a consistenza finale possono essere eseguite in qualsiasi regione di replica per ottenere latenze più basse. Le letture a elevata consistenza devono essere instradate all'unica regione primaria.

A volte è necessario modificare la regione attiva in risposta a un errore regionale, per semplificare la gestione dei dati. Evacuazione di una regione con le tabelle globali DynamoDBè un esempio di questo caso d'uso. Alcuni clienti cambieranno la regione attualmente attiva in base a una pianificazione regolare, ad esempio mediante un'implementazione basata sull'approccio "follow the sun" (operatività 24 ore su 24). In questo modo, la regione attiva si trova vicino all'area geografica con la maggiore attività e con la latenza di lettura e scrittura più bassa. Ha anche il vantaggio di chiamare quotidianamente il codice di modifica della regione, assicurandosi che sia ben testato prima di qualsiasi ripristino di emergenza.

Le regioni passive possono mantenere un set sottodimensionato dell'infrastruttura DynamoDB, che potrà essere potenziata solo quando la regione diventa attiva. Per una discussione più approfondita sui design delle lampade pilota e dello standby caldo, consulta Disaster Recovery (DR) Architecture on AWS, PartIII: Pilot Light and Warm Standby.

L'utilizzo della modalità di scrittura in una regione funziona bene quando si utilizzano tabelle globali per letture distribuite a livello globale a bassa latenza. Ad esempio, una grande società di servizi basati su social media ha milioni di utenti e miliardi di post. Al momento della creazione dell'account, ogni utente viene assegnato a una regione posizionata geograficamente vicino alla sua posizione. Nella tabella non globale vengono inseriti tutti i dati. L'azienda utilizza una tabella globale distinta per memorizzare la mappatura degli utenti nelle rispettive regioni di origine, utilizzando una modalità di scrittura in una regione. Conserva copie di sola lettura in tutto il mondo per aiutare a localizzare direttamente i dati di ogni utente con una latenza aggiuntiva minima. Gli aggiornamenti sono rari (solo quando si cambia la regione di origine di un utente) e attraversano una regione durante la scrittura per evitare qualsiasi possibilità di conflitti di scrittura.

Come altro esempio, si consideri un cliente di servizi finanziari che ha implementato un calcolo del cashback giornaliero. Usa la modalità di scrittura in qualsiasi regione per calcolare il saldo, ma utilizza la modalità di scrittura in una regione per tenere traccia dei pagamenti del cashback effettivo. Se desidera premiare un cliente con 1 centesimo per ogni 10 euro spesi al giorno, dovrà eseguire un'istruzione Query per tutte le transazioni del giorno precedente, calcolare il totale speso, scrivere la decisione relativa al cashback in una nuova tabella, eliminare il set di elementi sottoposto a query per contrassegnarli come consumati e sostituirli con un singolo elemento contenente l'eventuale importo residuo da inserire nei calcoli del giorno successivo. Tutto ciò richiede transazioni e quindi funzionerà meglio con la modalità di scrittura in una regione. Un'applicazione può combinare diverse modalità di scrittura, anche nella stessa tabella, a condizione che i carichi di lavoro non si sovrappongano in alcun modo.

Primaria mista (modalità di "scrittura nella propria regione")

La modalità di scrittura nella propria regione assegna diversi sottoinsiemi di dati a diverse regioni e consente operazioni di scrittura solo su elementi nella propria regione d'origine. Questa modalità si basa sul modello di replica attivo-passivo ma assegna la regione attiva in base all'elemento. Ogni regione è primaria per il proprio set di dati non sovrapposto e le scritture devono essere protette per garantire la corretta localizzazione.

Questa modalità è simile alla modalità di scrittura in una regione, tranne per il fatto che consente scritture a latenza inferiore, poiché i dati associati a ciascun utente finale possono essere collocati in prossimità della rete più vicina a quell'utente. Inoltre, distribuisce l'infrastruttura circostante in modo più uniforme tra le regioni e richiede meno lavoro per ricostruire l'infrastruttura durante uno scenario di failover, poiché tutte le regioni avranno una parte della propria infrastruttura già attiva.

La determinazione della regione di origine per gli elementi può essere effettuata in diversi modi:

Ad esempio, si supponga di lavorare per una società di giochi. Deve essere disponibile una bassa latenza per le operazioni di lettura e scrittura per tutti i giocatori di tutto il mondo. A ciascun giocatore è possibile assegnare la regione a lui più vicina. In quella regione vengono registrate tutte le operazioni di lettura e scrittura, garantendo una costante coerenza. read-after-write Tuttavia, se il giocatore viaggia o la sua regione di origine subisce un'interruzione dei servizi, una copia completa dei suoi dati sarà disponibile in altre regioni. Il giocatore può quindi essere assegnato a diverse regioni di origine, a seconda delle necessità.

Per fare un altro esempio, si supponga di lavorare in un'azienda di servizi di videoconferenza. I metadati di ogni teleconferenza vengono assegnati a una particolare regione. I partecipanti (chiamanti) possono utilizzare la regione più vicina a loro in modo da avere la latenza più bassa. In caso di interruzione dei servizi in tale regione, l'utilizzo delle tabelle globali consente un ripristino rapido poiché il sistema può spostare l'elaborazione della chiamata in un'altra regione in cui è già presente una copia replicata dei dati.