Quando NÃO fragmentar
Réplicas de leitura, particionamento e máquinas maiores resolvem a maioria dos problemas de escalabilidade — saiba quando a fragmentação é a resposta errada.
Quando NÃO fragmentar é uma aula grátis de SQL Academy no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de SQL Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de SQL Academy inclui 4 aulas no total.
A fragmentação é o último recurso
A fragmentação multiplica a complexidade operacional. A maioria das aplicações nunca precisa dela. Primeiro, esgote as opções mais simples.
Etapa 1: escalabilidade vertical
Uma máquina maior. As instâncias modernas de nuvem lidam facilmente com:
- 128 núcleos
- 1 TB de RAM
- 50.000 IOPS em NVMe
Isso representa de 100 mil a 500 mil QPS em um único nó do PostgreSQL. A maioria das aplicações se acomoda confortavelmente.
Etapa 2: réplicas de leitura
Se as leituras predominarem, adicione réplicas. Um primary e 3 réplicas podem atender a 10 vezes mais leituras.
Etapa 3: cache
Coloque Redis ou memcached na frente das consultas mais acessadas. Frequentemente, é o ganho mais barato.
Etapa 4: particionamento
O particionamento declarativo nativo do PG resolve o problema de uma "tabela grande demais" dentro de um único servidor. Frequentemente, é 100 vezes mais fácil do que a fragmentação.
Etapa 5: separação de serviços
Mova domínios diferentes para bancos de dados diferentes — banco de pedidos, banco de usuários, banco de análises. Cada um pode escalar de forma independente.
Etapa 6: retire as análises
Consultas OLTP → PostgreSQL. Consultas analíticas → ClickHouse / BigQuery / Snowflake. Muitas histórias de "precisamos fragmentar" são, na verdade, histórias de "as análises estão consumindo nosso OLTP".
Depois, talvez, a fragmentação
Se você ainda estiver ficando sem recursos com 50 TB de dados exclusivamente OLTP e a carga de trabalho exigir mais gravações do que um único servidor consegue suportar, comece a planejar os fragmentos.
Custo operacional da fragmentação
- Mais servidores para monitorar e atualizar
- Os backups entre fragmentos precisam ser coordenados
- As consultas entre fragmentos atingem o código da aplicação
- O reparticionamento é difícil
- Fragmentos sobrecarregados exigem rebalanceamento ativo
A estratégia de "fragmentar tarde"
Desenvolva usando padrões preparados para fragmentação (sempre inclua tenant_id, nunca use contadores incrementados globalmente) para que você CAN fragmentar mais tarde. Mas não fragmente até ser necessário.
Esquema preparado para fragmentação
Mesmo que você permaneça em um único nó, projete como se pudesse fragmentar no futuro:
- tenant_id em cada linha
- UUID ou IDs distribuídos (não use incremento automático)
- Nenhuma sequência globalmente exclusiva
- Chaves estrangeiras dentro do âmbito de um inquilino
Reconheça a compensação
A fragmentação aumenta a capacidade ao custo de recursos. JOINs, transações e consultas ficam mais difíceis. Certifique-se de que o ganho compense.
Recapitulação
A fragmentação resolve um problema real, mas é uma solução pesada.
- Escale verticalmente primeiro
- Use réplicas de leitura e cache
- Faça particionamento antes da fragmentação
- Retire as análises do OLTP
- Projete para permitir a fragmentação e adie a fragmentação de fato
Verificação rápida
Você está considerando a fragmentação porque as consultas OLTP estão lentas. Antes de fragmentar, qual etapa provavelmente ajudará mais?
Perguntas Frequentes
A aula “Quando NÃO fragmentar” é grátis?
Sim — o texto completo de “Quando NÃO fragmentar” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de SQL Academy, atualize para CoddyKit PRO. O curso de SQL Academy inclui 4 aulas no total.
O que vou aprender em “Quando NÃO fragmentar”?
Réplicas de leitura, particionamento e máquinas maiores resolvem a maioria dos problemas de escalabilidade — saiba quando a fragmentação é a resposta errada. Você pratica SQL Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar SQL Academy?
Nenhuma experiência prévia é necessária. SQL Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Quando NÃO fragmentar”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de SQL Academy?
Sim. Cada aula de SQL Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Estratégias de fragmentação: intervalo, hash e diretório
- Consultas entre fragmentos: o problema difícil
- Citus e PostgreSQL distribuído
- Quando NÃO fragmentar