DP-900: como usar indexes e consultas secundárias no Azure Table Storage

João Barros 21 de October de 2026 6 min de leitura

Vou ensinar como utilizar as chaves de partição e linha (PartitionKey e RowKey) no Azure Table Storage para modelares dados eficientes e fazeres consultas rápidas. Esta competência é útil no exame DP-900 porque avalia a tua compreensão de soluções NoSQL simples no Azure e é prática para cenários reais de aplicações com registo de eventos ou catálogos leves. No final deste artigo terás exemplos concretos, padrões comuns e armadilhas a evitar que te ajudam a tomar decisões de modelação informadas.

O que precisas de saber

Azure Table Storage é um serviço NoSQL chave-valor orientado a colunas, optimizado para grandes volumes de entidades simples. Cada entidade tem um PartitionKey e um RowKey que, em conjunto, formam a chave primária única. A combinação determina como os dados são distribuídos e lidos: consultas que usam PartitionKey (ou PartitionKey + RowKey) são muito mais rápidas e económicas do que varreduras totais.

Conceptualmente, pensa na PartitionKey como o identificador da partição física e na RowKey como a ordenação ou identificador único dentro dessa partição. Consultas que filtram por PartitionKey costumam ser O(1) relativamente ao número de partições consultadas — isto é, o serviço dirige‑se directamente à partição — enquanto uma query sem PartitionKey exige um scan por múltiplas partições e pode implicar leitura de muito mais dados, latência acrescida e custos mais elevados.

Exemplo conceptual: imagina um sistema de telemetria que guarda leituras por dispositivo e dia. Podes usar PartitionKey = DeviceId e RowKey = Timestamp (ou o contrário, dependendo dos padrões de consulta). Assim, obter leituras de um dispositivo é uma operação eficiente porque lês apenas a partição desse dispositivo, em vez de varrer milhões de registos. Em cenários com 1 milhão a 100 milhões de entidades, esta diferença é crítica.

Como funciona na prática

Principais comportamentos a saber:

PartitionKey agrupa entidades; todas as entidades na mesma partição estão fisicamente próximas e suportam transacções de lote dentro da mesma partição.
RowKey ordena entidades dentro da partição e, em conjunto com o PartitionKey, identifica unicamente cada entidade.
Consultar por PartitionKey é muito eficiente; sem PartitionKey, o serviço faz uma varredura (scan) que é lenta e pode consumir muito mais RU (request units) e largura de banda.

Exemplo de entidade (formato conceptual JSON):

{
  "PartitionKey": "DeviceA",
  "RowKey": "2026-10-21T09:00:00Z",
  "Temperature": 21.5,
  "Humidity": 60
}

Na prática, e para cargas de produção, convém medir: por exemplo, ler 10 registos numa partição dedicada pode demorar dezenas de milissegundos, enquanto um scan sobre milhões de registos pode demorar segundos e custar muito mais. Ao modelar, pensa sempre em latência, custo e capacidade de escrita/leitura por segundo.

Passo a passo: modelar para consultas eficientes

Segue estes passos quando planeias os teus esquemas no Table Storage.

Identifica padrões de consulta: que perguntas a aplicação faz com mais frequência? Ex.: obter leituras por dispositivo, por intervalo de tempo, por localização. Faz uma lista com as três consultas principais e prioriza a modelação para essas operações.
Escolhe PartitionKey para agrupar entidades que serão frequentemente lidas em conjunto. Ex.: DeviceId ou LocationId se lês por localização. Se esperas leitura por dia, podes usar LocationId|YYYYMMDD como PartitionKey para distribuir por dias.
Escolhe RowKey para ordenar / identificar singularmente dentro da partição. Ex.: Timestamp invertido (para leituras mais recentes primeiro) usando uma fórmula como MaxTicks - ticks, ou um identificador composto DeviceId|SequenceNumber.
Aproveita operações de lote quando precisares de escrever/actualizar múltiplas entidades na mesma partição: as operações em lote só são suportadas dentro da mesma PartitionKey e cada lote suporta até 100 operações, o que reduz overhead de rede e melhora a consistência transaccional.
Evita partições demasiado grandes: se um PartitionKey receber um volume de escrita/leituras muito elevado (hot partition), considera repartir por sub‑chaves (ex.: DeviceId + hour ou adiciona um salt de 0‑9) para distribuir a carga. Por exemplo, em vez de 50k writes/s numa partição, podes ter 10 partições com ~5k writes/s cada.

Exemplo: padrão para obter as últimas leituras de um dispositivo (RowKey com Timestamp invertido):

// Pseudocódigo conceptual de consulta
partition = "DeviceA"
// RowKeys foram gravadas como (MaxTimestamp - Timestamp) para ordenar descendente
query = TableQuery.where(PartitionKey == partition).take(10)
results = table.execute(query)

Erros comuns

Algumas armadilhas típicas ao trabalhar com Azure Table Storage:

Não planear os padrões de consulta: escolher PartitionKey/RowKey sem pensar nas queries leva a scans caros e lentos. Reavalia o esquema quando os requisitos mudam.
Partições demasiado quentes: usar um único PartitionKey para todos os registos (por exemplo, "All") causa gargalos de escrita e reduz o desempenho. Se começares a ver throttling ou latência elevada, é sinal para shardear.
Esperar capacidades de SQL: Table Storage não suporta joins, transacções multi‑partição nem consultas complexas. Se precisares disso, considera Cosmos DB, Azure SQL ou um design de pipeline ETL para agregação.

Como praticar

Para interiorizares estes conceitos, faz os laboratórios do Azure e exercita cenários reais. Consulta o Practice Assessment OFICIAL da Microsoft (é gratuito) para verificares o teu conhecimento geral do exame DP-900. Lê também a study guide oficial da Microsoft para DP-900 (gratuita) — ambos apresentam os tópicos medidos sem fornecer questões de exame reais.

Pratica no portal do Azure criando uma Storage Account com Table Storage ou usa o SDK (C#, Python, JavaScript) para inserir e consultar entidades. Testa variações: grava 1000 entidades numa única partição e depois grava as mesmas 1000 distribuídas por 10 partições; mede latência e custos. Experimenta operações em lote (até 100 registos) e observa ganhos de performance em comparação com inserções individuais.

Em resumo

PartitionKey e RowKey são cruciais para desempenho: usam‑se para agrupar e identificar entidades de forma eficiente.
Define PartitionKey com base nos teus padrões de consulta; evita partições "quentes" e varreduras globais.
Operações em lote são suportadas apenas dentro da mesma partição (até 100 operações) — aproveita‑as para eficiência e consistência.
Azure Table Storage é um NoSQL simples: não esperes capacidades relacionais avançadas; modela os dados para as queries que importam e valida com testes de carga reais.