O Domínio 3 do conteúdo oficial do DP-900 inclui "Identificar casos de uso do Azure Cosmos DB" e "Descrever as APIs do Azure Cosmos DB". As perguntas reais vão um passo além e costumam perguntar como escolher uma chave de partição, do que dependem as unidades de solicitação (RUs), se uma carga combina com o modo sem servidor ou com o dimensionamento automático e como os cinco níveis de consistência diferem.
Este post é um complemento de Fundamentos de dados não relacionais da nossa série de estudos do DP-900. Ele pega as RUs, as chaves de partição, os níveis de consistência e a lista de APIs apresentados lá e os amplia até o nível que você precisa para as perguntas da prova, nesta ordem: estrutura de recursos, design de partições, modos de taxa de transferência, distribuição global e consistência, e como escolher uma API.
---
Que tipo de banco de dados é o Cosmos DB?
Imagine uma rede de lojas de conveniência com filiais no mundo todo. A lista de produtos definida pela matriz é replicada em todas as filiais, então o cliente compra na mais próxima. O Azure Cosmos DB é um banco de dados NoSQL totalmente gerenciado (PaaS) construído do mesmo jeito: os dados são replicados nas regiões do Azure que você escolher, e os usuários leem e gravam na réplica mais próxima.
O Cosmos DB não depende de esquema. Itens do mesmo contêiner podem ter quantidades diferentes de propriedades e estruturas diferentes, e por padrão todas as propriedades são indexadas automaticamente, então você não precisa definir esquema nem índices com antecedência. Os dados são organizados em uma estrutura de quatro níveis.
| Nível | Função | |------|------| | Conta | O recurso do Azure de nível mais alto; define a API, as regiões e a consistência padrão | | Banco de dados | Um namespace lógico que agrupa contêineres relacionados | | Contêiner | A unidade básica de armazenamento e escala; chave de partição, taxa de transferência, política de indexação e TTL são definidos aqui | | Item | Um dado individual, chamado de documento, linha, nó ou aresta conforme a API |
O Cosmos DB combina com aplicativos que precisam de esquema flexível, usuários no mundo todo e latência baixa e constante. Exemplos típicos são a ingestão de IoT e telemetria, perfis de jogadores e rankings em jogos, catálogos de produtos e carrinhos em lojas virtuais e personalização em aplicativos web e móveis. Por outro lado, se você precisa de JOINs complexos entre muitas tabelas, o Azure SQL Database combina melhor, e para análise em grande escala, o Microsoft Fabric.
Dica de prova: "Respostas na casa de um dígito de milissegundos para usuários do mundo todo, dados JSON cujo esquema muda com frequência" → Cosmos DB. "Um sistema de pedidos com muitos JOINs entre tabelas" → Azure SQL Database, não Cosmos DB.
---
Chaves de partição: onde a escala começa
Os dados de um contêiner são divididos em partições lógicas conforme o valor da chave de partição. Itens com o mesmo valor de chave formam uma partição lógica, e o Cosmos DB distribui as partições lógicas entre partições físicas internas para ampliar armazenamento e taxa de transferência.
Uma partição lógica pode armazenar até 20 GB. Uma partição física processa até 10.000 RUs por segundo, então uma partição lógica também não pode passar desse limite. A taxa de transferência provisionada é dividida igualmente entre as partições físicas. Se as solicitações se concentram em poucas partições, elas viram partições quentes, e as solicitações podem ser limitadas (rate limiting) mesmo com taxa de transferência sobrando em outras. Depois de escolhida, a chave de partição não pode ser alterada no lugar. Para mudá-la, é preciso criar um contêiner novo e mover os dados.
| Boa chave de partição | Chave de partição ruim | |------|------| | Muitos valores distintos (ID de usuário, ID de dispositivo, ID de pedido) | Poucos valores (status, tipo, país) | | Armazenamento e solicitações espalhados igualmente entre os valores | Dados e solicitações concentrados em certos valores | | Aparece nos filtros das consultas frequentes | Toda consulta precisa varrer todas as partições |
Se os dados de um único valor de chave puderem passar de 20 GB, as chaves de partição hierárquicas permitem empilhar até três níveis de chaves (por exemplo, ID do locatário → ID do usuário) para distribuir os dados de forma mais uniforme.
Dica de prova: "A melhor propriedade para usar como chave de partição" → uma com muitos valores distintos e bem distribuídos. "Solicitações são recusadas mesmo com taxa de transferência sobrando, porque se concentram em poucas partições" → partição quente.
---
Unidades de solicitação (RUs) e modos de taxa de transferência
O que afeta o consumo de RUs
Uma unidade de solicitação (RU) é a moeda de desempenho do Cosmos DB, que reúne CPU, IOPS e memória em um único número. Uma leitura pontual de um item de cerca de 1 KB pelo ID e pela chave de partição custa 1 RU, e todas as operações, incluindo gravações, consultas e exclusões, são medidas em RUs.
| Fator | Efeito nas RUs | |------|------| | Tamanho do item | Itens maiores custam mais RUs para ler e gravar | | Indexação | Todas as propriedades são indexadas por padrão; excluir algumas reduz as RUs de gravação | | Quantidade de propriedades | Mais propriedades custam mais RUs na gravação | | Nível de consistência | Strong e Bounded staleness usam cerca do dobro de RUs nas leituras | | Complexidade da consulta | Mais resultados, predicados e funções custam mais |
Modos de taxa de transferência
| Modo | Como funciona | Melhor uso | |------|------|------| | Taxa de transferência provisionada (manual) | Reserva RU/s com antecedência, dedicadas a um contêiner ou compartilhadas no nível do banco (até 25 contêineres) | Tráfego estável e previsível | | Dimensionamento automático (autoscale) | Você define um máximo de RU/s e ele se ajusta instantaneamente entre 10% e 100% desse valor | Tráfego com picos em que dá para definir um limite superior | | Sem servidor | Nada a provisionar; você paga as RUs consumidas; só contas de uma região | Tráfego intermitente, imprevisível e baixo, desenvolvimento e testes |
Por exemplo, se você definir o máximo do dimensionamento automático em 20.000 RU/s, a taxa de transferência varia entre 2.000 e 20.000 RU/s. Contas sem servidor não podem ser distribuídas entre regiões, então, se você precisa de distribuição global, deve usar taxa de transferência provisionada.
Dica de prova: "Um aplicativo de desenvolvimento usado de vez em quando, pagando só pelo que usa" → sem servidor. "Tráfego tranquilo na maior parte do tempo, mas que dispara em eventos, com um máximo de RU/s definido" → dimensionamento automático. "Replicar em várias regiões" → não é possível no modo sem servidor.
---
Distribuição global e os cinco níveis de consistência
Gravações em várias regiões
Você pode adicionar regiões do Azure a uma conta a qualquer momento; os dados são replicados automaticamente e os usuários leem da réplica regional mais próxima. Com as gravações em várias regiões ativadas, as gravações também são atendidas na região mais próxima. Contas com gravações em várias regiões têm SLA de disponibilidade de 99,999%, e tanto leituras quanto gravações têm garantia de menos de 10 milissegundos no percentil 99.
Níveis de consistência
Quando as réplicas ficam em várias regiões, é preciso decidir quando um valor recém-gravado fica visível nas outras regiões. O Cosmos DB oferece esse equilíbrio em cinco níveis.
!Os cinco níveis de consistência do Azure Cosmos DB
| Nível | O que garante | Analogia | |------|------|------| | Strong | Toda leitura reflete a gravação mais recente | Uma transmissão ao vivo | | Bounded staleness | As leituras ficam atrás no máximo por um tempo ou número de versões definido | Uma transmissão com atraso máximo de cinco minutos | | Session | Dentro de uma sessão de cliente, você lê na hora o que gravou | O comentário que você publica aparece na hora na sua tela | | Consistent prefix | As gravações nunca chegam fora de ordem, mas podem não ser as mais recentes | Uma reprise que chega episódio a episódio, em ordem | | Eventual | Todas as réplicas convergem com o tempo; maior disponibilidade | Um cartão-postal que uma hora chega |
A consistência padrão é definida por conta, e cada solicitação pode relaxá-la para um nível mais fraco quando necessário. Session é o nível mais usado tanto em aplicativos de uma região quanto nos distribuídos globalmente.
Dica de prova: "O usuário precisa ver na hora o perfil que acabou de editar" → Session. "As leituras sempre precisam trazer o valor mais recente" → Strong. "Máxima disponibilidade e mínima latência, valores um pouco atrasados não são problema" → Eventual. "Atraso é aceitável, mas a ordem nunca pode mudar" → Consistent prefix.
---
Como escolher uma API
A API é escolhida ao criar a conta e define o formato dos dados, a linguagem de consulta e as bibliotecas de cliente que o aplicativo usa. O armazenamento interno é o mesmo; a API funciona como uma camada de abstração por cima.
| API | Modelo de dados | Linguagem de consulta | Escolha quando | |------|------|------|------| | NoSQL | Documentos JSON | Sintaxe parecida com SQL | É a escolha padrão para aplicativos novos; a API nativa (antes chamada SQL API) | | MongoDB | Documentos BSON | MongoDB Query Language (MQL) | Você quer continuar usando drivers e a experiência com MongoDB | | Table | Chave-valor | Consultas por chave no estilo OData | Migrar um aplicativo do Azure Table Storage que precisa de mais desempenho e distribuição global | | Apache Cassandra | Família de colunas | CQL | Levar uma carga de trabalho existente do Cassandra para um serviço gerenciado | | Apache Gremlin | Grafo (vértices e arestas) | Gremlin | Os relacionamentos são o centro, como em redes sociais, recomendações, detecção de fraude ou organogramas |
Guarde também algumas mudanças recentes. O Azure Cosmos DB for PostgreSQL está em processo de