Níveis de coerência no Azure Cosmos DB

Os bancos de dados distribuídos que dependem da replicação para alta disponibilidade, baixa latência ou ambos devem balancear a consistência de leitura, a disponibilidade, a latência e a taxa de transferência, conforme definido pelo teorema PACELC. A linearizabilidade do modelo de consistência forte é o padrão para a programação de dados. No entanto, ele aumenta as latências de gravação porque os dados devem ser replicados e confirmados em grandes distâncias. A consistência forte também reduz a disponibilidade durante falhas porque os dados não podem replicar e confirmar 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 no mercado atualmente fornece 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:

• Forte
• Desatualização limitada
• Session
• Prefixo consistente
• Eventual

Para obter mais informações sobre o nível de consistência padrão, consulte configurar o nível de consistência padrão ou substituir o nível de consistência padrão.

Cada nível equilibra a disponibilidade e o desempenho. A imagem a seguir mostra os níveis de consistência como um espectro.

Níveis de consistência e APIs do Azure Cosmos DB

O Azure Cosmos DB dá suporte a APIs compatíveis com o protocolo de transmissão para bancos de dados populares, incluindo MongoDB, Apache Cassandra, Apache Gremlin e Armazenamento de Tabelas do Azure. Para a API para Gremlin ou Table, o Azure Cosmos DB usa o nível de consistência padrão configurado na conta. Para saber mais sobre o mapeamento de nível de consistência, consulte a API para mapeamento de consistência do Cassandra para o Apache Cassandra e a API para mapeamento de consistência do MongoDB para o MongoDB.

Escopo da consistência de leitura

A consistência de leitura se aplica a uma única operação de leitura 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 padrão

Configure o nível de consistência padrão em sua conta do Azure Cosmos DB a qualquer momento. O nível de coerê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. Quando você altera a consistência no nível da conta, reimplanta seus aplicativos e faz as modificações de código necessárias para aplicar essas alterações. Saiba mais sobre 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. Saiba mais no artigo sobre a substituição do nível de consistência padrão .

Tip

Sobrescrever o nível de consistência padrão aplica-se apenas para leituras no cliente SDK. Uma conta configurada para consistência forte por padrão ainda grava e replica dados de forma síncrona em todas as regiões da conta. Quando a instância do cliente do SDK ou a solicitação substitui essa consistência pela de sessão ou menos rigorosa, as leituras são realizadas usando uma única réplica. Para obter mais informações, consulte os níveis de consistência e a taxa de transferência.

Importante

Recrie qualquer instância do SDK depois de alterar o nível de consistência padrão reiniciando o aplicativo. Esta etapa garante que o SDK use o novo nível de consistência padrão.

Garantias associadas a níveis de coerência

O Azure Cosmos DB garante que 100% de 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 – Lógica Temporal de Ações – são fornecidas no repositório GitHub azure/azure-cosmos-tla .

A semântica dos cinco níveis de coerência é descrita nas seções a seguir.

Coerência forte

A coerência forte oferece uma garantia de linearizabilidade. Linearizabilidade significa atender solicitações simultaneamente. É garantido que as leituras retornem a versão mais recente confirmada de um item. Um cliente nunca vê uma escrita não comprometida ou parcial. Os usuários sempre terão a garantia de ler a última escrita confirmada.

O gráfico a seguir mostra forte consistência com notas musicais. Depois que os dados são gravados na região "Oeste dos EUA 2", ao ler os dados de outras regiões, você obtém o valor mais recente:

Quorum dinâmico

Sob circunstâncias normais, para uma conta com consistência forte, um registro é considerado confirmado quando todas as regiões reconhecem a replicação do registro. Se sua conta tiver três ou mais regiões, o sistema poderá reduzir o número de regiões necessárias para um quorum quando algumas regiões estiverem lentas ou não responderem. Isso ajuda a manter a consistência forte mesmo que algumas regiões tenham problemas. Nesse ponto, regiões inativas são removidas do conjunto de quórum de regiões para preservar a coerência forte. Elas só são adicionadas quando se tornam consistentes com outras regiões e funcionam conforme o esperado. O número de regiões que podem ser potencialmente retiradas do conjunto de quorum depende do número total de regiões. Por exemplo, em uma conta de três ou quatro regiões, a maioria é de duas ou três regiões, respectivamente, portanto, apenas uma região pode ser removida em ambos os casos. Para uma conta de cinco regiões, a maioria é três, portanto, até duas regiões não responsivas podem ser removidas. Essa funcionalidade é conhecida como "quorum dinâmico" e pode melhorar a disponibilidade de gravação e a latência de replicação para contas com três ou mais regiões.

Note

Quando as regiões são removidas do conjunto de quorum como parte do quorum dinâmico, essas regiões não podem mais processar leituras até serem re-adicionadas ao quorum.

Consistência de desatualizaçã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 em 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 coerência de desatualização limitada, o retardo de dados entre duas regiões quaisquer é sempre menor do que um valor especificado. A quantidade pode ser versões "K" (ou seja, "atualizações") de um item ou intervalos de tempo "T", o que for atingido primeiro. Em outras palavras, quando você escolhe 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) das leituras pode estar atrasado em relação às gravações.

A defasagem limitada é principalmente benéfica para contas que realizam gravações em uma única região, mas possuem duas ou mais regiões de leitura. Se a defasagem de dados em uma região (determinada por partição física) exceder o valor de defasagem configurado, as escritas para essa partição serão reduzidas até que a defasagem volte a estar dentro do limite superior configurado.

Para uma conta de região única, "Bounded Staleness" oferece as mesmas garantias de consistência de gravação que as consistências Sessão e Eventual. Com atualização com latência limitada, os dados são replicados para obter uma maioria local (três réplicas em um conjunto de quatro réplicas) dentro de uma única região.

Importante

Com a consistência de Desatualização Limitada, as verificações de desatualização são feitas somente 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.

Ao usar Desatualização Limitada, as leituras retornam os dados mais recentes disponíveis nessa região, lendo de duas réplicas disponíveis na região. Como as gravações em uma região sempre são replicadas em maioria local (três em cada quatro réplicas), a consulta de duas réplicas retorna os dados mais atualizados disponíveis na região.

Importante

Com a consistência de Desatualização Limitada, as leituras de uma região não primária podem não mostrar os dados mais recentes de todas as regiões. No entanto, eles sempre retornam os dados mais recentes disponíveis nessa região, dentro do limite de desatualização permitido.

A consistência limitada funciona melhor para aplicativos distribuídos globalmente que usam contas de gravação em uma única região com duas ou mais regiões, onde se deseja uma consistência próxima à forte entre regiões. Para contas de escrita em várias regiões, com duas ou mais regiões, os servidores de aplicativos devem encaminhar leituras e escritas para a mesma região onde os servidores de aplicativos estão hospedados. A obsolescência controlada em uma conta de gravações múltiplas é um antipadrão. Esse nível exige uma dependência do retardo da replicação entre as regiões, o que não deve fazer diferença se os dados são lidos na mesma região em que foram gravados.

O gráfico a seguir ilustra a consistência de desatualização limitada com 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" fazem a leitura do valor escrito com base no tempo de retardo máximo configurado ou no máximo de operações:

Coerência de sessão

Na consistência de sessão, em uma única sessão de cliente, as leituras têm garantias de respeitar o princípio de leitura-das-suas-escritas e a garantia de escrita-segue-leituras. Essa garantia pressupõe uma única sessão de "gravador" ou o compartilhamento do token de sessão para vários gravadores.

Como todos os níveis de consistência mais fracos do que Forte, 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 receberá 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 na qual a operação de leitura é emitida contiver dados para o token especificado (ou um token mais recente), os dados solicitados retornarão. Se a réplica não contém dados para essa sessão, o cliente repete a solicitação em outra réplica da região. Se necessário, o cliente tenta fazer novamente a leitura em regiões extras disponíveis até que os dados do token da sessão especificado sejam recuperados.

Importante

Na Consistência da Sessão, o cliente usa um token de sessão para garantir que ele nunca lê dados correspondentes a uma sessão mais antiga. Se o cliente usar um token de sessão antigo, mas os dados mais recentes estiverem disponíveis no banco de dados, o sistema retornará a versão mais recente. Mesmo com um token desatualizado, você sempre obtém os dados mais recentes. 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 à partição, o que significa que estão associados exclusivamente a uma partição. Para garantir que você possa ler suas gravações, use o token de sessão gerado por último para os itens relevantes.

Se o cliente não iniciou uma gravação em uma partição física, o cliente não possui um token de sessão no cache e as leituras nessa partição física se comportem como leituras com consistência eventual. Da mesma forma, se o cliente for recriado, o cache de tokens da sessão também será recriado. Aqui também, as operações de leitura seguem o mesmo comportamento da coerência eventual, até que as operações de gravação seguintes recompilem o cache de tokens da 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 globalmente e de região única. Fornece latências de gravação, disponibilidade e largura de banda de leitura comparáveis à coerência eventual. A coerência da sessão também fornece garantias de coerência que atendem às necessidades dos aplicativos desenvolvidos para operar no contexto de usuários. O gráfico a seguir ilustra a consistência da sessão com notas musicais. O "gravador do Oeste dos EUA 2" e o "Leitor do Leste dos EUA 2" estão usando a mesma sessão (Sessão A), portanto, ambos leem os mesmos dados ao mesmo tempo. A região "Leste da Austrália", por sua vez, usa a "sessão B" e recebe os dados mais tarde, mas na mesma ordem que as gravações.

Consistência de prefixo coerente

Como todos os níveis de consistência mais fracos do que Forte, 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 em todas as outras regiões.

No prefixo consistente, as atualizações feitas como gravações de documento único atingem coerência eventual.

Atualizações feitas como um lote dentro de uma transação são retornadas coerentes com a transação na qual foram confirmadas. As operações de gravação dentro de uma transação envolvendo vários documentos são sempre visíveis juntas.

Suponha que duas operações de gravação sejam realizadas de forma transacional (operações do tipo tudo ou nada) no documento Doc1, seguida 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 em atraso, 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 coerência de prefixo coerente 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 do que Forte, 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.

Na coerência eventual, o cliente emite solicitações de leitura contra qualquer uma das quatro réplicas na região especificada. Essa réplica pode estar atrasada e pode retornar dados obsoletos ou não.

A consistência eventual é a forma mais fraca de consistência porque um cliente pode ler valores mais antigos do que os valores lidos no passado. A consistência eventual é ideal quando o aplicativo não exige nenhuma garantia de ordenação. Exemplos incluem contagem de retweets, curtidas ou comentários não lidos. O gráfico a seguir ilustra a coerência eventual com notas musicais.

Garantias de consistência na prática

Na prática, muitas vezes você pode obter garantias de consistência mais fortes. Garantias de consistência para uma operação de leitura correspondem à atualização e ordenação do estado do banco de dados que você solicita. A consistência de leitura está vinculada à ordenação e propagação das operações de gravação e atualização.

Se não houver operações de gravação no banco de dados, uma operação de leitura com consistência eventual, de sessão ou de prefixo consistente poderá produzir os mesmos resultados de uma operação de leitura com o nível de consistência forte.

Se sua conta estiver configurada com um nível de consistência diferente do nível de consistência forte, você poderá determinar a probabilidade de que seus clientes obtenham leituras fortes e consistentes para suas cargas de trabalho. Descubra essa probabilidade examinando a métrica PBS (Probabilistically Bounded Staleness ). Essa métrica é exposta no portal do Azure. Para obter mais informações, consulte a métrica PBS (Monitor Probabilistically Bounded Staleness).

A desatualização limitada probabilisticamente mostra o quão eventual é a consistência eventual. Essa métrica fornece informações sobre a frequência com que você obtém consistência mais forte do que o nível de consistência atualmente configurado 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 gravação e leitura.

Níveis de coerência e latência

A latência de leitura para todos os níveis de consistência é garantida como menor que 10 milissegundos no 99º percentil. A latência média de leitura, no 50º percentil, normalmente é de 4 milissegundos ou menos.

A latência de gravação para todos os níveis de consistência é garantida como inferior a 10 milissegundos no 99º percentil. A latência média de gravação, no 50º percentil, geralmente é de 5 milissegundos ou menos. Contas do Azure Cosmos DB que abrangem várias regiões com consistência forte são uma exceção a essa garantia.

Latência de gravação e coerência forte

Para contas do Azure Cosmos DB configuradas com coerência forte com mais de uma região, a latência de gravação é igual a duas vezes o RTT (tempo de ida e volta) entre qualquer uma das duas regiões mais distantes, mais 10 milissegundos no 99º percentil. Um RTT de rede alto entre regiões aumenta a latência de solicitação do Azure Cosmos DB porque a consistência forte conclui uma operação somente depois de garantir que a operação seja confirmada em todas as regiões da conta.

A latência exata de RTT depende da distância de velocidade da luz e da topologia de rede do Azure. A rede do Azure não fornece SLAs (contratos de nível de serviço de latência) para RTT entre 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. Use o portal do Azure acessando 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

Consistência forte para contas com regiões que abrangem mais de 5.000 milhas (8.000 quilômetros) é bloqueada por padrão devido à alta latência de gravação. Para habilitar essa funcionalidade, entre em contato com o suporte.

Níveis de coerência e taxa de transferência

• Para desatualização forte e limitada, as leituras são feitas em relação a duas réplicas em um conjunto de quatro réplicas (quorum minoritário) para garantir garantias de consistência. Sessão, prefixo consistente e consistência eventual usam leituras de uma única réplica. Como resultado, para o mesmo número de unidades de solicitação, a taxa de transferência de leitura para desatualização forte e limitada é metade da dos outros níveis de consistência.

• Para um determinado tipo de operação de gravação, como inserir, substituir, upsert ou excluir, a taxa de transferência de gravação para unidades de solicitação é idêntica em todos os níveis de consistência. Para uma consistência forte, as alterações devem ser realizadas em todas as regiões (maioria global), enquanto que para os demais níveis de consistência, a maioria local (três réplicas em um conjunto de quatro réplicas) é usada.

Nível de Consistência	Leituras de Quorum	Escritas de Quorum
Forte	Minoria local	Maioria global
Desatualização Limitada	Minoria local	Maioria local
Sessão	Réplica única (usando o token de sessão)	Maioria local
Prefixo Consistente	Réplica única	Maioria local
Eventual	Réplica única	Maioria local

Note

O custo de RU para leituras locais minoritárias é o dobro dos níveis de consistência mais fracos porque as leituras são feitas de duas réplicas para assegurar consistência nos níveis de consistência forte e obsolescência limitada.

Níveis de consistência e durabilidade dos dados

Em um ambiente de banco de dados distribuído globalmente, o nível de consistência afeta diretamente a durabilidade dos dados durante uma interrupção em toda a região. Ao desenvolver um plano de continuidade de negócios, entenda o período máximo de atualizações de dados recentes que o aplicativo pode tolerar perder durante a recuperação de um evento disruptivo. O período de tempo das atualizações que podem ser perdidas é chamado de RPO (objetivo de ponto de recuperação).

Esta tabela mostra a relação entre modelos de consistência e durabilidade de dados durante uma interrupção em toda a região.

Regiões	Modo de replicação	Nível de coerência	RPO
1	Única ou várias regiões de gravação	Qualquer nível de consistência	< 240 minutos
>1	Região única de gravação	Sessão, Prefixo Consistente, Eventual	< 15 minutos
>1	Região única de gravação	Consistência com Limitação de Defasagem	K & t
>1	Região única de gravação	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	Consistência com Limitação de Defasagem	K & t

K = O número de versões K (atualizações) de um item.

T = O intervalo de tempo T desde a última atualização.

Para uma conta de região única, 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 (objetivo mínimo de ponto de recuperação) para dados ao usar Desatualização Limitada.

Coerência forte e várias regiões de escrita

Contas do Azure Cosmos DB com várias regiões de gravação não podem usar consistência forte porque um sistema distribuído não pode fornecer um RPO (objetivo de ponto de recuperação) de zero e um RTO (objetivo de tempo de recuperação) de zero. Além disso, a consistência forte com várias regiões de gravação não melhora a latência de gravação porque as gravações devem ser replicadas e confirmadas em todas as regiões da conta. Essa configuração resulta na mesma latência de gravação que uma conta de região de gravação única.

Mais leituras

Para saber mais sobre conceitos de coerência, leia os artigos a seguir:

• Especificações TLA⁺ de alto nível para os cinco níveis de consistência oferecidos pelo Azure Cosmos DB
• Consistência de dados replicados explicada usando o beisebol (vídeo) por Doug Terry
• Consistência de dados replicados explicada pelo beisebol (whitepaper) por Doug Terry
• Garantias de Sessão para Dados Replicados com Consistência Fraca
• Compensações de consistência no design moderno de sistemas de banco de dados distribuídos: CAP é apenas parte da história
• Desatualização limitada probabilística (PBS) para quorums parciais práticos
• Eventualmente consistente - revisitado

Conteúdo relacionado

• Configurar o nível de consistência padrão
• Sobrescrever o nível de consistência padrão
• Saiba mais sobre o SLA do Azure Cosmos DB.