Níveis de consistência no Azure Cosmos DB
APLICA-SE A: 
NoSQL MongoDB Cassandra Gremlin Tabela
Os bancos de dados distribuídos que dependem da replicação para alta disponibilidade, baixa latência, ou ambos, devem fazer uma compensação fundamental entre a consistência de leitura, disponibilidade, latência e taxa de transferência, conforme definido pelo teorema PACELC. A linearização do modelo de consistência forte é o padrão ouro de programabilidade de dados. Mas isso adiciona um preço alto de latências de gravação mais altas devido aos dados terem que replicar e confirmar em grandes distâncias. A consistência forte também pode sofrer com a disponibilidade reduzida (durante falhas) porque os dados não podem ser replicados e confirmados em todas as regiões. A consistência eventual oferece maior disponibilidade e melhor desempenho, mas é mais difícil programar aplicativos porque os dados podem não ser consistentes em todas as regiões.
A maioria dos bancos de dados NoSQL distribuídos disponíveis comercialmente disponíveis no mercado hoje fornecem apenas consistência forte e eventual. O Azure Cosmos DB oferece cinco níveis bem definidos. Do mais forte ao mais fraco, os níveis são:
Para obter mais informações sobre o nível de consistência padrão, consulte configurando o nível de consistência padrão ou substituir o nível de consistência padrão.
Cada nível fornece compensações de disponibilidade e desempenho. A imagem a seguir mostra os diferentes níveis de consistência como um espectro.
Níveis de consistência e APIs do Azure Cosmos DB
O Azure Cosmos DB fornece suporte nativo para APIs compatíveis com o protocolo wire para bancos de dados populares. Estes incluem MongoDB, Apache Cassandra, Apache Gremlin e Azure Table Storage. Na API para Gremlin ou Table, o nível de consistência padrão configurado na conta do Azure Cosmos DB é usado. Para obter detalhes sobre o mapeamento de nível de consistência entre o Apache Cassandra e o Azure Cosmos DB, consulte API para mapeamento de consistência Cassandra. Para obter detalhes sobre o mapeamento de nível de consistência entre o MongoDB e o Azure Cosmos DB, consulte API para mapeamento de consistência do MongoDB.
Âmbito da coerência de leitura
A consistência de leitura aplica-se a uma única operação de leitura com escopo dentro de uma partição lógica. Um cliente remoto, um procedimento armazenado ou um gatilho podem emitir a operação de leitura.
Configurar o nível de consistência predefinido
Você pode configurar o nível de consistência padrão em sua conta do Azure Cosmos DB a qualquer momento. O nível de consistência padrão configurado em sua conta se aplica a todos os bancos de dados e contêineres do Azure Cosmos DB nessa conta. Todas as leituras e consultas emitidas em um contêiner ou banco de dados usam o nível de consistência especificado por padrão. À medida que você altera a consistência do nível da conta, certifique-se de reimplantar seus aplicativos e fazer as modificações de código necessárias para aplicar essas alterações. Para saber mais, consulte como configurar o nível de consistência padrão. Você também pode substituir o nível de consistência padrão para uma solicitação específica, para saber mais, consulte como substituir o artigo de nível de consistência padrão.
Gorjeta
Substituir o nível de consistência padrão só se aplica a leituras dentro do cliente SDK. Uma conta configurada para consistência forte por padrão ainda gravará e replicará dados de forma síncrona para cada região da conta. Quando a instância ou solicitação do cliente SDK substitui isso por Session ou consistência mais fraca, as leituras serão executadas usando uma única réplica. Para obter mais informações, consulte Níveis de consistência e taxa de transferência.
Importante
É necessário recriar qualquer instância do SDK depois de alterar o nível de consistência padrão. Isso pode ser feito reiniciando o aplicativo. Isso garante que o SDK use o novo nível de consistência padrão.
Garantias associadas aos níveis de consistência
O Azure Cosmos DB garante que 100% das solicitações de leitura atendam à garantia de consistência para o nível de consistência escolhido. As definições precisas dos cinco níveis de consistência no Azure Cosmos DB usando a linguagem de especificação TLA+ são fornecidas no repositório GitHub azure-cosmos-tla.
A semântica dos cinco níveis de consistência é descrita nas seções a seguir.
Consistência forte
A consistência forte fornece uma garantia de transação atómica. A linearização refere-se ao atendimento simultâneo de solicitações. As leituras são garantidas para retornar a versão confirmada mais recente de um item. Um cliente nunca vê uma gravação não confirmada ou parcial. Os usuários têm sempre a garantia de ler a última gravação confirmada.
O gráfico a seguir ilustra a forte consistência com as notas musicais. Depois que os dados são gravados na região "Oeste dos EUA 2", quando você lê os dados de outras regiões, obtém o valor mais recente:
Quórum dinâmico
Em circunstâncias normais, para uma conta com forte consistência, uma gravação é considerada confirmada quando todas as regiões reconhecem que o registro foi replicado para ela. No entanto, para contas com 3 regiões ou mais (incluindo a região de escrita), o sistema pode "reduzir" o quórum de regiões para uma maioria global nos casos em que algumas regiões não respondem ou respondem lentamente. Nessa altura, as regiões que não respondem são retiradas do conjunto de regiões do quórum, a fim de preservar uma forte coerência. Eles só serão adicionados novamente quando forem consistentes com outras regiões e tiverem o desempenho esperado. O número de regiões que podem ser potencialmente retiradas do quórum definido dependerá do número total de regiões. Por exemplo, em uma conta de 3 ou 4 regiões, a maioria é de 2 ou 3 regiões, respectivamente, portanto, apenas 1 região pode ser removida em ambos os casos. Para uma conta de 5 regiões, a maioria é 3, portanto, até 2 regiões que não respondem podem ser removidas. Esse recurso é conhecido como "quórum dinâmico" e pode melhorar a disponibilidade de gravação e a latência de replicação para contas com 3 ou mais regiões.
Nota
Quando as regiões são removidas do quórum definido como parte do quórum dinâmico, essas regiões não podem mais servir leituras até serem adicionadas novamente ao quórum.
Consistência de estagnação limitada
Para contas de gravação de região única com duas ou mais regiões, os dados são replicados da região primária para todas as regiões secundárias (somente leitura). Para contas de gravação de várias regiões com duas ou mais regiões, os dados são replicados da região em que foram originalmente gravados para todas as outras regiões graváveis. Em ambos os cenários, embora não seja comum, ocasionalmente pode haver um atraso de replicação de uma região para outra.
Na consistência de atraso limitado, o atraso de dados entre quaisquer duas regiões é sempre menor do que uma quantidade especificada. A quantidade pode ser versões "K" (ou seja, "atualizações") de um item ou por intervalos de tempo "T", o que for atingido primeiro. Em outras palavras, quando você escolhe a obsolescência limitada, a "obsolescência" máxima dos dados em qualquer região pode ser configurada de duas maneiras:
- O número de versões (K) do item
- O intervalo de tempo (T) lido pode ficar atrás das gravações
O Bounded Staleness é benéfico principalmente para contas de escrita de uma única região com duas ou mais regiões. Se o atraso de dados em uma região (determinado por partição física) exceder o valor de atraso configurado, as gravações para essa partição serão limitadas até que o atraso esteja de volta dentro do limite superior configurado.
Para uma conta de uma única região, o Bounded Staleness fornece as mesmas garantias de consistência de gravação que Session e Eventual Consistência. Com o Bounded Staleness, os dados são replicados para uma maioria local (três réplicas em um conjunto de quatro réplicas) em uma única região.
Importante
Com a consistência do Bounded Staleness, as verificações de atraso são feitas apenas entre regiões e não dentro de uma região. Dentro de uma determinada região, os dados são sempre replicados para uma maioria local (três réplicas em um conjunto de quatro réplicas), independentemente do nível de consistência.
Leituras ao usar o Atraso Delimitado retorna os dados mais recentes disponíveis nessa região lendo duas réplicas disponíveis nessa região. Como as gravações dentro de uma região sempre são replicadas para uma maioria local (três em cada quatro réplicas), consultar duas réplicas retorna os dados mais atualizados disponíveis nessa região.
Importante
Com a consistência do Bounded Staleness, as leituras emitidas em uma região não primária podem não necessariamente retornar a versão mais recente dos dados globalmente, mas têm a garantia de retornar a versão mais recente dos dados nessa região, que estará dentro do limite de obsoletismo máximo globalmente.
O Bounded Staleness funciona melhor para aplicativos distribuídos globalmente usando contas de gravação de uma única região com duas ou mais regiões, onde é desejada uma consistência quase forte entre regiões. Para contas de gravação de várias regiões com duas ou mais regiões, os servidores de aplicativos devem direcionar leituras e gravações para a mesma região em que os servidores de aplicativos estão hospedados. Atraso delimitado em uma conta de várias gravações é um antipadrão. Esse nível exigiria uma dependência do atraso de replicação entre regiões, o que não importa se os dados são lidos da mesma região em que foram gravados.
O gráfico a seguir ilustra a consistência limitada das notas musicais. Depois que os dados são gravados na região "Oeste dos EUA 2", as regiões "Leste dos EUA 2" e "Leste da Austrália" leem o valor gravado com base no tempo de atraso máximo configurado ou nas operações máximas:
Consistência de sessão
Na consistência da sessão, dentro de uma única sessão de cliente, as leituras têm a garantia de honrar as garantias de leitura-sua-gravação e gravação-segue-leituras. Esta garantia pressupõe uma única sessão de "escritor" ou a partilha do token de sessão para vários escritores.
Como todos os níveis de consistência mais fracos que o Strong, as gravações são replicadas para um mínimo de três réplicas (em um conjunto de quatro réplicas) na região local, com replicação assíncrona para todas as outras regiões.
Após cada operação de gravação, o cliente recebe um token de sessão atualizado do servidor. O cliente armazena em cache os tokens e os envia ao servidor para operações de leitura em uma região especificada. Se a réplica contra a qual a operação de leitura é emitida contiver dados para o token especificado (ou um token mais recente), os dados solicitados serão retornados. Se a réplica não contiver dados para essa sessão, o cliente tentará novamente a solicitação em relação a outra réplica na região. Se necessário, o cliente tenta novamente a leitura em regiões adicionais disponíveis até que os dados do token de sessão especificado sejam recuperados.
Importante
Na Consistência da Sessão, o uso de um token de sessão pelo cliente garante que os dados correspondentes a uma sessão mais antiga nunca serão lidos. No entanto, se o cliente estiver usando um token de sessão mais antigo e atualizações mais recentes tiverem sido feitas no banco de dados, a versão mais recente dos dados será retornada, apesar de um token de sessão mais antigo ser usado. O Token de Sessão é usado como uma barreira de versão mínima, mas não como uma versão específica (possivelmente histórica) dos dados a serem recuperados do banco de dados.
Os Tokens de Sessão no Azure Cosmos DB são associados a partições, o que significa que estão exclusivamente associados a uma partição. Para garantir que você possa ler suas gravações, use o token de sessão que foi gerado pela última vez para o(s) item(ns) relevante(s).
Se o cliente não iniciou uma gravação em uma partição física, o cliente não contém um token de sessão em seu cache e as leituras para essa partição física se comportam como leituras com Consistência Eventual. Da mesma forma, se o cliente for recriado, seu cache de tokens de sessão também será recriado. Aqui também, as operações de leitura seguem o mesmo comportamento de Consistência Eventual até que as operações de gravação subsequentes reconstruam o cache de tokens de sessão do cliente.
Importante
Se os Tokens de Sessão estiverem sendo passados de uma instância de cliente para outra, o conteúdo do token não deverá ser modificado.
A consistência da sessão é o nível de consistência mais usado para aplicativos distribuídos em uma única região e globalmente. Ele fornece latências de gravação, disponibilidade e taxa de transferência de leitura comparáveis à de consistência eventual. A consistência da sessão também fornece as garantias de consistência que se adequam às necessidades dos aplicativos escritos para operar no contexto de um usuário. O gráfico a seguir ilustra a consistência da sessão com notas musicais. O "West US 2 writer" e o "East US 2 reader" estão usando a mesma sessão (Sessão A) para que ambos leiam os mesmos dados ao mesmo tempo. Considerando que a região "Austrália Leste" está usando "Sessão B", ela recebe dados mais tarde, mas na mesma ordem das gravações.
Consistência de prefixo consistente
Como todos os níveis de consistência mais fracos que o Strong, as gravações são replicadas para um mínimo de três réplicas (em um conjunto de quatro réplicas) na região local, com replicação assíncrona para todas as outras regiões.
No prefixo consistente, as atualizações feitas como gravações de um único documento veem consistência eventual.
As atualizações feitas como um lote dentro de uma transação são retornadas consistentes com a transação na qual foram confirmadas. As operações de gravação dentro de uma transação de vários documentos são sempre visíveis juntas.
Suponha que duas operações de gravação são realizadas transacionalmente (operações de tudo ou nada) no documento Doc1 seguido pelo documento Doc2, dentro das transações T1 e T2. Quando o cliente faz uma leitura em qualquer réplica, o usuário vê "Doc1 v1 e Doc2 v1" ou "Doc1 v2 e Doc2 v2" ou nenhum documento se a réplica estiver atrasada, mas nunca "Doc1 v1 e Doc2 v2" ou "Doc1 v2 e Doc2 v1" para a mesma operação de leitura ou consulta.
O gráfico a seguir ilustra a consistência do prefixo de consistência com notas musicais. Em todas as regiões, as leituras nunca veem gravações fora de ordem para um lote transacional de gravações:
Consistência eventual
Como todos os níveis de consistência mais fracos que o Strong, as gravações são replicadas para um mínimo de três réplicas (em um conjunto de quatro réplicas) na região local, com replicação assíncrona para todas as outras regiões.
Em Consistência eventual, o cliente emite solicitações de leitura em qualquer uma das quatro réplicas na região especificada. Essa réplica pode estar atrasada e pode retornar dados obsoletos ou inexistentes.
A consistência eventual é a forma mais fraca de consistência porque um cliente pode ler os valores que são mais antigos do que os que leu no passado. A consistência eventual é ideal quando a aplicação não exige garantias de ordenação. Os exemplos incluem a contagem de Retweets, Gostos ou comentários não encadeados. O gráfico a seguir ilustra a eventual consistência com as notas musicais.
Garantias de coerência na prática
Na prática, muitas vezes você pode obter garantias de consistência mais fortes. As garantias de consistência para uma operação de leitura correspondem à atualização e à ordenação do estado do banco de dados solicitado. A consistência de leitura está ligada à ordenação e propagação das operações de gravação/atualização.
Se não houver operações de gravação no banco de dados, uma operação de leitura com níveis de consistência de prefixo eventual, de sessão ou consistentes provavelmente produzirá os mesmos resultados que uma operação de leitura com nível de consistência forte.
Se sua conta estiver configurada com um nível de consistência diferente da consistência forte, você poderá descobrir a probabilidade de que seus clientes obtenham leituras fortes e consistentes para suas cargas de trabalho. Você pode descobrir essa probabilidade observando a métrica Probabilistically Bounded Staleness (PBS). Essa métrica é exposta no portal do Azure, para saber mais, consulte Monitorar a métrica PBS (Probabilistically Bounded Staleness).
A obsolescência probabilisticamente limitada mostra quão eventual é a sua eventual consistência. Essa métrica fornece uma visão sobre com que frequência você pode obter uma consistência mais forte do que o nível de consistência que você configurou atualmente em sua conta do Azure Cosmos DB. Em outras palavras, você pode ver a probabilidade (medida em milissegundos) de obter leituras consistentes para uma combinação de regiões de escrita e leitura.
Níveis de consistência e latência
A latência de leitura para todos os níveis de consistência é sempre garantida como inferior a 10 milissegundos no percentil 99. A latência média de leitura, no percentil 50, é tipicamente de 4 milissegundos ou menos.
A latência de gravação para todos os níveis de consistência é sempre garantida como inferior a 10 milissegundos no percentil 99. A latência média de gravação, no percentil 50, é geralmente de 5 milissegundos ou menos. As contas do Azure Cosmos DB que abrangem várias regiões e são configuradas com forte consistência são uma exceção a essa garantia.
Latência de gravação e forte consistência
Para contas do Azure Cosmos DB configuradas com forte consistência com mais de uma região, a latência de gravação é igual a duas vezes o tempo de ida e volta (RTT) entre qualquer uma das duas regiões mais distantes, mais 10 milissegundos no percentil 99. O RTT de alta rede entre as regiões se traduzirá em latência mais alta para solicitações do Azure Cosmos DB, uma vez que uma consistência forte conclui uma operação somente depois de garantir que ela foi confirmada para todas as regiões de uma conta.
A latência exata do RTT é uma função da velocidade da distância da luz e da topologia de rede do Azure. A rede do Azure não fornece SLAs de latência para o RTT entre duas regiões do Azure, mas publica estatísticas de latência de ida e volta da rede do Azure. Para sua conta do Azure Cosmos DB, as latências de replicação são exibidas no portal do Azure. Você pode usar o portal do Azure indo para a seção Métricas e selecionando a opção Consistência. Usando o portal do Azure, você pode monitorar as latências de replicação entre várias regiões associadas à sua conta do Azure Cosmos DB.
Importante
Forte consistência para contas com regiões que abrangem mais de 5000 milhas (8000 quilômetros) é bloqueada por padrão devido à alta latência de gravação. Para habilitar esse recurso, entre em contato com o suporte.
Níveis de consistência e taxa de transferência
Para uma obsolescência forte e limitada, as leituras são feitas contra duas réplicas em um conjunto de quatro réplicas (quórum minoritário) para fornecer garantias de consistência. Sessão, prefixo consistente e eventuais leituras de réplica única. O resultado é que, para o mesmo número de unidades de solicitação, a taxa de transferência de leitura para obsoletos fortes e limitados é metade dos outros níveis de consistência.
Para um determinado tipo de operação de gravação, como inserir, substituir, atualizar e excluir, a taxa de transferência de gravação para unidades de solicitação é idêntica para todos os níveis de consistência. Para uma forte consistência, as alterações precisam ser comprometidas em todas as regiões (maioria global), enquanto para todos os outros níveis de consistência, a maioria local (três réplicas em um conjunto de quatro réplicas) está sendo usada.
| Nível de consistência | Quórum Lê | Quórum grava |
|---|---|---|
| Forte | Minoria local | Maioria Global |
| Estagnação limitada | Minoria local | Maioria local |
| Sessão | Réplica única (usando token de sessão) | Maioria local |
| Prefixo consistente | Réplica única | Maioria local |
| Eventual | Réplica única | Maioria local |
Nota
O custo das RUs de leituras para leituras de Minorias Locais é o dobro dos níveis de consistência mais fracos, porque as leituras são feitas a partir de duas réplicas para fornecer garantias de consistência para os níveis de consistência Strong e Bounded Staleness.
Níveis de consistência e durabilidade dos dados
Em um ambiente de banco de dados distribuído globalmente, há uma relação direta entre o nível de consistência e a durabilidade dos dados na presença de uma interrupção em toda a região. Ao desenvolver seu plano de continuidade de negócios, você precisa entender o período máximo de atualizações de dados recentes que o aplicativo pode tolerar perder ao se recuperar após um evento de interrupção. O período de tempo das atualizações que você pode perder é conhecido como RPO (Recovery Point Objetive, objetivo de ponto de recuperação).
Esta tabela define a relação entre o modelo de consistência e a durabilidade dos dados na presença de uma interrupção em toda a região.
| Região(ões) | Modo de replicação | Nível de consistência | RPO |
|---|---|---|---|
| 1 | Regiões de gravação únicas ou múltiplas | Qualquer nível de consistência | < 240 Minutos |
| >1 | Região de gravação única | Sessão, Prefixo Consistente, Eventual | < 15 minutos |
| >1 | Região de gravação única | Ecletismo | K & T |
| >1 | Região de gravação única | Forte | 0 |
| >1 | Várias regiões de gravação | Sessão, Prefixo Consistente, Eventual | < 15 minutos |
| >1 | Várias regiões de gravação | Ecletismo | K & T |
K = O número de versões "K" (isto é, atualizações) de um item.
T = O intervalo de tempo "T" desde a última atualização.
Para uma conta de uma única região, o valor mínimo de K e T é de 10 operações de gravação ou 5 segundos. Para contas de várias regiões, o valor mínimo de K e T é de 100.000 operações de gravação ou 300 segundos. Esse valor define o RPO mínimo para dados ao usar Limited Staleness.
Forte consistência e várias regiões de gravação
As contas do Azure Cosmos DB configuradas com várias regiões de gravação não podem ser configuradas para uma consistência forte, pois não é possível para um sistema distribuído fornecer um RPO de zero e um RTO de zero. Além disso, não há benefícios de latência de gravação no uso de consistência forte com várias regiões de gravação, pois uma gravação em qualquer região deve ser replicada e confirmada para todas as regiões configuradas na conta. Esse cenário resulta na mesma latência de gravação que uma única conta de região de gravação.
Ler mais
Para saber mais sobre conceitos de consistência, leia os seguintes artigos:
- Especificações TLA+ de alto nível para os cinco níveis de consistência oferecidos pelo Azure Cosmos DB
- Consistência de dados replicada explicada através do beisebol (vídeo) por Doug Terry
- Consistência de dados replicados explicada através do beisebol (whitepaper) por Doug Terry
- Garantias de sessão para dados replicados fracamente consistentes
- Compensações de consistência no design moderno de sistemas de banco de dados distribuídos: CAP é apenas parte da história
- Probabilistic Bounded Staleness (PBS) para quóruns parciais práticos
- Eventualmente Consistente - Revisitado