Decisão: qual estratégia de particionamento?
O particionamento divide uma tabela grande em várias partes físicas sob um único nome lógico, facilitando a remoção de dados antigos e permitindo que as consultas olhem apenas as partes relevantes (partition pruning). Em tabelas pequenas, porém, só adiciona complexidade. Esta árvore primeiro questiona se o particionamento é realmente necessário e depois orienta você entre Range, List, Hash e Composite com base nos padrões de acesso e distribuição.
A tabela é realmente grande o suficiente para precisar de particionamento?
Particionamento não é mágica de desempenho; é uma ferramenta de escala e de manutenção (ciclo de vida). Se a tabela não for grande o suficiente ou as consultas já tiverem bom desempenho com índices, o particionamento só traz complexidade de planos e sobrecarga de gerenciamento. Sua tabela está chegando a dezenas de milhões+ de linhas/centenas de GB, ou ainda é pequena/média?
- Sim, é muito grande e/ou dados antigos precisam ser excluídos/arquivados em massa
- Não, tabela pequena/média, ou não tenho certeza
Como você acessa os dados e como eles devem ser divididos?
A chave de partição deve ser a coluna pela qual a maioria das consultas filtra; só assim o pruning entra em ação. Qual é o padrão de acesso dominante? Por data/intervalos sequenciais (últimos 30 dias), por valores específicos de categoria/região, ou não há filtro claro e você quer distribuir a carga de forma uniforme?
- Intervalos sequenciais como data/número de sequência (últimos X dias, por mês)
- Conjuntos de valores discretos como categoria/região/tenant
- Sem intervalo/categoria claros; o objetivo é distribuir a carga uniformemente
- Data e alto volume ao mesmo tempo; é preciso dividir em duas dimensões
Recomendação: não particione (ainda)
O particionamento não traz benefício em tabelas pequenas/médias; índices bem escolhidos e manutenção normal bastam. O particionamento prematuro complica os planos de execução, perde o pruning com a chave errada e adiciona sobrecarga operacional.
Recomendação: particionamento por Range
O particionamento por Range divide as linhas por intervalos sequenciais de uma coluna (ex.: intervalos de datas: uma partição por mês/trimestre). É a estratégia mais comum e mais poderosa para séries temporais e tabelas em crescimento contínuo.
Recomendação: particionamento por List
O particionamento por List agrupa as linhas por valores discretos e conhecidos de uma coluna (ex.: region = 'TR','EU','US' ou ID do tenant). Quando existem categorias naturais e finitas, ele torna o acesso e o gerenciamento claros.
Recomendação: particionamento por Hash (distribuição uniforme)
O particionamento por Hash distribui as linhas de forma relativamente uniforme entre um número predefinido de partições com base no hash da coluna-chave. É usado para evitar hotspots e equilibrar a carga quando não há intervalo/categoria natural.
Recomendação: particionamento Composite (multinível)
O particionamento Composite combina duas estratégias: divide primeiro no nível superior e depois subdivide cada partição em subpartições (ex.: Range-by-Hash ou Range-by-List). É usado quando são necessários ao mesmo tempo ciclo de vida baseado em tempo e distribuição uniforme/separação por categoria.