Scegliere il livello di coerenza appropriato
Ognuno di questi modelli di coerenza può essere usato per scenari reali specifici. Ognuno prevede compromessi specifici a livello di disponibilità e prestazioni ed è supportato da contratti di servizio completi. Le semplici considerazioni seguenti consentono di fare la scelta giusta in molti scenari comuni.
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.
La coerenza di lettura si applica a una singola operazione di lettura il cui ambito si trova in una partizione logica. L'operazione di lettura può essere generata da un client remoto o da una stored procedure.
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.
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.
Coerenza con decadimento ristretto
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 T intervalli di tempo, a seconda di quale 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.
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 prevede una singola sessione "scrittore" o la condivisione del token di sessione per più scrittori.
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.
Coerenza con prefisso coerente
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 nei documenti Doc 1 e Doc 2, all'interno delle transazioni T1 e T2. Quando il client esegue una lettura in qualsiasi replica, l'utente visualizza "Doc 1 v1 e Doc 2 v1" o "Doc 1 v2 e Doc 2 v2," ma mai "Doc 1 v1 e Doc 2 v2" o "Doc 1 v2 e Doc 2 v1" per la stessa operazione di lettura o di query.
Coerenza finale
Nella coerenza finale non esiste alcuna garanzia di ordinamento per le letture. In assenza di ulteriori operazioni di scrittura, le repliche alla fine convergeranno.
La coerenza finale è la forma più debole di coerenza, perché un client può leggere i valori antecedenti a quelli letti prima. La coerenza finale è ideale nei casi in cui l'applicazione non richiede alcuna garanzia di ordinamento. Alcuni esempi includono il numero di retweet, like o commenti non in thread