Diagrama de sharding de banco de dados: chaves de shard, roteamento e resharding

O sharding divide um banco de dados em vários, cada um com uma parte dos dados. É a resposta quando uma única máquina não aguenta mais as escritas ou não comporta os dados, e também uma das decisões mais caras na vida de um sistema: consultas, transações, mudanças de schema e operação ficam todas mais difíceis.

Este artigo cobre quando o sharding vale a pena, como escolher uma chave de shard, os principais esquemas de sharding, como as consultas encontram o shard certo e como fazer resharding sem downtime. O diagrama mostra um banco de pedidos com sharding por hash e shards lógicos.

Tente todo o resto primeiro

Antes do sharding, verifique as opções mais baratas, mais ou menos nesta ordem:

1. Corrija consultas e índices. A maioria dos problemas de "banco lento demais" é um índice faltando ou uma consulta que lê demais.
2. Escale verticalmente. Uma máquina maior, com mais memória e discos mais rápidos, dá anos de fôlego a muitos sistemas.
3. Adicione réplicas de leitura para cargas dominadas por leitura; o artigo sobre replicação de banco de dados trata do atraso que vem com elas.
4. Coloque em cache as leituras mais frequentes, como no artigo sobre estratégias de cache.
5. Divida por função: mova as tabelas de analytics, busca ou auditoria para bancos próprios.

Faça sharding quando as escritas ou o volume de dados passarem do que um primário aguenta, mesmo depois desses passos, e a tendência indicar que vai piorar.

Escolhendo a chave de shard

A chave de shard decide em qual shard uma linha fica. Uma boa chave tem três propriedades:

• Toda consulta frequente a inclui. Se a consulta da lista de pedidos filtra por cliente, customer_id deixa o roteador enviá-la a um único shard. Uma consulta sem a chave precisa perguntar a todos os shards.
• Ela distribui a carga de forma uniforme. Muitos valores distintos, sem nenhum valor isolado gerando uma grande fatia do tráfego.
• Ela mantém juntos os dados relacionados. Todos os pedidos, itens e pagamentos de um cliente no mesmo shard significam que transações e joins continuam locais.

Num SaaS multi-tenant, a chave costuma ser o ID do tenant. Num app de consumo, o ID do usuário ou do cliente. Cuidado com chaves que parecem boas mas concentram carga, como um timestamp (todas as escritas novas vão para um shard) ou um código de país (um país domina).

Range, hash ou diretório

Um híbrido comum: calcule o hash da chave para um número fixo de shards lógicos (digamos 1.024) e mantenha um pequeno diretório que mapeia shards lógicos para hosts físicos. As chaves nunca mudam de shard lógico; só shards lógicos inteiros mudam de host. A equipe de engenharia do Instagram descreveu essa abordagem em 2012, com milhares de shards lógicos sobre muito menos servidores de banco de dados.

Roteando consultas

Alguma coisa precisa saber onde cada chave mora:

• Na aplicação, por meio de uma biblioteca que calcula o hash da chave e procura o host. É simples, mas todo serviço e toda linguagem precisam da mesma lógica.
• Num proxy entre a aplicação e os bancos. O Vitess faz isso para MySQL com o proxy VTGate, e o Citus faz para Postgres por meio de um nó coordenador.

Em qualquer caso, faça cache do mapa de shards e recarregue-o quando mudar. Um mapa desatualizado durante uma migração é o bug clássico de resharding: um roteador escreve no host antigo depois da virada, e a linha some silenciosamente do novo. Versione o mapa e rejeite escritas que carreguem uma versão antiga. Consultas sem a chave de shard são espalhadas para todos os shards e os resultados são combinados, o que funciona para tarefas administrativas raras e falha como caminho de acesso normal.

Resharding sem downtime

Com shards lógicos, adicionar capacidade significa mover alguns shards lógicos para um host novo:

1. Copie os dados dos shards lógicos para o host novo enquanto o antigo continua atendendo.
2. Transmita as mudanças em andamento, usando a replicação do banco ou change data capture, até a cópia alcançar o original.
3. Bloqueie rapidamente as escritas desses shards lógicos, deixe as últimas mudanças chegarem, atualize o mapa de shards e retome.
4. Verifique e depois apague os dados movidos do host antigo.

Vitess e Citus automatizam versões desse fluxo. Ensaie antes de precisar; fazer resharding sob carga pela primeira vez é um dia ruim.

IDs que funcionam entre shards

Uma sequência por banco distribui os mesmos IDs em todos os shards. Use IDs únicos sem coordenação: UUIDs (a versão 7 os mantém mais ou menos ordenados no tempo, o que é melhor para os índices) ou IDs de 64 bits no estilo Snowflake, que combinam um timestamp, um número de shard ou de máquina e um contador. Embutir o número do shard lógico no ID tem um bônus: só com um ID de pedido, o roteador sabe onde procurar sem perguntar a ninguém.

O diagrama de arquitetura

Como ler:

• Esquerda: o serviço de pedidos envia toda consulta com um ID de cliente ao roteador de shards.
• Centro: o roteador calcula o hash do ID do cliente para um de 1.024 shards lógicos e encontra o host no mapa de shards em cache (tracejado).
• Direita: quatro hosts Postgres guardam 256 shards lógicos cada. O host 4 está movendo sua metade superior para um novo host 5, a etapa de resharding em andamento.
• Canto superior direito: relatórios que cruzam clientes leem um data warehouse analítico alimentado por change data capture, então nunca se espalham pelos shards.
• O bloco Markdown lista as regras que todos que escrevem consultas precisam seguir.

Os custos que você aceita

O diagrama de arquitetura SaaS multi-tenant mostra a variante deste design com um shard por tenant, em que os trade-offs abaixo valem por tenant.

• Transações entre shards viram transações distribuídas ou sagas. Projete para que sejam raras.
• Restrições de unicidade entre shards precisam de um esquema de IDs global em vez de uma sequência por banco.
• Mudanças de schema rodam em todos os shards, então as migrações precisam de ferramentas e devem tolerar conclusão parcial.
• A operação se multiplica: backups, upgrades e monitoramento para cada shard.

O que colocar num diagrama de sharding

• A chave de shard e o esquema (hash, range, diretório).
• Shards lógicos e físicos, se você os separa.
• Onde o roteamento acontece: biblioteca, proxy ou coordenador.
• O caminho das consultas sem a chave, como um data warehouse ou um índice de busca.
• O estado do resharding, quando uma migração está em andamento.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione nós Contêiner do pack Modelo C4 para o serviço e o roteador de shards, e um Banco de dados para o mapa de shards.
3. Adicione nós Postgres do pack Dados para os hosts, rotulados com suas faixas de shards lógicos, mais um para o host novo.
4. Adicione um Armazém de dados do pack Dados para os relatórios, alimentado por uma aresta CDC pontilhada.
5. Desenhe a migração de resharding como uma aresta tracejada e adicione um bloco Markdown do pack Básico com as regras de sharding.

O exemplo usa 10 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

Qual a diferença entre sharding e particionamento? Particionamento normalmente significa dividir uma tabela dentro de um único servidor de banco de dados. Sharding espalha os dados por vários servidores, e cada um guarda só uma parte.

Como escolho uma chave de shard? Escolha o atributo pelo qual toda consulta frequente filtra e que mantém juntos os dados relacionados, com muitos valores distintos e carga uniforme, como um ID de tenant ou de cliente.

O que são shards lógicos? Um número fixo e grande de buckets de hash mapeados para menos servidores físicos. Mover shards lógicos inteiros entre servidores evita recalcular o hash de cada chave quando você adiciona capacidade.

Como rodo consultas em todos os shards? Evite-as nos caminhos críticos. Para relatórios, replique os dados num data warehouse; para tarefas administrativas raras, uma consulta espalhada pelo roteador é aceitável.

Quando devo fazer sharding? Quando o volume de escrita ou o tamanho dos dados passarem do que um primário único bem ajustado aguenta e a tendência continuar, depois de indexação, escala vertical, réplicas, cache e divisão por função.

Comece grátis — um assento, sem cartão de crédito.