Sharding de Banco de Dados - Scale Out com Particionamento Horizontal

O que e Sharding

Sharding e uma tecnica que particiona horizontalmente os dados e os armazena em multiplos bancos de dados (shards). Permite lidar com grandes volumes de dados e trafego que um unico banco de dados nao consegue processar.

Diferenca para Replicacao: A replicacao mantem copias dos mesmos dados em multiplos servidores, enquanto o sharding distribui dados diferentes em servidores diferentes.

Como o Sharding Funciona

flowchart TB
    subgraph Before["Antes do Sharding"]
        Single["Banco de Dados Unico<br/>Todos os dados de usuarios<br/>(100 milhoes de registros)"]
    end

flowchart LR
    subgraph After["Apos o Sharding"]
        S0["Shard 0<br/>Usuarios A-F<br/>25 milhoes"]
        S1["Shard 1<br/>Usuarios G-L<br/>25 milhoes"]
        S2["Shard 2<br/>Usuarios M-R<br/>25 milhoes"]
        S3["Shard 3<br/>Usuarios S-Z<br/>25 milhoes"]
    end

Metodos de Sharding

Sharding Baseado em Intervalo

Determina o shard pelo intervalo da chave.

Vantagens: Consultas por intervalo sao eficientes Desvantagens: Tendencia a desequilibrio nos dados

Sharding Baseado em Hash

Determina o shard pelo valor hash da chave.

shard_id = hash(user_id) % num_shards

Vantagens: Dados distribuidos uniformemente Desvantagens: Consultas por intervalo sao ineficientes

Sharding Baseado em Diretorio

Determina o shard atraves de uma tabela de lookup.

Vantagens: Mapeamento flexivel Desvantagens: Overhead do lookup

Escolha da Shard Key

A shard key e o elemento mais importante que determina o sucesso ou fracasso do sharding.

Condicoes de uma Boa Shard Key

• Alta cardinalidade (possui valores diversos)
• Adequada ao padrao de acesso
• Escritas distribuidas uniformemente
• A maioria das consultas inclui a chave

Exemplos de Shard Keys

Problema de Hotspots

Consultas Cross-Shard

Consultas que abrangem multiplos shards se tornam complexas.

Scatter-Gather

flowchart TB
    Client["Cliente"] --> Router["Roteador"]
    Router -->|"Scatter<br/>(Consulta para todos os shards)"| S0["S0"]
    Router --> S1["S1"]
    Router --> S2["S2"]
    Router --> S3["S3"]
    S0 -->|"Gather<br/>(Agrega resultados)"| Router
    S1 --> Router
    S2 --> Router
    S3 --> Router
    Router --> Client

Restricoes de JOIN

-- Dentro do mesmo shard: JOIN normal
SELECT u.name, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.id = 123;  -- Inclui a shard key

-- Cross-shard: juncao no lado da aplicacao
-- 1. Obter dados da tabela users
-- 2. Obter dados da tabela orders
-- 3. Fazer JOIN no lado da aplicacao

Rebalanceamento

E o trabalho de redistribuir dados entre shards.

Quando se Torna Necessario

• Adicao/remocao de shards
• Correcao de desequilibrio de dados
• Otimizacao de performance

Consistent Hashing

Tecnica que minimiza a movimentacao de dados mesmo quando o numero de shards muda.

Desafios do Sharding

Sharding Gerenciado

Criterios para Decisao de Sharding

Quando o sharding e necessario:

• Excede o limite de capacidade de um unico DB
• Throughput de escrita no limite
• Custo de escalabilidade vertical muito alto

Alternativas a considerar primeiro:

• Adicao de read replicas
• Introducao de cache
• Otimizacao de consultas
• Revisao de indices
• Migracao para instancia maior

Resumo

Sharding e uma tecnica poderosa para alcançar escalabilidade horizontal do banco de dados, mas tambem traz complexidade. A escolha da shard key e a chave para o sucesso, e deve-se decidir pela implementacao apos analisar suficientemente os padroes de acesso. Quando possivel, considere usar servicos gerenciados para reduzir a carga operacional.