Melhores Práticas OLTP/OLAP
Cargas de trabalho mistas exigem topologia e disciplina de GUC, não esperança. Use esta lista de verificação antes de apontar o Metabase para o primário de produção no PostgreSQL 18.4.
Como Usar Esta Lista
- Mapeie cada conexão de BI para uma réplica ou data warehouse.
- Defina os padrões de role antes de conceder login de relatórios.
- Revise
pg_stat_activityno primário semanalmente para consultas de varredura.
A - Topologia
- Direcione BI e SQL ad hoc para réplicas de leitura por padrão. Primário apenas para escritas e leituras de baixa latência.
- Exiba o atraso de replicação nas ferramentas de BI quando os KPIs forem sensíveis ao tempo. Confie, mas verifique o timestamp de reprodução.
- Limite o
pool_sizede relatórios independentemente do OLTP. Limite os "matadores de cache" concorrentes. - Agende ETL pesados fora do horário de pico, mesmo em réplicas. Proteja a recuperação do atraso.
- Planeje a exportação do data warehouse antes que o primário derreta. Replicação lógica ou ETL quando as réplicas saturarem.
B - GUC e Divisão de Roles
- Separe roles:
oltp_app,reporting,admin. Tempos limite ework_memdiferentes. - Mantenha o
work_memdo OLTP modesto (4-32MB). Evite padrões globais de 256MB. - Defina o
work_memde relatórios apenas compool_sizeetemp_file_limit. Evite estouros de RAM e disco. - Desabilite ou limite gathers paralelos na role OLTP. Habilite na réplica para análise.
- Use
statement_timeoutem segundos para OLTP, minutos para relatórios. Imposto viaALTER ROLE SET.
C - Salvaguardas de Consulta e Schema
- Exija revisão de
EXPLAINpara novo SQL de relatórios. Antes do agendamento de produção. - Prefira views materializadas para dashboards repetidos. Atualize na réplica quando possível.
- Evite
SELECT *amplos em tabelas com muito TOAST em BI. Projete colunas. - Indexe para caminhos OLTP no primário; desnormalize na réplica/MV para OLAP. Padrões de acesso diferentes.
- Bloqueie relatórios cross-tenant sem testes de RLS. Conecte-se como role de relatórios em staging.
D - Monitoramento
- Alerta sobre pico de CPU no primário correlacionado com usernames de relatórios. Detector de roteamento incorreto.
- Acompanhe o SLO de atraso da réplica durante janelas de BI. Escale a réplica antes que o SLA de atraso seja quebrado.
- Monitore
temp_bytesem sessões da role de relatórios. Sinal de transbordamento dework_mem. - Use
pg_stat_statementsporuserid. Quantifique o compartilhamento de custo OLAP. - Revisão pós-incidente: houve análise no primário? Causa raiz comum.
FAQs
Uma instância grande serve para MVP?
Sim, brevemente com timeouts rigorosos; planeje a réplica antes da escala de receita.Metabase no primário?
Apenas com usuário somente leitura, timeout agressivo e pool minúsculo; réplica fortemente preferida.Réplica síncrona para BI?
Reduz o atraso; adiciona custo de latência de commit no primário.CDC vs carga de BI?
Ambos competem no primário; monitore slots e volume WAL.Partição para OLAP?
Poda varreduras históricas; ajuda tanto o primário quanto a réplica.Autoscaling na nuvem?
Escale a vCPU/RAM da réplica antes do primário se o BI crescer.MV no primário?
A atualização bloqueia escritas; prefira réplica ou padrões de atualização concorrente.Extensões HTAP?
Avalie separadamente; o PostgreSQL principal ainda precisa de salvaguardas.Fim de mês financeiro?
Pré-escale o pool da réplica; congele SQL ad hoc no primário.Grupo de desempenho completo?
Revisite a seção `EXPLAIN` quando os planos regredirem após a divisão da topologia.Relacionado
- Noções Básicas de Carga de Trabalho - Visão geral de conflitos
- Réplicas de Leitura para Relatórios - Roteamento
- Consulta Paralela - Ajuste de workers
- Melhores Práticas de Pooling - Separação de pools
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.