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 e é apoiado 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
Em consistência de obsoletismo limitado, as leituras são garantidas para honrar a garantia de prefixo consistente. As leituras podem ficar atrás das gravações por, no máximo, versões "K" (ou seja, "atualizações") de um item ou por intervalo de tempo "T", o que for atingido primeiro. Em outras palavras, quando você escolhe a obsolescência limitada, a "obsolescência" 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
Para uma conta de uma única 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.000 operações de gravação ou 300 segundos.
Consistência de sessão
Na consistência da sessão, dentro de uma única sessão de cliente, as leituras são garantidas para honrar as garantias de prefixo consistente, leituras monotônicas, gravações monotônicas, leitura-sua-gravação e gravação-segue-leituras. Isso pressupõe uma única sessão de "gravador" ou o compartilhamento do token de sessão para vários escritores.
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 que são 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