PostgreSQL – Un peu d’histoire
PostgreSQL (parfois nommé « Postgres ») est né en 1986 sous le nom de POSTGRES, le projet de recherche de l’université de Californie à Berkeley, dirigé par le chercheur influent Michael Stonebraker. La conception initiale de POSTGRES avait pour but d’améliorer le système INGRES, prototype également mis au point par le le professeur Stonebraker. Les principales améliorations envisagées portaient sur les types de données utilisateurs (les « domaines »), les règles métiers complexes et les concepts de bases de données relationnelles à objets.
L’équipe de Stonebraker est restée active sur le développement de POSTGRES pendant huit ans, au cours desquels ils ont développé des fonctionnalités avancées telles que les règles de réécritures de requêtes, les procédures stockées et les types de données extensibles avec support d’indexation. POSTGRES a été ensuite commercialisé sous le nom « Illustra », acheté plus tard par Informix et intégré dans sa suite logicielle « Universal Server ». En 2001, IBM a acquis Informix pour 1 milliard de dollars.
POSTGRES utilisait son propre langage de requêtes, POSTQUEL. Techniquement meilleur que SQL grâce à sa richesse d’expression fondée sur des bases théoriques solides, en pratique POSTQUEL n’était pas ce que l’industrie attendait. C’est pourquoi en 1995 deux thésards encadrés par Stonebraker, Andrew Yu et Jolly Chen, ont remplacé POSTQUEL par SQL. Le projet est alors renommé Postgres95.
En 1996 le projet sort du cadre académique, et il devient clair que le nom Postgres95 ne vieillirait pas bien. Le projet est alors renommé PostgreSQL, et le « PostgreSQL Global Development Group » est créé : il s’agit d’un groupe international de de développeurs, la plupart travaillant dans l’industrie, et qui assument ensemble le contrôle du code de Postgres. La première version de PostgreSQL est numéroté v6, par fidélité aux versions issues de l’époque de Berkeley, et afin de bien montrer les apports réalisés par l’équipe du professeur Stonebraker.
Lors du développement des versions 6.*, de nombreuses fonctionnalités ont été implémentées, dont :
- Le contrôle d’accès simultané. Le verrouillage des tables est remplacé par « MVCC », un système sophistiqué qui permet aux requêtes en lecture de ne pas bloquer les requêtes en écriture et vice-versa
- D’importantes optimisations. Alors que le projet a historiquement privilégié la fiabilité des données et la robustesse, on voit des gains de performances significatifs.
- Des améliorations des types de données intégrés, incluant des fonctions avancées pour les dates et heures et le support des types de données géométriques
Pendant les 4 ans qui ont suivi, 5 nouvelles versions majeures sont produites, de 7.0 à 7.4 ; ces versions ont beaucoup apporté au projet :
- Tout d’abord, une implémentation des WAL (write-ahead logging). Il s’agit d’une famille de techniques permettant de mettre au point l’atomicité et la durabilité des transactions dans un système de bases de données. Des segments qui décrivent les modifications apportées à la base de données sont écrits sur disque avant que ces modifications soient appliquées aux données elles-mêmes.
- Jointures externes (OUTER JOINs)
- TOAST, une technique permettant de stocker des données compressées dans un stockage annexe afin de ne pas impacter les performances des requêtes qui n’ont pas besoin de lire ces données.
- De nombreux langages de procédures stockées, y compris PLpgSQL dont l’objectif est la compatibilité avec le PL/SQL d’Oracle®.
Si les versions 7.x ont surtout vu des améliorations de facilité d’utilisation et des fonctionnalités visant les développeurs, et qui pour plusieurs d’entre elles dépassaient l’offre concurrente des solutions propriétaires, les version 8.x (développées de 2004 à 2009) ont apporté à tous des fonctionnalités jusque là réservées aux budgets faramineux. Les WAL ont été au cœur de plusieurs de ces fonctionnalités, en particulier celles qui ont trait au clustering et à la haute-disponibilité. Cela correspond à l’orientation de 2ndQuadrant, qui contribue de nombreuses améliorations trouvées dans la version Open Source de PostgreSQL. Les versions 8.x sont également notables pour 2ndQuadrant, qui s’est impliqué fortemement dans leur développement.
La version 8.0 a apporté les savepoint, ou sous-transactions, permettant e subdiviser une transaction en sous-ensembles pouvant être annulés sans impacter la transaction principale. Une fonctionnalité plus importante encore a vu le jour en 8.0, le « Point In Time Recovery », une technique grâce à laquelle il est possible de sauvegarder en continu ses bases de données, puis de les restaurer à n’importe quel point dans le passé (typiquement, le point qui précède un incident de production). Cette version est aussi la première version de PostgreSQL à fonctionner sur les machines équipées de Windows.
La version 8.1, distribuée en 2005, contient une autre fonctionnalité développée par 2ndQuadrant pour les entreprises : le partitionnement des tables via les exclusions par contraintes, ce qui permet à PostgreSQL de ne pas parcourir les tables pour lesquelles il prouver l’absence de données ciblées par la requête en cours.
La version 8.2, distribuée en 2006, a consolidé les apports des deux versions précédentes, en particulier en ce qui concerne les WAL et leur utilisation dans le cadre de la reprise après indicent. Cette version est aussi celle sur laquelle Greenplum a basé son développement propriétaire qui cible les besoins des entrepôts de données. 4 ans plus tard, EMC s’est porté acquéreur de Greenplum et de leur solution, pour un montant non divulgué au public. Greenplum cependant avait déjà accumulé 61 millions de dollars d’investissements, ce qui a permis à la presse spécialisée d’estimer l’acquisition entre 100 et 150 millions de dollars.
En 2008 est distribuée la version 8.3, comprenant un grand nombre d’améliorations des performances, dont :
- Une optimisation du VACUUM via la technique appelée HOT pour « Heap-Only Tuples », qui permet d’obtenir des gains de performances spectaculaires mais aussi de stabiliser les caractéristiques de performances
- Les commits asynchrones, par Simon Riggs, directeur technique de 2ndQuadrant, permettent à chaque transaction de faire le compromis entre performances et durabilité
- Une réécriture du « background writer », par Greg Smith, dirigeant de 2ndQuadrant aux USA et expert des performances PostgreSQL, afin de bénéficier d’une stratégie « Just in Time » améliorant considérablement l’efficacité des écritures sur disques
- Une amélioration de la stratégie de gestion du cache afin que les lectures séquentielles de gros volumes de données ne prennent pas toute la place du cache, et dont le développement a été dirigé par 2ndQuadrant
- Le module pg_standby écrit par 2ndQuadrant qui permet de gérer simplement les nœuds « warm standby ».
La version 8.4, dernière sortie de la lignée 8.x, a été distribuée en 2009. Elle apporte de nouvelles fonctionnalités en termes de facilité d’utilisation, outils pour les développeurs et optimisations, dont :
- des outils SQL avancés tels les fonctions « window » et les expressions de tables (CTE, « Common Table Expressions »). Avant cette version, on ne trouvait ces fonctionnalités que dans un très petit nombre de systèmes propriétaires.
- la restauration des données en parallèle.
- La carte de visibilité (« visibility map »), une technique qui permet à VACUUM de ne pas traiter les données statiques.
- l’espace libre à réutiliser dans les tables est maintenu sur disque par le serveur, plutôt qu’en mémoire, libérant ainsi les administrateurs de bases de données de réglages fastidieux.
La lignée courante, 9.x, représente un tournant dans la communauté PostgreSQL, et ce pour plusieurs raisons. Tout d’abord, pour beaucoup d’utilisateurs, grâce à l’arrivée d’une solution de réplication intégrée et facile à déployer. Cette fonctionnalité est principalement due à 2ndQuadrant et fait suite aux développements liés aux WAL dans les versions précédentes, et au travail de Simon Riggs qui a développé « Hot Standby ».
Si la lignée 9.x représente un tel tournant, c’est aussi parce que PostgreSQL est passé de la situation où il était défini par comparaison aux systèmes propriétaires à la situation où il attire plus d’innovations que toutes les autres solutions, et surpasse maintenant la concurrence sur bien des aspects. En particulier, l’implémentation par 2ndQuadrant de la réplication synchrone dans PostgreSQL 9.1 apporte une valeur ajoutée déterminante : une réplication sans perte de données. Première mondiale, il est même possible de contrôler la durabilité de chaque transaction séparemment, et une même application peut mixer tous les niveaux de durabilité.
La lignée 9.x apporte aussi d’autres premières mondiales qui ne sont pas liées au WAL. Il s’agit en particulier du niveau d’isolation des transactions « sérialisable », fondé sur des recherches accadémiques récentes démontrant comment obtenir ce niveau d’isolation en utilisant le « predicate locking » (vérouillage de prédicats) et donc sans bloquer aucune transaction, sans risque de « deadlock ». Cette version inclus également les contraintes d’exclusion, permettant entre autre de régler facilement le problème de la double réservation de salle lorsque les horaires de réservation se recoupent, à nouveau en évitant tout vérouillage excessif. On trouve dans 9.1 les expressions de tables en écriture, développé par le consultant 2ndQuadrant Marko Tiikkaja, et qui autorise l’utilisation de commandes INSERT, UPDATE et DELETE dans une clause WITH, ce qui permet d’exprimer simplement des opérations compliquées.