Les fonctionnalités de PostgreSQL 9.1
Cet article analyse les fonctionnalités de PostgreSQL 9.1. Pour une vision plus large, référez vous à notre page sur l'histoire de PostgreSQL.
La sortie de PostgreSQL 9.1 le 12 septembre 2011 a été un évènement révolutionnaire dans la communauté PostgreSQL, pour les développeurs de PostgreSQL en général et les équipes 2ndQuadrant en particulier : en effet, cette version introduit de plusieurs fonctionnalités qui sont des premières mondiales, continuant ainsi de définir l'état de l'art des systèmes de gestion de bases de données relationnelles.
En particulier, 9.1 implémente la Réplication Synchrone.
Conçue et développée par Simon Riggs, directeur technique de 2ndQuadrant, la réplication synchrone résous un problème très différent de celui que la réplication asynchrone résolvait déjà dans la version 9.0, mais son implémentation bénéficie directement du travail que Simon a réalisé dans les versions précédentes de PostgreSQL. La réplication synchrone permet de valider les modification d'une transaction sur un serveur « standby » avant de les valider localement, étendant ainsi le niveau classique de la durabilité des données. Le « D » dans ACID, la durabilité est la garantie de retrouver les données qu'une transaction a commité même en cas d'échec matériel tel qu'une coupure de courrant.
« Heroku anime la plus grand offre de bases de données en tant que service dans le monde »… « L'arrivée de la réplication synchrone avec PostgreSQL 9.1 fourni à nos clients des moyens innovants de protéger leurs données critiques, et renforce PostgreSQL comme l'une des solutions de gestion de bases de données les plus agiles du marché. »
James Lindenbaum, co fondateur Heroku.
La réplication synchrone, de par sa nature, affecte les performances de façon plus importante que la réplication asynchrone, puisque pour garantir la durabilité des données le serveur principal doit attendre que le « standby » ait confirmé la transaction. Cette propriété rend la réplication synchrone extrêmement sensible à la latence de la communication entre les serveurs, en particulier sur de longues distances, où on ne sait toujours pas s'abstraire des limites imposées par la vitesse de la lumière.
Traditionnellement, la réplication synchrone est utilisée lorsque le besoin de durabilité est incontournable et dans les cas où son impact sur les performances ne place pas la solution hors budgets. C'est le cas des système de gestion des transactions financières, par exemple, qui peuvent utiliser des équipement réseau à faible latence.
Pour la première fois et seulement avec PostgreSQL 9.1, il est maintenant possible d'activer la réplication synchrone de manière sélective au sein de chaque transaction du système : chaque utilisateur, connexion, ou transaction peut dynamiquement choisir son niveau de durabilité. Il est donc possible de prendre en compte la valeur réelle des données en jeu. Par exemple, des données clientes critiques ou bien une transaction financière peuvent obtenir le niveau le plus sécurisé de durabilité, celui fourni par la réplication synchrone, alors que des données moins importantes, telles les journaux de communications instantanées, peuvent éviter d'être soumises à l'impact de performances de ce mode opératoire.
Lorsque l'on considère que typiquement très peu des transactions faites en bases de données ont besoin de ce niveau de durabilité, cette innovation prend tout son sens. Avec PostgreSQL 9.1, la réplication synchrone sort enfin de son écrin traditionnel : il ne s'agit plus d'une solution tout ou rien que seuls les budgets faramineux peuvent se permettre.
La réplication synchrone nécessite que l'utilisateur déclare une liste de serveurs prioritaires : si le premier de la liste était en échec, le suivant serait alors promu comme standby synchrone. Ainsi, le « cluster » peut maintenir sa garantie de durabilité même en cas de panne partielle, ce qui en fait une solution robuste.
Une autre fonctionnalité à ne pas manquer dans PostgreSQL 9.1 est l'addition du support complet des Extensions, par Dimitri Fontaine, dirigeant de 2ndQuadrant France. Ce support des Extensions offre la possibilité de déployer des contributions additionnelles sur le serveur en une simple commande SQL, et de les supprimer tout aussi aisément. Le système d'extension peut être comparé à un système de « package », contenant un un ensemble de fonctionnalités qui ensemble résolvent un problème particulier. Il peut s'agir par exemple de la gestion des numéro ISBNs, ou bien d'ajouter des fonctions de chiffrement à PostgreSQL.
PostgreSQL a toujours été extensible à souhait, et cela a été exploité par une myriade d'extensions existantes. Malgré cela, il n'était pas possible d'administrer une base de donnée étendue de la sorte comme un ensemble unis. Maintenant qu'il est possible de faire de la sorte, le projet PGXN propose un catalogue d'extensions centralisé, et rend un service comparable à celui que le CPAN fourni à la communauté Perl.
PostgreSQL 9.1 est équipée des derniers travaux sur les performances en écriture disque de Gregory Smith, consultant 2ndQuadrant. Greg a travaillé sur la déduplication des requêtes de syncronisation disque (fsync est l'opération qui permet de forcer l'écriture immédiate sur disque de toutes les données modifiées récemment et qui seraient encore seulement en mémoire) ; cette optimisation améliore beaucoup les performances des installations soumises à une forte charge en écriture. Greg a également simplifié la configuration du serveur en mettant au point une méthode de calcul fiable permettant de déterminer automatiquement la valeur de wal_buffers.
L'arrivée d'une implémentation de SQL/MED (« Management of External Data », ou Gestion des Données Externes) dans PostgreSQL 9.1 est pleine de conséquences pratiques. Il s'agit du standard SQL décrivant comment inter-connecter les systèmes de bases de données hétérogènes. Cela permet aux utilisateurs de définir des « Tables distantes » (foreign tables), qui peuvent faire partie des requêtes SQL au même titre que les tables classiques, mais qui en réalité représentent des données stoquées dans une source externe : un fichier CVS, une table dans un SGBD concurrent, ou même une source Twitter.
Une autre première mondiale dans PostgreSQL 9.1 concerne la gestion de l'isolation des transactions, avec l'implémentation du niveau sérialisable. Il s'agit du plus haut niveau d'isolation décrit par le standard SQL, et à partir de PostgreSQL son comportement respecte sa définition mathématique stricte : à tout ensemble de transactions sérialisables joué en concurrence correspondra une exécution séquentielle de ces même transactions. En particulier les lectures fantômes qui pouvaient avoir lieu dans des niveaux d'isolation moins stricts, et qui continuent d'être présentes dans les systèmes concurrents tels Oracle®, peuvent provoquer des anomalies qui sont maintenant impossibles avec PostgreSQL. Grâce au travail de Kevin Grittner, administrateur de bases de données pour le tribunal d'état du Wisconsin, à Dan Ports, qui prépare sa thèse au MIT ; et suite aux travaux de recherche de Michael James Cahill, l'implémentation dans PostgreSQL de ce niveau d'isolation est faite de manière remarquablement efficace et n'ajoute aucun verrouillage additionnel au niveau d'isolation disponible dans les versions précédentes de PostgreSQL.
Enfin, les requêtes avec clause WITH, appelées Expressions Communes de Tables ou bien CTE pour « Common Table Expressions », sont améliorées d'une façon prévue par aucun autre SGBD. En effet, la syntaxe WITH permet de définir une vue qui n'existe que pour la durée d'une requête SQL, et permet d'organiser une requête complexe en fragments plus faciles à maintenir. Cette forme permet aussi de réaliser des traitements de parcours d'arbres ou de graphes, puisqu'elle supporte les définitions récursives.
Le consultant 2ndQuadrant Marko Tiikkaja a ajouté à ces requêtes WITH le support des requêtes d'écriture de données, INSERT, UPDATE et DELETE. Cela permet de mettre en œuvre en une seule requête des comportements avancés, tels le déplacement d'enregistrement d'une table à une autre au sein d'une seule commande complètement atomique. Une telle technique est utilisable dans le cadre de la gestion des partitions lorsque de nouvelles tables filles sont créées, ou encore dans le cadre d'opérations d'archivages.
