Níveis de coerência no Azure Cosmos DB
APLICA-SE AO: 
NoSQL MongoDB Cassandra Gremlin Table
Bancos de dados distribuídos que dependem de replicação para alta disponibilidade, baixa latência ou ambos, devem realizar uma compensação fundamental entre a coerência de leitura, a disponibilidade, a latência e a taxa de transferência, conforme definido pelo teorema PACELC. A linearizabilidade do modelo de coerência forte é o padrão ouro de programação de dados. Mas ela adiciona um preço alto de latências de gravação maiores, pois os dados devem ser replicados e confirmados em grandes distâncias. A coerência forte também pode ter a disponibilidade reduzida (durante as falhas), porque os dados não podem ser replicados nem confirmados em todas as regiões. A coerência eventual oferece maior disponibilidade e melhor desempenho, mas é mais difícil programar aplicativos, pois os dados podem não ser coerentes em todas as regiões.
Atualmente, a maioria dos bancos de dados NoSQL distribuídos comercialmente disponíveis no mercado fornece uma coerê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 configurar 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 desempenho e disponibilidade. A imagem a seguir mostra diferentes níveis de coerência como um espectro.
Níveis de consistência e APIs do Azure Cosmos DB
O Azure Cosmos DB oferece suporte nativo para transmissão compatível com o protocolo de APIs para bancos de dados populares. Isso inclui armazenamento MongoDB, Apache Cassandra, Apache Gremlin e Armazenamento de Tabelas do Azure. Na API para Gremlin ou Tabelas, o nível de coerência padrão configurado na conta do Azure Cosmos DB é usado. Para obter detalhes sobre o mapeamento de nível de coerência entre o Apache Cassandra e o Azure Cosmos DB, consulte o Mapeamento de coerência da API para Cassandra. Para obter detalhes sobre o mapeamento de nível de coerência entre o MongoDB e o Azure Cosmos DB, consulte o Mapeamento de coerência da API para MongoDB.
Escopo da coerência de leitura
A consistência de leitura se aplica a uma única operação de leitura no escopo dentro de uma partição lógica. Um cliente remoto ou um procedimento armazenado pode emitir a operação de leitura.
Configurar o nível de consistência padrão
Você pode configurar o nível de coerê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. À 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 obter mais informações, consulte configurar o nível de consistência padrão. Você também pode substituir o nível de coerência padrão para uma solicitação específica. Para saber mais, confira o artigo sobre como Substituir o nível de coerência padrão.
Dica
A substituição do nível de consistência padrão aplica-se somente a leituras dentro do cliente do SDK. Uma conta configurada para consistência forte por padrão ainda gravará e replicará dados de modo síncrono em todas as regiões da conta. Quando a instância ou solicitação do cliente do SDK substituir essa opção por Sessão ou por uma consistência mais fraca, as leituras serão executadas com uma só 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 coerência padrão. Isso pode ser feito ao reiniciar o aplicativo. Isso garante que o SDK use o novo nível de coerência padrão.
Garantias associadas a níveis de coerência
O Azure Cosmos DB garante que 100% de solicitações de leitura atendam a garantia de coerência para o nível de consistência que você escolher. As definições precisas dos cinco níveis de coerência no Azure Cosmos DB usando 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 coerência é descrita nas seções a seguir.
Coerência forte
A coerência forte oferece uma garantia de transação atômica. Transação atômica se refere ao fornecimento de solicitações simultaneamente. As leituras são garantidas para retornar a versão mais recente de um item. Um cliente nunca vê uma gravação não comprometida ou parcial. Os usuários sempre terão a garantia de ler a última gravação confirmada.
O gráfico a seguir ilustra a coerência forte 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:
Coerê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 de várias regiões com duas ou mais regiões, os dados são replicados da região em que foram originalmente gravados em 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. O volume podem ser versões "K" (ou seja, "atualizações") de um item ou por intervalos de tempo "T", o que for alcançado primeiro. Em outras palavras, quando você escolhe desatualização limitada, o máximo de “desatualização” dos dados em qualquer região pode ser configurado de duas maneiras:
- O número de versões (K) do item
- O intervalo de tempo (T) pelo qual as leituras podem ficar atrás das gravações
A desatualização limitada é benéfica principalmente para contas de gravação de região única com duas ou mais regiões. Se o retardo de dados em uma região (determinado por partição física) exceder o valor de desatualização configurado, as gravações dessa partição serão limitadas até que a desatualização volte ao limite superior configurado.
Para uma conta de região única, a desatualização limitada fornece as mesmas garantias de coerência de gravação que a sessão e a coerência eventual. Com a desatualização limitada, os dados são replicados em maioria local (três réplicas em um conjunto de quatro réplicas) em uma só 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. Em determinada região, os dados são sempre replicados em uma maioria local (três réplicas em um conjunto de quatro réplicas), independentemente do nível de consistência.
As leituras durante o uso da desatualização limitada retornam os dados mais recentes disponíveis nessa região pela leitura 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 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 máximo de desatualização globalmente.
A Desatualização Limitada funciona melhor para aplicativos distribuídos globalmente usando contas de gravação de região única com duas ou mais regiões, quando é 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. A desatualização limitada em uma conta de várias gravações é 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 são garantidas para respeitar as garantias de leituras de suas gravações e as garantias de gravação de seguidas leituras. Essa garantia pressupõe uma sessão de “gravador” único ou o compartilhamento do token da 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 de Sessão, o uso de um token de sessão pelo cliente garantirá 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 as atualizações mais recentes foram instaladas no banco de dados, a versão mais recente dos dados retornará, apesar do uso de um token de sessão mais antigo. 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 vinculados à partição, o que significa que são associados exclusivamente a uma partição. Para garantir que você possa ler suas gravações, use o último token de sessão que foi gerado para os itens relevantes.
Se o cliente não iniciou uma gravação em uma partição física, ele não contém um token de sessão no cache e as leituras nessa partição física se comportam como leituras com a coerência eventual. Da mesma forma, se o cliente é recriado, o cache de tokens da sessão também é 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 do cliente para outra, o conteúdo do token não deverá ser modificado.
A coerência da sessão é o nível de coerência mais amplamente usado para aplicativos de região única e distribuídos globalmente. Ela fornece latências de gravação, disponibilidade e taxa de transferência de leitura comparáveis à coerência eventual. A coerência da sessão também fornece garantias de coerência de acordo com as necessidades dos aplicativos gravados, a fim de operar no contexto de um usuário. O gráfico a seguir ilustra a coerência de 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.
Coerê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 de coerência, as atualizações feitas como gravações de documento único veem 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 de vários documentos são sempre visíveis juntas.
Suponha que duas operações de gravação executem transacionalmente (operações todos ou nenhum) no documento Doc1 seguido pelo documento Doc2, dentro das transações T1 e T2. Quando o cliente faz uma leitura em qualquer réplica, ele vê “Doc1 v1 e Doc2 v1” ou “Doc1 v2 e Doc2 v2” ou nenhum desses documentos se a réplica está 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 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:
Coerê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 em uma das quatro réplicas na região especificada. Esta réplica pode estar atrasada e poderá não retornar dados ou retornar dados obsoletos.
A coerência eventual é a forma mais fraca de coerência, pois um cliente pode ler valores mais antigos do que aqueles que tinha lido no passado. A consistência eventual é ideal quando o aplicativo não exige nenhuma garantia de ordenação. Os exemplos incluem a contagem de retweets, curtidas ou comentários não encadeados. O gráfico a seguir ilustra a coerência eventual com notas musicais.
Garantias de consistência na prática
Na prática, você pode obter garantias de coerência mais fortes com frequência. 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. Consistência de leitura é vinculada ao pedido e a propagação das operações de gravação/atualização.
Se não houver operações de gravação no banco de dados, é provável que uma operação de leitura com níveis de coerência eventual, de sessão ou prefixo coerente produza os mesmos resultados de uma operação de leitura com um nível de coerência forte.
Se a sua conta estiver configurada com um nível de coerência diferente de coerência forte, você poderá descobrir a probabilidade de os clientes obterem leituras fortes e consistentes para suas cargas de trabalho. Você pode descobrir essa probabilidade examinando a métrica PBS (Desatualização Limitada Probabilística). Essa métrica é exposta no portal do Azure, para obter mais informações, consulte métrica Monitor Probabilistic Bounded Staleness (PBS).
A desatualização limitada mostra de maneira probabilística se a coerência eventual é eventual. Essa métrica fornece uma percepção da frequência com que você pode obter uma coerência mais forte que o nível configurado atualmente na 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 coerência é sempre asseguradamente menor que 10 milissegundos no 99º percentil contando com suporte do SLA. A latência de leitura média, no 50º percentil, é normalmente 4 milissegundos ou menos.
A latência de gravação para todos os níveis de coerência é sempre asseguradamente menor que 10 milissegundos no 99º percentil. A latência média de gravação, 50 º percentil, geralmente é 5 milissegundos ou menos. Contas do Azure Cosmos DB que abrangem várias regiões e são configuradas com coerê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. O RTT alto de rede entre as regiões será convertido em uma latência mais alta para solicitações do Azure Cosmos DB, uma vez que a coerência forte conclui uma operação somente depois de garantir que ela tenha sido confirmada em todas as regiões de uma conta.
A latência RTT é uma função de distância à velocidade da luz e a topologia de rede exata do Azure. A rede do Azure não fornece SLAs de latência para o RTT entre duas regiões do Azure, no entanto, ela 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 Coerê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
A coerência forte para contas com regiões que abrangem mais de 5 mil milhas (8 mil 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 coerência e taxa de transferência
Para uma 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 fornecer garantias de coerência. Sessão, prefixo coerente e eventual fazem 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 forte e desatualização limitada é a metade dos outros níveis de coerência.
Para um determinado tipo de operação de gravação, como inserir, substituir, submeter, 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 coerência forte, as alterações precisam ser confirmadas em cada região (maioria global). Nos outros níveis de coerência, a maioria local (três réplicas em um conjunto de quatro réplicas) é usada.
| Nível de coerência | Leituras de Quorum | Gravações 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 Coerente | Réplica única | Maioria local |
| Eventual | Réplica única | Maioria local |
Observação
O custo das RU/s de leituras para leituras de Minoria Local é duas vezes maior que os níveis de coerência mais fracos, pois as leituras são feitas de duas réplicas para fornecer garantias de coerência para forte e desatualização limitada.
Observação
O custo das RU/s das leituras dos níveis de consistência de desatualização forte e limitada consome aproximadamente duas vezes mais RUs durante a execução das operações de leitura quando comparado com outros níveis de consistência relaxados.
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 a durabilidade dos dados e o nível de consistência no caso de uma interrupção em toda a região. À medida que você desenvolve seu plano de continuidade do negócio, é necessário saber o período máximo de atualizações de dados recentes que o aplicativo pode perder sem maiores problemas durante a recuperação após um evento de interrupção. O período de tempo de atualizações que você pode perder é conhecido como RPO (objetivo de ponto de recuperação).
Esta tabela define a relação entre a durabilidade dos dados e o modelo de coerência na presença de uma interrupção em toda a região.
| Regiões | Modo de replicação | Nível de coerência | RPO |
|---|---|---|---|
| 1 | Uma 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 | Desatualização limitada | 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 | Desatualizaçã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 é 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 mil operações de gravação ou 300 segundos. Esse valor define o RPO mínimo de dados quando a desatualização limitada é usada.
Coerência forte 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 a coerência forte, pois um sistema distribuído não pode fornecer um RPO e um RTO zero. Além disso, não há benefícios de latência de gravação com o uso de coerência forte com várias regiões de gravação, pois uma gravação em qualquer região deve ser replicada e confirmada em todas as regiões configuradas na conta. Esse cenário resulta na mesma latência de gravação de 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 de TLA+ de alto nível para os cinco níveis de coerência oferecidos pelo Azure Cosmos DB
- Explicação de Coerência de Dados Replicados por meio do beisebol (vídeo) por Doug Terry
- Explicação de Coerência de Dados Replicados por meio do beisebol (whitepaper) por Doug Terry
- Session Guarantees for Weakly Consistent Replicated Data
- Equilíbrio de coerência no design do banco de dados distribuído moderno: CAP é só uma parte da história
- Probabilistic Bounded Staleness (PBS) for Practical Partial Quorums (PBS (Probabilistic Bounded Staleness) para quóruns parciais práticos)
- Eventualmente Coerente – Revisado
Próximas etapas
Para saber mais sobre os níveis de coerência no Azure Cosmos DB, leia os artigos a seguir: