Changer de système de gestion de bases de données n’est que rarement une tâche simple. L’une des premières étapes de la validation de la migration consiste à valider son intérêt en termes de coûts et de bénéfices, parfois aussi appelé « retour sur investissement ». J’ai lu récemment un article qui détaille des points techniques pour lesquels une migration vers PostgreSQL peut s’avérer coûteuse, Migration Oracle PostgreSQL : les 13 grandes lacunes qui peuvent s’avérer cauchemardesque.
Cet article est très intéressant et le point de vue exprimé me semble honnête et sincère, je regrette seulement que tout ne soit pas exact ou à jour dans les détails concernant PostgreSQL. Globalement, il est vrai que les concurrents propriétaires de notre solution Open Source favorite disposent encore de fonctionnalités avancées que nous ne retrouvons pas dans PostgreSQL, et cela peut s’avérer déstabilisant ou bien peut nuire à votre capacité à migrer vers PostgresQL.
Il faut se rendre compte que PostgreSQL n’étant pas édité par une entreprise unique, les fonctionnalités de chaque nouvelle version sont celles que les développeurs ont choisi d’implémenter. Pas de département Marketing pour arbitrer les éléments à ajouter dans cette fameuse liste qui aide les commerciaux à mieux faire leur travail. L’avantage de cette organisation est qu’elle permet à tout utilisateur de participer à établir les priorités du développement du projet, en contribuant les fonctionnalités manquantes. Cela peut se faire directement lorsque l’on dispose des compétences nécessaires en interne, ou bien en sponsorisant une entreprise spécialisée, telle 2ndQuadrant.
Pour être juste avec l’auteur de l’article précédent, rappelons tout de même qu’il détaille un point de vue technique d’administrateur de bases de données qui s’attache à résoudre les problèmes réels qui font son quotidien, la remarque sur l’influence du Marketing n’est pas une remarque sur l’article référencé ci-dessus.
Répondre aux 13 points cités serait trop long et trop technique pour le faire ici. Prenons tout de même le temps d’en relever quelques uns, qui illustrent l’attitude du projet PostgreSQL. La gestion des espaces de stockage, par exemple, est laissée aux programmes spécialisés (tels LVM), car les développeurs de PostgreSQL utilisent le système de fichiers et de blocs sous-jacents et refusent d’en dupliquer les fonctionnalités.
Quant à la gestion des transactions, rappelons qu’avec la sortie de PostgreSQL 9.1 plus tôt cette année, nous offrons la seule implémentation du niveau sérialisable qui ne repose pas sur des verrous forts et qui soit démontrée correcte. Ce qui fait défaut à PostgreSQL est la notion de procédure permettant de contrôler des transactions autonomes. Il est possible de contourner cette absence en utilisant les outils dblink ou plproxy, et je connais plusieurs société d’expertise qui seront heureuses de vous expliquer comment faire cela.
La partitionement dans PostgreSQL est un sujet qui mériterait un billet à lui tout seul. C’est un problème que nous voulons résoudre chez 2ndQuadrant, et nous avons plusieurs pistes afin d’arriver à une bonne solution. Sponsoriser nos travaux sur le sujet est un des meilleurs moyens à votre disposition afin de faciliter votre migration vers PostgreSQL dès la sortie de sa prochaine version majeure. Ce même raisonnement s’applique parfaitement aux requêtes parallèles, autre sujet important sur lequel nous saurons vous aider.
Il existe des moyens d’influencer l’optimisation de requêtes que réalise PostgreSQL, mais pas avec les fameux indices de requêtes. Utiliser ceux-ci pose de grands problèmes de compatibilité et demande de revoir l’ensemble des requêtes qui les utilisent pour toute migration à une version majeure plus récente de votre SBGD propriétaire, il me semble. Le compromis n’est pas si facile à faire.
Les index couvrants ont été développés (par Robert Haas, qui travaille pour EnterpriseDB) et seront disponibles dans PostgreSQL 9.2, sans avoir à déclarer quoi que ce soit. Si les seules colonnes dont vous avez besoin sont indexées, alors PostgreSQL saura seul en tirer parti. Le profilage de requête est grandement amélioré pour la prochaine version de PostgreSQL, suite à des travaux réalisés par 2ndQuadrant.
Enfin, PostgreSQL dispose en versions 9.0 et 9.1 d’une solution de réplication intégrée. Cela est le résultat des 7 dernières années de travaux de Simon Riggs (2ndQuadrant) concernant la gestion des journaux de transaction. En version 9.1 PostgreSQL propose une solution de réplication synchrone contrôlable pour chaque transaction. Vous pouvez faire cohabiter une réplication synchrone et une réplication asynchrone au sein de la même installation de bases de données afin de bénéficier simultanément des avantages de sécurité et durabilité des données sans nuire aux performances des transactions moins importantes. Une fois de plus, cela est une première mondiale, nul autre système de gestion de bases de données ne dispose d’une telle solution.
En conclusion, l’article que j’ai référencé au début de ce billet est une bonne lecture même s’il n’est pas suffisamment à jour. Certaines utilisations des SGBD propriétaires peuvent s’avérer difficiles à reproduire sous PostgreSQL et il est indispensable de savoir évaluer cela dès le début de l’analyse de faisabilité et de coûts. Dans bien des cas cependant, participer à la mise au point de la fonctionnalité manquante en en finançant le développement sera la meilleure stratégie possible. Le retour sur investissement ne sera qu’assez peu modifié : étant donné les prix des licences propriétaires, on a vu (en conférence PostgreSQL Europe à Amsterdam) des projets inclure un développement spécifique et voir son retour sur investissement passer de 2 mois à… 8 mois, ce qui reste inférieur à 1 an!
Alors, qu’attendez-vous pour évaluer les bénéfices que vous aurez à migrer vers PostgreSQL ?