Escolher nível certo de consistência

Concluído

Cada um dos modelos de consistência pode ser usado em cenários específicos do mundo real. Cada um deles oferece disponibilidade precisa e compensações de desempenho apoiadas por SLAs abrangentes. As considerações simples a seguir ajudarão você a fazer a escolha certa em muitos cenários comuns.

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.

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

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.

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.

Coerência de desatualização limitada

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.

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.

Coerência de prefixo coerente

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 sejam executadas nos documentos Doc 1 e Doc 2, dentro das transações T1 e T2. Quando o cliente faz uma leitura em qualquer réplica, o usuário vê “Doc 1 v1 e Doc 2 v1” ou “Doc 1 v2 e Doc 2 v2”, mas nunca “Doc 1 v1 e Doc 2 v2” ou “Doc 1 v2 e Doc 2 v1” para a mesma operação de leitura ou consulta.

Coerência eventual

Na coerência eventual, não há garantia de ordem para leituras. Na ausência de qualquer gravação adicional, as réplicas eventualmente convergem.

A consistência eventual é a forma mais fraca de consistência porque um cliente pode ler valores que são mais antigos do que os que ele leu anteriormente. 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