(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisboa

DP-900: como usar índices secundários em Azure Cosmos DB

João Barros 19 de September de 2026 4 min de leitura

Vou ensinar‑te a competência: compreender e usar índices secundários em Azure Cosmos DB. Esta habilidade aparece na secção de dados não relacionais do DP-900 e é útil na prática para optimizar o desempenho de leitura e o custo de RU em aplicações que usam Cosmos DB.

O que precisas de saber

Azure Cosmos DB é uma base de dados não relacional multimodel que indexa automaticamente documentos JSON. Índices secundários (secondary indexes) permitem consultas rápidas em propriedades que não são a chave primária. Por padrão, o Cosmos DB cria um índice para todas as propriedades, tornando a maioria das consultas rápidas sem esquema adicional. Contudo, o índice automático pode aumentar custos e latência de escrita; por isso, é importante perceber como configurar a política de indexação.

Exemplo simples: tens documentos com esta estrutura num contentor:

{
  "id": "1",
  "nome": "Ana",
  "idade": 30,
  "cidade": "Lisboa",
  "tags": ["clientes", "premium"]
}

Se quiseres consultar por cidade (WHERE cidade = 'Lisboa'), um índice secundário na propriedade cidade acelera a consulta. Se raramente consultas por uma propriedade, podes excluí‑la do índice para reduzir custos de escrita.

Como funciona

A política de indexação em Cosmos DB define quais caminhos JSON são indexados e com que tipo de índice (Hash, Range) e precisão. Pontos-chave:

  • Included paths: caminhos a indexar (ex.: "/cidade/?", "/tags/*").
  • Excluded paths: caminhos a excluir do índice para reduzir o custo de escrita.
  • Tipos de índice: Range para operadores <, >, ORDER BY e consultas de intervalo; Hash para igualdade (==), mais eficiente em espaço.
  • Consistência e RU: índices aumentam o custo de RU nas operações de escrita. Ajustar a política altera o trade‑off entre leituras rápidas e escritas mais dispendiosas.

Exemplo de política de indexação (simplificado) em JSON:

{
  "indexingMode": "consistent",
  "includedPaths": [
    { "path": "/cidade/?" },
    { "path": "/idade/?" }
  ],
  "excludedPaths": [
    { "path": "/comentarios/*" }
  ]
}

Na prática

Passos para optimizar índices secundários numa base de produção:

  1. Identifica os padrões de consulta: analisa as queries mais frequentes — quais propriedades aparecem em WHERE, JOIN, ORDER BY ou em filtros de intervalo.
  2. Escolhe o tipo de índice conforme o uso: usa Range se precisares de ORDER BY ou filtros de intervalo (ex.: idade > 18); usa Hash para igualdade (ex.: cidade = 'Porto').
  3. Exclui propriedades de baixo uso: campos grandes (ex.: blobs em base64, arrays muito extensos) ou raramente consultados devem ser excluídos.
  4. Testa e mede RU: antes e depois de alterar a política, mede o RU consumido nas escritas e nas leituras e a latência das queries.

Exemplo prático com Azure Portal / SDK: altera a política via portal ou ARM/SDK — aqui um fragmento de JSON para incluir um índice do tipo Range numa propriedade de texto cujo ORDER BY se espera:

{
  "includedPaths": [
    {
      "path": "/nome/?",
      "indexes": [
        { "kind": "Range", "dataType": "String", "precision": -1 }
      ]
    }
  ],
  "excludedPaths": [
    { "path": "/largeBlob/*" }
  ]
}

Depois de aplicada, reavalia o desempenho das consultas. Se necessário, reindexa conteúdos (em alguns cenários pode ser preciso recriar o contentor para uma reindexação completa, dependendo das alterações).

Erros comuns

1) Presumir que o índice automático é sempre ideal: ter tudo indexado aumenta o custo de escrita. Ajusta a política conforme os padrões de leitura/escrita.

2) Usar Range sem necessidade: Range consome mais espaço e RU; para igualdade prefere Hash.

3) Esquecer de medir RU após alterações: alterar a política sem monitorização pode degradar o custo ou a latência. Testa sempre antes de ir para produção.

Como praticar

Cria um contentor de teste em Azure Cosmos DB (modo Core/SQL) e faz experimentos: insere documentos com diferentes formatos e simula cargas de leitura/escrita. Usa o portal e os SDKs para modificar a política de indexação e observa o RU e as latências.

Para preparação do exame DP-900, faz o Practice Assessment OFICIAL gratuito da Microsoft e consulta a study guide oficial (gratuita). Estes recursos oficiais ajudam a validar o conhecimento sem recorrer a materiais proibidos.

Em resumo

  • Índices secundários em Cosmos DB aceleram consultas em propriedades que não são chave primária.
  • Configurar included/excluded paths e escolher entre Hash e Range ajuda a equilibrar o custo de RU e a performance.
  • Mede sempre RU e latência antes e depois de alterações; optimiza com base em padrões reais de consulta.
  • Pratica no Azure e usa o Practice Assessment e a study guide oficiais e gratuitos da Microsoft.