Melhores Práticas de Séries Temporais
Como Usar Esta Lista
- Aplique ao projetar métricas, eventos ou tabelas de ingestão de IoT.
- Automatize trabalhos de partição e retenção antes do primeiro rollover de mês de produção.
- Revise quando o volume de dados aumentar 10x ou os usuários de BI reclamarem da latência do dashboard.
A - Schema e Tempo
- Use
timestamptzpara todos os timestamps de eventos. Armazene UTC; converta na exibição. - Inclua tempo nos caminhos de acesso primários. Padrão comum btree
(device_id, ts DESC). - Particione por intervalo de tempo em tabelas de alto volume. Mensal ou diário por taxa de ingestão.
- Pré-crie partições com dois meses de antecedência. Cron ou pg_partman; nunca confie na partição
DEFAULTsilenciosamente. - Evite
timestamp without time zone. Bugs de DST e TZ de sessão (veja cenários de defeito).
B - Índices e Consultas
- Adicione BRIN em
tspara partições somente de anexação. Complemento, não substituição, de btree para dispositivo+tempo. - Escopo de dashboards para janelas de tempo. Sem
SELECTilimitado no histórico bruto. - Use agregações contínuas ou rollups materializados. Visualizações horárias/diárias para tráfego de BI.
- Roteie BI de longo alcance para o data warehouse quando o ADR indicar. Janela ativa do Postgres apenas.
- EXPLAIN grandes agregações antes de enviar. Confirme a poda de partições nos planos.
C - Retenção
- Política de retenção como código. Partição
DROP TABLEouadd_retention_policydo Timescale. - Prefira DROP/DETACH em vez de DELETE milhões de linhas. Economiza dor de vacuum e WAL.
- Arquive partições frias para armazenamento de objetos antes de descartar, se a conformidade exigir.
DETACHe depois exporte Parquet. - Documente a substituição de bloqueio legal. Algumas partições congeladas; marque na tabela de metadados.
- Teste a restauração do arquivo anualmente. Dados frios são inúteis se corrompidos.
D - Operações
- Monitore falhas nos limites das partições. Alerte sobre erros de inserção no final do mês.
- Acompanhe o tamanho da tabela e do índice por partição. Preveja o disco antes que surpresas de descarte automático ocorram.
- Execute ANALYZE após preenchimento em massa. O planejador precisa de estatísticas por partição filha.
- Avalie o Timescale apenas via ADR de lista de permissões. Implicações de pré-carga e licenciamento.
- Revise o ADR de offload de OLAP em crescimento 10x. Pacote de evidências do pg_stat_statements.
FAQs
Quando começar a particionar?
Quando consultas de intervalo de tempo ou exclusões de retenção não atingem o SLO; geralmente 50 GB+ ou alta taxa de inserção diária.Partição DEFAULT?
Use apenas como rede de segurança com monitoramento; não como estratégia primária.pg_cron para manutenção?
Agende a criação/descarte de partições e a atualização de MV; requer lista de permissões de extensão.Apenas BRIN?
Não para consultas pontuais de dispositivo; sim como auxiliar em varreduras apenas de tempo.Compressão?
Timescale ou data warehouse colunar; o toast nativo do Postgres não é uma estratégia de compressão de séries temporais.Réplicas de leitura para dashboards?
Sim para o caminho ativo; ainda precisa de rollups para varreduras enormes.Detecção de lacunas?
generate_series para continuidade de gráfico; trabalho de monitoramento separado.Métricas multi-inquilino?
Particione primeiro por tempo; subparticione ou índice tenant_id em segundo lugar.Eventos JSONB?
Extraia colunas indexadas; mantenha o jsonb bruto para depuração com TTL.Verificações de migração em CI?
Afirme que o DDL da partição e o trabalho de retenção foram registrados na mesma versão.Relacionados
- Noções Básicas de Séries Temporais - partição + BRIN
- TimescaleDB - hypertables
- Agregações Contínuas - rollups
- ADR de Offload de OLAP - ClickHouse/BigQuery
- Melhores Práticas de Particionamento - higiene de partição nativa
Versões do Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PostGIS 3.5+, pgbouncer 1.x e Patroni 3.x.