Escolher o nível de consistência certo
Cada um dos modelos de consistência pode ser usado para cenários específicos do mundo real. Cada um fornece compensações precisas de disponibilidade e desempenho apoiadas por SLAs abrangentes. As considerações simples a seguir ajudam você a fazer a escolha certa em muitos cenários comuns.
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.
A consistência de leitura aplica-se a uma única operação de leitura com 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 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.
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.
Consistência de estagnação limitada
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.
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.
Consistência de prefixo consistente
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 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.
Consistência eventual
Em eventual consistência, não há garantia de encomenda para leituras. Na ausência de escritas adicionais, as réplicas acabam por convergir.
A consistência eventual é a forma mais fraca de consistência porque um cliente pode ler os valores mais antigos do que os que leu antes. 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