PostgreSQL – La historia hasta ahora

PostgreSQL (o Postgres) comenzó su vida en 1986 como POSTGRES, un proyecto de investigación de la universidad de Berkeley en California, dirigido por el investigador de base de datos de gran influencia Michael Stonebraker. En el diseño de POSTGRES, el equipo de Stonebraker buscó mejorar a INGRES, un proyecto prototipo anterior también dirigido por Stonebraker, principalmente a través del soporte de tipos de datos definidos por el usuario (o “dominios”) con reglas complejas de negocio arbitrarias y otros conceptos relacionados a los objetos.

El equipo de Stonebraker desarrolló POSTGRES activamente por ocho años, y desarrolló características que incluyen reglas, procedimientos y tipos extensivos con índices. POSTGRES luego se comercializó como Illustra, que luego fue adquirido por Informix para integrarlo en su Servidor Universal. En 2001, IBM adquirió Informix por la cifra de 1000 millones de dólares.

POSTGRES usaba su propio lenguaje de consultas, POSTQUEL, Aunque teóricamente superior al dominante SQL, con una mayor profundidad de expresión debido a sus fundamentos teóricos más avanzados, en la práctica POSTQUEL no se alineaba con las necesidades de la industria, que ya se había estandarizado con SQL. Por esa razón, en 1995, dos estudiantes de Ph.D. en el laboratorio de Stonebraker, Andrew Yu y Jolly Chen, reemplazaron POSTQUEL con un subconjunto extendido de SQL. POSTGRES pasó a llamarse Postgres95.

En 1996, el proyecto obtuvo un gran interés desde fuera de la academia. Estaba claro que el nombre Postgre95 no iría bien con el tiempo, y el proyecto se renombró a PostgreSQL. El grupo global de desarrolladores de PostgreSQL, una afiliación internacional de desarrolladores de base de datos que trabajan principalmente en la industria, había nacido y asumió control del código fuente de Postgres. PostgreSQL empezó con la versión 6, para mantener consistencia con el control de versiones de Berkeley, como una señal de reconocimiento a la importante contribución hecha por el equipo de Stonebraker.

Durante esta era de desarrollo de código abierto de la versión 6.*, se desarrollaron muchas de las características que llegarían a definir PostgreSQL, incluyendo:

  • Control de concurrencia multiversión. El bloqueo a nivel de tabla fue reemplazado por MVCC, un sistema sofisticado que previene a los lectores de bloquear a los escritores y a los escritores de bloquear a los lectores. MVCC fue popularizado por Oracle a principio de los 80, y su uso en el gratuito PostgreSQL ayudó a mejorar la adopción de la técnica en los muchos otros sistemas de base de datos que ahora lo soportan.
  • Se hicieron mejoras de velocidad importantes. Si bien el proyecto tiene confiabilidad e integridad de datos priorizada históricamente, hubo un aumento significativo en el rendimiento.
  • Mejora de tipos integrados, incluyendo tipos sofisticados de fecha y hora, y soporte para tipos geométricos avanzados.

Los aproximadamente 4 años y 5 correspondientes versiones principales (de la 7.0 a la 7.4) que marcaron la era 7.* trajeron más mejoras. Incluyendo:

  • En particular, una implementación inicial del WAL (registro de escritura adelantada). El WAL es una familia de técnicas para proveer atomicidad y durabilidad en sistemas de base de datos. Los segmentos de WAL escribe en el disco una descripción de los cambios hechos a la base de datos, antes que tener que aplicar directamente esos cambios.
  • OUTER JOINs
  • TOAST, una técnica para almacenar mayor cantidad de datos comprimidos y fuera de línea, por lo que la base de datos podría, por ejemplo, ser usada para almacenar grandes pasajes de texto eficientemente.
  • Algunos lenguajes de procedimientos, incluyendo PL/PGSQL, basado en el PL/SQL de Oracle.

Si bien la línea 7.* estuvo marcada por mejoras de usabilidad y características avanzadas enfocadas al desarrollador que por mucho superaba a todos los proveedores de bases de datos propietarias, fue la línea 8.*, que duró desde el 2004 hasta el 2009, la que trajo características que previamente se creían ser de la competencia exclusiva de 2 o 3 megacorporaciones. WAL – el registro de escritura anticipada – fue una parte arquitecturalmente integral de muchas de estas características, particularmente la clusterización y características de alta disponibilidad. Fue y es uno de los enfoques continuos de las contribuciones de código abierto por parte de 2ndQuadrant para PostgreSQL. La línea 8.* también es notable por marcar la fundación de 2ndQuadrant, que, desde el principio y a partir de la versión 8.0, estuvo fuertemente involucrado en el proceso de desarrollo de PostgreSQL.

Inicialmente, la versión 8.0 trajo una importante característica: Puntos de restauración, o sub-transacciones, por lo que una pieza atómica de trabajo (es decir, una transacción) puede subdividirse en piezas más pequeñas de trabajo que pueden atómicamente abortarse individualmente, sin la necesidad de abortar la transacción completa. Los puntos de restauración incluso pueden ser anidados arbitrariamente. Tal vez una característica aún más importante introducida en esa versión fue la Restauración de un Punto en el Tiempo, una técnica por medio de la cual es posible proveer respaldos continuos del servidor, o regresar a cierto punto en el pasado antes de una falla. También trajo la tan esperada versión nativa para Windows.

La versión 8.1 de 2005 trajo otra característica de clase empresarial por parte de 2ndQuadrant: Particionamiento de tablas mediante el uso de “exclusión de restricciones”, la cual es una característica que permite al planeador elidir un escaneo en tablas hijas de una tabla madre en una herencia de jerarquía, cuando pude determinar que tal escaneo puede no retornar ningún registro para la consulta en cuestión.

La versión 8.2 en 2006 consolidó las ganancias de las 2 versiones anteriores, con instrumentos mejorados de información de WAL y varias características de recuperación ante fallos. La versión 8.2 también fue notable por ser la versión usada por Greenplum como base para su producto de base de datos propietario, dirigido al mercado de almacenamiento de datos. Mientras que el valor exacto de la adquisición no fue hecho público, Greenplum había planteado, según se informa, cerca de $61 millones en financiación antes de la adquisición, con eso como base, la prensa tecnológica independientemente estimó el valor de la oferta entre $100 y $150 millones.

La versión 8.3 de 2008 marcó un hito en el rendimiento. Trajo una serie de características mayores de rendimiento, incluyendo:

  • HOT (tuplas de sólo tabla), como una optimización que permite el reciclaje de tuplas muertas, no solamente por el usual proceso de VACUUM, sino también que al momento de hacer INSERT o UPDATE, no ocurra ningún cambio a las columnas indexadas. Aparte de mejorar considerablemente el rendimiento, esta optimización también hace el rendimiento más consistente.
  • Commit asíncrono, una característica introducida por Simon Riggs, CTO de 2ndQuadrant para permitirle a las transacciones hacer commit asíncronamente por razones de rendimiento, que pude ser usado por aplicaciones donde esto sea conveniente.
  • Re-escritura del escritor en segundo plano por parte del consultor principal de PostgreSQL de Estados Unidos y experto en rendimiento en Postgres, Gregory Smith, para introducir una nueva estrategia justo a tiempo, que mejoraba considerablemente la eficiencia de la escritura en el disco.
  • Una mejora lideraba por 2ndQuarant a la estrategia de desalojo de caché, para que los escaneos secuenciales grandes no saquen a la fuerza indebidamente páginas de caché usadas frecuentemente del caché del buffer en la misma medida.
  • Módulo pg_standby, escrito por 2ndQuadrant, que permite una fácil gestión de espera semiactiva.

La versión 8.4, la última de la línea 8.*, fue lanzada en 2009. Trajo nuevas mejoras en la usabilidad, características centradas en el desarrollo y rendimiento, incluyendo:

  • Más características avanzadas de SQL, como funciones ventana y expresiones comunes de tabla. Antes de esta versión, estas características estaban exclusivamente disponibles en un pequeño número de sistemas de base de datos propietarios.
  • Restauración paralela: Restaurar la base de datos de un respaldo lógico en paralelo.
  • El mapa de visualización, que reduce notablemente la sobrecarga de vacuum para tablas que no cambian frecuentemente.
  • El mapa de espacio libre en disco, lo que simplificó la gestión del mapa de espacio libre al punto de que ya no es algo que deba ser considerado por los usuarios finales.

La actual línea 9.* representa un cambio para la comunidad PostgreSQL, por varias razones; principalmente, en la mente de la mayoría de los usuarios, por la introducción de esta versión de replicación binaria en tiempo real. Esta fue una característica principal traída por el trabajo de 2ndQuadrant, como un complemento lógico del anterior trabajo para la comunidad de la compañía en las características liberadas de WAL, específicamente, la introducción de la función de espera activa por parte del CTO de 2ndQuadrant Simon Riggs.

Otra razón por la que la línea 9.* representa un cambio es porque con ella, PostgreSQL ha pasado de ser frecuentemente definido por comparaciones con sistemas de gestión de base de datos propietarios a ser considerado estar en la vanguardia, superando a todos sus competidores en un número de áreas importante. Tal vez lo más notable sea que la introducción por parte de 2ndQuadrant de la replicación síncrona en PostgreSQL 9.1 ofrezca algo de inmenso valor: replicación sin pérdida de datos. En una primicia mundial, los usuarios incluso pueden controlar la durabilidad de cada transacción, y todos los niveles de durabilidad pueden co-existir en la misma aplicación.

La línea 9.* también trae una serie de primicias mundiales no directamente relacionadas con WAL. Estas incluyen la característica de aislamiento de instantánea serializable, basado en un reciente y bien recibido documento académico, a través del cual es posible alcanzar verdadera serialización ofrecida por el bloqueo de predicado, sin causar ningún bloquea a las transacciones, y por lo tanto sin ningún bloqueo adicional. También incluye restricciones de exclusión, mediante las cuales es posible solucionar el problema de doble reserva (para evitar la doble contabilización de una sala de conferencias por medio de tener sesiones superpuestas en el mismo cuarto), aplicado de la misma manera que una restricción unique sin el uso de pesados bloqueos explícitos que matan el rendimiento. Un ejemplo adicional de una característica innovadora disponible a partir de PostgreSQL 9.1, es la escritura de expresiones comunes de tabla, introducido por el consultor de 2ndQuadrant Marko Tiikkaja. Esta extensión no estándar de las expresiones comunes de tabla del estándar SQL le permite usar la cláusula WITH que contengan subconsultas que no sean solamente SELECT, sino también INSERT, UPDATE y DELETE. Esto facilita diversos patrones útiles, como el fácil traslado de datos (Haciendo un DELETE en una tabla y un INSERT en otra) dentro de una sola consulta o instantánea.


Stay in touch with us

Subscribe to our monthly newsletter to hear the latest developments from 2ndQuadrant and related technologies.

We’ll also send you any important news or updates that we think you’ll find useful.

We value your privacy and will not pass your details on to anyone else.