Mejores prácticas de OLTP/OLAP

Las cargas de trabajo mixtas necesitan topología y disciplina de GUC, no esperanza. Utilice esta lista de verificación antes de apuntar Metabase al primario de producción en PostgreSQL 18.4.

Cómo usar esta lista

• Asigne cada conexión de BI a una réplica o almacén de datos.
• Establezca los valores predeterminados de los roles antes de otorgar el inicio de sesión de informes.
• Revise pg_stat_activity en el primario semanalmente para buscar consultas de escaneo.

A - Topología

• Enrute BI y SQL ad hoc a réplicas de lectura por defecto. El primario solo para escrituras y lecturas de baja latencia.
• Muestre el retraso de replicación en las herramientas de BI cuando los KPI sean sensibles al tiempo. Confíe pero verifique la marca de tiempo de reproducción.
• Limite pool_size de informes de forma independiente de OLTP. Limite los eliminadores de caché concurrentes.
• Programe ETL por lotes pesados fuera de las horas pico, incluso en réplicas. Proteja la puesta al día de la reproducción.
• Planifique la exportación del almacén de datos antes de que el primario se derrita. Replicación lógica o ETL cuando las réplicas se saturen.

B - GUC y división de roles

• Separe los roles: oltp_app, reporting, admin. Diferentes tiempos de espera y work_mem.
• Mantenga work_mem de OLTP modesto (4-32 MB). Evite los valores predeterminados globales de 256 MB.
• Establezca work_mem de informes solo con pool_size y temp_file_limit. Evite explosiones de RAM y disco.
• Deshabilite o limite las recopilaciones paralelas en el rol OLTP. Habilite en la réplica para análisis.
• Use statement_timeout en segundos para OLTP, minutos para informes. Forzado a través de ALTER ROLE SET.

C - Salvaguardas de consultas y esquemas

• Requiera revisión de EXPLAIN para SQL de informes nuevos. Antes del horario de producción.
• Prefiera vistas materializadas para paneles repetidos. Actualice en la réplica cuando sea posible.
• Evite SELECT * amplios en tablas con mucho TOAST en BI. Proyecte columnas.
• Indexe para rutas OLTP en el primario; desnormalice en la réplica/MV para OLAP. Diferentes patrones de acceso.
• Bloquee informes entre inquilinos sin pruebas de RLS. Conéctese como rol de informes en staging.

D - Monitoreo

• Alerta sobre picos de CPU del primario correlacionados con nombres de usuario de informes. Detector de enrutamiento incorrecto.
• Rastree el SLO de retraso de la réplica durante las ventanas de BI. Escala la réplica antes de que se rompa el SLA de retraso.
• Monitoree temp_bytes en sesiones de rol de informes. Señal de desbordamiento de work_mem.
• Use pg_stat_statements por userid. Cuantifique la cuota de costo de OLAP.
• Revisión post-incidente: ¿hubo análisis en el primario? Causa raíz común.

Preguntas frecuentes

Relacionado

• Conceptos básicos de carga de trabajo - Resumen de conflictos
• Réplicas de lectura para informes - Enrutamiento
• Consulta paralela - Ajuste de trabajadores
• Mejores prácticas de agrupación - Separación de pools

Versiones de pila: Esta página se escribió para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.