La parte de PostgreSQL que más odiamos (2023)

La parte que más odiamos de PostgreSQL

• PostgreSQL se ha consolidado como el DBMS más querido en internet durante los últimos 5 años. Esto se debe a su confiabilidad, funcionalidad, escalabilidad y a que es adecuado para la mayoría de las cargas de trabajo operativas.
• Sin embargo, su implementación del control de concurrencia multiversión (MVCC) es considerada la peor en comparación con otros DBMS relacionales.

¿Qué es el control de concurrencia multiversión?

• El objetivo de MVCC es permitir que varias consultas lean y escriban en la base de datos al mismo tiempo sin interferir entre sí.
• El DBMS mantiene múltiples versiones en lugar de sobrescribir la fila existente, y las consultas eligen la versión adecuada para satisfacer la solicitud.
• Este enfoque elimina la necesidad de bloqueos explícitos de registros y permite que las consultas observen una instantánea de la base de datos.

El control de concurrencia multiversión de PostgreSQL

• Cuando PostgreSQL actualiza una fila existente, usa un método de almacenamiento de versiones append-only que crea una nueva versión para aplicar los cambios.
• Este enfoque provoca varios problemas complejos.

Almacenamiento multiversión

• PostgreSQL almacena todas las versiones de una fila en el mismo espacio de almacenamiento.
• Al actualizar, asigna un nuevo slot de versión, copia la versión existente y aplica los cambios.
• PostgreSQL usa una cadena de versiones para registrar la relación entre versiones.

Vacuum de versiones

• PostgreSQL usa un proceso de vacuum para eliminar versiones antiguas.
• El autovacuum se ejecuta periódicamente para eliminar versiones expiradas y reutilizar el espacio.

Por qué el MVCC de PostgreSQL es el peor

• La implementación de MVCC en PostgreSQL es un diseño de los años 80 y no encaja con los patrones modernos de sistemas log-structured.
• Se explican cuatro problemas principales que surgen del MVCC de PostgreSQL.

Problema 1: copia de versiones

• PostgreSQL copia todas las columnas a la nueva versión, lo que incrementa la duplicación de datos y los requisitos de almacenamiento.
• MySQL y Oracle evitan este problema almacenando deltas.

Problema 2: hinchamiento de tablas

• Las versiones expiradas de PostgreSQL ocupan espacio y, si el autovacuum no logra eliminarlas, la base de datos sigue creciendo.
• Esto degrada el rendimiento de las consultas.

Problema 3: mantenimiento de índices secundarios

• PostgreSQL debe actualizar todos los índices en cada actualización.
• Esto degrada el rendimiento de las consultas.

Problema 4: gestión de vacuum

• El rendimiento de PostgreSQL depende en gran medida de la eficacia del autovacuum.
• Si el autovacuum no funciona correctamente, aparecen problemas de rendimiento.

Resumen de GN⁺

• PostgreSQL sigue siendo un DBMS muy querido, pero su implementación de MVCC no es moderna.
• Resolver los problemas de MVCC de PostgreSQL requiere mucho tiempo y esfuerzo.
• Se puede mejorar el rendimiento optimizando la configuración de autovacuum de PostgreSQL.
• Como alternativas para resolver los problemas de MVCC de PostgreSQL, se pueden considerar MySQL y Oracle.

[GN⁺]

Comentarios de Hacker News

• OrioleDB intentó resolver el problema con un nuevo motor de almacenamiento

  • Si las operaciones son principalmente INSERT, no se requiere espacio adicional
  • Hay un límite en la cantidad de sentencias dentro de una transacción, pero se puede evitar usando COPY FROM
  • Desde la perspectiva del DBA, no es necesario administrar por separado el espacio de rollback/undo

• El diseño de PostgreSQL no es malo en todos los aspectos

  • MySQL y Oracle almacenan deltas comprimidos entre la versión nueva y la versión actual
  • git no almacena diffs y, de forma similar a PostgreSQL, guarda el objeto completo

• La implementación de MVCC en Oracle y MySQL no almacena la dirección física de la nueva versión

  • En su lugar, almacena un identificador lógico para que el DBMS encuentre la dirección física de la versión actual
  • Esto puede hacer más lenta la lectura de índices secundarios, pero reduce la sobrecarga gracias a otras ventajas

• Al actualizar una sola fila en MySQL, SELECT id WHERE something; UPDATE what WHERE id=id es mucho más rápido

  • En tareas comunes no se usa este enfoque, y eso hace más lentas las operaciones DML puntuales

• En la década de 2010, MongoDB fue visto como "webscale" debido a las escrituras no durables

  • Esto fue resultado del marketing

• No está de acuerdo con la explicación sobre pg_repack

  • VACUUM FULL es pesado, pero repack es una alternativa más rápida y liviana

• PostgreSQL ganó popularidad por las siguientes razones

  • seguridad de los datos, ACID, similitud con Oracle, MVCC, cumplimiento del estándar SQL, el equipo de Postgres, la comunidad, los tipos de datos, alto rendimiento y la flexibilidad de BSD
  • PostgreSQL sigue evolucionando constantemente y la comunidad ha jugado un papel importante

• Existe la pregunta de si el almacenamiento completo de nuevas versiones de tuplas-fila en PostgreSQL es una propiedad del motor de almacenamiento predeterminado

• El artículo estaba bien escrito y era fácil de leer y entender

  • Ayudó a comprender los problemas relacionados con el vacuum, y los diagramas también eran buenos