Livelli di coerenza in Azure Cosmos DB
SI APPLICA A: 
Nosql Mongodb Cassandra Gremlin Tabella
I database distribuiti che si basano sulla replica per la disponibilità elevata, la 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 ripido da latenze di scrittura più elevate a causa della necessità di replicare ed eseguire il commit su distanze elevate. La coerenza assoluta può anche subire una riduzione della disponibilità (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. Questi includono 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 API per il mapping di coerenza cassandra. Per informazioni dettagliate sul mapping del 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 il cui ambito si trova in 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. Per altre informazioni, è 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 soddisfano la garanzia di coerenza per qualsiasi livello 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à. La linearizzabilità fa riferimento 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 che i dati vengono scritti 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 comuni, può verificarsi occasionalmente 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 "K" versioni (ovvero "aggiornamenti") di un elemento o per intervalli di tempo "T", a qualsiasi valore raggiunto per primo. In altre parole, quando si sceglie decadimento ristretto, la "decadimento massimo" dei dati in qualsiasi area può essere configurata in due modi:
- Numero di versioni (K) dell'elemento
- L'intervallo di tempo (T) delle letture potrebbe essere ritardato rispetto alle scritture
Il decadimento ristretto è utile principalmente per gli account di scrittura in un'area singola 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 al limite superiore configurato.
Per un account a singola area, decadimento ristretto offre le stesse garanzie di coerenza di scrittura di Session e Eventual Consistency. 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 delimitato 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 la coerenza con decadimento ristretto, le letture rilasciate in un'area non primaria potrebbero non restituire necessariamente la versione più recente dei dati a livello globale, ma vengono restituite 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 è preferibile una coerenza assoluta tra aree. Per gli account di scrittura in più aree con due o più aree, i server applicazioni devono indirizzare le operazioni di lettura e scrittura nella stessa area in cui sono ospitati i server applicazioni. Decadimento ristretto in un account multi-scrittura è un anti-modello. 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 del decadimento ristretto con le note musicali. Dopo aver scritto i 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 di lettura/scrittura e letture di tipo write-follows.In session consistency, within a single client session, reads are guaranteed to honor the read-your-write, and write-follows-reads guarantees. 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 rispetto a 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 su cui viene eseguita l'operazione di lettura contiene 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 di versione minima, 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 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 di Coerenza finale fino a quando le successive operazioni di scrittura 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 delle sessioni è il livello di coerenza più diffuso sia per le singole aree che per le applicazioni distribuite a livello globale. Fornisce latenze di scrittura, disponibilità e velocità effettiva di lettura paragonabili a quel livello di coerenza finale. La coerenza della sessione fornisce anche 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 che entrambe leggono gli stessi dati contemporaneamente. Mentre l'area "Australia orientale" usa "Session B", quindi riceve i dati in un secondo momento ma nello stesso ordine delle scritture.
Coerenza con prefisso coerente
Analogamente a tutti i livelli di coerenza più deboli rispetto a 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.
Gli aggiornamenti effettuati in batch all'interno di una transazione vengono restituiti coerenti alla transizione in cui ne è stato eseguito il 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 dal documento Doc2, all'interno delle transazioni T1 e T2. Quando il client esegue una lettura in qualsiasi replica, l'utente vede "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 v2 v1" per la stessa operazione di lettura o query.
Nella figura seguente viene illustrata la coerenza del prefisso di coerenza con le note musicali. In tutte le aree le letture non vengono mai visualizzate scritture non in ordine per un batch transazionale di scritture:
Coerenza finale
Come tutti i livelli di coerenza più deboli rispetto a 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 invia richieste di lettura a una delle quattro repliche nell'area specificata. Questa replica potrebbe essere in ritardo e potrebbe restituire dati non aggiornati o non aggiornati.
La coerenza finale è la forma più debole di coerenza 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, mi piace o commenti non threadati. La figura 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 non sono presenti operazioni di scrittura nel database, è probabile che un'operazione di lettura con livelli di coerenza finale, sessione o prefisso coerente restituisca gli stessi risultati di un'operazione di lettura con un livello di coerenza assoluta.
Se l'account è configurato con un livello di coerenza diverso dalla coerenza assoluta, è possibile verificare che i client possano ottenere letture complesse e coerenti per i carichi di lavoro. È possibile determinare questa probabilità esaminando la metrica Probabilistically Bounded Staleness (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 inferiore.
La latenza di scrittura per tutti i livelli di coerenza è sempre inferiore a 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 assoluta rappresentano un'eccezione a questa garanzia.
Latenza di scrittura e coerenza assoluta
Per gli account Azure Cosmos DB configurati con coerenza assoluta con più aree, la latenza di scrittura è uguale a due volte il tempo di round trip (RTT) tra una delle due aree più lontane, più 10 millisecondi al 99° percentile. Il RTT di rete elevato tra le aree si tradurrà in una latenza più elevata per le richieste di Azure Cosmos DB perché la coerenza assoluta 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 protocollo RTT tra due aree di Azure, ma pubblica le statistiche di latenza round trip della rete di Azure. Per l'account Azure Cosmos DB, le latenze di replica vengono visualizzate nella portale di Azure. È possibile usare il portale di Azure passando alla sezione Metriche e quindi selezionando l'opzione Coerenza. Usando il portale di Azure, è possibile monitorare le latenze di replica tra varie aree associate all'account Azure Cosmos DB.
Importante
La coerenza assoluta 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 garantire la decadimento sicuro e ristretto, le letture vengono eseguite su due repliche in un set di quattro repliche (quorum di minoranza) per garantire la coerenza. Sessione, prefisso coerente ed eventuale eseguire letture a replica singola. Il risultato è che, per lo stesso numero di unità richiesta, la velocità effettiva di lettura per decadimento sicuro e ristretto è la 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 coerenza assoluta, è 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 |
|---|---|---|
| Assoluto | Minoranza locale | Maggioranza globale |
| Decadimento ristretto | Minoranza locale | Maggioranza locale |
| Sessione | Replica singola (con token di sessione) | Maggioranza locale |
| Coerenza del prefisso | Replica singola | Maggioranza locale |
| Finale | Replica singola | Maggioranza locale |
Nota
Il costo delle prestazioni delle ur/sec delle letture per le letture di minoranza locale è due volte quello dei livelli di coerenza più deboli perché le letture vengono eseguite da due repliche per garantire la coerenza per lo stato di decadimento sicuro e ristretto.
Nota
Il costo delle prestazioni delle UR/s delle letture per i livelli di coerenza con decadimento sicuro e ristretto utilizza circa due volte più UR durante l'esecuzione di operazioni di lettura rispetto a quella di altri livelli di coerenza meno elevati.
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. Durante lo sviluppo del piano di continuità aziendale, è necessario comprendere il periodo massimo di aggiornamenti dei dati recenti che l'applicazione può tollerare la perdita durante il ripristino dopo un evento di interruzione. Il periodo di tempo degli aggiornamenti che è possibile 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.
| Area/e | 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 di area, il valore minimo di K e T è 10 operazioni di scrittura o 5 secondi. Per gli account in più aree il valore minimo di K e T è 100.000 operazioni di scrittura o 300 secondi. Questo valore definisce il valore RPO minimo per i dati quando si usa decadimento delimitato.
Coerenza assoluta e più aree di scrittura
Gli account Azure Cosmos DB configurati con più aree di scrittura non possono essere configurati per coerenza assoluta perché non è possibile che un sistema distribuito fornisca un RPO pari a zero e un RTO pari a zero. Inoltre, non esistono vantaggi per la latenza di scrittura sull'uso di una coerenza assoluta con più aree di scrittura perché è necessario replicare e eseguire il commit di una scrittura in qualsiasi area e di 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)
- Replicated Data Consistency Explained Through Baseball (video) (La coerenza dei dati replicati illustrata attraverso il baseball) di Doug Terry
- Replicated Data Consistency Explained through Baseball (white paper) (La coerenza dei dati replicati illustrata attraverso il baseball) 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: