Operar con una instancia mínima de Postgres de dos núcleos: ideas sobre optimización de consultas

Artículo original ↗ Discusión en Hacker News ↗

Hacer funcionar toda una empresa sobre una pequeña instancia de PostgreSQL de dos núcleos provoca un debate más amplio sobre dónde colocar la complejidad: en un diseño cuidadoso de consultas y la optimización del esquema, o simplemente comprando más capacidad de base de datos. Los comentaristas discuten si conviene trasladar la lógica y los joins a la capa de aplicación o mantener las reglas de negocio y la integridad de los datos en la base de datos, abordando mantenibilidad, rendimiento y garantías ACID. Muchos consideran que la alfabetización básica en SQL, la indexación y el análisis de planes de consulta están infrautilizados, mientras que otros subrayan que el tiempo de desarrollo y el encaje producto-mercado a menudo importan más que exprimir hasta la última gota de eficiencia de la base de datos.

Viabilidad de instancias diminutas de Postgres

  • A muchos comentaristas les gusta el recordatorio de que un hardware modesto (2 núcleos, unos pocos GB de RAM) puede manejar cargas de trabajo serias, haciéndose eco de “hace 20 años hacíamos mucho con bastante menos”.
  • Algunos ejecutan aplicaciones enteras en VMs muy pequeñas o en hosts ARM baratos y reportan buenos TPS/RPS con un diseño cuidadoso y caché.
  • Otros argumentan que, aunque inspira, esto puede ser excesivo cuando las instancias en la nube son relativamente baratas de ampliar.

Trasladar la lógica de la base de datos a la aplicación

  • La línea del artículo de “trasladar la lógica a la aplicación” se debate.
  • Los críticos dicen que mover joins/filtros a la app a menudo aumenta la E/S de red, los viajes de ida y vuelta y la complejidad, y desaprovecha las fortalezas de la BD.
  • Los defensores señalan casos en los que:
    • Los recursos de la app escalan más barato que los recursos de la BD.
    • Los parámetros opcionales o las condiciones complejas se manejan mejor con varias consultas dirigidas que con una gran consulta que “hace de todo”.
    • Dividir joins de “pointer-chasing” en varias consultas indexadas puede hacer que los sistemas sean más “NoSQL-ready” y más fáciles de cachear.

Lógica de negocio en la BD vs en el código

  • Un bando prefiere un uso intensivo de procedimientos almacenados y restricciones para que la lógica crítica sea ACID, centralizada y consistente.
  • Otro bando prefiere una “BD tonta”:
    • Las cargas de trabajo mixtas de computación + datos son más difíciles de perfilar y ajustar.
    • Se considera que los ecosistemas y herramientas de lenguajes de BD (estilo PL/SQL) son más débiles, más difíciles de probar, versionar y documentar.
  • El desacuerdo gira en torno a la mantenibilidad frente a la fuerte integridad de datos, no solo al rendimiento.

Planificación de consultas, joins e índices

  • Los comentaristas cuestionan la idea de que métodos de join como nested loop/hash/merge sean “subóptimos” en general; dependen del contexto.
  • El planificador basado en costes de Postgres puede elegir malos órdenes de joins, especialmente con estadísticas deficientes o muchos joins; la falta de hints explícitos de join frustra a algunos.
  • Se mencionan soluciones: ajustar work_mem, join_collapse_limit, desactivar tipos de join (enable_*), usar WITH MATERIALIZED y entender las estadísticas de las tablas.
  • Existe amplio acuerdo en que entender SQL, los planes de consulta y la indexación es cada vez más raro, pero crucial.

Compromisos entre coste y optimización

  • Un lado: el tiempo de desarrollo es mucho más caro que unos pocos núcleos adicionales o más RAM; sobreoptimizar para ahorrar unos pocos miles al año es ir a lo barato y salir caro.
  • El otro lado: la cultura de “simplemente añade hardware/cloud” lleva a facturas recurrentes masivas; el ajuste básico de consultas y el diseño de esquemas deberían ser práctica estándar.
  • Varios subrayan que una atención modesta y continua al rendimiento evita crisis posteriores y la extinción de incendios por parte de SRE.