Modalità di scrittura in qualsiasi regione (non primaria)

La modalità di scrittura in qualsiasi regione è completamente attiva e non impone restrizioni su dove può avvenire un'operazione di scrittura. Qualsiasi regione può accettare una richiesta scritta in qualsiasi momento. Questa è la modalità più semplice, ma può essere utilizzata solo con alcuni tipi di applicazioni. È adatto quando tutte le operazioni di scrittura sono idempotenti. Idempotenti significa che sono ripetibili in modo sicuro in modo che le operazioni di scrittura simultanee o ripetute tra le regioni non siano in conflitto, ad esempio quando un utente aggiorna i propri dati di contatto. Funziona bene anche per un set di dati di sola aggiunta in cui tutte le operazioni di scrittura sono inserti univoci sotto una chiave primaria deterministica, che è un caso speciale di idempotente. Infine, questa modalità è adatta laddove il rischio di operazioni di scrittura in conflitto è 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, poiché qualsiasi operazione di scrittura recente può essere ripetuta un numero qualsiasi di volte su qualsiasi regione secondaria. Laddove possibile, è consigliabile usare questa modalità di scrittura nella fase di progettazione.

Ad esempio, diversi servizi di streaming video utilizzano tabelle globali per tenere traccia di segnalibri, recensioni, indicatori di stato delle visualizzazioni e così via. Queste distribuzioni possono utilizzare la modalità di scrittura su qualsiasi regione purché garantiscano che ogni operazione di scrittura sia idempotente. Questo accade se ogni aggiornamento, ad esempio l'impostazione di un nuovo codice temporale più recente, l'assegnazione di una nuova recensione o l'impostazione di un nuovo stato dell'orologio, assegna direttamente il nuovo stato dell'utente e il successivo valore corretto per un articolo non dipende dal suo valore corrente. Se, per caso, le richieste di scrittura dell'utente vengono indirizzate a regioni diverse, l'ultima operazione di scrittura persisterà e lo stato globale verrà regolato in base all'ultima assegnazione. Le operazioni di lettura in questa modalità alla fine diventeranno coerenti, con un ritardo rispetto al ReplicationLatency valore 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. Questa azienda è stata in grado di utilizzare la modalità di scrittura in qualsiasi modalità regionale con un'attenta riprogettazione. Lo schizzo di progettazione iniziale prevedeva un solo RunningBalance articolo per cliente. Le azioni dei clienti hanno aggiornato il saldo con un'ADDespressione non idempotente (poiché il nuovo valore corretto dipende dal valore corrente) e il saldo non è stato sincronizzato se ci sono state due operazioni di scrittura sullo stesso saldo all'incirca nello stesso momento in regioni diverse. La riprogettazione utilizza lo streaming degli eventi, che funziona come un registro con un flusso di lavoro di sola aggiunta. Ogni azione del cliente aggiunge un nuovo elemento alla raccolta di elementi gestita per tale cliente. (Una raccolta di articoli è l'insieme di elementi che condividono una chiave primaria ma hanno chiavi di ordinamento diverse.) Ogni operazione di scrittura è un inserto idempotente che utilizza l'ID cliente come chiave di partizione e l'ID della transazione come chiave di ordinamento. Questo design rende più difficile il calcolo della bilancia, in quanto richiede l'estrazione degli elementi seguita da alcuni calcoli sul lato client, ma rende tutte le operazioni di scrittura idempotenti e consente di ottenere significative semplificazioni in termini di routing e failover. Query Questo passaggio della procedura è descritto in modo dettagliato più avanti in questa guida.

Un terzo esempio riguarda un'azienda che fornisce servizi di inserimento di annunci online. Questa società ha deciso che un basso rischio di perdita di dati sarebbe accettabile per ottenere le semplificazioni di progettazione della modalità di scrittura in qualsiasi modalità regionale. Quando pubblicano annunci, hanno solo pochi millisecondi per recuperare metadati sufficienti per determinare quale annuncio mostrare e quindi per registrare l'impressione dell'annuncio in modo da non ripetere lo stesso annuncio a breve. Usano tabelle globali per ottenere sia operazioni di lettura a bassa latenza per gli utenti finali di tutto il mondo sia operazioni di scrittura a bassa latenza. Registrano tutte le impressioni dell'annuncio di un utente all'interno di un singolo elemento, rappresentato da un elenco crescente. Utilizzano un elemento anziché aggiungerlo a una raccolta di elementi, in modo da poter rimuovere le impressioni pubblicitarie meno recenti come parte di ogni operazione di scrittura senza pagare per un'operazione di eliminazione. Questa operazione di scrittura non è idempotente; se lo stesso utente finale vede annunci pubblicati da più regioni all'incirca contemporaneamente, è possibile che un'operazione di scrittura per un'impressione dell'annuncio ne sovrascriva un'altra. Il rischio è che un utente possa vedere un annuncio ripetuto di tanto in tanto. Hanno deciso che questo è accettabile.