O Que É Sharding de Banco de Dados? Dividindo Dados Entre Máquinas
Sharding de banco de dados divide um único dataset por múltiplos bancos de dados, cada um contendo um subconjunto dos dados escolhido por uma shard key.
Uma réplica escala leituras, mas não escritas; toda escrita ainda atinge um primário. O sharding escala escritas dividindo os próprios dados: cada shard é um banco de dados separado contendo parte dos dados, selecionada por uma shard key. É poderoso, mas invasivo, consultas, transações e operações todas ficam mais difíceis, então costuma ser um último recurso.
Como o sharding divide dados
Uma shard key, ID de usuário, região, tenant, determina em qual shard uma dada linha vive. Cada shard é um banco de dados independente. Uma consulta por um usuário toca um shard; uma consulta por todos os usuários precisa se espalhar por todos os shards e combinar resultados.
O que ele te dá
- Escala de escrita além de um único primário.
- Datasets menores por shard, mais rápidos de consultar e indexar.
- Isolamento de falha: um shard fora afeta apenas sua fatia de dados.
- Um caminho para além dos limites de uma única máquina.
Os custos que ele adiciona
Consultas e transações entre shards são difíceis ou impossíveis. Escolher uma shard key ruim cria hot spots. Rebalancear dados quando você adiciona shards é uma operação grande. Esses custos são por que o sharding é evitado até que opções mais simples se esgotem.
Testando sistemas com sharding
Testes de banco de dados único não vão pegar bugs de roteamento de shard ou erros de consulta entre shards. O CI deve testar contra uma configuração multi-shard para que roteamento, fan-out e lógica de rebalanceamento sejam exercitados, não apenas presumidos.
Deploys e migrações ficam mais difíceis
Uma migração de esquema precisa rodar em cada shard, e uma operação de resharding é um processo cuidadoso e faseado. Pipelines coordenam e verificam essas mudanças multi-shard, porque uma migração parcial deixa shards inconsistentes.
Configurações de teste multi-shard
Subir várias instâncias de shard a cada execução de CI é intensivo em recursos. Runners aquecidos e bem dimensionados (como o Latchkey oferece) evitam que esses testes realistas e multi-shard arrastem o pipeline.
Principais conclusões
- Sharding divide dados por bancos de dados independentes via uma shard key para escalar escritas.
- Ele torna consultas entre shards, transações e rebalanceamento significativamente mais difíceis.
- Migrações e testes precisam cobrir todos os shards, não um único banco representativo.