Níveis de consistência no Azure Cosmos DB

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

As bases de dados distribuídas que dependem da replicação para elevada disponibilidade, baixa latência ou ambas têm de fazer uma troca fundamental entre a consistência de leitura, a disponibilidade, a latência e o débito, conforme definido pelo teorema PACELC. A linearizabilidade do modelo de consistência forte é o padrão gold da programação de dados. No entanto, adiciona um preço elevado a partir de latências de escrita mais elevadas devido aos dados terem de ser replicados e consolidados em grandes distâncias. A consistência forte também pode sofrer de uma disponibilidade reduzida (durante falhas) porque os dados não podem ser replicados e consolidados em todas as regiões. A consistência eventual oferece uma maior disponibilidade e um melhor desempenho, mas é mais difícil programar aplicações porque os dados podem não ser completamente consistentes em todas as regiões.

A maioria das bases de dados NoSQL distribuídas disponíveis atualmente no mercado fornecem apenas consistência forte e eventual. O Azure Cosmos DB oferece cinco níveis bem definidos. Dos mais fortes aos mais fracos, os níveis são:

Para obter mais informações sobre o nível de consistência predefinido, veja Configurar o nível de consistência predefinido ou substituir o nível de consistência predefinido.

Cada nível fornece compromissos de disponibilidade e desempenho. A imagem seguinte mostra os diferentes níveis de consistência como um espetro.

Consistência como um espetro

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

O Azure Cosmos DB fornece suporte nativo para APIs compatíveis com protocolos de transmissão para bases de dados populares. Estes incluem MongoDB, Apache Cassandra, Apache Gremlin e Armazenamento de Tabelas do Azure. Ao utilizar a API para Gremlin ou Tabela, é utilizado o nível de consistência predefinido configurado na conta do Azure Cosmos DB. Para obter detalhes sobre o mapeamento ao nível de consistência entre o Apache Cassandra e o Azure Cosmos DB, veja API for Cassandra consistency mapping (Mapeamento de consistência da API para Cassandra). Para obter detalhes sobre o mapeamento do nível de consistência entre o MongoDB e o Azure Cosmos DB, veja API for MongoDB consistency mapping (Mapeamento de consistência da API para MongoDB).

Âmbito da consistência de leitura

A consistência de leitura aplica-se a uma única operação de leitura no âmbito de uma partição lógica. A operação de leitura pode ser emitida por um cliente remoto ou por um procedimento armazenado.

Configurar o nível de consistência predefinido

Pode configurar o nível de consistência predefinido na sua conta do Azure Cosmos DB em qualquer altura. O nível de consistência predefinido configurado na sua conta aplica-se a todas as bases de dados e contentores do Azure Cosmos DB nessa conta. Por predefinição, todas as leituras e consultas emitidas num contentor ou numa base de dados utilizam o nível de consistência especificado. Para saber mais, veja como configurar o nível de consistência predefinido. Também pode substituir o nível de consistência predefinido de um pedido específico. Para saber mais, veja como Substituir o artigo de nível de consistência predefinido .

Dica

Substituir o nível de consistência predefinido aplica-se apenas a leituras no cliente do SDK. Uma conta configurada para consistência forte por predefinição continuará a escrever e a replicar dados de forma síncrona para todas as regiões da conta. Quando a instância de cliente do SDK ou o pedido substitui esta situação por Sessão ou consistência mais fraca, as leituras serão realizadas com uma única réplica. Para obter mais informações, veja Níveis de consistência e débito.

Importante

É necessário recriar qualquer instância do SDK depois de alterar o nível de consistência predefinido. Isto pode ser feito ao reiniciar a aplicação. Isto garante que o SDK utiliza o novo nível de consistência predefinido.

Garantias associadas a níveis de consistência

O Azure Cosmos DB garante que 100% dos pedidos de leitura cumprem a 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 com a linguagem de especificação TLA+ são fornecidas no repositório do GitHub azure-cosmos-tla .

A semântica dos cinco níveis de consistência é descrita nas secções seguintes.

Consistência forte

A consistência forte fornece uma garantia de transação atómica. A linearizabilidade refere-se à entrega de pedidos em simultâneo. É garantido que as leituras devolvem a versão consolidada mais recente de um item. Um cliente nunca vê uma escrita não consolidada ou parcial. Os utilizadores têm sempre a garantia de ler a escrita consolidada mais recente.

O gráfico seguinte ilustra a forte consistência com notas musicais. Depois de os dados terem sido escritos na região "E.U.A. Oeste 2", quando lê os dados de outras regiões, obtém o valor mais recente:

Ilustração de um nível de consistência forte

Consistência de estagnação limitada

Para contas de escrita 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 (só de leitura). Para contas de escrita de várias regiões com duas ou mais regiões, os dados são replicados a partir da região onde foram originalmente escritos em todas as outras regiões graváveis. Em ambos os cenários, embora não seja comum, pode haver ocasionalmente um atraso de replicação de uma região para outra.

Na consistência de estagnação limitada, os dados entre duas regiões não serão atrasados em mais do que versões "K" (ou seja, "atualizações") de um item ou por intervalos de tempo "T", o que for atingido primeiro. Por outras palavras, quando escolhe a estagnação limitada, a "estagnação" máxima dos dados em qualquer região pode ser configurada de duas formas:

  • O número de versões (K) do item
  • As leituras do intervalo de tempo (T) podem ficar para trás das escritas

A Estagnação Limitada é benéfica principalmente para contas de escrita de região única com duas ou mais regiões. Se o atraso dos dados numa região (determinado por partição física) exceder o valor de estagnação configurado, as escritas para essa partição serão limitadas até que a estagnação esteja novamente dentro do limite superior configurado.

Para uma conta de região única, a Estagnação Limitada fornece as mesmas garantias de consistência de escrita que a Consistência De Sessão e Eventual, com os dados a serem replicados para uma maioria local (três réplicas num conjunto de réplicas de quatro) numa única região.

Importante

Com a consistência da Estagnação Limitada, as verificações de estagnação são efetuadas apenas entre regiões e não numa região. Numa determinada região, os dados são sempre replicados para uma maioria local (três réplicas num conjunto de réplicas) independentemente do nível de consistência.

As leituras ao utilizar a Estagnação Limitada devolverão os dados mais recentes disponíveis nessa região ao ler a partir de duas réplicas disponíveis nessa região. Uma vez que as escritas numa região são sempre replicadas para uma maioria local (3 em 4 réplicas), consultar duas réplicas devolverá os dados mais atualizados disponíveis nessa região.

Importante

Com a consistência de Estagnação Limitada, as leituras emitidas numa região não primária podem não devolver necessariamente a versão mais recente dos dados globalmente, mas têm a garantia de devolver a versão mais recente dos dados nessa região, que estará dentro do limite máximo de estagnação a nível global.

A Estagnação Limitada funciona melhor para aplicações distribuídas globalmente através de contas de escrita de uma única região com duas ou mais regiões, onde é desejada uma consistência quase forte entre regiões. Para contas de escrita de várias regiões com duas ou mais regiões, os servidores de aplicações devem direcionar leituras e escritas para a mesma região na qual os servidores de aplicações estão alojados. Assim, a Estagnação Limitada numa conta de várias escritas é um anti-padrão, uma vez que exigiria uma dependência do desfasamento da replicação entre regiões, o que não deve importar se os dados são lidos a partir da mesma região em que foram escritos.

O gráfico seguinte ilustra a consistência de estagnação limitada com notas musicais. Depois de os dados terem sido escritos na região "E.U.A. Oeste 2", as regiões "E.U.A. Leste 2" e "Leste da Austrália" leem o valor escrito com base no tempo de atraso máximo configurado ou nas operações máximas:

Ilustração do nível de consistência de estagnação limitada

Consistência de sessão

Na consistência da sessão, numa única sessão de cliente, é garantido que as leituras respeitam as garantias de leitura-as-suas-escritas e de escrita-segue-leituras. Isto pressupõe uma única sessão de "escritor" ou partilha do token de sessão para vários escritores.

Como todos os níveis de consistência mais fracos do que Forte, as escritas são replicadas para um mínimo de três réplicas (num 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 escrita, o cliente recebe um Token de Sessão atualizado do servidor. Estes tokens são colocados em cache pelo cliente e enviados para o servidor para operações de leitura numa região especificada. Se a réplica em relação à qual a operação de leitura é emitida contiver dados para o token especificado (ou um token mais recente), os dados pedidos são devolvidos. Se a réplica não contiver dados para essa sessão, o cliente repetirá o pedido relativamente a outra réplica na região. Se necessário, o cliente repetirá a leitura em regiões disponíveis adicionais até que os dados do token de sessão especificado sejam obtidos.

Importante

Em Consistência de Sessão, a utilização do cliente de um token de sessão garante que os dados correspondentes a uma sessão mais antiga nunca serão lidos. No entanto, se o cliente estiver a utilizar um token de sessão mais antigo e tiverem sido feitas atualizações mais recentes à base de dados, a versão mais recente dos dados será devolvida apesar de ser utilizado um token de sessão mais antigo. O Token de Sessão é utilizado como uma barreira de versão mínima, mas não como uma versão específica (possivelmente histórica) dos dados a obter da base de dados.

Se o cliente não iniciou uma escrita numa partição física, não conterá um token de sessão na cache e as leituras para essa partição física irão comportar-se como leituras com Consistência Eventual. Da mesma forma, se o cliente for recriado, a cache de tokens de sessão também será recriada. Também aqui, as operações de leitura seguirão o mesmo comportamento que a Consistência Eventual até que as operações de escrita subsequentes reconstruam a cache de tokens de sessão do cliente.

Importante

Se os Tokens de Sessão estiverem a ser transmitidos de uma instância de cliente para outra, o conteúdo do token não deve ser modificado.

A consistência da sessão é o nível de consistência mais utilizado tanto para uma única região como para aplicações distribuídas globalmente. Fornece latências de escrita, disponibilidade e débito de leitura comparáveis às de consistência eventual, mas também fornece as garantias de consistência que se adequam às necessidades das aplicações escritas para operar no contexto de um utilizador. O gráfico seguinte ilustra a consistência da sessão com notas musicais. O "escritor E.U.A. Oeste 2" e o "leitor E.U.A. Leste 2" estão a utilizar a mesma sessão (Sessão A) para que ambos leiam os mesmos dados ao mesmo tempo. Enquanto a região "Leste da Austrália" está a utilizar a "Sessão B", recebe dados mais tarde, mas pela mesma ordem que as escritas.

Ilustração do nível de consistência da sessão

Consistência de prefixo consistente

Como todos os níveis de consistência mais fracos do que Strong, as escritas são replicadas para um mínimo de três réplicas (num 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 efetuadas como escritas de documento único veem a consistência eventual. Atualizações efetuadas como um lote numa transação, são devolvidos consistentes com a transação em que foram consolidadas. As operações de escrita numa transação de vários documentos são sempre visíveis em conjunto.

Suponha que duas operações de escrita são efetuadas de forma transacional (todas ou nada) no documento Doc1, seguido do documento Doc2, nas transações T1 e T2. Quando o cliente faz uma leitura em qualquer réplica, o utilizador verá "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 seguinte ilustra a consistência do prefixo de consistência com notas musicais. Em todas as regiões, as leituras nunca veem escritas fora de ordem para um lote transacional de escritas:

Ilustração do prefixo consistente

Consistência eventual

Como todos os níveis de consistência mais fracos do que Strong, as escritas são replicadas para um mínimo de três réplicas (num 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 emitirá pedidos de leitura em relação a qualquer uma das quatro réplicas na região especificada. Esta réplica pode estar atrasada e pode devolver dados obsoletos ou não.

A consistência eventual é a forma de consistência mais fraca porque um cliente pode ler os valores mais antigos do que os que tinha lido anteriormente. A consistência eventual é ideal onde a aplicação não necessita de garantias de ordenação. Os exemplos incluem a contagem de Retweets, Gostos ou comentários não por tópicos. O gráfico seguinte ilustra a consistência eventual com notas musicais.

viIllustração de consistência eventual

Garantias de consistência na prática

Na prática, pode obter muitas vezes garantias de consistência mais fortes. As garantias de consistência para uma operação de leitura correspondem à frescura e ordenação do estado da base de dados que pedir. A consistência de leitura está associada à ordenação e propagação das operações de escrita/atualização.

Se não existirem operações de escrita na base de dados, é provável que uma operação de leitura com níveis de consistência eventual, de sessão ou de prefixo consistente produza os mesmos resultados que uma operação de leitura com um nível de consistência forte.

Se a sua conta do Azure Cosmos DB estiver configurada com um nível de consistência diferente da consistência forte, pode descobrir a probabilidade de os seus clientes obterem leituras fortes e consistentes para as suas cargas de trabalho ao observar a métrica Desajuste Limitada Probabilisticamente (PBS). Esta métrica é exposta no portal do Azure, para saber mais, veja Monitorizar a métrica De Estagnação Limitada Probabilisticamente (PBS).

A estagnação limitada probabilística mostra como a consistência eventual é eventual. Esta métrica fornece uma visão da frequência com que pode obter uma consistência mais forte do que o nível de consistência que configurou atualmente na sua conta do Azure Cosmos DB. Por outras palavras, pode ver a probabilidade (medida em milissegundos) de obter leituras fortemente 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, é normalmente de 4 milissegundos ou menos.

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

Latência de escrita e Consistência forte

Para contas do Azure Cosmos DB configuradas com consistência forte com mais de uma região, a latência de escrita é 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 rede elevada entre as regiões irá traduzir-se numa latência mais elevada para pedidos do Azure Cosmos DB, uma vez que a consistência forte só conclui uma operação depois de garantir que foi consolidada em todas as regiões dentro de uma conta.

A latência RTT exata é uma função de distância de velocidade de luz e a 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, no entanto, publica estatísticas de latência de ida e volta da rede do Azure. Para a sua conta do Azure Cosmos DB, as latências de replicação são apresentadas no portal do Azure. Pode utilizar o portal do Azure (aceda ao painel Métricas, selecione Separador Consistência) para monitorizar as latências de replicação entre várias regiões associadas à sua conta do Azure Cosmos DB.

Importante

A forte consistência das contas com regiões que se estendem por mais de 8000 quilómetros está bloqueada por predefinição devido à latência de escrita elevada. Para ativar esta capacidade, contacte o suporte.

Níveis de consistência e débito

  • Para uma estagnação forte e limitada, as leituras são feitas em relação a duas réplicas num conjunto de réplicas (quórum minoritário) para fornecer garantias de consistência. Sessão, prefixo consistente e eventual efetuar leituras de réplica única. O resultado é que, para o mesmo número de unidades de pedido, o débito de leitura para estagnação forte e limitada é metade dos outros níveis de consistência.

  • Para um determinado tipo de operação de escrita, como inserir, substituir, upsert e eliminar, o débito de escrita para unidades de pedido é idêntico para todos os níveis de consistência. Para uma consistência forte, as alterações têm de ser consolidadas em todas as regiões (maioria global) enquanto para todos os outros níveis de consistência, a maioria local (três réplicas num conjunto de réplicas) está a ser utilizada.

Nível de Consistência Leituras de Quórum Escritas de Quórum
Forte Minoria Local Maioria Global
Estagnação Delimitada Minoria Local Maioria Local
Sessão Réplica Única (com o token de sessão) Maioria Local
Prefixo Consistente Réplica Única Maioria Local
Eventual Réplica Única Maioria Local

Nota

O custo das leituras de RU/s para leituras da Minoria Local é duas vezes superior ao 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 Estagnação Forte e Limitada.

Níveis de consistência e durabilidade de dados

Num ambiente de base de dados distribuído globalmente, existe uma relação direta entre o nível de consistência e a durabilidade dos dados na presença de uma indisponibilidade em toda a região. À medida que desenvolve o seu plano de continuidade de negócio, tem de compreender o período máximo de atualizações de dados recentes que a aplicação pode tolerar perder ao recuperar após um evento disruptivo. O período de tempo das atualizações que pode perder é conhecido como objetivo de ponto de recuperação (RPO).

A tabela abaixo define a relação entre o modelo de consistência e a durabilidade dos dados na presença de uma indisponibilidade em toda a região.

Regiões Modo de replicação Nível de consistência RPO
1 Regiões de escrita única ou múltipla Qualquer Nível de Consistência < 240 Minutos
>1 Região de escrita única Sessão, Prefixo Consistente, Eventual < 15 minutos
>1 Região de escrita única Estagnação Limitada K&T
>1 Região de escrita única Forte 0
>1 Várias regiões de escrita Sessão, Prefixo Consistente, Eventual < 15 minutos
>1 Várias regiões de escrita Estagnação Limitada K&T

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

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

Para uma única conta de região, o valor mínimo de K e T é 10 operações de escrita ou 5 segundos. Para contas de várias regiões, o valor mínimo de K e T é 100 000 operações de escrita ou 300 segundos. Isto define o RPO mínimo para os dados ao utilizar a Estagnação Limitada.

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

As contas do Azure Cosmos DB configuradas com várias regiões de escrita não podem ser configuradas para uma consistência forte, uma vez que não é possível que um sistema distribuído forneça um RPO de zero e um RTO de zero. Além disso, não existem benefícios de latência de escrita na utilização de uma consistência forte com várias regiões de escrita, uma vez que uma escrita em qualquer região tem de ser replicada e consolidada em todas as regiões configuradas na conta. Isto resulta na mesma latência de escrita que uma única conta de região de escrita.

Leitura adicional

Para saber mais sobre os conceitos de consistência, leia os seguintes artigos:

Passos seguintes

Para saber mais sobre os níveis de consistência no Azure Cosmos DB, leia os seguintes artigos: