Livelli di coerenza in Azure Cosmos DB
SI APPLICA A: 
NoSQL MongoDB Cassandra Gremlin Tabella
I database distribuiti che si basano sulla replica per garantire disponibilità elevata, bassa latenza o entrambe, devono applicare il compromesso fondamentale tra coerenza di lettura, disponibilità, latenza e velocità effettiva come definito dal teorema PACELC. La linearizzabilità del modello di coerenza assoluta rappresenta lo standard assoluto di programmabilità dei dati, ma aggiunge il caro prezzo di latenze di scrittura più elevate dovute alla necessità di replicare ed eseguire il commit su grandi distanze. La coerenza assoluta può anche essere caratterizzata da una riduzione della disponibilità (durante gli errori) perché i dati non possono eseguire la replica e 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 Ignorare il 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. In API per Gremlin o per Tabella, viene utilizzato il livello di coerenza predefinito configurato per l'account Azure Cosmos DB. Per informazioni dettagliate sul mapping del livello di coerenza tra Apache Cassandra e Azure Cosmos DB, vedere Mapping della coerenza di API per Cassandra. Per informazioni dettagliate sul mapping del livello di coerenza tra MongoDB e Azure Cosmos DB, vedere Mapping della coerenza di 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, una stored procedure o un trigger possono avviare 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 modificare il codice in base alle necessità per applicare queste modifiche. Per altre informazioni, vedere come configurare il livello di coerenza predefinito. È anche possibile ignorare il livello di coerenza predefinito per una richiesta specifica. Per altre informazioni, vedere l'articolo relativo alla procedura per ignorare il livello di coerenza predefinito.
Suggerimento
È possibile ignorare il livello di coerenza predefinito solo per le operazioni di lettura all'interno del client SDK. Un account configurato in modo predefinito per la coerenza assoluta continuerà a eseguire operazioni di scrittura e replica dei dati in modo sincrono in ogni area dell'account. Quando l'istanza o la richiesta del client SDK ignora questo aspetto con una coerenza di sessione o più debole, le operazioni di lettura verranno eseguite usando una singola replica. Per altre informazioni, vedere Livelli di coerenza e velocità effettiva.
Importante
È necessario ricreare un'istanza dell'SDK dopo aver modificato il livello di coerenza predefinito. A tale scopo è possibile 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 sono stati scritti nell'area "Stati Uniti occidentali 2", quando si leggono i dati da altre aree, si ottiene il valore più recente:
Quorum dinamico
In circostanze normali, per un account con coerenza assoluta, viene considerato commit di una scrittura quando tutte le aree riconoscono che il record è stato replicato in esso. Tuttavia, per gli account con 3 aree o più (inclusa l'area di scrittura), il sistema può "ridurre" il quorum delle aree a una maggioranza globale nei casi in cui alcune aree non rispondono o rispondono lentamente. A questo punto, le aree che non rispondono vengono estratte dal set di quorum di aree per mantenere la coerenza assoluta. Verranno aggiunti di nuovo solo una volta che sono coerenti con altre aree e vengono eseguite come previsto. Il numero di aree che possono essere potenzialmente estratte dal set di quorum dipenderà dal numero totale di aree. Ad esempio, in un account di 3 o 4 aree, la maggior parte è rispettivamente 2 o 3 aree, quindi solo 1 area può essere rimossa in entrambi i casi. Per un account di 5 aree, la maggior parte è 3, quindi è possibile rimuovere fino a 2 aree che non rispondono. Questa funzionalità è nota come "quorum dinamico" e può migliorare sia la disponibilità di scrittura che la latenza di replica per gli account con 3 o più aree.
Nota
Quando le aree vengono rimosse dal set di quorum come parte del quorum dinamico, tali aree non sono più in grado di gestire le letture fino a quando non vengono aggiunte nuovamente al quorum.
Coerenza con decadimento ristretto
Per gli account di scrittura a singola area con due o più aree, i dati vengono replicati dall'area primaria in 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 in cui sono stati scritti originariamente in tutte le altre aree scrivibili. In entrambi gli scenari, anche se non comuni, può verificarsi occasionalmente un ritardo di replica da un'area all'altra.
Nella coerenza con decadimento ristretto, il ritardo dei dati tra due aree è sempre minore di una quantità specificata. La quantità può essere "K" versioni (ovvero "aggiornamenti") di un elemento o per intervalli di tempo "T", qualsiasi valore venga raggiunto per primo. In altre parole, quando si sceglie il decadimento ristretto, il "decadimento" massimo dei dati in qualsiasi area può essere configurata in due modi:
- Numero di versioni (K) dell'elemento
- Intervallo di tempo (T) in cui le operazioni di lettura possono essere in ritardo rispetto alle operazioni di scrittura
Il 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 operazioni di scrittura per tale partizione vengono limitate fino a quando non si torna al limite massimo configurato per il decadimento.
Per un account a singola area, il decadimento ristretto offre le stesse garanzie di coerenza di scrittura della coerenza di sessione o finale. Con il decadimento ristretto, i dati vengono replicati a maggioranza locale (tre repliche in un set di quattro repliche) nella singola area.
Importante
Con la 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 a maggioranza locale (tre repliche in un set di quattro repliche) indipendentemente dal livello di coerenza.
Quando si usa il decadimento ristretto, le operazioni di lettura restituiscono i dati più recenti disponibili in tale area leggendo da due repliche disponibili in tale area. Poiché le operazioni di scrittura all'interno di un'area vengono sempre replicate a maggioranza locale (tre sui quattro repliche), la consultazione di due repliche restituisce i dati più aggiornati disponibili in tale area.
Importante
Con la coerenza con decadimento ristretto, le operazioni di lettura avviate in un'area non primaria potrebbero non restituire necessariamente la versione più recente dei dati a livello globale, ma restituiscono sicuramente la versione più recente dei dati in tale area, che si troverà entro il limite massimo di decadimento a livello globale.
Il decadimento ristretto è ideale per le applicazioni distribuite a livello globale che usano 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. Il decadimento ristretto in un account con più operazioni di scrittura è un anti-pattern. Questo livello richiede una dipendenza dal ritardo di replica tra aree, che non deve essere importante se i dati vengono letti dalla stessa area in cui sono stati scritti.
La figura seguente illustra la coerenza con 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 al numero massimo di operazioni:
Coerenza di sessione
Nella coerenza di sessione, all'interno di una singola sessione client, si garantisce che le operazioni di lettura rispettino le garanzie di lettura delle proprie operazioni di scrittura e di scrittura basata sulle letture. Questa garanzia presuppone una sessione a singolo “writer” o la condivisione del token di sessione per più writer.
Come tutti i livelli di coerenza più deboli rispetto alla coerenza assoluta, le operazioni di scrittura 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. 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 per un token più recente), vengono restituiti i dati richiesti. Se la replica non contiene i dati per tale sessione, il client ritenta la richiesta in un'altra replica dell'area. Se necessario, il client ritenta l'operazione di lettura in aree disponibili aggiuntive fino a quando non vengono recuperati i dati per il token di sessione specificato.
Importante
Nella coerenza di sessione, l'utilizzo di un token di sessione da parte del client garantisce che i dati corrispondenti a una sessione precedente non vengano mai letti. Tuttavia, se il client usa un token di sessione meno recente e sono stati apportati aggiornamenti più recenti al database, la versione più recente dei dati verrà restituita nonostante venga usato un token di sessione meno recente. Il token di sessione viene usato come barriera di versione minima, ma non come versione specifica (forse cronologica) dei dati da recuperare dal database.
I token di sessione in Azure Cosmos DB sono associati alle partizioni, questo significa che sono associati esclusivamente a una partizione. Per assicurare che l'utente possa leggere le proprie operazioni di scrittura, usare il token di sessione generato più recentemente per gli elementi pertinenti.
Se il client non ha avviato un'operazione di scrittura in una partizione fisica, non contiene un token di sessione nella cache e le operazioni di lettura in tale partizione fisica si comportano come operazioni di lettura con coerenza finale. Analogamente, se il client viene ricreato, viene ricreata anche la relativa 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 del client a un'altra, il contenuto del token non deve essere modificato.
La coerenza di sessione è il livello di coerenza più usato sia per applicazioni a singola area che per quelle distribuite a livello globale. Fornisce latenze di scrittura, disponibilità e velocità effettiva di lettura paragonabili a quel livello di coerenza finale. Fornisce inoltre le garanzie di coerenza che soddisfano le esigenze delle applicazioni scritte per operare nel contesto di un utente. La figura seguente illustra la coerenza di sessione con le note musicali. Il "writer Stati Uniti occidentali 2" e il "lettore Stati Uniti orientali 2" usano la stessa sessione (Sessione A), quindi entrambi leggono gli stessi dati contemporaneamente. Mentre l'area "Australia orientale" usa la "Sessione B", quindi riceve i dati in un secondo momento ma nello stesso ordine delle operazioni di scrittura.
Coerenza con prefisso coerente
Come tutti i livelli di coerenza più deboli rispetto alla coerenza assoluta, le operazioni di scrittura 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 nessuna) nel documento Doc1 seguito dal documento Doc2, all'interno delle transazioni T1 e T2. Quando il client esegue un'operazione di lettura in una replica qualsiasi, l'utente vede "Doc1 v1 e Doc2 v1" o "Doc1 v2 e Doc2 v2" o nessun documento se la replica è in ritardo, ma mai "Doc1 v1 e Doc2 v2" o "Doc1 v2 e Doc2 v1" per la stessa operazione di lettura o di query.
La figura seguente illustra la coerenza del prefisso di coerenza con le note musicali. In tutte le aree le operazioni di lettura non visualizzano mai operazioni di scrittura non in ordine per un batch transazionale di operazioni di scrittura:
Coerenza finale
Come tutti i livelli di coerenza più deboli rispetto alla coerenza assoluta, le operazioni di scrittura vengono replicate in almeno tre repliche (in un set di quattro repliche) nell'area locale, con replica asincrona in tutte le altre aree.
Nella 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 assenti.
La coerenza finale è la forma più debole di coerenza perché un client può leggere valori meno recenti rispetto 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 in thread. 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 nel database non ci sono operazioni di scrittura, un'operazione di lettura con livello di coerenza finale, di sessione o con prefisso coerente è probabile che fornisca gli stessi risultati di un'operazione di lettura con livello di coerenza assoluto.
Se l'account è configurato con un livello di coerenza diverso dalla coerenza assoluta, è possibile conoscere la probabilità dei client di ottenere operazioni di lettura con coerenza assoluta per i carichi di lavoro. È possibile determinare questa probabilità esaminando la metrica del decadimento ristretto probabilistico (Probabilistic 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 offre informazioni dettagliate sulla frequenza con cui si ottiene una coerenza più elevata rispetto al livello di coerenza attualmente configurato per l'account Azure Cosmos DB. In altre parole, è possibile visualizzare la probabilità (misurata in millisecondi) di ottenere operazioni di lettura 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 uguale o inferiore ai 4 millisecondi.
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 di Azure Cosmos DB che si estendono su più aree e sono configurati con coerenza assoluta costituiscono 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 tra una delle due aree più lontane, più 10 millisecondi al 99° percentile. Il tempo di round trip di rete elevato tra le aree si tradurrà in una maggiore latenza 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 relativi alla latenza per il tempo di round trip tra due aree di Azure, ma pubblica le statistiche di latenza del round trip della rete di Azure. Per l'account Azure Cosmos DB, le latenze di replica vengono visualizzate nel 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 5.000 miglia (8.000 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 la coerenza assoluta e con decadimento ristretto, le operazioni di lettura vengono eseguite su due repliche in un set di quattro repliche (quorum di minoranza) per garantire la coerenza. Le coerenze di sessione, con prefisso coerente e finale eseguono operazioni di lettura a replica singola. Il risultato è che, per lo stesso numero di unità richiesta, la velocità effettiva di lettura per la coerenza assoluta e con decadimento ristretto è la metà rispetto agli 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 la coerenza assoluta, è necessario eseguire il commit delle modifiche in ogni area (a 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 | Operazioni di lettura del quorum | Operazioni di scrittura del 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 in UR/s delle operazioni di lettura a minoranza locale è due volte quello dei livelli di coerenza più deboli perché le operazioni di lettura vengono eseguite da due repliche per garantire la coerenza per i livelli di coerenza del decadimento forte e ristretto.
Livelli di coerenza e durabilità dei dati
All'interno di un ambiente di database distribuito a livello globale sussiste 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 conoscere il periodo massimo di aggiornamenti di dati recenti di cui l'applicazione è in grado di tollerare la perdita durante il ripristino dopo un'interruzione. Il periodo di tempo degli aggiornamenti che è possibile perdere è noto come obiettivo del punto di ripristino (RPO).
La tabella seguente 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 singola o multiple | Qualsiasi livello di coerenza | < 240 minuti |
| >1 | Singola area di scrittura | Sessione, Prefisso coerente, Finale | < 15 minuti |
| >1 | Singola area di scrittura | Decadimento ristretto | K e T |
| >1 | Singola area di scrittura | Assoluta | 0 |
| >1 | Più aree di scrittura | Sessione, Prefisso coerente, Finale | < 15 minuti |
| >1 | Più aree di scrittura | Decadimento ristretto | K e T |
K = numero di versioni "K" (vale a dire, aggiornamenti) di un elemento.
T = intervallo di tempo "T" dall'ultimo aggiornamento.
Per un account a singola area, il valore minimo di K e T è 10 operazioni di scrittura o 5 secondi. Per un account a più aree, 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 il decadimento ristretto.
Coerenza assoluta e più aree di scrittura
Gli account Azure Cosmos DB configurati con più aree di scrittura non possono essere configurati per la coerenza assoluta perché non è possibile che un sistema distribuito fornisca un RPO pari a zero e un RTO pari a zero. Inoltre, non ci sono vantaggi per la latenza di scrittura sull'uso di una coerenza assoluta con più aree di scrittura perché è necessario replicare ed eseguire il commit di un'operazione di scrittura in una qualsiasi area in tutte le aree configurate all'interno dell'account. Questo scenario comporta la stessa latenza di scrittura di un account a singola 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)