Quelques concepts en vrac

Comparaison n’est souvent pas raison

      Comment ne pas tromper en choisissant son SGBD ? Tout d’abord les benchmarks (bancs d’essai) synthétiques TPC-C, H...Z, très peu pour moi. Au fil du temps, vous constaterez que le produit vainqueur du bench est toujours celui de la société qui le publie. Je me fie plus aux déploiements réels.
      Comme lors du basculement des Unix propriétaires vers Linux, le retournement du consensus se fait en plusieurs phases. La situation a évolué très vite depuis le milieu des années 2010. Il n’est déjà plus nécessaire de convaincre que PostgreSQL peut remplacer avantageusement tout SGBDR propriétaire. Le SILL (Socle Interministériel de Logiciels Libres) mais surtout le CIGREF (Club Informatique des Grandes Entreprises Françaises) le mentionnent officiellement.
      Mais ce sont surtout les études menées par les services informatiques convergeant toutes vers la même conclusion, puis les retours d’expériences réussies, qui emportent la conviction. Qu’est-ce que cela change pour les fournisseurs et éditeurs de logiciels tiers ? Concrétement, exiger un SGBDR propriétaire constitue à présent un handicap dans de nombreux appels d’offre. Une telle exigeance entraîne en effet une pénalité qui peut devenir rédhibitoire. Il devient donc petit à petit dangereux pour un éditeur de logiciels d’exiger le couplage de son produit avec un SGBDR propriétaire.

      Tout dépend en fait de vos besoins présents et futurs. Si vous utilisez depuis des années Oracle Standard Edition et que vous savez que vous ne passerez jamais sur une édition supérieure alors PostgreSQL est un choix ne comportant aucun risque au niveau des besoins couverts par le produit.
      Depuis les versions 9.x et surtout 10, PostgreSQL n’a même plus grand chose à craindre de l’Enterprise Edition d’Oracle Database pour gérer de gros volumes d’informations. A ce sujet, beaucoup de fonctionnalités intéressantes apparues au fil des versions sont fournies par Oracle sous forme d’options de l’Enterprise Edition. Cette politique vous oblige à dépenser toujours davantage pour bénéficier de ces nouvelles fonctionnalités.
      Pour revenir à l’exemple de la bibliothèque, supposons que vous aimeriez bien construire une deuxième bibliothèque pour éviter de devoir interrompre le travail si la première brûlait. Idéalement, vous aimeriez y envoyer certains de vos lecteurs pour permettre aux auteurs de travailler plus sereinement. Vous voudriez aussi que le travail validé des auteurs soit disponible instantanément dans les deux bâtiments.
      Si vous souhaitez réaliser cela de manière logicielle avec un SGBD, ce n’est possible ni avec Oracle Express Edition (la version gratuite limitée en 11gR2 à 11Go de données) ni Oracle Standard Edition Two. En fait, utiliser la base de secours en lecture n’est même pas possible avec Oracle Enterprise Edition. Il faut une option appelée Active Dataguard alors que PostgreSQL propose cela nativement. J’ai utilisé cette fonctionnalité de hot standby pour répliquer des données médicales critiques entre 2 datacenters. La stabilité et les performances se sont révélées impressionnantes (aucun incident depuis le démarrage en 2016).

      Selon les utilisations, PostgreSQL peut être supérieur ou inférieur à Oracle Enterprise Edition au niveau des fonctionnalités disponibles. Mais PostgreSQL est supérieur à Oracle Standard Edition dans quasi tous les cas et l’écart se creuse.
      Le problème pour les clients d’Oracle est que leur fournisseur ignore complètement cet aspect. Oracle a en effet rendu la Standard Edition Two moins attractive que ne l’étaient les Standard Edition One et Standard Edition.
      La Standard Edition Two reprend globalement la place de l’ancienne Standard Edition au niveau de la tarification catalogue. Le ticket d’entrée pour cette Standard Edition Two est environ trois fois plus élevé que celui de l’ancienne Standard Edition One.
      La Standard Edition Two reprend pourtant les limitations techniques de la Standard Edition One (serveurs à 2 processeurs maximum).
      Une limitation nouvelle a même été ajoutée. Elle a été formulée de manière à ce que les utilisateurs puissent plus difficilement utiliser les capacités des nouvelles générations de processeurs pour faire des économies de licences et de support.
      Cet épisode illustre de manière implacable le risque que représente la dépendance vis-à-vis d’un fournisseur unique susceptible de changer les règles du jeu comme bon lui semble.
      Sur le court terme, ces changements permettent certes à Oracle de protéger, voire augmenter ses marges.
      Sur le long terme, en revanche, cela pourrait se révéler désastreux pour eux. Dans un projet, Oracle Database ne sera bientôt plus du tout perçu comme un facteur rassurant mais comme un facteur d’incertitude et de risque. Comment convaincre des clients de choisir leurs technologies et surtout de passer dans leur cloud avec une image pareille ? En matière de bases de données, une réputation de stabilité à tous niveaux est importante. Choisir un SGBD est en effet un choix de long terme car changer de produit n’est pas simple. Je ne peux plus recommander Oracle Database dans le cadre de nouveaux projets. J’ai pourtant été enthousiaste techniquement au sujet de ce logiciel, jusqu’à devenir OCM (Oracle Certified Master).

      Quelle conclusion en tirer ? Il faut refuser de devenir dépendant d’un éditeur, quel qu’il soit. Aucun risque de cette nature avec PostgreSQL qui est le fruit d’une longue histoire et qui dispose des caractéristiques essentielles pour être considéré comme un SGBDR sérieux sur le long terme.
      Avez-vous ou aurez-vous besoin des options d’Oracle Database Enterprise Edition qui manquent à PostgreSQL ou sont-elles superflues ?
      Ces options seront-elles intégrées dans de futures versions de PostgreSQL ou sont-elles déjà simplement couvertes par le système d’exploitation ?
      PostgreSQL a tendance a ne pas réinventer la roue et à ne pas proposer de fonctionnalités si elles sont redondantes avec celles proposées par d’autres couches logicielles.
      En pratique, dans les grandes entreprises, plusieurs systèmes de gestion de base de données cohabitent la plupart du temps, relationnels et non relationnels. Vous avez alors à administrer ou faire administrer des base de données diverses en fonction des applicatifs que vous achetez. Même avec un outil de qualité il est possible d’avoir un résultat désastreux. Pour reprendre l’exemple de la bibliothèque, si vous laissez entrer tout le monde sans contrôle et si vous ne disposez que d’un exemplaire de chaque ouvrage, vous perdrez des livres, voire tous les livres, en cas d’incendie.

Et moi, et moi, et moi...

      Voilà, ça y est. Enthousiaste ou contraint et forcé, vous allez devoir utiliser PostgreSQL. Si vous ne choisissez pas de vous faire héberger alors vous allez devoir définir une architecture, la dimensionner avec des tests de charge et la déployer. En fonction de ce que vous avez déjà à disposition, il faudra peut-être installer ou faire installer du matériel, des logiciels (systèmes d’exploitation etc.). PostgreSQL ne fera PAS tout. En fait, aucun SGBD ne fait TOUT et pourtant certains en font déjà trop.
      Autour de PostgreSQL, vous aurez un environnement à définir. Avant même de recevoir la première information, vous aurez mis en place des mécanismes de sauvegarde, de supervision, voire de reprise et continuité d’activité, en fonction de critères précis. Certains mécanismes peuvent être déployés au fil du temps. Cependant, avant toute mise en production, vous devez avoir mis en place les mécanismes de sauvegarde des données et vous devez avoir testé et documenté les scenarii à appliquer si un incident survient. La liste des incidents et le temps que vous mettrez à les résoudre avec les moyens matériels, logiciels et humains à votre disposition doivent être connus et fixés par écrit. Aucun malentendu sur le périmètre couvert ne doit exister entre le DBA et le DSI (directeur du système d’information).

      D’accord mais après avoir fait tout ça, est-ce que je peux dormir pendant 100 ans au moins ? Non, il faudra sans doute veiller à la sécurité en évaluant et en passant les patches par exemple. C’est heureusement très facile avec PostgreSQL. Bientôt arriveront peut-être aussi les premiers utilisateurs mécontents : "La base est lente. On aurait mieux fait de prendre MySQL ou Firebird..."
      En fait, sans doute pas. Mais vous devrez identifier le problème (je propose un outil pour cela) et apporter une action corrective si le problème est effectivement côté base. Un problème de performance remonté en production est un échec. Le DBA est important mais n’est qu’un maillon de la chaîne parmi d’autres.
      Le meilleur DBA ne pourra que difficilement compenser des choix erronés effectués par ailleurs. Il aurait par exemple fallu informer les développeurs et travailler avec eux pour qu’ils connaissent et appliquent quelques bonnes pratiques en matière de performance. Utilise l’index Luke comme titre un site célèbre...à condition qu’il existe et qu’il soit pertinent.

Oui mais non ! Moi je suis DBA Oracle, je ne veux rien faire d’autre et de toute façon je n’ai pas le temps

      Avec le recul, j’ai pu constater que déployer des environnements haute disponibilité est plus rapide avec PostgreSQL qu’avec Oracle Database ou SQL Server.
      Au niveau de l’administration, certains DBA constatent ensuite avec un peu de crainte que certaines tâches constituant une grande partie de leur métier disparaissent au passage à PostgreSQL. De plus, ce SGBD est facilement pris en main par des administrateurs système Linux mais aussi à présent Microsoft de la nouvelle génération connaissant déjà des produits comme Ansible, Nagios, Docker etc.
      Il faut le voir comme une opportunité pour les DBA d’apporter une autre forme de valeur ajoutée. Ils peuvent encore davantage s’intéresser aux aspects fonctionnels, aux besoins des utilisateurs et développeurs etc.
      La nécessité de sortir des cavernes finira même par toucher les DBA travaillant avec un produit aussi complexe qu’Oracle Database. Par certains côtés, les outils d’administration fournis par Oracle pouvaient faire penser à la machine à planter les clous de Gaston Lagaffe, nécessitant d’être fixée au mur avec deux clous afin d’en planter un.
      Mais les choses ne sont pas figées. Larry Ellison n’a-t-il pas parlé de bases de données autonomes ? Pour l’instant, cela peut faire sourire un DBA Oracle mais la réalité finira peut-être par rattraper véritablement les annonces commerciales. Et puis il y a le cloud.

Tu ne marcheras jamais seul

      Avec PostgreSQL, vous disposerez du support communautaire au niveau du code. Une version majeure sort tous les ans et elle est supportée au minimum 5 ans (bugs et failles de sécurité).
      La documentation est complète, en anglais et en français. Si vous avez des questions ou si vous cherchez des conseils, vous trouverez votre bonheur sur de multiples forums, à commencer par celui du site.
      Certains éditeurs d’applicatifs compatibles avec PostgreSQL assureront un support basique de la combinaison applicatif-SGBD. Vous pouvez aussi souscrire du support supplémentaire auprès d’une société spécialisée. La plus connue en France est historiquement Dalibo mais 2nd Quadrant (une référence au niveau international) propose aussi ses services par exemple.

      Certaines sociétés rêvent d’être l’équivalent pour PostgreSQL de Red Hat ou Canonical pour Linux. EnterpriseDB (EDB) propose ainsi du support, notamment sur une version maison de PostgreSQL estampillée Enterprise. Ils se basent sur le modèle économique de Microsoft et surtout d’Oracle, à savoir le paiement en fonction du nombres de processeurs utilisés par PostgreSQL dans votre organisation.
      Si cela fonctionne, c’est jackpot pour EDB. Cependant, ce modèle a du mal à passer pour le support d’un SGBD open source, en tous cas pour les entreprises déjà passées à PostgreSQL. Elles n’ont plus besoin de la couche de compatibilité Oracle Database. Elles disposent souvent de support en interne. Il ne doit donc pas être simple de prouver qu’on apporte pour plusieurs milliers d’euros par processeur de valeur ajoutée. Le cas de Splendid Data est encore un peu différent puisqu’ils proposent la version communautaire de PostgreSQL et quelques produits associés sous un nom commercial, PostgresPURE.

      Comme vous le voyez, le choix est très large. Une petite remarque tout de même. EnterpriseDB, c’est du sérieux au niveau technique mais d’autres entreprises proposent ou ont proposé une version propriétaire de PostgreSQL. La version communautaire de PostgreSQL est déjà "Enterprise" dans le sens où elle est prête pour tout type de production. Ajouter officiellement le mot Enterprise et quelques fonctions de compatibilité ne transforme pas PostgreSQL en Oracle Database et ne dispense pas de tout travail lors des migrations. Sur la durée, c’est toujours la version communautaire qui est restée la référence. Passer à PostgreSQL doit être un choix mûrement réfléchi. Il faut une vraie raison pour utiliser une version propriétaire qui vous limite dans votre liberté. Garder des syntaxes Oracle Database dans les programmes n’en est sans doute pas une.