Distribuzione globale dei dati con Azure Cosmos DB - sotto le quinte

  • Si applica a: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Azure Cosmos DB è un servizio di base in Azure, quindi viene distribuito in tutte le aree Azure in tutto il mondo, tra cui il pubblico, sovrano, il Dipartimento della Difesa (DoD) e i cloud governativi.

A livello generale, i dati del contenitore di Azure Cosmos DB vengono partizionati orizzontalmente in molti set di repliche, che replicano le scritture, in ciascuna regione. I set di repliche eseguono operazioni di commit in modo permanente usando un quorum di maggioranza.

Ogni area contiene tutte le partizioni di dati di un contenitore Azure Cosmos DB e può gestire le letture e gestire le scritture quando è abilitata la scrittura in più aree. Se l'account Azure Cosmos DB viene distribuito tra le aree N Azure, saranno presenti almeno N x 4 copie di tutti i dati.

All'interno di un data center, vengono distribuiti e gestiti gli Azure Cosmos DB su enormi blocchi di macchine, ognuno con spazio di archiviazione locale dedicato. All'interno di un data center, Azure Cosmos DB viene distribuito in molti cluster, ognuno potenzialmente in esecuzione su più generazioni di hardware. I computer all'interno di un cluster vengono in genere distribuiti in 10-20 domini di errore per la disponibilità elevata all'interno di un'area. L'immagine seguente mostra la topologia del sistema di distribuzione globale Azure Cosmos DB:

Topologia del sistema

La distribuzione globale in Azure Cosmos DB è chiavi in mano: In qualsiasi momento, con pochi clic o a livello di codice con una singola chiamata API, è possibile aggiungere o rimuovere le aree geografiche associate al database Azure Cosmos DB. Un database Azure Cosmos DB, a sua volta, è costituito da un set di contenitori Azure Cosmos DB. In Azure Cosmos DB i contenitori fungono da unità logiche di distribuzione e scalabilità. Le raccolte, le tabelle e i grafici creati sono (internamente) solo Azure Cosmos DB contenitori. I contenitori sono completamente indipendenti dallo schema e forniscono un ambito per una query. I dati in un contenitore Azure Cosmos DB vengono indicizzati automaticamente al momento dell'inserimento. L'indicizzazione automatica consente agli utenti di eseguire query sui dati senza problemi di gestione dello schema o dell'indice, soprattutto in una configurazione distribuita a livello globale.

  • In una determinata area, i dati all'interno di un contenitore vengono distribuiti usando una chiave di partizione, che viene fornita e gestita in modo trasparente dalle partizioni fisiche sottostanti (distribuzione locale).

  • Ogni partizione fisica viene inoltre replicata in più aree geografiche (distribuzione globale).

Quando un'app che usa Azure Cosmos DB ridimensiona in modo elastico la velocità effettiva in un contenitore Azure Cosmos DB o usa più spazio di archiviazione, Azure Cosmos DB gestisce in modo trasparente le operazioni di gestione delle partizioni (divisione, clonazione, eliminazione) in tutte le aree. Indipendentemente dalla scalabilità, dalla distribuzione o dagli errori, Azure Cosmos DB continua a fornire un'unica immagine di sistema dei dati all'interno dei contenitori, che vengono distribuiti a livello globale in un numero qualsiasi di aree.

Come illustrato nell'immagine seguente, i dati all'interno di un contenitore vengono distribuiti lungo due dimensioni, all'interno di un'area e tra aree, in tutto il mondo:

partizioni fisiche

Una partizione fisica viene implementata da un gruppo di repliche, denominato set di repliche. Ogni computer ospita centinaia di repliche che corrispondono a diverse partizioni fisiche all'interno di un set fisso di processi, come illustrato nell'immagine precedente. Le repliche corrispondenti alle partizioni fisiche vengono posizionate in modo dinamico e con carico bilanciato nei computer all'interno di un cluster e nei data center all'interno di un'area.

Una replica appartiene in modo univoco a un tenant Azure Cosmos DB. Ogni replica ospita un'istanza del motore di Azure Cosmos DB database, che gestisce le risorse e gli indici associati. Il motore di database Azure Cosmos DB opera su un sistema di tipi basato su atom-record-sequence (ARS). Il motore è indipendente dal concetto di schema, sfocando il confine tra la struttura e i valori di istanza dei record. Azure Cosmos DB ottiene l'agnosticismo completo dello schema tramite l'indicizzazione automatica di tutti gli elementi all'inserimento in modo efficiente, che consente agli utenti di eseguire query sui dati distribuiti a livello globale senza dover gestire lo schema o la gestione degli indici.

Il motore di database Azure Cosmos DB è costituito da componenti che includono l'implementazione di diverse primitive di coordinamento, runtime del linguaggio, query processor e sottosistemi di archiviazione e indicizzazione responsabili rispettivamente dell'archiviazione transazionale e dell'indicizzazione dei dati. Per garantire durabilità e disponibilità elevata, il motore di database conserva i dati e l'indice nelle unità SSD e ne esegue la replica, rispettivamente tra le istanze del motore di database all'interno dei set di repliche. I tenant di dimensioni maggiori corrispondono a una scalabilità superiore di velocità effettiva e archiviazione e dispongono di repliche più grandi o in numero maggiore o di entrambi. Ogni componente del sistema è completamente asincrono: nessun thread si blocca mai e ognuno esegue operazioni di breve durata senza incorrere in eventuali opzioni di thread non necessarie. Limitazione di frequenza e contropressione sono integrate nell'intero stack dal controllo di ammissione a tutti i percorsi di input/output. Il motore di database di Azure Cosmos DB è progettato per sfruttare la concorrenza con granularità fine e per garantire un'elevata larghezza di banda mentre opera all'interno di quantità ridotte di risorse di sistema.

La distribuzione globale di Azure Cosmos DB si basa su due astrazioni chiave: replica-sets e partition-sets. Un set di repliche è un blocco predefinito modulare per il coordinamento e un set di partizioni è una sovrapposizione dinamica di una o più partizioni fisiche distribuite geograficamente. Per comprendere il funzionamento della distribuzione globale, è necessario comprendere queste due chiavi di astrazioni.

Set di repliche

Una partizione fisica viene materializzata come un gruppo di repliche, autogestito e con bilanciamento dinamico del carico, distribuito su più domini di guasto, denominato set di repliche. Questo set implementa collettivamente il protocollo replicato dello stato del computer per rendere i dati all'interno della partizione fisica altamente disponibili, durevoli e coerenti. L'appartenenza al set di repliche N è dinamico: fluttua tra NMin e NMax in base agli errori, alle operazioni amministrative e al tempo necessario per rigenerare/ripristinare le repliche non riuscite. In base alle modifiche dell'appartenenza, anche il protocollo della replica riconfigura anche le dimensioni del quorum di lettura e scrittura. Per distribuire in modo uniforme la velocità effettiva assegnata a una determinata partizione fisica, si usano due idee:

  • In primo luogo, il costo di elaborazione delle richieste di scrittura sul leader è superiore al costo di applicazione degli aggiornamenti al follower. Di conseguenza, il leader ha in bilancio più risorse di sistema rispetto ai follower.

  • In secondo luogo, per quanto possibile, il quorum di lettura per un livello di coerenza specifico è costituito esclusivamente dalle repliche dei follower. A meno che non necessario, sarà possibile evitare di contattare il leader per la gestione delle operazioni di lettura. Vengono impiegate numerose idee derivanti dalla ricerca svolta sulla relazione tra carico e capacità nei sistemi basati sul quorum per i cinque modelli di coerenza supportati da Azure Cosmos DB.

Per altre informazioni sui set di repliche e sulla relativa correlazione con le partizioni fisiche, vedere Set di repliche di partizione.

Set di partizioni

Un gruppo di partizioni fisiche, una da ognuna delle aree di database configurate con il Azure Cosmos DB, è composta per gestire lo stesso set di chiavi replicate in tutte le aree configurate. Questa primitiva di coordinamento superiore è denominata set di partizioni, ovvero una sovrapposizione dinamica di partizioni fisiche distribuita geograficamente per la gestione di un determinato set di chiavi. Mentre una determinata partizione fisica (un set di repliche) è presente all'interno di un cluster, un set di partizioni può estendersi su cluster, data center e aree geografiche come mostrato nell'immagine seguente:

Set di partizioni

È possibile considerare un set di partizioni come un "super set di repliche" geograficamente disperso, composto da più set di repliche che dispongono dello stesso numero di chiavi. Analogamente a un set di repliche, anche l'appartenenza a un set di partizioni è dinamica, che varia in base alle operazioni implicite di gestione delle partizioni fisiche per aggiungere/rimuovere nuove partizioni da e verso un determinato set di partizioni, ad esempio quando si aumenta la velocità effettiva in un contenitore, si aggiunge o si rimuove un'area al database Azure Cosmos DB o in caso di errori. Grazie al fatto che ogni partizione (di un set) gestisce l'appartenenza al set di partizioni all'interno del proprio set di repliche, l'appartenenza è completamente decentralizzata e a disponibilità elevata. Durante la riconfigurazione di un set di partizioni, viene specificata anche la topologia della sovrapposizione tra le partizioni fisiche. La topologia viene selezionata in modo dinamico in base al livello di coerenza, la distanza geografica e la larghezza di banda della rete disponibile tra le partizioni fisiche di origine e di destinazione.

Il servizio consente di configurare i database Azure Cosmos DB con una singola area di scrittura o più aree di scrittura e, a seconda della scelta, i set di partizioni sono configurati per accettare le scritture in una o tutte le aree. Il sistema usa un protocollo di consenso annidato e a due livelli: un livello opera all'interno delle repliche di un set di repliche di una partizione fisica accettando le scritture; l'altro opera a livello di un set di partizioni per fornire garanzie di ordinamento complete per tutte scritture sulle quali è stato eseguito il commit all'interno del set di partizioni. Questo consenso multistrato annidato è fondamentale per l'implementazione dei nostri rigorosi accordi sul livello di servizio (SLA) per l'elevata disponibilità, nonché per l'implementazione dei modelli di coerenza che Azure Cosmos DB offre ai propri clienti.

Risoluzione dei conflitti

Il nostro progetto per la propagazione degli aggiornamenti, la risoluzione dei conflitti e il rilevamento della causalità è ispirato dal lavoro precedente sugli algoritmi dell'epidemia e sul sistema Bayou. Mentre i kernel delle idee sono sopravvissuti e forniscono un pratico quadro di riferimento per comunicare la progettazione del sistema Azure Cosmos DB, essi hanno anche subito una trasformazione significativa come li abbiamo applicati al sistema Azure Cosmos DB. Ciò era necessario, perché i sistemi precedenti non sono stati progettati né con la governance delle risorse né con la scalabilità in base alla quale Azure Cosmos DB deve funzionare, né per fornire le funzionalità (ad esempio, la coerenza con decadimento ristretto) e i contratti di servizio rigorosi e completi che Azure Cosmos DB forniscono ai propri clienti.

Ricordare che un set di partizioni viene distribuito in più aree e segue il protocollo di replica di Azure Cosmos DB (scritture in più aree) per replicare i dati nelle partizioni fisiche che comprendono quel set di partizioni. Ogni partizione fisica (di un set di partizioni) in genere accetta le scritture e gestisce le letture dei client locali di una determinata area. Le scritture accettate da una partizione fisica all'interno di un'area vengono memorizzate in modo duraturo e rese altamente disponibili all'interno della partizione fisica prima di essere confermate al client. Si tratta di operazioni di scrittura provvisorie e vengono propagate alle altre partizioni fisiche all'interno del set di partizioni usando un canale antientropia. I client possono richiedere operazioni di scrittura provvisori o sulle quali è stato eseguito il commit, passando un'intestazione di richiesta. La propagazione antientropia (inclusa la frequenza della propagazione) è dinamica e basata sulla topologia del set di partizioni, la prossimità dell'area delle partizioni fisiche e il livello di coerenza configurato. All'interno di un set di partizioni, Azure Cosmos DB segue uno schema di commit primario con una partizione arbiter selezionata dinamicamente. La selezione dell'arbitro è dinamica ed è parte integrante della riconfigurazione del set di partizioni basata sulla topologia dell'overlay. Le operazioni di scrittura (inclusi multi-row/in batch gli aggiornamenti) in cui è stato eseguito il commit sono garantite per essere ordinate.

Vengono utilizzati vettori di orologi codificati (contenenti l'ID della regione e gli orologi logici corrispondenti a ciascun livello di consenso rispettivamente per il set di repliche e per il set di partizioni) per il tracciamento della causalità e dei vettori di versione al fine di identificare e risolvere i conflitti di aggiornamento. La topologia e l'algoritmo di selezione peer sono progettati per garantire risorse di archiviazione predefinite e minime e un sovraccarico di rete minimo dei vettori della versione. L'algoritmo garantisce la rigida proprietà di convergenza.

Per i database Azure Cosmos DB configurati con più aree di scrittura, il sistema offre diversi criteri di risoluzione dei conflitti automatici flessibili tra cui gli sviluppatori possono scegliere, tra cui:

  • Last-Write-Wins (LWW) che, per impostazione predefinita, utilizza una proprietà timestamp definita dal sistema (che si basa sul protocollo dell'orologio di sincronizzazione dell'ora). Azure Cosmos DB consente inoltre di specificare qualsiasi altra proprietà numerica personalizzata da utilizzare per la risoluzione dei conflitti.
  • Il criterio di risoluzione dei conflitti personalizzato definito dall'applicazione (espresso tramite procedure di merge), progettato per la riconciliazione semantica dei conflitti secondo le definizioni dell'applicazione. Queste procedure vengono richiamate quando vengono rilevati conflitti di scrittura-scrittura nell'ambito di una transazione di database sul lato server. Il sistema fornisce esattamente una volta la garanzia per l'esecuzione di una routine di tipo merge come parte del protocollo di impegno. Esistono diversi esempi di risoluzione dei conflitti disponibili.

Modelli di coerenza

Se si configura il database Azure Cosmos DB con una o più aree di scrittura, è possibile scegliere tra five modelli di coerenza ben definiti. Questi modelli vanno dalla coerenza assoluta alla coerenza finale e influiscono sul modo in cui le repliche all'interno dei set di partizioni sincronizzano i dati.

Nel contesto della distribuzione globale:

  • Il decadimento ristretto usa il protocollo anti-entropia in modo limitato, assicurando che i prefissi non si accumulino e che le operazioni di scrittura non siano limitate inutilmente.
  • La coerenza delle sessioni garantisce operazioni di lettura e scrittura monotoniche, la lettura delle proprie operazioni di scrittura, la scrittura basata sulle letture e prefisso coerente in tutto il mondo.
  • La coerenza assoluta richiede la replica sincrona tra aree, il che significa che gli account di scrittura in più aree non traggono vantaggio dalla bassa latenza di scrittura o dalla disponibilità elevata di scrittura quando si usa questo livello.

Per informazioni dettagliate sulla semantica e sulle garanzie del livello di coerenza, vedere Livelli di latenza in Azure Cosmos DB. I modelli di coerenza vengono inoltre descritti matematicamente usando TLA+ specifiche.

Passaggi successivi

Scoprire come configurare la distribuzione globale utilizzando i seguenti articoli:

  • Last updated on