Sharding particiona dados horizontalmente. Escala além de um servidor. Complexo mas necessário para bilhões de rows.
Conceitos Principais
Shard Key
Column para particionar. user_id, tenant_id, geo_region. Escolha afeta distribuição e queries.
Partitioning Strategy
Range: user_id 1-1M → shard1. Hash: hash(user_id) % N. Geo: region = "US" → shard_us.
Routing Layer
Proxy direciona queries ao shard correto. Vitess, Citus, custom. App não sabe de sharding.
Cross-Shard Queries
JOIN entre shards: difícil. Agregações: scatter-gather. Denormalize para evitar.
Passo a Passo
- Escolha Shard Key: Análise: queries mais comuns. user_id para multi-tenant. tenant_id para SaaS. Evite hot shards (distribuição desigual).
- Setup Citus (Postgres): Install Citus extension. SELECT create_distributed_table('users', 'user_id'). Auto-sharding com consistent hashing.
- MongoDB Sharding: sh.enableSharding("mydb"). sh.shardCollection("mydb.users", { user_id: "hashed" }). Mongos router.
- Migrate Data: Incremental: replica e sync. Cutover em janela de manutenção. Validate antes de drop old.
- Handle Cross-Shard: Denormalize: duplicar dados. Application-level JOINs. Aggregation pipelines (MongoDB). Cache results.
Boas Praticas
Recomendacoes
• Shard apenas quando necessário (>10TB)
• Escolha shard key cuidadosamente
• Evite cross-shard queries
• Monitor shard distribution
• Rebalance shards periodicamente
• Test failover
Erros Comuns
Evite estes erros
• Shard muito cedo (over-engineering)
• Shard key errada (hot shards)
• Não planejar cross-shard queries
• Não monitorar distribuição
• Rebalancing manual (automatize)
Checklist
- Shard key escolhida
- Sharding tool configurado
- Data migrada
- Queries testadas
- Monitoring ativo
- Rebalancing automático