Sharding de banco de dados: como dividir dados para escalar aplicações
Entenda como o sharding de banco de dados distribui dados entre servidores, evita hotspots e ajuda aplicações a escalar com segurança e eficiência.
Uma aplicação cresce, o banco recebe mais leituras e escritas, e chega um momento em que aumentar CPU, memória ou armazenamento deixa de resolver o problema com eficiência.
Surge então uma alternativa poderosa — e complexa: dividir os dados entre vários servidores.
Esse processo é chamado de sharding de banco de dados. Cada servidor armazena uma parte do conjunto total, permitindo distribuir capacidade e carga.
A aplicação continua enxergando uma base lógica, mas os registros vivem em shards diferentes.
O benefício depende de uma boa chave de distribuição e de consultas compatíveis com ela.
Uma decisão ruim cria hotspots, consultas espalhadas, transações caras e migrações difíceis.
Neste guia, você aprenderá como o sharding funciona, quando adotá-lo e quais problemas precisam ser resolvidos antes da primeira divisão.
O que é sharding de banco de dados?
Sharding é uma forma de particionamento horizontal em que as linhas de uma base lógica são distribuídas entre diferentes nós.
Cada shard armazena apenas uma fração dos registros, mas mantém a estrutura e os índices necessários para atender sua parte da carga.
Se uma plataforma tem milhões de clientes, por exemplo, os dados podem ser divididos pelo identificador do cliente.
Uma requisição carrega essa chave, o roteador descobre o shard responsável e envia a consulta ao destino correto.
O objetivo é escalar horizontalmente: adicionar máquinas para aumentar armazenamento, CPU e capacidade de escrita.
Isso difere de escalar verticalmente, que significa trocar uma máquina por outra maior.
Sharding, particionamento e replicação: qual é a diferença?
| Técnica | O que faz | Finalidade principal |
|---|---|---|
| Particionamento | Divide uma tabela em partes físicas, normalmente no mesmo servidor | Organização, manutenção e desempenho |
| Sharding | Distribui partes dos dados entre nós independentes | Escala horizontal de armazenamento e carga |
| Replicação | Mantém cópias dos mesmos dados em outros nós | Disponibilidade e escala de leitura |
A documentação de particionamento do PostgreSQL descreve divisões por faixa, lista e hash dentro de uma tabela lógica.
No sharding, essas partes atravessam o limite de uma única instância e passam a exigir roteamento e operação distribuída.
Replicação e sharding costumam coexistir. Cada shard pode ter réplicas para tolerar falhas; as réplicas contêm o mesmo subconjunto, enquanto shards diferentes contêm subconjuntos diferentes.
Como funciona uma arquitetura com shards
Uma arquitetura fragmentada precisa de três elementos: nós de armazenamento, metadados sobre a distribuição e um componente capaz de rotear consultas.
O roteador pode estar na biblioteca da aplicação, em um proxy ou no próprio banco distribuído.
- A aplicação envia a operação e, sempre que possível, a chave de distribuição.
- O roteador consulta o mapa ou calcula o destino.
- Um shard executa a consulta direcionada.
- Quando vários shards participam, o coordenador combina os resultados.
Nos conceitos do Citus, um coordenador usa metadados para encaminhar consultas aos workers.
Dependendo da localização dos dados, ele roteia para um único nó ou paraleliza a operação entre vários.
O que é uma shard key?
Shard key é o campo, ou conjunto de campos, usado para decidir onde um registro será armazenado.
Ela influencia distribuição, roteamento, consultas, joins, transações e até a dificuldade de ampliar o cluster.
A documentação de shard keys do MongoDB destaca dois objetivos que precisam coexistir: espalhar os documentos de forma equilibrada e facilitar os padrões de consulta mais comuns.
Otimizar apenas um deles costuma transferir o problema para outro ponto.
Estratégias de distribuição dos dados
A estratégia define como o espaço de chaves é dividido. Faixa, hash e diretório são os modelos mais comuns.
Sistemas reais podem combinar técnicas, incluir zonas geográficas ou usar shards virtuais para facilitar movimentações futuras.
Sharding por faixa
Valores próximos ficam juntos: clientes de A a F em um shard, de G a M em outro, ou eventos separados por períodos.
Consultas de intervalo podem atingir poucos nós, mas chaves crescentes, como datas, concentram novas escritas na faixa mais recente.
Sharding por hash
Uma função transforma a chave em um valor distribuído pelo espaço dos shards. A carga tende a ficar mais uniforme, inclusive para identificadores crescentes.
A desvantagem é perder localidade: uma busca por faixa pode precisar consultar o cluster inteiro.
As orientações oficiais sobre hashed sharding mostram justamente essa troca entre distribuição uniforme e eficiência de consultas por intervalo.
Sharding por diretório ou região
Um diretório mantém o mapa entre chaves e shards. Isso facilita mover clientes específicos ou isolar uma conta grande, mas transforma o catálogo em parte crítica do caminho.
Outra variação usa regiões para reduzir latência ou cumprir residência de dados, exigindo regras claras para usuários que mudam de localidade.
Como escolher uma boa shard key
Uma boa chave tem cardinalidade suficiente, distribui volume e taxa de acesso, aparece nas consultas frequentes e permanece relativamente estável.
Em SaaS multi-tenant, tenant_id costuma ser natural porque mantém os dados de cada cliente próximos.
- Meça bytes, linhas, leituras e escritas por valor candidato.
- Analise crescimento e sazonalidade, não apenas a fotografia atual.
- Liste consultas que não carregam a chave e quanto elas custariam.
- Verifique se tabelas relacionadas podem usar a mesma chave.
- Planeje clientes muito maiores que a média.
Um grande cliente pode sobrecarregar sozinho o shard que o contém. Nesse caso, buckets adicionais, isolamento dedicado ou uma chave composta podem ajudar, desde que a aplicação saiba localizar todas as partes.
Hotspots: quando um shard recebe carga demais
Hotspot ocorre quando dados ou tráfego ficam concentrados em poucos nós. O cluster pode parecer equilibrado em gigabytes e continuar desequilibrado em CPU, bloqueios ou escritas por segundo.
Chaves monotônicas, celebridades, campanhas, grandes tenants e dados “quentes” recentes são causas comuns.
A correção pode envolver dividir faixas, mover tenants, adicionar buckets, usar cache ou redesenhar o acesso.
Adicionar servidores sem mudar o mapeamento não redistribui automaticamente a carga.
Consultas direcionadas e scatter-gather
Uma consulta direcionada contém a shard key e visita apenas o nó responsável. Já uma operação scatter-gather é enviada a vários shards; o coordenador aguarda respostas, combina, ordena e devolve o resultado.
Relatórios globais, busca sem chave, ordenação e paginação profunda podem ficar caros. A latência passa a depender do shard mais lento, e um nó indisponível pode produzir erro ou resultado parcial.
Para agregações recorrentes, considere tabelas derivadas, processamento assíncrono ou um sistema analítico separado.
Modelagem, joins e colocação de dados
Dados consultados juntos devem, quando possível, morar juntos. Pedidos, itens e pagamentos distribuídos pelo mesmo tenant_id podem realizar joins dentro de um worker. Se cada tabela usa uma chave incompatível, a consulta precisa movimentar dados pela rede.
Tabelas pequenas e globais, como categorias e tipos de status, podem ser replicadas em todos os nós.
Denormalização também reduz joins entre shards, mas aumenta duplicação e exige um processo confiável de atualização.
Antes de distribuir, reveja índices em banco de dados. Cada shard precisa de índices adequados, e índices desnecessários continuam consumindo memória, armazenamento e capacidade de escrita.
Transações entre shards
Transações locais a um shard são mais simples. Quando uma operação modifica vários nós, o sistema pode usar protocolos distribuídos, mas paga em latência, disponibilidade e complexidade de recuperação.
Modele invariantes importantes para caberem na mesma unidade de distribuição.
Quando isso não for possível, processos com idempotência, estados intermediários e compensações podem ser mais resilientes do que manter uma transação longa atravessando o cluster.
Identificadores únicos em um banco fragmentado
Uma sequência auto-incremental central pode virar gargalo ou exigir coordenação. Alternativas incluem identificadores gerados pela aplicação, faixas reservadas por shard ou chaves que carregam uma parte de origem.
O identificador global e a shard key não precisam ser o mesmo campo. Porém, buscar apenas pelo ID pode exigir um diretório ou uma chave que permita descobrir o shard.
Avalie também o impacto de valores aleatórios nos índices e de valores ordenados na concentração de escritas.
Replicação, consistência e alta disponibilidade
Se cada shard existe em uma única máquina, a falha dessa máquina indisponibiliza parte dos dados.
Por isso, shards de produção geralmente são conjuntos replicados com eleição, failover e uma política explícita de confirmação de escrita.
Ler de réplicas pode aumentar capacidade, mas cria risco de dados atrasados.
Defina quais fluxos precisam ler a própria escrita, quais aceitam consistência eventual e como o cliente reage durante troca de primário. Sharding amplia a capacidade; replicação protege cada parte.
Rebalanceamento e resharding
Rebalancear significa mover faixas ou buckets para corrigir distribuição. Resharding altera a divisão, o número de shards ou a própria chave.
Ambos consomem rede, disco e CPU, podendo competir com o tráfego da aplicação.
O fluxo documentado de resharding no Vitess copia dados para os destinos, deixa as réplicas alcançarem a origem, compara a integridade e então transfere o tráfego.
A implementação varia, mas copiar, acompanhar mudanças, validar e cortar são etapas recorrentes.
Backup e recuperação
Copiar cada shard em horários diferentes pode gerar um conjunto global incoerente.
O plano deve registrar um ponto lógico comum, preservar metadados de roteamento e incluir configurações, credenciais e versões de esquema.
Teste restauração completa e recuperação de apenas um shard. Um backup que existe, mas não consegue ser reintegrado ao mapa do cluster, não resolve o incidente.
Requisitos de retenção e região também precisam acompanhar os dados durante movimentações.
O que monitorar em um cluster fragmentado
- Volume, crescimento e operações por shard.
- CPU, memória, disco, conexões e bloqueios por nó.
- Latência de consultas direcionadas e espalhadas.
- Atraso de replicação e estado de failover.
- Movimentações pendentes, taxa de cópia e erros de validação.
- Distribuição por tenant e detecção de chaves quentes.
Médias globais escondem desequilíbrios. Compare percentis entre shards e alerte quando um nó se afasta do grupo.
Inclua a shard key ou um identificador seguro no contexto dos traces para localizar o caminho da consulta sem expor dados sensíveis.
Como migrar sem interromper a aplicação
- Meça o banco atual e confirme que o limite não é consulta ou índice inadequado.
- Escolha uma tabela ou domínio com chave clara e baixo acoplamento.
- Crie o mapa de roteamento e prepare o esquema nos destinos.
- Copie o histórico em lotes controlados e verificáveis.
- Use Change Data Capture ou mecanismo equivalente para acompanhar novas alterações.
- Compare contagens, checksums e consultas representativas.
- Transfira leituras e escritas gradualmente, com caminho de reversão.
- Somente remova a origem após o período de segurança.
Evite dual write ingênuo, em que a aplicação grava em dois lugares e presume que ambos sempre terão sucesso.
Um log de mudanças ou outbox oferece reentrega e auditoria mais confiáveis.
Quando vale a pena usar sharding
- O conjunto de dados ou a taxa de escrita supera uma máquina viável.
- O crescimento é contínuo e previsível.
- Existe uma chave que distribui carga e aparece nas consultas.
- Os domínios podem operar com poucas transações entre shards.
- A equipe consegue operar, observar e recuperar um sistema distribuído.
Arquiteturas multi-tenant e alguns sistemas de microsserviços podem ter limites naturais de distribuição.
Mesmo assim, o desenho deve partir do padrão dos dados, não apenas da quantidade de serviços.
Quando não usar sharding
Não fragmente uma base pequena apenas porque o produto pode crescer. A própria documentação do MongoDB recomenda começar sem sharding quando o conjunto cabe em um servidor, pois a fragmentação precoce oferece pouco benefício e adiciona custo operacional.
Antes, corrija consultas, índices, pools de conexão e processamento desnecessário. Avalie cache, arquivamento, particionamento local, réplicas de leitura e uma instância maior.
O conteúdo sobre fundamentos do PostgreSQL ajuda a revisar essa base antes de distribuir.
Serviços gerenciados podem absorver parte da operação. Ao analisar bancos de dados em nuvem, confirme se a escala declarada inclui escritas, transações e padrões de consulta semelhantes aos seus.
Checklist antes de fragmentar o banco
- O gargalo foi medido e não pode ser resolvido de forma mais simples?
- A shard key foi testada com distribuição de dados e tráfego?
- As consultas sem chave estão identificadas e possuem estratégia?
- Joins e invariantes críticos permanecem locais sempre que possível?
- Hotspots e grandes tenants têm tratamento previsto?
- Resharding, backup, failover e restauração foram ensaiados?
- Métricas e traces permitem comparar cada shard?
- A migração possui validação e rollback?
O banco distribuído também expõe mais endpoints e credenciais. Incorpore autenticação forte, criptografia, segmentação e as boas práticas de APIs seguras e escaláveis ao plano operacional.
Perguntas frequentes
Sharding melhora qualquer consulta lenta?
Não. Consultas direcionadas podem ficar mais rápidas, mas operações que visitam todos os shards podem ganhar latência de rede e coordenação. Primeiro confirme plano de execução e índices.
Cada shard precisa de réplica?
Em produção, normalmente sim. Sem réplica ou mecanismo equivalente, a falha de um nó torna indisponível a parte do conjunto armazenada nele.
É possível mudar a shard key depois?
Depende da tecnologia, mas geralmente é uma operação cara. Ela pode exigir copiar os dados, acompanhar alterações, validar destinos e transferir o tráfego para um novo mapa.
Sharding funciona em bancos SQL?
Sim. Plataformas e extensões distribuem bancos relacionais, mas joins, chaves estrangeiras, sequências e transações entre shards podem ter restrições ou custos adicionais.
Quantos shards criar no início?
Não existe número universal. Use volume, taxa de operações, capacidade por nó e horizonte de crescimento.
Shards virtuais podem separar a divisão lógica do número atual de máquinas.
O que acontece quando um shard falha?
Sem alta disponibilidade, apenas a parte dos dados daquele shard fica inacessível, mas isso pode quebrar fluxos completos.
Com réplicas, o sistema promove outro nó conforme sua política de failover.
Conclusão
Sharding de banco de dados permite ultrapassar os limites de uma única máquina ao distribuir registros e carga.
A técnica funciona melhor quando a chave acompanha os padrões de acesso e mantém operações relacionadas no mesmo nó.
O verdadeiro trabalho começa depois da divisão: observar hotspots, recuperar falhas, mover dados e controlar consultas entre shards.
Por isso, adote sharding após medir o limite atual, testar a distribuição e preparar migração e rollback. Escalar horizontalmente deve reduzir um gargalo real, não apenas tornar a arquitetura mais impressionante.