# Sharding banco dados: o que é e quando particionar

> Sharding banco de dados é uma técnica de escalabilidade horizontal que divide um banco de dados grande em partes menores e independentes chamadas shards, cada uma armazenada em servidores separados. Sharding distribui a carga de trabalho e melhora a performance, mas não é indicado para todos os sistemas. A decisão de particionar deve considerar a complexidade operacional e os requisitos de consulta.

*Blog Sem Juízo · Novidades · 29 de julho de 2026 · Igor Bastos*

Sharding é uma técnica de escalabilidade horizontal que divide um banco de dados grande em partes menores chamadas shards. Cada shard é um subconjunto independente armazenado em servidores diferentes, permitindo distribuir carga e melhorar performance. Mas não é para todo mundo: 

## O que é sharding em banco de dados?

Sharding (ou fragmentação horizontal) é uma técnica de escalabilidade que divide um banco de dados grande em partes menores e independentes, chamadas shards. Cada shard contém um subconjunto dos dados e pode ser armazenado em servidores diferentes. Diferente da replicação, que cria cópias idênticas dos dados, o sharding distribui registros distintos entre os nós. Isso permite que consultas e escritas sejam paralelizadas, reduzindo a carga sobre um único servidor. A técnica é comum em sistemas com grande volume de dados, como redes sociais e plataformas de e-commerce. Mas não é uma bala de prata: a complexidade operacional aumenta e o custo de coordenação entre shards pode ser alto.

## Como funciona a fragmentação horizontal?

A fragmentação horizontal divide uma tabela em linhas. Imagine uma tabela de usuários com 10 milhões de registros. Em vez de armazenar tudo em um banco, você define uma regra, a chave de shard, que determina qual shard cada linha vai parar. Por exemplo, usuários com ID entre 1 e 1.000.000 vão para o Shard A, IDs 1.000.001 a 2.000.000 para o Shard B, e assim por diante. Cada shard é um banco de dados completo, com seu próprio esquema e recursos de CPU, memória e disco. As consultas que filtram pela chave de shard são rápidas, pois só acessam um nó. Consultas que varrem todos os shards (scatter-gather) são mais lentas e complexas.

## Qual a diferença entre sharding e particionamento?

Particionamento é um termo guarda-chuva que inclui sharding. O particionamento pode ser vertical (dividir colunas de uma tabela em tabelas diferentes) ou horizontal (dividir linhas). Sharding é um caso específico de particionamento horizontal em que os fragmentos são armazenados em servidores distintos. Ou seja: todo sharding é particionamento horizontal, mas nem todo particionamento horizontal é sharding, você pode particionar uma tabela dentro do mesmo servidor (em tabelas ou arquivos separados) sem distribuí-la entre máquinas. Sharding implica distribuição física.

## Quando usar sharding no banco de dados?

Use sharding quando o banco de dados único não consegue mais atender à demanda de leitura e escrita, mesmo após otimizações como índices, cache e replicação. Sinais típicos: consultas ficam lentas mesmo com índices bem desenhados, o disco está sempre perto do limite, ou o custo de escalar verticalmente (comprar hardware maior) fica proibitivo. Sharding faz sentido para aplicações com volume de dados na casa dos terabytes ou bilhões de registros, onde a taxa de crescimento é alta e previsível. Exemplo: um sistema de logs que recebe 10 milhões de eventos por dia. Sem sharding, o banco cresce sem controle. Com sharding por data, cada dia vai para um shard diferente, facilitando consultas e descarte de dados antigos.

## Quando não usar sharding?

Não use sharding se o banco cabe em um servidor com folga. A complexidade de gerenciar múltiplos shards, backup, restore, migração, rebalanceamento, só se justifica quando o gargalo é real. Também evite sharding se a aplicação precisa de consultas que cruzem muitos shards com frequência (joins distribuídos são lentos e difíceis). Aplicações com requisitos fortes de consistência transacional (ACID) sofrem em ambientes sharded, pois transações que envolvem múltiplos shards exigem protocolos complexos como two-phase commit. Se o volume de dados é moderado e o crescimento lento, prefira escalar verticalmente ou usar replicação com leitura em réplicas.

## Quais são os tipos de sharding?

Existem três estratégias principais:

**Sharding por intervalo**: divide os dados com base em um intervalo de valores da chave (ex: IDs de 1 a 1 milhão no Shard A, de 1 milhão+1 a 2 milhões no Shard B). É simples de implementar, mas pode causar hotspots se a distribuição dos dados for desigual.

**Sharding por hash**: aplica uma função hash na chave de shard e mapeia o resultado para um shard. Distribui os dados de forma mais uniforme, mas dificulta consultas por intervalo.

**Sharding por diretório**: usa um serviço de lookup que mapeia cada chave para um shard. Flexível para rebalanceamento, mas adiciona latência e um ponto de falha.

## Como escolher a chave de shard?

A chave de shard é a coluna usada para decidir onde cada registro será armazenado. A escolha errada causa hotspots (um shard recebe muito mais carga que os outros) ou consultas lentas. Prefira uma chave com alta cardinalidade (muitos valores distintos) e que seja usada na maioria das consultas da aplicação. Exemplos: ID do usuário, ID do pedido, data/hora. Evite chaves com poucos valores (como status, gênero) ou que mudam com frequência (como endereço de e-mail). Se a consulta mais comum é "buscar pedidos de um usuário", usar user_id como chave de shard é natural, todos os pedidos do mesmo usuário ficam no mesmo shard.

## Quais os desafios do sharding?

O principal desafio é o rebalanceamento. Quando você adiciona ou remove servidores, os dados precisam ser redistribuídos entre os shards, operação complexa e demorada. Outro problema: consultas que não filtram pela chave de shard precisam consultar todos os shards (scatter-gather), aumentando latência e consumo de recursos. Backup e restore também são mais complicados, pois cada shard precisa ser tratado individualmente. Além disso, operações como joins e transações entre shards são caras ou inviáveis. Sistemas sharded exigem planejamento cuidadoso de monitoramento e automação.

## Sharding vs replicação: qual a diferença?

Replicação cria cópias idênticas dos dados em servidores diferentes. O objetivo é disponibilidade e distribuição de leitura, todos os servidores têm o mesmo dado. Sharding divide os dados, cada servidor tem uma parte diferente. Eles podem ser combinados: cada shard pode ter réplicas para alta disponibilidade. A replicação não resolve o problema de escalabilidade de escrita (todas as escritas vão para o primário), enquanto o sharding distribui as escritas entre vários nós. Para aplicações com muita escrita, sharding é mais indicado.

## Sharding é suportado nativamente pelos bancos?

Alguns bancos oferecem sharding nativo: MongoDB (com sharding automático via cluster), MySQL Cluster (NDB), PostgreSQL (via extensões como Citus), Cassandra (particionamento por hash nativo), e bancos NoSQL como DynamoDB e Bigtable. Bancos relacionais tradicionais como MySQL e PostgreSQL não têm sharding nativo embutido, você precisa implementar a lógica na aplicação ou usar middlewares como Vitess (para MySQL) ou pg_shard. Avalie se a complexidade de um banco sharded nativo compensa o custo de aprendizado e operação.

## Como implementar sharding na prática?

Comece com um planejamento: identifique a chave de shard ideal baseada nos padrões de consulta da sua aplicação. Escolha a estratégia (intervalo, hash ou diretório) e defina o número inicial de shards. Implemente na aplicação um roteador que direcione cada consulta para o shard correto. Configure monitoramento para detectar hotspots e crescimento desigual. Prepare um plano de rebalanceamento para quando for necessário adicionar shards. Teste com carga real antes de colocar em produção. Ferramentas como Vitess, Citus e MongoDB Atlas simplificam parte desse trabalho, mas não eliminam a necessidade de entender o comportamento dos dados.

## Vale a pena sharding para projetos pequenos?

Para projetos pequenos ou em estágio inicial, sharding é um exagero. A complexidade operacional e o custo de infraestrutura geralmente superam os benefícios. Um banco bem modelado com índices adequados, cache (Redis, Memcached) e replicação de leitura resolve a maioria dos gargalos. Sharding só faz sentido quando essas opções se esgotam. Comece simples, monitore o crescimento e só pense em fragmentar quando houver dados concretos de que o banco único não escala mais.

## FAQ sobre sharding em banco de dados

### Sharding deixa o banco mais rápido?

Sim, para consultas que filtram pela chave de shard. Como cada shard tem menos dados, as consultas são mais rápidas. Mas consultas que varrem todos os shards podem ficar mais lentas devido ao overhead de coordenação.

### Sharding é a mesma coisa que particionamento?

Não exatamente. Particionamento é dividir uma tabela em partes. Sharding é um particionamento horizontal onde cada parte vai para servidores diferentes. Você pode particionar dentro do mesmo servidor sem sharding.

### Como escolher o número de shards?

Depende do volume de dados e da taxa de crescimento. Uma prática comum é começar com um número que permita crescimento por 12 a 18 meses sem rebalanceamento. Muitos shards pequenos aumentam a complexidade; poucos shards grandes podem não resolver o gargalo.

### Sharding funciona com qualquer banco de dados?

Funciona melhor em bancos NoSQL (MongoDB, Cassandra) que têm suporte nativo. Bancos relacionais tradicionais exigem implementação na aplicação ou uso de middlewares como Vitess ou Citus. Nem todos os bancos suportam transações distribuídas.

### É possível desfazer o sharding depois?

Sim, mas é um processo complexo e demorado. Você precisa consolidar todos os shards de volta em um único banco, o que pode exigir migração offline e causar downtime. Por isso a decisão de sharding deve ser bem avaliada.

### Sharding afeta a consistência dos dados?

Sim. Em ambientes sharded, garantir consistência forte entre shards é difícil e caro. A maioria dos sistemas adota consistência eventual. Se sua aplicação exige transações ACID rigorosas, sharding pode não ser a melhor escolha.

---

Fonte (canonical): https://blogsemjuizo.com.br/novidades/sharding-banco-dados-o-que-e-e-quando-particionar/