Tabelle attive globali in NDCS
Oracle NoSQL Database Cloud Service supporta un'architettura di tabelle attive globali in cui è possibile creare tabelle, replicarle in più aree e gestire i dati sincronizzati tra le repliche regionali.
Le aziende di oggi devono fornire servizi più rapidi e migliori ai propri clienti. La latenza di rete è un parametro cruciale per valutare le prestazioni di qualsiasi applicazione. La latenza di rete è il tempo minimo necessario a un pacchetto di dati per viaggiare attraverso la rete. Gli utenti si aspettano di completare le loro attività online senza problemi e rapidamente da qualsiasi luogo. Per soddisfare tali aspettative, le aziende devono ospitare applicazioni e dati nelle aree distribuite più vicine ai propri utenti.
Oracle NoSQL Database Cloud Service fornisce una soluzione a questi requisiti tramite le tabelle Global Active. Questa funzione consente di replicare in modo trasparente i dati delle applicazioni scritti in un'area geografica tra più aree.
- Lettura e scrittura in locale e accesso ai dati a livello globale: una configurazione attiva-attiva delle tabelle Global Active in più aree garantisce che un aggiornamento eseguito su una tabella in un'area venga replicato automaticamente nelle repliche della tabella in altre aree di replica. È possibile accedere ai dati da qualsiasi area replicata.
- Prestazioni: le tabelle Global Active consentono di leggere e scrivere i dati localmente, fornendo una latenza in millisecondi a singola cifra, caratteristica dell'accesso locale per l'applicazione distribuita a livello globale su qualsiasi scala. Ciò può migliorare le prestazioni delle applicazioni globali su larga scala e ridurre la latenza per le richieste di applicazioni.
- Facile da impostare e gestire: Oracle NoSQL Database Cloud Service elimina la complessità della distribuzione e della gestione della replica multiregionale utilizzando le tabelle Global Active. L'aggiunta di repliche di tabelle regionali è semplice e può essere eseguita utilizzando le API, Terraform o la console OCI.
- Resilienza a più aree: le tabelle Global Active consentono anche la tolleranza agli errori nel raro caso di un errore dell'area. Se una singola area diventa non disponibile o non in linea, le richieste dell'applicazione possono essere reindirizzate a un'area in cui la tabella viene replicata e le operazioni di lettura e scrittura possono essere eseguite su questa tabella.
Come scegliere un'impostazione attiva globale in NDCS?
La funzione Tabelle attive globali consente di replicare in modo trasparente i dati dell'applicazione scritti in un'area in più aree.
Un evento raro di un singolo errore di area non dovrebbe influire sull'esperienza degli utenti. Ad esempio, se una singola area diventa offline, isolata o degradata, l'applicazione dovrebbe essere reindirizzata a un'area diversa e continuare a eseguire letture e scritture come prima. In breve, il tuo database deve fornire un disaster recovery anche quando un'area non riesce. Puoi utilizzare una tabella Global Active in Oracle NoSQL Database Cloud Service (NDCS) per fornire funzionalità di disaster recovery tramite una configurazione attivo-attiva o per replicare attivamente i dati in più aree in modo da ottenere una bassa latenza utilizzando l'accesso ai dati locale.
Considera le esigenze di un utente viaggiante che acquista da un sito web popolare. Possono accedere allo stesso sito di shopping da diverse parti del mondo lo stesso giorno. È necessario garantire all'utente una latenza minima e un'interazione senza interruzioni, indipendentemente da dove si trovino.
La funzione della tabella Global Active in NDCS fornisce una soluzione per entrambi gli scenari descritti in precedenza. Esaminiamo ciascuno dei due scenari e capiamo come una tabella Global Active sarà la soluzione migliore per fornire alta disponibilità, bassa latenza e disaster recovery.
Nel primo scenario, si supponga che la propria azienda utilizzi NDCS a Phoenix (US-West), Francoforte (Germania) e Tokyo (Giappone) e che si disponga di una tabella denominata ShoppingCart in cui sono memorizzate le informazioni sugli acquisti dei clienti che effettuano acquisti in diverse regioni del mondo. In questo esempio, l'azienda fornisce assistenza ai propri clienti tramite data center geograficamente più vicini. Tale impostazione riguarda più posizioni geografiche in cui è disponibile Oracle NoSQL Database Cloud Service. Un'architettura con due o più aree geografiche distribuite e il servizio NoSQL Database Cloud disponibile in ciascuna di queste aree è nota come architettura di tabella attiva globale. La tabella ShoppingCart è una tabella attiva globale e viene replicata in più aree.
In una configurazione attiva-attiva, è disponibile NDCS in più aree e i dati in tutte le aree vengono sincronizzati. Quando un'area non riesce, le tabelle attive globali nelle altre aree di replica continueranno a funzionare come al solito e non saranno interessate dall'area non riuscita. Quando l'area non riuscita torna, la replica della tabella regionale verrà sincronizzata con le altre aree. La tabella Global Active fornisce funzionalità di disaster recovery in quanto quando un'area è inattiva, l'applicazione è connessa a un'altra replica.
Nel secondo scenario, assumere l'utente a Phoenix, negozi online, e aggiunge un telefono cellulare al loro carrello. L'area NDCS della costa occidentale gestisce questa sessione e l'utente sperimenta una latenza minima delle richieste di lettura e scrittura dal data store locale dell'area. Questo utente arriva poi su un aereo per la Germania, atterra 13 ore dopo, arriva in hotel, si collega alla rete Wi-Fi, va al negozio online della società mobile e scopre che c'è un altro modello del telefono che sembra più attraente. Così l'utente decide di aggiornare il carrello con questo nuovo modello del telefono e continua a navigare nel negozio di e-commerce mobile. Il data store regionale di Francoforte, che è il data store più vicino, gestisce questa sessione e offre all'utente la stessa esperienza di lettura e scrittura a bassa latenza di quella degli Stati Uniti. L'utente si reca quindi in Giappone e decide di visitare un negozio mobile locale per ottenere maggiori informazioni sugli ultimi modelli mobili. L'utente aggiorna quindi il carrello con l'ultimo modello del telefono presente nel negozio mobile. Poiché NoSQL Database Cloud Service è disponibile in tre aree: una a Phoenix, una seconda in Germania e una terza in Giappone e ogni volta che l'utente aggiorna il carrello o sfoglia l'e-commerce store mobile, i risultati di ricerca personalizzati e altri dati vengono recuperati da un'area locale più vicina all'utente. Questo tipo di elaborazione locale offre le latenze più basse, le migliori prestazioni ed elimina l'accesso alla rete geografica.
Concetti di base
Terminologia utilizzata nelle tabelle attive globali:
- Regione: una regione di Oracle Cloud Infrastructure (OCI). Si tratta di un'unica area geografica localizzata in cui i clienti possono distribuire le proprie applicazioni.
- Area mittente: area da cui viene replicato un aggiornamento di tabella in altre aree.
- Area ricevente: area che riceve l'aggiornamento della tabella da un'altra area.
- Tabella Singleleton: tabella non replicata a livello regionale.
- Replica tabella regionale: replica di una tabella creata in un'altra area.
- Tabella Global Active: tabella contenente una o più repliche di tabelle regionali.
Regole di base per la creazione e la gestione delle tabelle attive globali:
- La tabella singleton deve avere almeno una colonna JSON.
- Lo stato dello schema della tabella deve essere FROZEN.
- Nell'area ricevente non deve esistere già una tabella con lo stesso nome.
- Nell'area del destinatario, il compartimento (con lo stesso nome di quello nell'area del mittente) deve esistere già.
- Prima di eliminare una tabella, è necessario rimuovere tutte le repliche della tabella regionale.
Nota
In NDCS la replica delle tabelle regionali viene eseguita in modalità asincrona in background.È possibile creare tabelle figlio in una tabella attiva globale. Una tabella figlio di una tabella attiva globale può essere una tabella singola o una tabella attiva globale. Per rendere la tabella figlio una tabella attiva globale, è necessario congelare lo schema della tabella figlio e aggiungere una replica regionale. È possibile selezionare una delle repliche regionali della tabella padre.
Workflow tabella attiva globale
Cosa viene replicato in una tabella Global Active?
- Definizione/schema tabella
- Indici nella tabella - Numero e definizioni degli indici secondari.
- Dati nella tabella.
- Capacità di lettura e scrittura: per impostazione predefinita, il limite di lettura di una replica regionale è lo stesso di qualsiasi altra replica regionale della tabella attiva globale. Tuttavia, le operazioni di lettura sono puramente locali, pertanto è possibile impostare facoltativamente i limiti di lettura di ogni area. Per impostazione predefinita, il limite di scrittura di una replica regionale è lo stesso di qualsiasi altra replica regionale della tabella Global Active. Tuttavia, i limiti di scrittura possono essere impostati su valori diversi in ogni area.
- Capacità di storage: poiché tutte le repliche regionali della tabella Global Active memorizzano gli stessi dati della tabella, il limite di memorizzazione di una replica regionale viene copiato in tutte le altre repliche regionali della tabella Global Active.
- Time To Live (TTL) predefinito tabella
Aggiunta di una replica della tabella regionale
Nota
Quando si aggiunge una replica della tabella regionale, la tabella nell'area del destinatario viene posizionata nello stesso compartimento con lo stesso nome della tabella nell'area del mittente. Durante il ciclo di vita della tabella Global Active è possibile spostarla in un altro compartimento in qualsiasi momento.Capacità (unità di lettura, unità di scrittura e storage) per le repliche delle tabelle regionali
Quando si aggiunge una replica regionale di una tabella, i campi capacità di lettura, capacità di scrittura e capacità di memorizzazione utilizzano automaticamente i valori corrispondenti della tabella nell'area del mittente. È tuttavia possibile modificare e modificare i valori della capacità di lettura e scrittura della tabella nell'area ricevente. Impossibile modificare la capacità di storage della tabella. La tabella nell'area del destinatario ha la stessa capacità di storage della tabella nell'area del mittente. La modalità capacità di una tabella Global Active può essere su richiesta o con provisioning eseguito. È inoltre possibile modificare la modalità di capacità di qualsiasi replica regionale per una tabella Global Active dopo che è stata creata. La modifica della modalità di capacità è locale di tale replica regionale e non ha effetto su altre repliche regionali della tabella Global Active.
TTL dei record nelle repliche delle tabelle regionali
Il valore di Table Time To Live (TTL) viene espresso come la quantità di tempo (numero di ore o giorni) che i dati possono essere memorizzati nella tabella. Oracle NoSQL Database Cloud Service consente agli sviluppatori di impostare un tempo di scadenza nelle righe delle tabelle, trascorso il quale le righe scadono automaticamente e non sono più disponibili. Dopo la durata specificata, le righe scadono automaticamente e non sono più disponibili. Il TTL nella replica della tabella regionale è lo stesso valore del TTL della tabella nell'area del mittente. Quando una riga viene replicata in altre aree, la relativa ora di scadenza viene replicata come indicatore orario assoluto. Pertanto, questa riga scadrà contemporaneamente, indipendentemente da quando è stata replicata.
Una volta creata, la replica della tabella regionale viene inizializzata con i dati della tabella dell'area del mittente. Durante questa inizializzazione dei dati di tabella, se viene raggiunto il valore TTL, queste righe scadranno e un'operazione di lettura non visualizzerà questi record.
Ambito delle operazioni DDL dopo la creazione delle repliche delle tabelle regionali:
- Aggiungi indice
- Elimina indice
- Modifica della capacità di storage della tabella
- Modifica nella tabella TTL
- Modifica in unità di lettura
- Modifica in unità di scrittura
- Modifica in modalità capacità da su richiesta a provisioning eseguito o viceversa
Considerazioni sulla modellazione dei dati per le tabelle attive globali
Perché congelare lo schema di una tabella?
In una configurazione di tabella Global Active sono presenti tabelle in NDCS distribuite in più aree e tutte le aree servono contemporaneamente richieste di lettura e scrittura. L'applicazione che si connette a NDCS deve essere progettata per connettersi all'area di replica più vicina. La chiave primaria, la chiave di partizione e i dati della tabella devono essere identici nelle aree di replica poiché queste tre sono una parte intrinseca del modo in cui l'applicazione utilizza la tabella e il modo in cui le query vengono eseguite. In una tabella Global Active, poiché i record di tabella possono essere scritti contemporaneamente nella tabella in più aree, diventa necessario raggiungere un consenso sullo schema per la tabella. A tale scopo, è possibile impedire la modifica dello schema, forzando tutte le aree a un consenso immediato sullo schema di una tabella. Per semplicità, prestazioni e prevedibilità, Oracle NoSQL Cloud Service richiede il congelamento di uno schema per qualsiasi tabella che partecipa alla replica regionale. Pertanto, prima di convertire una tabella singleton in una tabella attiva globale, lo schema della tabella deve essere bloccato e non sono consentite ulteriori modifiche allo schema. Se è necessario modificare lo schema di una tabella Global Active dopo aver creato le repliche regionali, eliminare prima tutte le repliche regionali, modificare lo schema della tabella e quindi aggiungere di nuovo le repliche regionali. Il servizio cloud Oracle NoSQL ripopola tutte le repliche regionali con i dati più aggiornati dall'area del mittente.
Perché in una tabella è necessaria almeno una colonna JSON durante il blocco dello schema?
Il coordinamento di un'alterazione dello schema nelle repliche delle tabelle regionali è difficile e porta a potenziali casi di errore. Fornire una colonna JSON offre maggiore flessibilità nello schema e impedisce la necessità di una modifica dello schema.
Definizione dell'identità in una tabella attiva globale
-
L'identità di un record in una replica di tabella regionale deve essere univoca in tutte le repliche regionali della tabella. Le chiavi naturali (identificatori univoci globali che identificano ogni record in una tabella) possono essere utilizzate come identità nelle tabelle Global Active solo se possono garantire l'univocità in tutte le repliche delle tabelle regionali.
- Quando si utilizza l'identità generata dal sistema in una tabella Global Active, è necessario utilizzare UUID. Nella maggior parte dei casi, la colonna di identità non deve essere utilizzata perché non è garantito che sia univoca tra le repliche delle tabelle regionali.
Criteri e autorizzazioni utente
I criteri IAM di una tabella sono specifici dell'area del mittente.
Quando un utente aggiunge una replica di una tabella singleton o di una tabella Global Active, nell'area ricevente non viene aggiunto alcun criterio o autorizzazione utente. L'utente nell'area di origine che desidera creare e gestire le repliche deve disporre anche dei privilegi necessari nell'area ricevente. In caso contrario, si verifica un errore quando l'utente aggiunge una replica della tabella regionale.
Una volta create le repliche della tabella regionale, la replica di qualsiasi modifica dei dati da un'area mittente all'area ricevente non richiede alcuna autorizzazione utente. Ciò significa che la modifica dei dati in una tabella di replica verrà replicata in tutte le altre repliche della tabella indipendentemente dall'autorizzazione dell'utente. Di seguito sono elencate le autorizzazioni necessarie per la creazione e la gestione delle repliche delle tabelle regionali.
Aggiungi replica:
Gli utenti che desiderano gestire le repliche di una tabella devono disporre dell'autorizzazione NOSQL_TABLE_ALTER nell'area del mittente e di tutte le aree del ricevente esistenti. Gli utenti che desiderano creare una nuova replica devono disporre dell'autorizzazione NOSQL_TABLE_CREATE nell'area del ricevente (in cui deve essere creata una replica). Quando si crea una replica di tabella regionale, l'autorizzazione di lettura e scrittura esistente della tabella nell'area del mittente non viene creata nell'area del destinatario. Gli utenti che desiderano creare una nuova replica nell'area ricevente sono responsabili della creazione delle autorizzazioni di lettura e scrittura della tabella per ogni replica della tabella regionale creata.
Elimina replica:
Gli utenti che desiderano gestire le repliche di una tabella devono disporre dell'autorizzazione NOSQL_TABLE_ALTER nell'area del mittente e in tutte le aree del ricevente esistente. Gli utenti che desiderano eliminare una replica devono disporre dell'autorizzazione NOSQL_TABLE_DROP nell'area del destinatario (in cui è necessario eliminare una replica).
Crea indice:
Gli utenti che desiderano creare indici nelle repliche delle tabelle regionali devono disporre dell'autorizzazione NOSQL_INDEX_CREATE.
Elimina indice:
Gli utenti che desiderano eliminare gli indici nelle repliche delle tabelle regionali devono disporre dell'autorizzazione NOSQL_INDEX_DROP.
Aggiorna limiti tabella/TTL/:
Gli utenti che desiderano gestire le repliche di una tabella devono disporre dell'NOSQL_TABLE_ALTERautorizzazione in tutte le repliche delle tabelle regionali.
Letture, scritture e transazioni ACID
Dopo aver creato una tabella Global Active, è possibile eseguire operazioni di lettura o scrittura sulla tabella utilizzando le API di accesso ai dati esistenti o le istruzioni DML.
Per ottenere la latenza migliore, l'applicazione in genere verrà letta da una replica regionale locale. I dati nella replica regionale locale includeranno anche gli aggiornamenti dei dati replicati da altre repliche di tabelle regionali. Ogni volta che si esegue un'operazione di scrittura (INSERT, UPDATE o DELETE) in una tabella Global Active, le modifiche verranno replicate in più aree in modo asincrono. In altre parole, quando si scrive una riga nell'area del mittente, l'operazione di scrittura viene eseguita completamente nell'area del mittente senza attendere l'aggiornamento delle aree di replica. Se più aree aggiornano una riga con la stessa chiave primaria, viene applicata una regola per decidere quale aggiornamento dell'area viene considerato finale. In tutti questi casi, questa regola di risoluzione dei conflitti integrata determinerà la vincita e il commit dell'aggiornamento con l'indicatore orario più recente nel database. Questa regola si applica anche durante l'aggiornamento del valore TTL da più aree contemporaneamente.
Le transazioni ACID sono locali per un'area. Quando una transazione esegue il commit, è garantito che sia atomica, coerente, isolata e duratura solo nell'area in cui si è verificata la scrittura. La semantica del modello di coerenza di una replica di tabella regionale è la stessa di una tabella non replicata. La coerenza delle repliche delle tabelle regionali non è assoluta. La coerenza assoluta è locale di una singola area in cui si esegue l'operazione di lettura. Le letture dei dati replicati dall'area del mittente alle aree del ricevente sono sempre coerenti.
Le scritture da un'area mittente vengono replicate in tutte le aree riceventi entro un intervallo di tempo. Questo intervallo di tempo per replicare le modifiche in più aree include il tempo necessario per ricevere i dati dalla replica della tabella regionale nell'area del mittente e il tempo necessario per completare le operazioni di scrittura nell'area del destinatario. Alla fine, l'area ricevente riceve l'aggiornamento dall'area mittente e l'area ricevente non perde mai un aggiornamento della transazione avvenuto nell'area mittente. Tutte le repliche dei tavoli regionali riceveranno infine la scrittura e diventeranno durevoli.
Panoramica del ritardo della replica
Ogni volta che si esegue un'operazione di scrittura (INSERT, UPDATE o DELETE) in una tabella Global Active, le modifiche verranno replicate in più aree in modo asincrono.
In altre parole, quando si scrive una riga nell'area del mittente, l'operazione di scrittura viene eseguita completamente nell'area del mittente senza attendere l'aggiornamento delle aree di replica. La latenza di rete crea un ritardo nella replica delle modifiche alle aree riceventi. La latenza per la replica delle modifiche in più aree include il tempo necessario per ricevere le scritture dalla replica e applicarle nell'area ricevente. Se non sono state eseguite scritture di applicazione per la tabella nell'area del mittente, il servizio utilizza i meccanismi di ping per calcolare un'approssimazione del ritardo e la statistica del ritardo rimarrà disponibile nell'area del destinatario.
Per ulteriori dettagli sulla metrica Ritardo replica, vedere Dettagli sul ritardo replica.
Panoramica sulla creazione di una tabella attiva globale
Il processo di creazione di una tabella attiva globale inizia con la creazione di una tabella singleton e quindi la conversione in una tabella attiva globale
- Creare una tabella singleton e assicurarsi che una colonna sia JSON.
- Modificare lo stato dello schema della tabella da Mutabile a Congelato.
- Decidere l'area in cui si desidera aggiungere una replica regionale della tabella. Durante l'aggiunta di una replica regionale, i campi Capacità di lettura, Capacità di scrittura e Capacità di storage vengono popolati automaticamente con i valori corrispondenti dell'area del mittente. È possibile modificare la capacità di lettura e scrittura della tabella.
- Il servizio cloud crea la tabella nell'area ricevente. Se la tabella nell'area di origine contiene dati, inizia a copiare i dati dall'area del mittente nell'area del destinatario. Mentre i dati vengono copiati dall'area del mittente all'area del destinatario, la percentuale di inizializzazione aumenta da 0 a 100. È possibile visualizzare il valore della percentuale di inizializzazione sotto le informazioni della tabella nella console OCI, come mostrato di seguito. Nessuna operazione DML consentita nella nuova replica della tabella regionale fino al completamento del processo di inizializzazione.
