Actualización para los perezosos: cómo PostgreSQL 12 mejora el rendimiento

PostgreSQL 12, la última versión de “la mejor base de datos relacional de código abierto del mundo” saldrá en un par de semanas (si todo va según lo planeado). Esto sigue el calendario habitual de lanzar una nueva versión con un montón de funciones nuevas una vez al año y, francamente, eso es impresionante. Por eso me convertí en miembro activo de la comunidad PostgreSQL.

En mi opinión, a diferencia de versiones anteriores, PostgreSQL 12 no contiene una o dos características revolucionarias (como partición o paralelismo de consultas). Una vez bromeé diciendo que la característica principal de PostgreSQL 12 es una mayor estabilidad. ¿No es eso lo que necesita cuando gestiona los datos críticos de su empresa?

Pero PostgreSQL 12 no se detiene ahí: con nuevas funciones y mejoras, las aplicaciones funcionarán mejor, ¡Y todo lo que necesitas hacer es actualizar!

(Bueno, tal vez reconstruir los índices, pero en esta versión no da tanto miedo como estamos acostumbrados).

Será fantástico actualizar PostgreSQL e inmediatamente disfrutar de mejoras significativas sin complicaciones innecesarias. Hace unos años, revisé una actualización de PostgreSQL 9.4 a PostgreSQL 10 y vi cómo la aplicación se aceleró gracias al paralelismo de consultas mejorado en PostgreSQL 10. Y, lo más importante, no se requirió casi nada de mi parte (solo establecí un parámetro de configuración max_parallel_workers).

De acuerdo, es conveniente que las aplicaciones funcionen mejor inmediatamente después de una actualización. Y nos esforzamos mucho en complacer a los usuarios, porque PostgreSQL tiene cada vez más.

Entonces, ¿cómo puede hacerte feliz una simple actualización a PostgreSQL 12? Te lo diré ahora.

Principales mejoras en la indexación

Sin indexación, una base de datos no llegará muy lejos. ¿De qué otra manera puedes encontrar información rápidamente? El sistema de indexación fundamental de PostgreSQL se llama árbol B. Este tipo de índice está optimizado para sistemas de almacenamiento.

Simplemente usamos el operador. CREATE INDEX ON some_table (some_column)y PostgreSQL hace mucho trabajo para mantener el índice actualizado mientras insertamos, actualizamos y eliminamos valores constantemente. Todo funciona por sí solo, como por arte de magia.

Pero los índices PostgreSQL tienen un problema: estan inflados y ocupar espacio adicional en el disco y reducir el rendimiento de la recuperación y actualización de datos. Por "inflación" me refiero a mantener ineficazmente la estructura del índice. Esto puede, o no, estar relacionado con las tuplas de basura que elimina. VACÍO (gracias a Peter Gaghan por la información)Pedro Geoghegan)). La inflación del índice es especialmente notable en cargas de trabajo donde el índice cambia activamente.

PostgreSQL 12 mejora enormemente el rendimiento de los índices del árbol B y los experimentos con puntos de referencia como TPC-C han demostrado que, en promedio, ahora se utiliza un 40% menos de espacio. Ahora dedicamos menos tiempo no sólo a mantener los índices del árbol B (es decir, a las operaciones de escritura), sino también a recuperar datos, porque los índices son mucho más pequeños.

Aplicaciones que actualizan activamente sus tablas, normalmente aplicaciones OLTP (procesamiento de transacciones en tiempo real): utilizará el disco y procesará las solicitudes de manera mucho más eficiente. Cuanto más espacio en disco, más espacio tendrá la base de datos para crecer sin actualizar la infraestructura.

Algunas estrategias de actualización requieren reconstruir los índices del árbol B para aprovechar estos beneficios (p. ej. pg_actualizar no reconstruirá los índices automáticamente). En versiones anteriores de PostgreSQL, la reconstrucción de índices grandes en tablas generaba un tiempo de inactividad significativo porque no se podían realizar cambios mientras tanto. Pero PostgreSQL 12 tiene otra característica interesante: ahora puedes reconstruir índices en paralelo con el comando REINDEXAR CONCURRENTEMENTEpara evitar por completo el tiempo de inactividad.

Hay otras mejoras en la infraestructura de indexación en PostgreSQL 12. Otra cosa donde había algo de magia... registro de escritura anticipada, también conocido como WAL (registro de escritura anticipada). El registro de escritura anticipada registra cada transacción en PostgreSQL en caso de falla y replicación. Las aplicaciones lo utilizan para archivar y recuperación en un momento dado. Por supuesto, el registro de escritura anticipada se escribe en el disco, lo que puede afectar al rendimiento.

PostgreSQL 12 ha reducido la sobrecarga de los registros WAL creados por los índices GiST, GIN y SP-GiST durante la construcción del índice. Esto proporciona varios beneficios tangibles: los registros WAL ocupan menos espacio en disco y los datos se reproducen más rápido, como durante la recuperación ante desastres o la recuperación en un momento dado. Si utiliza 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 la experiencia sin ningún esfuerzo de su parte.

Partición: más grande, mejor y más rápida

PostgreSQL 10 introducido partición declarativa. En PostgreSQL 11 se ha vuelto mucho más fácil de usar. En PostgreSQL 12 puedes cambiar la escala de las secciones.

En PostgreSQL 12, el rendimiento del sistema de particiones ha mejorado significativamente, especialmente si hay miles de particiones en la tabla. Por ejemplo, si una consulta afecta sólo a unas pocas particiones en una tabla con miles de ellas, se ejecutará mucho más rápido. El rendimiento no solo mejora para este tipo de consultas. También notarás cuán rápidas son las operaciones INSERT en tablas con múltiples particiones.

Grabar datos usando COPIA - por cierto, esta es una gran manera descarga masiva de datos y aquí hay un ejemplo recibiendo JSON — Las tablas particionadas en PostgreSQL 12 también se han vuelto más eficientes. Con COPY todo ya era rápido, pero en PostgreSQL 12 vuela absolutamente.

Gracias a estas ventajas, PostgreSQL le permite almacenar conjuntos de datos aún más grandes y facilitar su recuperación. Y ningún esfuerzo de tu parte. Si la aplicación tiene muchas particiones, como la grabación de datos de series temporales, una simple actualización mejorará significativamente su rendimiento.

Si bien esto no es exactamente una mejora de "actualizar y disfrutar", PostgreSQL 12 le permite crear claves externas que hacen referencia a tablas particionadas, lo que hace que trabajar con particiones sea un placer.

CON consultas ahora mejoró mucho

¿Cuándo se aplicó un parche para las expresiones de tabla comunes integradas (también conocido como CTE, también conocido como CON consultas), no podía esperar para escribir un artículo sobre lo felices que estaban los desarrolladores de aplicaciones con PostgreSQL. Esta es una de esas características que acelerará la aplicación. A menos, por supuesto, que utilices CTE.

A menudo encuentro que a los novatos en SQL les encanta usar CTE; si los escribes de cierta manera, realmente se siente como si estuvieras escribiendo un programa imperativo. Personalmente, me gustó reescribir estas consultas para evitar sin CTE y aumentar la productividad. Ahora todo es diferente.

PostgreSQL 12 le permite incorporar un tipo específico de CTE sin efectos secundarios (SELECT), que se utiliza sólo una vez cerca del final de la solicitud. Si hiciera un seguimiento de las consultas CTE que reescribí, la mayoría de ellas entrarían en esta categoría. Esto ayuda a los desarrolladores a escribir código claro que ahora también se ejecuta rápidamente.

Además, PostgreSQL 12 optimiza la ejecución de SQL, sin que usted tenga que hacer nada. Y aunque probablemente no necesite optimizar dichas consultas ahora, es fantástico que PostgreSQL continúe trabajando en la optimización de consultas.

Justo a tiempo (JIT): ahora predeterminado

En sistemas PostgreSQL 12 con soporte LLVM La compilación JIT está habilitada de forma predeterminada. En primer lugar, obtienes apoyo. JIT para algunas operaciones internas, y en segundo lugar, consultas con expresiones (el ejemplo más simple es x + y) en listas de selección (que tienes después de SELECT), agregados, expresiones con cláusulas WHERE y otras pueden usar JIT para mejorar el rendimiento.

Dado que JIT está habilitado de forma predeterminada en PostgreSQL 12, el rendimiento mejorará por sí solo, pero recomiendo probar la aplicación en PostgreSQL 11, que introdujo JIT, para medir el rendimiento de las consultas y ver si necesita ajustar algo.

¿Qué pasa con el resto de las nuevas características de PostgreSQL 12?

PostgreSQL 12 tiene un montón de características nuevas e interesantes, desde la capacidad de explorar datos JSON utilizando expresiones de ruta SQL/JSON estándar hasta la autenticación multifactor con un parámetro. clientcert=verify-full, columnas creadas y mucho más. Suficiente para una publicación aparte.

Al igual que PostgreSQL 10, PostgreSQL 12 mejorará el rendimiento general inmediatamente después de la actualización. Por supuesto, usted puede tener su propio camino: pruebe la aplicación en condiciones similares en el sistema de 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 esperaba, no sea perezoso en las pruebas. aplicaciones a fondo, antes de lanzarlas a producción.

Fuente: habr.com