, la última versión de "la mejor base de datos relacional de código abierto del mundo", se lanzará en un par de semanas (si todo sale según lo planeado). Esto se alinea con el calendario habitual: una nueva versión con un montón de nuevas características se lanza una vez al año, y, honestamente, eso es impresionante. Por eso me convertí en un miembro activo de la comunidad de PostgreSQL.
En mi opinión, a diferencia de versiones anteriores, PostgreSQL 12 no incluye una o dos funciones revolucionarias (como la partición o el paralelismo de consultas). Bromeé diciendo que la principal característica de PostgreSQL 12 es su mayor estabilidad. ¿Y no es eso lo que se necesita cuando gestionas datos críticos para tu negocio?
Pero PostgreSQL 12 no se detiene ahí: con nuevas características y mejoras, las aplicaciones funcionarán mejor, y solo necesitas hacer una actualización.
(Bueno, tal vez también reindexar, pero en esta versión no es tan complicado como solíamos pensar.)
Sería genial actualizar PostgreSQL y disfrutar inmediatamente de mejoras significativas sin muchas complicaciones. Hace unos años, analicé la actualización de PostgreSQL 9.4 a PostgreSQL 10 y vi cómo se aceleró la aplicación gracias a la mejora del paralelismo de consultas en PostgreSQL 10. Y, lo más importante, casi no se necesitaba nada de mi parte (solo configurar un parámetro de configuración. max_parallel_workers).
Es cómodo cuando las aplicaciones funcionan mejor inmediatamente después de la actualización. Y hacemos todo lo posible para complacer a los usuarios, ya que cada vez hay más para PostgreSQL.
¿Y cómo te hará feliz una simple actualización a PostgreSQL 12? Te lo cuento ahora.
Mejoras serias en la indexación
Sin indexación, la base de datos no avanzará mucho. ¿Cómo más se puede encontrar información rápidamente? El sistema de indexación fundamental de PostgreSQL se llama . Este tipo de índice está optimizado para sistemas de almacenamiento.
Simplemente usamos el operador CREATE INDEX ON some_table (some_column), y PostgreSQL realiza gran parte del trabajo para mantener el índice actualizado mientras seguimos insertando, actualizando y eliminando valores. Todo funciona por sí mismo, como por arte de magia.
Pero los índices de PostgreSQL tienen un problema: se y ocupan espacio adicional en el disco, y el rendimiento de la extracción y actualización de datos disminuye. Por "inflación", me refiero a un mantenimiento ineficaz de la estructura del índice. Esto puede estar, o no estar, relacionado con los tuplas basura que elimina (gracias a la información de Peter Geoghegan ()). La inflación del índice es especialmente notable en cargas de trabajo donde el índice se modifica activamente.
PostgreSQL 12 mejora significativamente el rendimiento de los índices de árbol B, y los experimentos con pruebas tipo TPC-C han demostrado que el espacio utilizado ahora es un 40% menor en promedio. Ahora gastamos menos tiempo no solo en el mantenimiento de los índices de árbol B (es decir, en las operaciones de escritura), sino también en la extracción de datos, ya que los índices se han reducido considerablemente.
Las aplicaciones que actualizan activamente sus tablas, generalmente son aplicaciones OLTP (), utilizarán el disco de manera mucho más eficiente y procesarán las consultas. Cuanto más espacio haya en el disco, más espacio tendrá la base de datos para crecer sin necesidad de actualizar la infraestructura.
Algunas estrategias de actualización requieren reconstruir los índices de árbol B para aprovechar estas ventajas (por ejemplo, no reconstruirá los índices automáticamente). En versiones anteriores de PostgreSQL, reconstruir grandes índices en tablas resultaba en un tiempo de inactividad significativo, dado que durante este tiempo no se podían realizar cambios. Pero en PostgreSQL 12 hay otra característica interesante: ahora se pueden reconstruir los índices de manera paralela con el comando , para evitar completamente el tiempo de inactividad.
En PostgreSQL 12 también hay otras mejoras en la infraestructura de indexación. Otra cosa que no se quedó sin magia es , también conocido como WAL (write-ahead log). El registro de escritura anticipada graba cada transacción en PostgreSQL en caso de fallos y replicación. Las aplicaciones lo utilizan para la archivación y . Por supuesto, el registro de escritura anticipada se escribe en el disco, lo que puede afectar el rendimiento.
En PostgreSQL 12, se redujeron los costos de las entradas WAL generadas por los índices GiST, GIN y SP-GiST al construir un índice. Esto trae varias ventajas notables: las entradas WAL ocupan menos espacio en disco y los datos se reproducen más rápido, por ejemplo, durante la recuperación de fallos o la restauración a un momento específico. Si utilizas estos índices en tus aplicaciones (como es el caso de las aplicaciones geoespaciales que utilizan mucho el índice GiST basado en PostGIS), esta es otra característica que mejorará considerablemente el rendimiento sin ningún esfuerzo adicional de tu parte.
Particionamiento: más, mejor, más rápido
En PostgreSQL 10 se introdujo . En PostgreSQL 11 se volvió mucho más fácil de usar. En PostgreSQL 12 se puede cambiar la escala de las secciones.
En PostgreSQL 12, el rendimiento del sistema de particionamiento ha mejorado considerablemente, especialmente si hay miles de secciones en la tabla. Por ejemplo, si una consulta solo afecta a unas pocas secciones en una tabla con miles de ellas, se ejecutará mucho más rápido. La mejora del rendimiento no se limita a este tipo de consultas. También notarás que las operaciones INSERT en tablas con muchas secciones se han acelerado.
La inserción de datos utilizando — por cierto, es una excelente manera y aquí hay un ejemplo — en las tablas particionadas de PostgreSQL 12 también se ha vuelto más eficiente. Con COPY ya era rápido, pero en PostgreSQL 12 es aún más veloz.
Gracias a estas ventajas, en PostgreSQL se pueden almacenar conjuntos de datos de mayor tamaño, y su recuperación se ha vuelto más sencilla. Y sin ningún esfuerzo de tu parte. Si tu aplicación tiene muchas secciones, por ejemplo, si registra datos de series temporales, una simple actualización mejorará notablemente su rendimiento.
Y aunque esta mejora no es realmente del tipo 'actualizamos y estamos contentos', en PostgreSQL 12 se pueden crear claves externas que apuntan a tablas particionadas, lo que hace que trabajar con particionamiento sea un placer.
Las consultas WITH han mejorado mucho
Cuando (también conocidas como CTE, o consultas WITH), tenía muchas ganas de escribir un artículo sobre cómo los desarrolladores de aplicaciones con PostgreSQL . Esta es una de esas características que acelerará la aplicación. Si es que, por supuesto, está utilizando CTE.
A menudo noto que los principiantes en SQL tienden a usar CTE: si se escriben de una manera específica, sientes que estás escribiendo un programa imperativo. Personalmente, me gustaba reescribir estas consultas para evitarlas. sin CTE y mejorar el rendimiento. Ahora todo es diferente.
PostgreSQL 12 permite incorporar un tipo específico de CTE sin efectos secundarios (SELECCIONAR), que se utiliza solo una vez hacia el final de la consulta. Si llevara un registro de las consultas con CTE que reescribí, la mayoría de ellas caerían en esta categoría. Esto ayuda a los desarrolladores a escribir código entendible que ahora además funciona rápidamente.
Además, PostgreSQL 12 optimiza la ejecución de SQL por sí mismo, no tendrás que hacer nada. Y aunque ahora, probablemente, ya no tendré que optimizar esas consultas, es genial que PostgreSQL siga trabajando en la optimización de consultas.
Just-in-Time (JIT) — ahora por defecto
En sistemas PostgreSQL 12 con soporte La compilación JIT está habilitada por defecto. Primero, obtienes soporte para algunas operaciones internas, y en segundo lugar, las consultas con expresiones (el ejemplo más simple es x + y) en las listas de selección (las que tienes después de SELECT), agregados, expresiones con cláusulas WHERE y demás pueden utilizar JIT para mejorar el rendimiento.
Dado que JIT está habilitado en PostgreSQL 12 por defecto, el rendimiento mejorará por sí mismo, pero recomiendo probar la aplicación en PostgreSQL 11, donde JIT solo apareció, para medir el rendimiento de las consultas y saber si se necesita ajustar algo.
¿Y qué pasa con las demás nuevas funciones de PostgreSQL 12?
PostgreSQL 12 tiene un montón de nuevas funciones interesantes, desde la capacidad de explorar datos JSON utilizando las expresiones estándar de la ruta SQL/JSON hasta la autenticación multifactor con el parámetro clientcert=verify-full, columnas generadas y mucho más. Merece una publicación aparte.
Al igual que PostgreSQL 10, PostgreSQL 12 aumentará el rendimiento general inmediatamente después de la actualización. Por supuesto, puedes tener tu propio enfoque: prueba la aplicación bajo condiciones similares en un sistema en producción antes de habilitar las mejoras, como hice yo con PostgreSQL 10. Incluso si PostgreSQL 12 ya es más estable de lo que pensé, no te des por vencido en realizar pruebas de calidad en las aplicaciones antes de lanzarlas en producción.
Fuente: habr.com
