PostgreSQL 12 , la última versión de "la mejor base de datos relacional de código abierto del mundo", sale en un par de semanas (si todo sale según lo planeado). Esto corresponde al calendario habitual: una nueva versión con muchas características nuevas sale una vez al año y, francamente, es impresionante. Por lo tanto, me convertí en un miembro activo de la comunidad PostgreSQL.
En mi opinión, a diferencia de las versiones anteriores, PostgreSQL 12 no contiene una o dos funciones revolucionarias (como, por ejemplo, la partición o el paralelismo de las consultas). Una vez bromeé diciendo que la característica principal de PostgreSQL 12 es más estabilidad. ¿No es eso lo que necesita cuando administra datos comerciales críticos?
Pero PostgreSQL 12 no se limita a esto: con nuevas características y mejoras, las aplicaciones funcionarán mejor, ¡ y solo necesita actualizar!
(Bueno, tal vez incluso reconstruir los índices, pero en esta versión ya no da tanto miedo como solíamos hacerlo).
Será genial actualizar PostgreSQL e inmediatamente disfrutar de mejoras significativas sin gestos innecesarios. Hace unos años, analicé la actualización de PostgreSQL 9.4 a PostgreSQL 10 y vi cómo la aplicación se aceleró debido al paralelismo mejorado de consultas en PostgreSQL 10. Y, lo más importante, casi no se me exigía nada (solo establecía el max_parallel_workers configuración max_parallel_workers ).
De acuerdo, es conveniente cuando, justo después de la actualización, las aplicaciones funcionan mejor. Y estamos tratando de complacer a los usuarios, porque PostgreSQL tiene más de ellos.
¿Y cómo una simple actualización a PostgreSQL 12 te hace feliz? Te lo diré ahora.
Grandes mejoras de indexación
Sin indexación, la base de datos no irá muy lejos. ¿Y de qué otra forma encontrar información rápidamente? El sistema de indexación fundamental de PostgreSQL se llama B-tree . Este tipo de índice está optimizado para sistemas de almacenamiento.
Solo usamos la CREATE INDEX ON some_table (some_column) , y PostgreSQL hace un gran trabajo al mantener el índice actualizado mientras constantemente insertamos, actualizamos y eliminamos valores. Todo funciona solo, como por arte de magia.
Pero los índices PostgreSQL tienen un problema: se hinchan y ocupan espacio en disco adicional, y se reduce el rendimiento de recuperación y actualización de datos. Por "hinchazón" me refiero a mantener ineficazmente la estructura del índice. Puede o no ser debido a las tuplas de basura que VACUUM elimina (gracias por la información a Peter Geoghegan ). La hinchazón del índice es particularmente notable en las cargas de trabajo donde el índice está cambiando activamente.
PostgreSQL 12 mejora seriamente el rendimiento de los índices del árbol B, y los experimentos con pruebas como TPC-C mostraron que el espacio ahora se usa, en promedio, en un 40% menos. Ahora dedicamos menos tiempo no solo a mantener los índices del árbol B (es decir, a las operaciones de escritura), sino también a extraer datos, porque los índices se han vuelto mucho más pequeños.
Las aplicaciones que actualizan activamente sus tablas, generalmente aplicaciones OLTP ( procesamiento de transacciones en tiempo real ), son mucho más eficientes en el uso del disco y el procesamiento de solicitudes. Cuanto más espacio en disco, más espacio tiene la base de datos para crecer sin actualizar la infraestructura.
Algunas estrategias de actualización requieren la reconstrucción de los índices del árbol B para aprovecharlas (por ejemplo, pg_upgrade no reconstruirá los índices automáticamente). En versiones anteriores de PostgreSQL, la reconstrucción de grandes índices en tablas condujo a un tiempo de inactividad significativo, porque en ese momento era imposible realizar cambios. Pero PostgreSQL 12 tiene otro truco genial: ahora puede reconstruir índices en paralelo con el comando REINDEX CONCURRENTEMENTE para evitar por completo el tiempo de inactividad.
PostgreSQL 12 tiene otras mejoras en la infraestructura de indexación. Otra cosa que no podría prescindir de la magia es el registro de escritura anticipada, que también es WAL (registro de escritura anticipada). Un registro de escritura anticipada registra cada transacción en PostgreSQL en caso de falla y replicación. Las aplicaciones lo usan para hacer copias de seguridad y restaurar en un momento determinado . Por supuesto, el registro de escritura anticipada se escribe en el disco, y esto puede afectar el rendimiento.
PostgreSQL 12 ha reducido la sobrecarga de los WAL creados por los índices GiST, GIN y SP-GiST al construir el índice. Esto proporciona varias ventajas tangibles: los registros WAL ocupan menos espacio en disco y los datos se reproducen más rápido, por ejemplo, durante la recuperación de una falla o recuperación en un momento determinado. Si usa dichos índices en sus aplicaciones (por ejemplo, las aplicaciones geoespaciales basadas en PostGIS usan mucho el índice GiST), esta es otra característica que mejorará significativamente el rendimiento sin ningún esfuerzo de su parte.
Particionamiento: más grande, mejor, más rápido
PostgreSQL 10 introdujo la partición declarativa . PostgreSQL 11 lo hizo mucho más fácil de usar. En PostgreSQL 12, puede cambiar la escala de las secciones.
En PostgreSQL 12, el rendimiento del sistema de particionamiento es mucho mejor, especialmente si hay miles de secciones en la tabla. Por ejemplo, si una consulta afecta solo unas pocas secciones de una tabla, donde hay miles de ellas, se ejecutará mucho más rápido. Se ha mejorado el rendimiento no solo para este tipo de consultas. También notará cómo las operaciones INSERT se han acelerado en tablas con muchas particiones.
Escribir datos usando COPY , por cierto, esta es una excelente manera de cargar datos en masa y aquí hay un ejemplo de recepción de JSON , en tablas particionadas en PostgreSQL 12 también se ha vuelto más eficiente. Con COPY, todo fue muy rápido, pero en PostgreSQL 12 vuela.
Gracias a estos beneficios, PostgreSQL puede almacenar conjuntos de datos aún más grandes y facilitar la recuperación. Y sin esfuerzo de tu parte. Si la aplicación tiene muchas secciones, por ejemplo, registra datos de series de tiempo, una simple actualización mejorará significativamente su rendimiento.
Aunque esta mejora no proviene completamente de la categoría "actualizar y alegrarse", en PostgreSQL 12 puede crear claves externas que hacen referencia a tablas particionadas para que trabajar con particiones sea un placer.
CON las consultas son mucho mejores
Cuando el parche se aplicó a las expresiones de tabla generalizadas incorporadas (son CTE, también son CON consultas), estaba ansioso por escribir un artículo sobre cómo los desarrolladores de aplicaciones con PostgreSQL estaban encantados . Esta es una de esas características que acelerará la aplicación. A menos, por supuesto, que esté usando CTE.
A menudo noto que a los recién llegados a SQL les gusta usar CTE: si los escribes de cierta manera, sientes directamente que estás escribiendo un programa imperativo. Personalmente, me encantó volver a escribir estas consultas para prescindir de CTE y aumentar el rendimiento. Ahora todo es diferente.
PostgreSQL 12 le permite incrustar un tipo específico de CTE sin efectos secundarios ( SELECT ), que se usa solo una vez cerca del final de la consulta. Si mantuve estadísticas de solicitudes con CTE que reescribí, la mayoría de ellas entrarían en esta categoría. Esto ayuda a los desarrolladores a escribir código comprensible que ahora también funciona rápidamente.
Además, PostgreSQL 12 optimiza la ejecución de SQL en sí, no tiene que hacer nada. Y aunque ahora, probablemente, no necesitaré optimizar tales consultas, es genial que PostgreSQL continúe trabajando en la optimización de consultas.
Just-in-Time (JIT): ahora predeterminado
En los sistemas PostgreSQL 12 con soporte LLVM , la compilación JIT está habilitada de manera predeterminada. En primer lugar, obtiene soporte JIT para algunas operaciones internas y, en segundo lugar, consultas con expresiones (el ejemplo más simple es x + y) en las listas de selección (que tiene después de SELECCIONAR), agregados, expresiones con cláusulas WHERE y otras puede usar JIT para mejorar el rendimiento.
Dado que JIT se incluye en PostgreSQL 12 de manera predeterminada, el rendimiento mejorará por sí solo, pero recomiendo probar la aplicación en PostgreSQL 11, donde JIT parece medir el rendimiento de las consultas y ver si necesita ajustar algo.
Pero, ¿qué pasa con las otras características nuevas de PostgreSQL 12?
PostgreSQL tiene 12 toneladas de nuevas características interesantes, desde la capacidad de examinar datos JSON utilizando expresiones de ruta SQL / JSON estándar hasta la autenticación clientcert=verify-full con el clientcert=verify-full , columnas creadas y mucho más. Suficiente para una publicación separada.
Al igual que PostgreSQL 10, PostgreSQL 12 mejorará el rendimiento general justo después de la actualización. Por supuesto, puede hacerlo a su manera: pruebe la aplicación en condiciones similares en el sistema de trabajo antes de activar las mejoras, como hice con PostgreSQL 10. Incluso si PostgreSQL 12 ya es más estable de lo que esperaba, no sea flojo para probar la calidad de las aplicaciones, antes de lanzarlos en producción.