DP-900: entender e usar partição horizontal (sharding) para dados não relacionais

Vou ensinar‑te a competência de escolher e usar uma partition key (partição horizontal / sharding) em bases de dados não relacionais no Azure — essencial para o DP‑900 e para construir aplicações escaláveis. Saber isto ajuda‑te a optimizar desempenho, custos e escalabilidade em serviços como Azure Cosmos DB.

O que precisas de saber

Partição horizontal (sharding) consiste em dividir uma colecção de documentos ou itens em várias partições físicas, com base num valor de chave (partition key). Nos serviços NoSQL do Azure, como Azure Cosmos DB, cada item é armazenado numa partição lógica determinada pela partition key; o serviço gerirá as partições físicas por detrás, permitindo escalabilidade e paralelismo.

Exemplo: uma aplicação de comércio electrónico pode usar "tenantId" ou "customerId" como partition key. Um documento de encomenda pode ter a forma:

{
  "orderId": "A123",
  "customerId": "C789",
  "items": [...],
  "total": 79.90
}

Se a partition key for customerId, todas as encomendas do mesmo cliente ficam na mesma partição lógica — útil para consultas frequentes por cliente e para transacções locais. A escolha da partition key afecta o throughput (RU/s), a latência e o custo.

Como funciona e pontos-chave

Principais propriedades e decisões a conhecer:

• Cardinalidade: a partition key ideal tem alta cardinalidade (muitos valores distintos) para distribuir uniformemente os dados entre partições.
• Uniformidade de carga: além da cardinalidade, os valores da partition key devem gerar carga semelhante — evitar chaves que concentrem o tráfego num pequeno conjunto (hot partitions).
• Consultas e transacções: escolher uma partition key que suporte padrões de consulta. Consultas que filtram pela partition key são mais rápidas e económicas; operações multi‑item atómicas normalmente ficam limitadas a uma única partition key.
• Imutabilidade: idealmente, a partition key é imutável (não alteres o valor do documento), porque mover dados entre partições tem custo e limitações.

Decisão prática: pondera o volume de itens por valor, a frequência de leitura/escrita por valor e a necessidade de transacções locais. Se tens utilizadores com grande número de registos, evita usar um valor com demasiados itens que cause hot partitions.

Na prática — configuração em Azure Cosmos DB (exemplo conceptual)

Passos simplificados para criar uma colecção com partition key (conceito aplicável a outros serviços NoSQL):

1. Identifica o padrão de acesso: quais filtros são mais comuns? por cliente, por região, por produto?
2. Escolhe a candidate partition key (ex.: /customerId ou /regionId).
3. Cria a conta/colecção especificando a partition key. No portal do Azure ou via ARM/CLI, defines o path da partition key.
4. Testa com cargas representativas: mede latência, RU/s e distribuição de partições.
5. Ajusta se detectares hot partitions — pode ser necessária uma nova modelação (ex.: combinar valores: customerId_regionId) ou usar hashing do id.

Exemplo conceptual de criação via JSON (simplificado, não é comando real):

{
  "id": "orders",
  "partitionKey": {
    "paths": ["/customerId"],
    "kind": "Hash"
  }
}

Nota: no portal/CLI do Azure especificas a partition key ao criar a coleção; depois é difícil alterá‑la sem recriar a coleção e migrar dados.

Erros comuns

• Escolher uma partition key com baixa cardinalidade (ex.: "status" com valores como "open/closed"): causa partições desbalanceadas e hot partitions.
• Escolher uma chave que concentra tráfego (ex.: usar uma data quando a maior parte do tráfego ocorre nas datas mais recentes), criando picos e degradação de desempenho.
• Mudar frequentemente a partition key ou usar chaves mutáveis: obriga a migrações complexas e aumenta o custo operacional.

Como praticar

Pratica no portal do Azure ou com a conta gratuita: cria uma conta Cosmos DB, experimenta colecções com diferentes partition keys e usa ferramentas de carga para observar RU/s, latência e distribuição de partições. Para preparação do exame, realiza o Practice Assessment OFICIAL e gratuito da Microsoft para DP‑900 e segue a study guide gratuita no site da Microsoft. Esses recursos oficiais ajudam‑te a medir conhecimentos sem usar material proibido.

Em resumo

• Partition key (sharding) divide dados horizontalmente; é vital para escalabilidade em NoSQL como Azure Cosmos DB.
• Escolhe uma chave com alta cardinalidade e distribuição de carga equilibrada; considera padrões de consulta e necessidade de transacções locais.
• Evita chaves mutáveis ou com concentração de tráfego (hot partitions) e testa com cargas reais antes de produção.
• Pratica com o portal/CLI do Azure e usa o Practice Assessment e a study guide oficiais e gratuitos da Microsoft para preparar o DP‑900.