Tabelle attive globali in NDCS

Oracle NoSQL Database Cloud Service supporta un'architettura di tabelle attiva globale 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 impiegato da un pacchetto di dati per viaggiare attraverso la rete. Gli utenti si aspettano di completare le loro attività online in modo fluido e rapido 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 offre una soluzione a questi requisiti tramite tabelle attive globali. Questa funzione consente di replicare in modo trasparente i dati dell'applicazione scritti in un'area in più aree.

Vantaggi delle tabelle attive globali:

Come selezionare 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 guasto di una singola regione non dovrebbe influire sull'esperienza degli utenti. Ad esempio, se una singola area diventa offline, isolata o degradata, l'applicazione deve essere reindirizzata a un'area diversa e continuare a eseguire letture e scritture come prima. In breve, il database deve fornire un disaster recovery anche quando un'area non funziona. Puoi utilizzare una tabella Global Active in Oracle NoSQL Database Cloud Service (NDCS) per fornire il disaster recovery tramite la configurazione attiva-attiva o per replicare attivamente i dati in più aree per ottenere una bassa latenza utilizzando l'accesso ai dati locale.

Considera le esigenze di un utente in viaggio che fa acquisti da un sito web popolare. Possono accedere allo stesso sito di shopping da diverse parti del mondo lo stesso giorno. È necessario garantire agli utenti la latenza minima e un'interazione perfetta, indipendentemente da dove si trovino.

La funzione Tabella attiva globale in NDCS fornisce una soluzione a entrambi gli scenari descritti in precedenza. Esaminiamo ciascuno dei due scenari e comprendiamo 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 (Stati Uniti - Ovest), Francoforte (Germania) e Tokyo (Giappone) e che si disponga di una tabella denominata ShoppingCart che memorizza le informazioni sugli acquisti dei clienti che fanno acquisti in diverse regioni del mondo. In questo esempio, la tua azienda sta servendo i propri clienti tramite data center geograficamente più vicini a loro. Tale impostazione coinvolge più posizioni geografiche in cui è disponibile Oracle NoSQL Database Cloud Service. Un'architettura con due o più aree distribuite geograficamente e il servizio NoSQL Database Cloud disponibili 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 Attivo globale fornisce il 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 serve questa sessione e la latenza minima delle richieste di lettura e scrittura dell'esperienza utente 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à di telefonia mobile e scopre che c'è un altro modello di 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 a Francoforte, che è il data store più prossimale, serve questa sessione e offre all'utente la stessa esperienza di lettura e scrittura a bassa latenza di quella negli Stati Uniti. L'utente viaggia quindi in Giappone e decide di visitare un negozio mobile locale per ottenere ulteriori informazioni sugli ultimi modelli mobili. L'utente aggiorna quindi il carrello con l'ultimo modello di telefono presente nel negozio mobile. Poiché NoSQL Database Cloud Service è disponibile in tre aree, una a Phoenix, la seconda in Germania e la terza in Giappone e sono disponibili più repliche di tabelle regionali, ogni volta che l'utente aggiorna il carrello o naviga nel negozio di e-commerce 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 prestazioni migliori ed elimina l'accesso alla rete geografica.

Concetti di base

Terminologia utilizzata nelle tabelle attive globali:

Regole di base per la creazione e la gestione delle tabelle attive globali:

Per creare e gestire una tabella attiva globale, è necessario soddisfare i criteri riportati di seguito.

Nota: in NDCS la replica della tabella regionale viene eseguita in modo asincrono in background.

È possibile creare tabelle figlio in una tabella attiva globale. Una tabella figlio di una tabella attiva globale può essere una tabella singleton 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 scegliere una delle repliche regionali della tabella padre.

Flusso di lavoro tabella attiva globale

Cosa viene replicato in una tabella Global Active?

Quando si aggiunge una replica di tabella regionale di una tabella NoSQL esistente, la tabella singleton viene convertita in una tabella attiva globale. I seguenti elementi verranno replicati in una tabella.

Nota: le tag OCI consentono di aggiungere metadati alle risorse. Una o più tag possono essere associate a una tabella attiva globale. Le tag OCI non vengono replicate e una tabella attiva globale può avere tag diverse in aree diverse.

Aggiunta di una replica di tabella regionale

Quando si replica una tabella, la tabella viene creata in un'altra area, denominata area ricevente. Se la tabella nell'area del mittente è un singleton, verrà convertita in una tabella attiva globale. Se la tabella nell'area del mittente è già una tabella attiva globale, verrà aggiunta un'altra replica regionale alla tabella. La replica regionale viene inizializzata con i dati della tabella dell'area del mittente. Ad esempio, se la tabella nell'area del mittente contiene 1000 righe, tutti i dati vengono copiati nella replica regionale appena creata.

Nota: quando si aggiunge una replica di tabella regionale, la tabella nell'area ricevente viene posizionata nello stesso compartimento con lo stesso nome di tabella della tabella nell'area del mittente. Durante il ciclo di vita della tabella Attivo globale, è possibile spostare la tabella 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 storage vengono impostati automaticamente sui 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 ricevente ha la stessa capacità di storage della tabella nell'area del mittente. La modalità di capacità di una tabella attiva globale può essere su richiesta o di cui è stato eseguito il provisioning. È inoltre possibile modificare la modalità di capacità di qualsiasi replica regionale per una tabella attiva globale dopo la creazione. La modifica della modalità di capacità è locale per tale replica regionale e non ha effetto su altre repliche regionali della tabella Attivo globale.

TTL dei record nelle repliche delle tabelle regionali

Tempo di permanenza tabella (TTL) è espresso come il periodo di tempo (numero di ore o giorni) durante il quale i dati possono vivere nella tabella. Oracle NoSQL Database Cloud Service consente agli sviluppatori di impostare un tempo di scadenza sulle righe della tabella, 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, l'ora di scadenza viene replicata come indicatore orario assoluto. Pertanto, questa riga scadrà contemporaneamente, indipendentemente da quando è stata replicata.

Una volta creata, la replica di una tabella regionale viene inizializzata con i dati della tabella dell'area del mittente. Durante questa inizializzazione dei dati della 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 della tabella regionale:

Le seguenti operazioni DDL hanno un ambito globale, il che significa che una modifica in una replica della tabella regionale viene propagata automaticamente a tutte le repliche della tabella regionale.

Le seguenti operazioni DDL hanno un ambito locale, il che significa una modifica solo nella replica della tabella regionale in cui è stata avviata.

Considerazioni sulla modellazione dei dati per le tabelle attive globali

Perché è necessario congelare lo schema di una tabella?

In una configurazione di tabella attiva globale, le tabelle in NDCS sono distribuite in più aree e tutte le aree gestiscono 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 partizione e i dati della tabella devono essere identici tra le aree di replica poiché queste tre sono una parte intrinseca del modo in cui l'applicazione utilizza la tabella e del modo in cui vengono eseguite le query. In una tabella Attivo globale, poiché i record di tabella possono essere scritti contemporaneamente nella tabella in più aree, diventa necessario raggiungere un consenso sullo schema per la tabella. È possibile eseguire questa operazione impedendo la modifica dello schema, costringendo 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 congelato e non sono consentite ulteriori modifiche allo schema. Se è necessario modificare lo schema di una tabella Attivo globale dopo aver creato le repliche regionali, è necessario prima eliminare tutte le repliche regionali, modificare lo schema della tabella e quindi aggiungere di nuovo le repliche regionali. Il servizio Oracle NoSQL Cloud inserirà di nuovo tutte le repliche regionali con i dati più recenti provenienti dall'area del mittente. Per questo motivo, si consiglia di avere almeno una colonna JSON nella tabella in quanto fornisce maggiore flessibilità nello schema e impedisce la necessità di un'alterazione dello schema.

Definizione dell'identità in una tabella attiva globale

Polizze 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 vengono aggiunti criteri o autorizzazioni utente. Anche l'utente nell'area di origine che desidera creare e gestire le repliche deve disporre 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 mittente e in tutte le aree ricevente esistenti. Gli utenti che desiderano creare una nuova replica devono disporre dell'autorizzazione NOSQL_TABLE_CREATE nell'area ricevente (dove è necessario creare una replica). Quando si crea una replica della tabella regionale, l'autorizzazione di lettura e scrittura esistente della tabella nell'area del mittente non viene creata nell'area del ricevente. 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 esistenti. Gli utenti che desiderano eliminare una replica devono disporre dell'autorizzazione NOSQL_TABLE_DROP nell'area ricevente (dove è 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'autorizzazione NOSQL_TABLE_ALTER in tutte le repliche della tabella regionale.

Lettura, scrittura e transazioni ACID

Dopo aver creato una tabella attiva globale, è possibile eseguire operazioni di lettura o scrittura sulla tabella utilizzando le API di accesso ai dati o le istruzioni DML esistenti.

Per la massima latenza, l'applicazione in genere legge 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) su una tabella Attivo globale, 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à il successo dell'aggiornamento con l'indicatore orario più recente e il commit nel database. Questa regola si applica anche durante l'aggiornamento del valore TTL da più aree contemporaneamente.

Le transazioni ACID sono locali in un'area. Quando una transazione si impegna, è garantita solo che è atomica, coerente, isolata e durevole, nella regione in cui si è verificata la scrittura. La semantica del modello di coerenza di una replica di tabella regionale è uguale a quella di una tabella non replicata. La coerenza delle repliche delle tabelle regionali non è assoluta. La coerenza assoluta è locale a una singola area in cui si esegue l'operazione di lettura. Le letture dei dati replicati dall'area mittente alle aree ricevente sono sempre alla fine coerenti.

Le scritture di un'area mittente vengono replicate in tutte le aree ricevente 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 ricevente. Alla fine, l'area ricevente riceve l'aggiornamento dall'area mittente e l'area ricevente non perde mai un aggiornamento delle transazioni che si è verificato nell'area mittente. Tutte le repliche della tabella regionale alla fine riceveranno la scrittura e diventeranno durevoli.

Panoramica del ritardo della replica

Ogni volta che si esegue un'operazione di scrittura (INSERT, UPDATE o DELETE) su una tabella Attivo globale, 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 ricevente. La latenza per la replica delle modifiche in più aree include il tempo necessario per ricevere scritture dalla replica e applicarle nell'area ricevente. Se non è stata eseguita alcuna scrittura dell'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 sarà ancora disponibile nell'area del ricevente.

Per ulteriori dettagli sulla metrica Ritardo replica, vedere Dettagli su 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 con la conversione in una tabella attiva globale

Di seguito sono elencati i passi per creare una tabella Attivo globale.