TL;DR: A Microsoft disponibilizou em GA a funcionalidade de alterar a chave de partição em containers do Azure Cosmos DB for NoSQL, com suporte a copy online. Isso elimina a necessidade de migrações manuais complexas, permitindo reparticionar dados com near-zero downtime. Para empresas brasileiras que lidam com hot partitions ou mudanças de schema, a novidade reduz riscos operacionais e custos de reengenharia.
Por que a escolha da chave de partição importa?
Em Azure Cosmos DB, a chave de partição é uma das decisões de design mais críticas. Ela determina como os dados são distribuídos entre partições físicas, como as queries são roteadas e, em última análise, o desempenho da aplicação em escala.
O problema é que aplicações evoluem. Uma chave que funcionava bem no lançamento pode se tornar um gargalo com o tempo. Exemplos comuns:
- Hot partitions – Uma chave que antes distribuía tráfego uniformemente agora concentra a maioria das requisições em poucas partições lógicas.
- Cross-partition queries – Novos padrões de acesso forçam a consulta a percorrer várias partições, aumentando o consumo de RU e a latência.
- Limites de tamanho de partição lógica – Crescimento imprevisto pode aproximar a partição do limite de 20 GB.
- Evolução do schema – Um novo modelo de dados pode exigir uma estratégia de particionamento diferente.
Até agora, alterar a chave de partição exigia uma migração manual no nível da aplicação: criar um novo container, escrever código de migração, gerenciar cutover e planejar downtime. Para muitos times, essa complexidade significava conviver com uma chave que já não servia ao workload.
Como funciona o Change Partition Key?
A Microsoft implementou a funcionalidade usando a infraestrutura de container copy intra-conta do Cosmos DB. O processo tem três etapas principais:
- Iniciar o job – Selecione o container de origem e o de destino (com a nova chave), e inicie a cópia.
- Monitorar progresso – Acompanhe o status no portal do Azure. No modo online, as escritas na origem são continuamente replicadas para o destino.
- Realizar o cutover – Quando o destination alcançar o source, pare as escritas, finalize o job e aponte a aplicação para o novo container.
Passo a passo para começar
Pré-requisitos:
- Uma conta Azure Cosmos DB for NoSQL
- O container que deseja reparticionar
- Acesso ao portal do Azure
Procedimento:
- No portal, abra o Data Explorer, selecione o container e vá em Scale & Settings > Partition Keys.
- Clique em Change para criar um job de mudança de partition key.
- Escolha entre modo online (escritas contínuas) ou offline (pausa total durante a cópia).
- Crie um novo container com a chave desejada ou selecione um existente no mesmo database e inicie o job.
- Acompanhe o progresso (número de documentos copiados) diretamente no portal.
Para cópia online:
- Pare as escritas quando o contador de documentos processados se aproximar do total.
- Selecione Complete para finalizar e fazer o flush de alterações residuais.
Após a conclusão, atualize sua aplicação para conectar-se ao novo container.
Melhores práticas e cuidados
- Teste em ambiente não produtivo antes de aplicar em produção, validando a distribuição uniforme dos dados.
- Monitore o consumo de RU durante a cópia, pois ela utiliza a throughput provisionada. Escale temporariamente se necessário.
- Planeje uma janela de downtime breve no modo online para o flush final antes do cutover.
- Verifique as queries após a migração – idealmente, queries-chave devem se tornar point reads ou single-partition queries.
- Para mudanças cross-account, utilize o mesmo recurso de container copy selecionando outra conta no portal.
Recursos adicionais
- Documentação: Change partition key
- Documentação: Container copy jobs
- Documentação: Hierarchical partition keys
- Best practices: Choosing a partition key
Perguntas Frequentes
- Posso alterar a chave de partição sem parar as escritas no container original?
Sim. O modo online replica continuamente as escritas para o destino, permitindo near-zero downtime. Apenas uma breve interrupção para flush final é necessária.
- Quanto tempo leva o processo de copy e como ele impacta a performance?
Depende do volume de dados e da throughput provisionada. O job consome RUs, podendo afetar operações normais. Monitore e escale temporariamente se necessário.
- Existe risco de perda de dados ou inconsistência?
Não. O processo usa a infraestrutura de copy do Cosmos DB com garantia de consistência. O cutover só ocorre após o destino estar sincronizado.
- Preciso criar um novo container ou posso usar um existente?
Ambos são possíveis. Você pode criar um novo container ou selecionar um container vazio no mesmo database.
- Essa funcionalidade está disponível para todas as APIs do Cosmos DB?
Atualmente, apenas para API NoSQL (SQL). Para outras APIs (MongoDB, Cassandra, Gremlin), ainda é necessário migração manual.
Artigo originalmente publicado por Richa Gaur em Azure Updates - Latest from Azure Charts.
