Quelques concepts en vrac

(sujet préalablement traité en 2015)

Les bases de données, le rôle du DBA (database administrator, administrateur de base de données)

Un top modèle pour vos informations

      Une base de données permet de stocker des informations, de les relire, de les mettre à jour...et surtout de ne pas les perdre. Un bout de papier ou une ardoise permettent de stocker des informations et de les mettre à jour mais, pour que la gestion soit efficace, les données doivent être organisées et disponibles de manière pérenne.
      Un informaticien d’IBM, Codd, a proposé un modèle complet pour cela, le modèle relationnel. Il a aussi fixé les règles pratiques permettant de l’utiliser. D’autres modèles existent mais celui de Codd a connu et connaît toujours beaucoup de succès.

Habiller le top modèle

      L’ancêtre de PostgreSQL, Ingres, a été l’un des premiers logiciels à mettre en application ce modèle grâce aux travaux de Michael Stonebraker et des ses étudiants de l’université de Berkeley dans les années 1970.
      Le logiciel a changé de nom. Il a connu beaucoup d’évolutions en s’ouvrant à une communauté mondiale de développeurs et en adoptant le langage normalisé pour interroger les données (SQL, structured query language).
      PostgreSQL est toujours améliorable et amélioré à la fin des années 2010. Mais il a atteint depuis déjà nombre d’années le degré de maturité attendu en milieu professionnel.

Un peu d’ordre, bande de pirates

      Supposons que vous gériez une bibliothèque et base documentaire d’entreprise, une gigantesque entreprise.
      Vous allez avoir beaucoup de lecteurs, beaucoup d’auteurs. Il faut leur permettre de travailler ensemble dans de bonnes conditions.
      Les auteurs peuvent ajouter ou modifier des documents mais il y a des limites à fixer. Pas question de laisser traîner des documents à moitié raturés et incompréhensibles à disposition des lecteurs. Certaines modifications peuvent concerner plusieurs documents et ne prendre sens que lorsqu’ils sont tous mis à jour. Pendant ce travail d’écriture, les documents dans leur version modifiée ne doivent être accessibles qu’à leur auteur. Si, finalement, l’auteur abandonne son idée alors les documents sur lesquels il travaillait doivent tous être restitués dans leur état original. En revanche, si sa modification est globalement bonne, il faut que les futurs lecteurs et auteurs en bénéficient immédiatement.
      La bibliothèque va vivre mais, à tout moment, tout ce qu’elle contient doit former un ensemble rangé et cohérent. Enfin, il ne faudra surtout jamais perdre tous ces précieux documents qui constituent la richesse et la connaissance de l’entreprise.
      Mettre en place une telle gestion avec du papier, des vigiles etc. ce n’est pas facile. Codd et un logiciel comme PostgreSQL vont vous faciliter la tâche. L’outil ne fait pas tout mais, sous réserve que vous l’utilisiez correctement, vous conserverez une bibliothèque fonctionnelle. Personne en dehors de l’entreprise ne touchera aux bouquins, les auteurs ne se marcheront pas sur les pieds, les lecteurs trouveront rapidement ce qu’ils cherchent et vous ne perdrez jamais de livres.

Il ne doit en rester qu’un et c’est MON logiciel préféré qui est le seul choix possible

      Ne riez pas, certains y croient ou plutôt tentent de vous le faire croire.
      Si vous choisissez PostgreSQL, vos critères les plus importants sont probablement parmi les suivants :

      Bref vous voulez être libre, vous ne voulez pas payer trop cher et vous voulez de la qualité. PostgreSQL est un excellent choix mais, en matière de SGBDR (système de gestion de base de données relationnelle), d’autres choix sont possibles.
SQLite est le SGBDR le plus répandu et même un des logiciels les plus diffusés au monde toutes catégories confondues. Il ne répond pas aux mêmes besoins que PostgreSQL mais n’hésitez pas à vous renseigner à son sujet.
      Si la dépendance vis-à-vis d’un éditeur n’est pas un problème pour vous alors SQL Server peut être un choix pertinent. Si vous optez pour ce logiciel, il vous faudra acquérir des licences pour l’utiliser. Il vous faudra aussi développer et maintenir une culture Microsoft importante côté serveur et, notamment, disposer d’administrateurs système Windows compétents pour tirer pleinement parti de votre investissement. Certes, SQL Server est enfin disponible avec certaines distributions de Linux depuis la version 2016 mais il faudra encore un peu recul pour juger si ces combinaisons sont intéressantes et pérennes en production.
      Si vous voulez un logiciel de base de données assurant tout ou partie des tâches pouvant aussi être déléguées au système de stockage ou d’exploitation alors Oracle Database constitue un choix adéquat. Oracle propose notamment des systèmes clé en main, Exadata et autres. Attention cependant, le choix assez large au niveau du système d’exploitation donne une impression d’ouverture aux plus anciens pour qui les systèmes Unix/Oracle paraissaient ouverts en comparaison des mainframes (macroordinateurs). Cette ouverture est illusoire par rapport à la véritable ouverture constituée par les logiciels open source.
      Le coût des licences Oracle Database est encore plus élevé qu’avec SQL Server et le code est aussi fermé. Encore une fois, vous dépendez entièrement d’un éditeur unique.
      Dépendre de son fournisseur n’est jamais souhaitable mais avec Microsoft et Oracle le problème est accru. L’évolution de leurs prix peut aussi être fonction de celle du cours des devises, en l’occurence la conversion EUR/USD si votre société est basée en France.
      Si vous confiez vos données à un cloud propriétaire alors l’enfermement est encore plus grand et votre dépendance peut devenir quasi totale.

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.

Mise à jour : 11/02/2018