Livelli di coerenza in Azure Cosmos DB
SI APPLICA A:
Nosql Mongodb Cassandra Gremlin Tabella
I database distribuiti che si basano sulla replica per disponibilità elevata, bassa latenza o entrambi, devono fare un compromesso fondamentale tra coerenza di lettura, disponibilità, latenza e velocità effettiva, come definito dal teorema PACELC. La linearizzabilità del modello di coerenza assoluta è lo standard gold della programmabilità dei dati. Ma aggiunge un prezzo ripida da latenze di scrittura più elevate a causa della necessità di replicare ed eseguire il commit su distanze elevate. La coerenza assoluta può anche risentire della disponibilità ridotta (durante gli errori) perché i dati non possono replicare ed eseguire il commit in ogni area. La coerenza finale offre una maggiore disponibilità e prestazioni migliori, ma è più difficile programmare le applicazioni perché i dati potrebbero non essere coerenti in tutte le aree.
La maggior parte dei database NoSQL distribuiti attualmente disponibili sul mercato offre solo coerenza assoluta e finale. Azure Cosmos DB offre cinque livelli ben definiti. Dal più forte al più debole, i livelli sono:
Per altre informazioni sul livello di coerenza predefinito, vedere Configurazione del livello di coerenza predefinito o override del livello di coerenza predefinito.
Ogni livello prevede compromessi tra disponibilità e prestazioni. L'immagine seguente illustra i diversi livelli di coerenza sotto forma di spettro.
Livelli di coerenza e API di Azure Cosmos DB
Azure Cosmos DB offre il supporto nativo per le API compatibili con il protocollo di collegamento per i database più diffusi. Sono inclusi MongoDB, Apache Cassandra, Apache Gremlin e Archiviazione tabelle di Azure. Nell'API per Gremlin o Table viene usato il livello di coerenza predefinito configurato nell'account Azure Cosmos DB. Per informazioni dettagliate sul mapping del livello di coerenza tra Apache Cassandra e Azure Cosmos DB, vedere MAPPING di coerenza dell'API per Cassandra. Per informazioni dettagliate sul mapping a livello di coerenza tra MongoDB e Azure Cosmos DB, vedere Mapping di coerenza dell'API per MongoDB.
Ambito della coerenza di lettura
La coerenza di lettura si applica a una singola operazione di lettura con ambito all'interno di una partizione logica. Un client remoto o una stored procedure può eseguire l'operazione di lettura.
Configurare il livello di coerenza predefinito
È possibile configurare il livello di coerenza predefinito nell'account Azure Cosmos DB in qualsiasi momento. Il livello di coerenza predefinito configurato per l'account si applica a tutti i database di Azure Cosmos DB e ai contenitori in tale account. Per impostazione predefinita, tutte le operazioni di lettura e le query eseguite su un contenitore o un database usano il livello di coerenza specificato. Quando si modifica la coerenza a livello di account, assicurarsi di ridistribuire le applicazioni e apportare eventuali modifiche al codice necessarie per applicare queste modifiche. Per altre informazioni, vedere come configurare il livello di coerenza predefinito. È anche possibile eseguire l'override del livello di coerenza predefinito per una richiesta specifica. Per altre informazioni, vedere l'articolo Eseguire l'override del livello di coerenza predefinito .
Suggerimento
L'override del livello di coerenza predefinito si applica solo alle letture all'interno del client SDK. Un account configurato per coerenza assoluta per impostazione predefinita continuerà a scrivere e replicare i dati in modo sincrono in ogni area dell'account. Quando l'istanza del client SDK o la richiesta esegue l'override di questa operazione con La sessione o la coerenza più debole, le letture verranno eseguite usando una singola replica. Per altre informazioni, vedere Livelli di coerenza e velocità effettiva.
Importante
È necessario ricreare qualsiasi istanza dell'SDK dopo aver modificato il livello di coerenza predefinito. A tale scopo, riavviare l'applicazione. In questo modo l'SDK usa il nuovo livello di coerenza predefinito.
Garanzie associate ai livelli di coerenza
Azure Cosmos DB garantisce che il 100% delle richieste di lettura soddisfi la garanzia di coerenza per il livello di coerenza scelto. Le definizioni precise dei cinque livelli di coerenza in Azure Cosmos DB che usano il linguaggio di specifica TLA+ sono disponibili nel repository GitHub azure-cosmos-tla .
La semantica dei cinque livelli di coerenza è descritta nelle sezioni seguenti.
Coerenza assoluta
La coerenza assoluta offre una garanzia di linearizzabilità. Linearizability si riferisce alla gestione simultanea delle richieste. È garantito che le letture restituiscano sempre la versione di un elemento di cui sia stato eseguito il commit più di recente. Un client non visualizza mai una scrittura parziale o di cui non sia stato eseguito il commit. Gli utenti possono sempre essere certi di leggere la scrittura più recente sottoposta a commit.
La figura seguente illustra la coerenza assoluta con le note musicali. Dopo aver scritto i dati nell'area "Stati Uniti occidentali 2", quando si leggono i dati da altre aree, si ottiene il valore più recente:
Coerenza con decadimento ristretto
Per gli account di scrittura a singola area con due o più aree, i dati vengono replicati dall'area primaria a tutte le aree secondarie (di sola lettura). Per gli account di scrittura in più aree con due o più aree, i dati vengono replicati dall'area originariamente scritti in tutte le altre aree scrivibili. In entrambi gli scenari, anche se non è comune, può verificarsi un ritardo di replica da un'area a un'altra.
Nella coerenza con decadimento ristretto, il ritardo dei dati tra due aree è sempre minore di una quantità specificata. L'importo può essere costituito da versioni "K", ovvero "aggiornamenti" di un elemento o da intervalli di tempo "T", a qualsiasi livello di tempo venga raggiunto per primo. In altre parole, quando si sceglie decadimento ristretto, è possibile configurare il massimo "decadimento" dei dati in qualsiasi area in due modi:
- Numero di versioni (K) dell'elemento
- L'intervallo di tempo (T) delle letture potrebbe essere ritardato rispetto alle scritture
La decadimento ristretto è utile principalmente per gli account di scrittura a singola area con due o più aree. Se il ritardo dei dati in un'area (determinata per partizione fisica) supera il valore di decadimento configurato, le scritture per tale partizione vengono limitate fino a quando non si torna all'interno del limite superiore configurato.
Per un account a singola area, la decadimento ristretto offre le stesse garanzie di coerenza di scrittura della sessione e della coerenza finale. Con decadimento ristretto, i dati vengono replicati in una maggioranza locale (tre repliche in un set di quattro repliche) nella singola area.
Importante
Con coerenza con decadimento ristretto, i controlli di decadimento vengono eseguiti solo tra aree e non all'interno di un'area. All'interno di una determinata area, i dati vengono sempre replicati in una maggioranza locale (tre repliche in un set di quattro repliche) indipendentemente dal livello di coerenza.
Legge quando si usa decadimento ristretto restituisce i dati più recenti disponibili in tale area leggendo da due repliche disponibili in tale area. Poiché le scritture all'interno di un'area vengono sempre replicate in una maggioranza locale (tre su quattro repliche), la consulenza di due repliche restituisce i dati più aggiornati disponibili in tale area.
Importante
Con coerenza con decadimento ristretto, le letture eseguite in un'area non primaria potrebbero non restituire necessariamente la versione più recente dei dati a livello globale, ma è garantito che restituisca la versione più recente dei dati in tale area, che si troverà entro il limite massimo di decadimento a livello globale.
Lo stato di decadimento ristretto è ideale per le applicazioni distribuite a livello globale usando account di scrittura a singola area con due o più aree, in cui è richiesta la coerenza assoluta tra le aree. Per gli account di scrittura in più aree con due o più aree, i server applicazioni devono indirizzare le letture e le scritture nella stessa area in cui sono ospitati i server applicazioni. Decadimento ristretto in un account multi-scrittura è un anti-pattern. Questo livello richiede una dipendenza dal ritardo di replica tra aree, che non devono essere importanti se i dati vengono letti dalla stessa area in cui è stato scritto.
La figura seguente illustra la coerenza di decadimento ristretto con le note musicali. Dopo la scrittura dei dati nell'area "Stati Uniti occidentali 2", le aree "Stati Uniti orientali 2" e "Australia orientale" leggono il valore scritto in base al tempo massimo di ritardo configurato o alle operazioni massime:
Coerenza di sessione
Nella coerenza della sessione, all'interno di una singola sessione client, le letture sono garantite per rispettare le garanzie read-your-write e write-follows-reads. Questa garanzia presuppone una singola sessione "writer" o la condivisione del token di sessione per più writer.
Come tutti i livelli di coerenza più deboli di Strong, le scritture vengono replicate in almeno tre repliche (in un set di quattro repliche) nell'area locale, con replica asincrona in tutte le altre aree.
Dopo ogni operazione di scrittura, il client riceve un token di sessione aggiornato dal server. Il client memorizza nella cache i token e li invia al server per le operazioni di lettura in un'area specificata. Se la replica in cui viene eseguita l'operazione di lettura contiene i dati per il token specificato (o un token più recente), vengono restituiti i dati richiesti. Se la replica non contiene dati per tale sessione, il client ritenta la richiesta su un'altra replica nell'area. Se necessario, il client ritenta la lettura in aree disponibili aggiuntive fino a quando non vengono recuperati i dati per il token di sessione specificato.
Importante
In Coerenza sessione l'utilizzo del client di un token di sessione garantisce che i dati corrispondenti a una sessione precedente non vengano mai letti. Tuttavia, se il client usa un token di sessione precedente e sono stati apportati aggiornamenti più recenti al database, la versione più recente dei dati verrà restituita nonostante venga usato un token di sessione precedente. Il token di sessione viene usato come barriera minima di versione, ma non come versione specifica (possibilmente cronologica) dei dati da recuperare dal database.
I token di sessione in Azure Cosmos DB sono associati a partizioni, ovvero sono associati esclusivamente a una partizione. Per assicurarsi di poter leggere le scritture, usare il token di sessione che è stato generato per gli elementi pertinenti.
Se il client non ha avviato una scrittura in una partizione fisica, il client non contiene un token di sessione nella cache e le letture in tale partizione fisica si comportano come le letture con Coerenza finale. Analogamente, se il client viene ricreato, viene ricreata anche la cache dei token di sessione. Anche in questo caso, le operazioni di lettura seguono lo stesso comportamento della coerenza finale fino a quando le operazioni di scrittura successive ricompilano la cache dei token di sessione del client.
Importante
Se i token di sessione vengono passati da un'istanza client a un'altra, il contenuto del token non deve essere modificato.
La coerenza della sessione è il livello di coerenza più usato sia per le singole aree che per le applicazioni distribuite a livello globale. Fornisce latenze di scrittura, disponibilità e velocità effettiva di lettura paragonabile a quella della coerenza finale. La coerenza della sessione fornisce inoltre le garanzie di coerenza che soddisfano le esigenze delle applicazioni scritte per operare nel contesto di un utente. L'immagine seguente illustra la coerenza della sessione con le note musicali. Il writer "Stati Uniti occidentali 2" e il lettore "Stati Uniti orientali 2" usano la stessa sessione (Sessione A) in modo da leggere entrambi gli stessi dati contemporaneamente. Mentre l'area "Australia orientale" usa "Session B" in modo da ricevere i dati in un secondo momento, ma nello stesso ordine delle scritture.
Coerenza con prefisso coerente
Come tutti i livelli di coerenza più deboli di Strong, le scritture vengono replicate in almeno tre repliche (in un set di quattro repliche) nell'area locale, con replica asincrona in tutte le altre aree.
Nel prefisso coerente, gli aggiornamenti apportati come scrittura di singoli documenti vedono la coerenza finale.
Aggiornamenti effettuato come batch all'interno di una transazione, vengono restituiti coerenti con la transazione in cui sono stati sottoposti a commit. Le operazioni di scrittura all'interno di una transazione di più documenti sono sempre visibili insieme.
Si supponga che due operazioni di scrittura vengano eseguite in modo transazionale (tutte o niente) nel documento Doc1 seguito da documento Doc2, all'interno delle transazioni T1 e T2. Quando il client esegue una lettura in qualsiasi replica, l'utente visualizza "Doc1 v1 e Doc2 v1" o "Doc1 v2 e Doc2 v2" o nessun documento se la replica è in ritardo, ma non "Doc1 v1 e Doc2 v2" o "Doc1 v2 e Doc2 v1" per la stessa operazione di lettura o query.
L'immagine seguente illustra la coerenza del prefisso di coerenza con le note musicali. In tutte le aree le letture non vengono mai visualizzate scritture in ordine per un batch transazionale di scritture:
Coerenza finale
Come tutti i livelli di coerenza più deboli di Strong, le scritture vengono replicate in almeno tre repliche (in un set di quattro repliche) nell'area locale, con replica asincrona in tutte le altre aree.
In Coerenza finale, il client genera richieste di lettura su una delle quattro repliche nell'area specificata. Questa replica può essere in ritardo e potrebbe restituire dati non aggiornati.
La coerenza finale è la forma di coerenza più debole perché un client può leggere i valori precedenti a quelli letti in passato. La coerenza finale è ideale nei casi in cui l'applicazione non richiede alcuna garanzia di ordinamento. Gli esempi includono il numero di retweet, like o commenti non thread. L'immagine seguente illustra la coerenza finale con le note musicali.
Garanzie di coerenza in pratica
In pratica, è spesso possibile ottenere garanzie di coerenza più solide. Per un'operazione di lettura, le garanzie di coerenza corrispondono al livello di aggiornamento e ordinamento dello stato del database richiesto. La coerenza di lettura è associata all'ordinamento e alla propagazione delle operazioni di scrittura/aggiornamento.
Se nel database non sono presenti operazioni di scrittura, è probabile che un'operazione di lettura con livelli di coerenza del prefisso finale, sessione o coerente restituisca gli stessi risultati di un'operazione di lettura con un livello di coerenza elevato.
Se l'account è configurato con un livello di coerenza diverso dalla coerenza forte, è possibile individuare la probabilità che i client possano ottenere letture forti e coerenti per i carichi di lavoro. È possibile capire questa probabilità esaminando la metrica Dissegnamento probabilestico (PBS). Questa metrica viene esposta nel portale di Azure. Per altre informazioni, vedere Monitorare la metrica del decadimento ristretto probabilistico (Probabilistic Bounded Staleness, PBS).
Il decadimento ristretto probabilistico mostra il livello di finalità della coerenza finale. Questa metrica fornisce informazioni dettagliate sulla frequenza con cui è possibile ottenere una coerenza più forte rispetto al livello di coerenza attualmente configurato nell'account Azure Cosmos DB. In altre parole, è possibile visualizzare la probabilità (misurata in millisecondi) di ottenere letture coerenti per una combinazione di aree di scrittura e lettura.
Livelli di coerenza e latenza
La latenza di lettura per tutti i livelli di coerenza è sempre minore ai 10 millisecondi al 99° percentile. La latenza di lettura media, al 50° percentile, è in genere di 4 millisecondi o meno.
La latenza di scrittura per tutti i livelli di coerenza è sempre garantita a meno di 10 millisecondi al 99° percentile. La latenza di scrittura media, al 50° percentile, è in genere uguale o inferiore ai 5 millisecondi. Gli account Azure Cosmos DB che si estendono su diverse aree e sono configurati con coerenza forte sono un'eccezione a questa garanzia.
Latenza di scrittura e coerenza avanzata
Per gli account Azure Cosmos DB configurati con coerenza elevata con più aree, la latenza di scrittura è uguale a due volte tempo di round trip (RTT) tra una delle due aree più lontane, più 10 millisecondi al 99° percentile. RTT di rete elevata tra le aree si tradurrà in una latenza più elevata per le richieste di Azure Cosmos DB perché la coerenza elevata completa un'operazione solo dopo aver verificato che sia stato eseguito il commit in tutte le aree all'interno di un account.
La latenza RTT esatta è una funzione della velocità della luce e la topologia di rete di Azure. La rete di Azure non fornisce contratti di servizio di latenza per il RTT tra due aree di Azure, ma pubblica le statistiche sulla latenza round trip di rete di Azure. Per l'account Azure Cosmos DB, le latenze di replica vengono visualizzate nella portale di Azure. È possibile usare la portale di Azure passando alla sezione Metriche e quindi selezionando l'opzione Coerenza. Usando la portale di Azure, è possibile monitorare le latenze di replica tra varie aree associate all'account Azure Cosmos DB.
Importante
La coerenza elevata per gli account con aree che si estendono su più di 5000 miglia (8000 chilometri) è bloccata per impostazione predefinita a causa di una latenza di scrittura elevata. Per abilitare questa funzionalità, contattare il supporto tecnico.
Livelli di coerenza e velocità effettiva
Per una maggiore e limitata stalezza, le letture vengono eseguite su due repliche in un set di quattro repliche (quorum di minoranza) per garantire la coerenza. Sessione, prefisso coerente ed eventuali letture di replica singola. Il risultato è che, per lo stesso numero di unità richiesta, la velocità effettiva di lettura per una velocità effettiva elevata e vincolata è metà degli altri livelli di coerenza.
Per un determinato tipo di operazione di scrittura (come inserimento, sostituzione, upsert ed eliminazione), la velocità effettiva di scrittura per le unità di richieste è identica per tutti i livelli di coerenza. Per una coerenza forte, è necessario eseguire il commit delle modifiche in ogni area (maggioranza globale), mentre per tutti gli altri livelli di coerenza, viene usata la maggioranza locale (tre repliche in un set di quattro repliche).
| Livello di coerenza | Letture quorum | Scritture quorum |
|---|---|---|
| Assoluta | Minoranza locale | Maggioranza globale |
| Decadimento ristretto | Minoranza locale | Maggioranza locale |
| Sessione | Replica singola (usando il token di sessione) | Maggioranza locale |
| Coerenza del prefisso | Replica singola | Maggioranza locale |
| Finale | Replica singola | Maggioranza locale |
Nota
Il costo delle letture ur/s per le letture delle minoranze locali è due volte quello dei livelli di coerenza più deboli perché le letture vengono eseguite da due repliche per garantire la coerenza per lo scostamento sicuro e limitato.
Nota
Il costo delle ur/s delle letture per i livelli di coerenza elevata e vincolata utilizza circa due volte più UR durante l'esecuzione di operazioni di lettura rispetto a quella di altri livelli di coerenza rilassata.
Livelli di coerenza e durabilità dei dati
All'interno di un ambiente di database distribuito a livello globale, esiste una relazione diretta tra il livello di coerenza e la durabilità dei dati in presenza di un'interruzione a livello di area. Quando si sviluppa il piano di continuità aziendale, è necessario comprendere il periodo massimo di aggiornamenti dei dati recenti che l'applicazione può tollerare per perdere quando si ripristina dopo un evento di interruzione. Il periodo di tempo degli aggiornamenti che si potrebbe permettere di perdere è noto come obiettivo del punto di ripristino (RPO).
Questa tabella definisce la relazione tra il modello di coerenza e la durabilità dei dati in presenza di un'interruzione a livello di area.
| Aree geografica | Modalità di replica | Livello di coerenza | RPO |
|---|---|---|---|
| 1 | Aree di scrittura singole o multiple | Qualsiasi livello di coerenza | < 240 minuti |
| >1 | Area di scrittura singola | Sessione, Prefisso coerente, Finale | < 15 minuti |
| >1 | Area di scrittura singola | Decadimento ristretto | K&T |
| >1 | Area di scrittura singola | Assoluta | 0 |
| >1 | Più aree di scrittura | Sessione, Prefisso coerente, Finale | < 15 minuti |
| >1 | Più aree di scrittura | Decadimento ristretto | K&T |
K = Numero di versioni "K" (ovvero aggiornamenti) di un elemento.
T = Intervallo di tempo "T" dall'ultimo aggiornamento.
Per un singolo account area, il valore minimo di K e T è 10 operazioni di scrittura o 5 secondi. Per gli account multi-area il valore minimo di K e T è 100.000 operazioni di scrittura o 300 secondi. Questo valore definisce l'RPO minimo per i dati quando si usa Lo stato non limitato.
Coerenza avanzata e più aree di scrittura
Gli account Azure Cosmos DB configurati con più aree di scrittura non possono essere configurati per una coerenza complessa perché non è possibile che un sistema distribuito fornisca un RPO pari a zero e un RTO di zero. Inoltre, non esistono vantaggi per la latenza di scrittura sull'uso di una coerenza elevata con più aree di scrittura perché è necessario replicare e eseguire il commit in tutte le aree configurate all'interno dell'account. Questo scenario comporta la stessa latenza di scrittura di un singolo account di area di scrittura.
Altri riferimenti
Per altre informazioni sui concetti di coerenza, vedere gli articoli seguenti:
- High-level TLA+ specifications for the five consistency levels offered by Azure Cosmos DB (Specifiche TLA+ di alto livello per i cinque livelli di coerenza offerti da Azure Cosmo DB)
- Coerenza dei dati replicata spiegata tramite baseball (video) di Doug Terry
- Coerenza dei dati replicata spiegata tramite baseball (whitepaper) di Doug Terry
- Session Guarantees for weakly consistent replicated data (Garanzie di sessione per i dati replicati con coerenza debole)
- Consistency Tradeoffs in Modern Distributed Database Systems Design: CAP is Only Part of the Story (Compromessi sulla coerenza nella progettazione di sistemi di database distribuiti moderni: CAP è solo una parte della storia)
- Probabilistic Bounded Staleness (PBS) for Practical Partial Quorums (Decadimento ristretto probabilistico per quorum parziali pratici)
- Eventually Consistent - Revisited (Coerenza finale - Rivisitato)
Passaggi successivi
Per altre informazioni sui livelli di coerenza in Azure Cosmo DB, vedere gli articoli seguenti: