Ha sido un gran año para la base de datos relacional de código abierto PostgreSQL. Los desarrolladores de Stack Overflow la nombraron la base de datos más buscada en 2021 y DB-Engines la nombró Sistema de Gestión de Bases de Datos del Año por tercera vez. Así que cuando los responsables de su mantenimiento lanzaron la versión 14 el mes pasado, era mejor que dejara huella. La nueva versión viene con más de 220 parches, lo que supone un aumento del 30% respecto a lo habitual.
Umair Shahid, responsable de PostgreSQL en el proveedor de software de rendimiento de bases de datos empresariales Percona, así como presidente del comité del código de conducta de PostgreSQL, líder de los grupos de usuarios en Islamabad y Dubai, y parte del comité de grupos de usuarios de la Asociación PostgreSQL de EE.UU. (PgUS); destaca las actualizaciones de la versión 14 en cuanto a rendimiento, escalado horizontal, observabilidad, experiencia del desarrollador y seguridad, que te traemos ahora.
PostgreSQL v14.0: Mejora del rendimiento
Shahid agrupó las mejoras de rendimiento en dos grupos: las que «simplemente funcionan» detrás de la escena sin la intervención del usuario, y las que requieren cambios de configuración para funcionar. Ambas aumentarán la eficiencia del almacenamiento y de los recursos, lo que por supuesto reduce el coste.
La reducción de la saturación es una de esas mejoras entre bastidores. Los índices que se actualizan con frecuencia tienden a tener tuplas muertas -cualquier registro que se haya eliminado pero que siga ocupando espacio- que provocan la saturación del índice. Normalmente, estas tuplas se eliminan sólo cuando se ejecuta un vacío. Entre vacíos, a medida que la página se llena, una actualización o inserción provocará una división de la página, algo que no es reversible, explicó Shahid.
Esta división se produciría aunque las tuplas muertas dentro de la página existente se hubieran eliminado, dejando espacio para tuplas adicionales. En PostgreSQL 14, las tuplas muertas se detectan automáticamente y se eliminan incluso entre vacíos, lo que permite reducir el número de divisiones de página, lo que a su vez reduce el hinchamiento del índice.
Del mismo modo, cuando se eliminan datos y se ejecuta un vacío, antes de 14, PostgreSQL marcaba esos datos como a eliminar y luego esperaba a la siguiente ronda de vacío para liberar realmente el espacio. Un nuevo algoritmo permite el borrado ansioso de esos datos, con lo que se libera el espacio de forma más eficiente.
El aspirador es ahora capaz de identificar y liberar el espacio de una sola vez». Shahid lo calificó como «una forma más eficaz de reducir la utilización del espacio y aumentar la eficiencia».
Aun así, los desarrolladores y los administradores de bases de datos dispondrán del habitual búfer de recuperación en un momento dado.
Esta versión también aporta más funciones a la ejecución de consultas en paralelo, en la que PostgreSQL puede idear planes de consulta que pueden aprovechar varias CPU para responder a las consultas más rápidamente. Ahora tu base de datos puede ejecutar consultas en paralelo para RETURN QUERY y REFRESH MATERIALIZED VIEW.
Otras actualizaciones destacadas incluyen el modo pipeline para LibPQ, que es la interfaz que utilizan los desarrolladores para conectar su aplicación a la base de datos. Con PostgreSQL, ahora tienen la posibilidad de utilizar un modo pipeline. LibPQ solía ser de un solo hilo, en el que esperaba a que se completara la ejecución de una consulta antes de enviar la siguiente a la base de datos. Ahora, los desarrolladores pueden introducir varias transacciones en la canalización y LibPQ las ejecutará turno a turno para retroalimentar los resultados a la aplicación. La aplicación ya no tiene que esperar a que se complete la primera transacción para ejecutar la siguiente.
Esta fue una de las actualizaciones en las que Shahid comentó: «¿Por qué no pensamos en esto antes? ¡Es algo tan obvio! Pero así es como progresa la tecnología».
Otra posible obviedad a posteriori es la actualización de TOAST, que ahora permite la compresión LZ4. TOAST es un sistema que permite almacenar datos mucho más grandes. Antes de la versión 14, utilizaba PGLZ, que es un algoritmo de compresión muy rápido, pero la relación de compresión real era pequeña. LZ4 también es muy rápido -Shahid dijo que es sin pérdidas, lo que significa que no se pierden datos, como ocurriría con una fotografía comprimida que aparece pixelada- y también tiene una alta relación de compresión.
Dijo que varía según los datos, pero que el algoritmo utiliza inteligentemente el espacio que necesita para los datos. Siguiendo con el ejemplo de la foto, si tuvieras una de un cielo azul claro, la comprimiría con una relación de compresión mucho mayor que una foto muy colorida de un bosque otoñal.
PostgreSQL v14.0: Escalabilidad horizontal y cargas de trabajo distribuidas
Lo siguiente en las adiciones de esta versión es la replicación de transacciones en curso. Una configuración típica de clúster casi nunca tendrá un único nodo, porque se convertiría en el único punto de fallo. Normalmente se distribuye con un nodo primario y nodos secundarios que se comunican entre sí para asegurarse de que se sincronizan. Antes, las transacciones grandes se escribían en el disco hasta que se completaba la transacción, y sólo entonces se replicaban a los nodos secundarios. Con PostgreSQL 14, las transacciones en curso pueden replicarse a los nodos en espera, sin necesidad de esperar a que se complete la transacción.
Las otras actualizaciones de la escalabilidad horizontal tienen que ver con el Foreign Data Wrapper. Con un FDW, tienes la posibilidad de fragmentar o trocear los datos de forma que puedas distribuirlos entre distintos servidores para conseguir una escalabilidad horizontal para cargas de trabajo distribuidas. Ahora puedes realizar inserciones masivas en lugar de fila por fila, no sólo en las tablas locales sino también en las extranjeras.
Además, mientras se ejecuta una consulta, se realiza el escaneo o lectura de la tabla para saber de dónde obtener los datos. Las consultas locales podían ejecutarse en paralelo desde la versión 12, pero ahora también puedes ejecutar escaneos paralelos de tablas externas.
PostgreSQL v14.0: Observabilidad
También se han realizado muchas mejoras en la observabilidad de la base de datos para los administradores de la misma, ofreciendo una visión más profunda y estadísticas.
El motor principal de PostgreSQL expone una API que permite a los usuarios escribir extensiones personalizadas para mejorar la funcionalidad sin hacer ningún cambio en el motor principal. Una de las extensiones más populares es pg_stat_statement, que controla las consultas en la base de datos y hace un seguimiento de las estadísticas. Utiliza el hashing de las consultas para asignar identificadores únicos a las consultas que luego puede rastrear a través del núcleo del servidor.
«En la versión 14 de PostgreSQL, hemos llevado esa técnica de hashing de la extensión al servidor central, de modo que puedes utilizar el mismo hash y trabajar con cualquier otra extensión para la misma consulta». Shahid continuó diciendo que, antes, sólo el servidor central y pg_stat_statement conocían ese ID – ahora cualquier extensión puede utilizar el mismo ID, lo que permite una observabilidad mucho más rica en todo el sistema PostgreSQL y en las funciones de registro.
PostgreSQL v14.0: Comodidad para el desarrollador
«Si alguien está desarrollando una aplicación, no puedes esperar que sea un experto en bases de datos», dijo Shahid.
Entre otras mejoras de la experiencia del desarrollador, Shahid dijo que han realizado mejoras en JSON que perfeccionan aún más la usabilidad de los datos no estructurados, para que los desarrolladores puedan utilizarlos en los lenguajes que les gustan, incluidos Python y Java.
«No se trata sólo de obtener la función en un tipo de datos nativo, sino de asegurarse de que los desarrolladores la utilicen de la forma en que están acostumbrados», dijo.
También han añadido tipos de rango múltiple. Antes de esta versión, los desarrolladores sólo podían tener un tipo de rango, con puntos de inicio y finalización específicos, como que una oficina esté abierta de 9 a 17 h. Ahora, puedes especificar un rango no contiguo en una matriz de rangos, como que esta sala de reuniones esté ocupada de 9 a 9:30 h, de 11 a 12 h, etc. Ahora puedes mantener todo el periodo del día en la misma variable.
Los típicos procedimientos almacenados se añadieron en PostgreSQL 11, dando a los desarrolladores el control transaccional en un bloque de código. PostgreSQL 14 implementa el parámetro OUT, lo que permite a los desarrolladores devolver datos utilizando varios parámetros en sus procedimientos almacenados. Esta característica será familiar para los desarrolladores de Oracle y una adición bienvenida para la gente que intenta migrar de Oracle a PostgreSQL.
PostgreSQL v14.0: Seguridad
Quizá la característica más interesante para muchos usuarios no se mencionó hasta el final de nuestra entrevista con Shahid: la seguridad.
Una de las posibles desventajas de PostgreSQL antes de esta versión era que el método de autenticación por defecto había sido MD5, que, entre otras cosas, ya no cumple la norma de tarjetas de pago PCI DSS. MD5 aprovecha una clave encriptada que poseen ambas partes. «Cuando envías tus datos, necesitas tener un mecanismo para intentar asegurarte de que la otra parte sabe cómo desencriptar».
Sin embargo, explicó Shahid, si alguien está husmeando en el medio, hay una pequeña posibilidad de que MD5 se descifre por el camino.
El método de autenticación por defecto de PostgreSQL es ahora SCRAM, el Mecanismo de Autenticación de Respuesta de Desafío Salado, que cumple la norma de la industria con un mayor nivel de cumplimiento. El desafío salado envía datos sin decirle al destinatario cómo descifrarlos: ambas partes ya saben cómo hacerlo. Eso elimina el poder del sniffer.
También han realizado actualizaciones de los roles predefinidos, como pg_read_all_data que permite asignar un privilegio a un usuario que tiene la capacidad de leer todos los datos. El caso de uso común es el de los analistas o el de alguien encargado de configurar una plataforma de replicación en la que se añaden nuevas tablas.
También añadieron el pg_write_all_data. Shahid dio el ejemplo de una tabla que establece las características de las tablas.
«pg_write_all_data concede privilegios de tipo superusuario al usuario, por lo que debe utilizarse con moderación. Pero en los casos en que se necesita, proporciona mucha comodidad. Las aplicaciones evolucionan, las bases de datos evolucionan, los esquemas evolucionan. Un privilegio general para escribir todos los datos puede garantizar que el usuario siga teniendo los permisos necesarios, que no se pierda la asignación explícita de dichos permisos con las actualizaciones», dijo Shahid.
Hizo hincapié en que se trata de una comodidad que debe utilizarse sólo con moderación.
¿Qué hace que PostgreSQL sea tan popular?
«La licencia tiene mucho que ver con ello», argumenta Shahid. «No porque la gente lea realmente la licencia para intentar entenderla. Es que en el código abierto hay distintos grados de apertura».
Continuó diciendo que la licencia de código abierto de PostgreSQL es lo más liberal posible, ya que consta de sólo 143 palabras que resumió como:
- Haz lo que quieras con ella.
- No culpes a la Universidad de California si algo va mal.
Shahid explicó que esta apertura es la razón por la que todos los principales proveedores de la nube pueden ofrecer soluciones PostgreSQL y por la que hay tantas bifurcaciones y cambios de marca de la base de datos.
Además, al igual que sirve a los sistemas distribuidos, es el producto de una comunidad de código abierto muy distribuida.
«Tiene una comunidad única detrás del proyecto en el sentido de que no está dirigido por una única entidad comercial. PostgreSQL es una verdadera empresa multiusuario, multirregional y multiétnica. El único aspecto de la toma de decisiones es ‘Lo que es bueno para el proyecto’, no ‘Lo que es bueno para el negocio’, porque no hay negocio», dijo, recordando que el código abierto es un modelo de desarrollo, no un modelo de negocio.
Dijo que si se miran las cifras absolutas, no hay duda de que MySQL y Oracle tienen más usuarios, pero que el crecimiento ha sido más bien plano, mientras que las soluciones de código abierto como PostgreSQL siguen un crecimiento ascendente.
Y recuerda, si quieres aprender un poco más sobre PostgreSQL recuerda que puedes consultar nuestro tutorial: Cómo integrar la base de datos postgreSQL en XAMPP en Windows
