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 ! Une liste de courses, un fichier de tableur permettent aussi de stocker des informations mais pour que la gestion soit efficace les données doivent être organisées.
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é mais il a atteint depuis déjà nombre d’annéees 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. Par exemple, 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 mise à 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 (ou se fait brutalement licencier) le ou 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 ce sera MON logiciel préféré qui est le meilleur en tout, pour tout, partout hahahahahaha (rire machiavélique) !!!!!!!!
Et moi, et moi, et moi...
Tu ne marcheras jamais seul
Ne riez pas, certains y croient ! Supposons que vous ayez participé au choix du modèle relationnel pour organiser vos données et du logiciel pour implémenter ce modèle. Si vous avez choisi PostgreSQL, parmi vos critères les plus importants, se trouvaient probablement :
Bref vous voulez être libre, vous ne voulez pas payer trop cher mais vous voulez de la qualité. PostgreSQL est un BON choix et ce site vous aidera à le rendre excellent j’espère.
Cependant 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 double dépendance vis-à-vis d’un éditeur et d’un système d’exploitation 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 2016 sera (enfin) disponible sous Linux mais il faudra du recul pour juger si cette combinaison est intéressante 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 du système d’exploitation donne une impression d’ouverture mais le coût des licences est encore plus élevé qu’avec SQL Server et le code d’Oracle Database 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.
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 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.
Il faut tout de même que je me mouille un peu en comparant les SGBD ? D’abord les benchs bidons 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éussis. Quand le DBA d’un site ayant connu une belle progression dans le début des années 2010, leboncoin.fr, décrit comment PostgreSQL est utilisé pour le stockage de leurs données c’est significatif par exemple.
Voici donc en résumé mon opinion...tout dépend de vos besoins présents et futurs ! Si vous utilisez depuis des années Oracle dans sa version Standard Edition One, Standard Edition et maintenant Standard Edition Two et que vous savez que vous ne passerez jamais sur une édition supérieure alors PostgreSQL est un choix ne comportant (quasiment) aucun risque au niveau des besoins couverts par le produit.
Je montre même que PostgreSQL peut constituer un plus intéressant si vous bridez vos besoins pour rester dans une édition d’Oracle abordable.
Pour revenir à l’exemple de la bibliothèque supposons que vous aimeriez bien construire une deuxième bibliothèque pour éviter de devoir fermer si la première brûlait. Idéalement vous aimeriez y envoyer certains de vos lecteurs pour permettre aux auteurs de travailler plus sereinement et vous voudriez 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 ce genre de fonctionnalité nativement.
Globalement, au niveau des fonctionnalités, Oracle Enterprise Edition + Options > PostgreSQL > Oracle Standard Edition. Cele reste vrai mais avec le temps l’écart entre PostgreSQL et Oracle Enterprise Edition se réduit alors que l’écart entre PostgreSQL et Oracle Standard Edition se creuse. Le problème pour les clients d’Oracle est que leur fournisseur ignore complètement cet aspect. Oracle a même rendu la Standard Edition encore moins attractive qu’elle ne l’était. La Standard Edition Two introduite en 2015 est en effet au prix de l’ancienne Standard Edition. Le ticket d’entrée de cette Standard Edition Two a donc environ triplé par rapport à l‡ancienne Standard Edition One dont elle reprend pourtant les limitations techniques (serveurs à 2 processeurs maximum etc.)
PostgreSQL a les caractéristiques essentielles pour être considéré comme un SGBDR sérieux. 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.
Voilà ça y est. Enthousiaste ou contraint et forcé vous allez devoir administrer PostgreSQL. Notez que vous auriez pu faire héberger et administrer vos bases mais vous avez décidé de conserver vos données "en interne". Pourquoi pas ! Vous allez devoir définir une architecture, la dimensionner avec des tests de charge et la déployer. Euh c’est à dire ? Et bien sans être exhaustif, 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 mais certains en font plus que d’autres (trop ?). Si vous avez acheté un Exadata d’Oracle vous pouvez avoir des performances affreuses et perdre des données si vous faites n’importe quoi par ailleurs. Cependant vous aurez (a priori) moins de travail au niveau stockage et système d’exploitation, ne serait-ce qu’au niveau du choix.
Autour de PostgreSQL vous aurez un environnement à mettre en place. 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).
Et une fois que c’est déployé je dors jusqu’à la prochaine migration au moins ? Et non il faudra sans doute veiller à la sécurité en évaluant et en passant les patches par exemple. Bientôt arriveront peut-être aussi les premiers utilisateurs mécontents. "La base PostgreSQL elle est lente on aurait mieux fait de prendre MySQL ou Access !!!!!!!!!!!!!".
En fait non sans doute pas mais vous devrez identifier le problème et proposer une action corrective. 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 et travailler avec les développeurs pour qu’ils continuent à suivre 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 !
Avec PostgreSQL vous disposerez du support communautaire au niveau du code : une version majeure est supportée 5 ans (bogues et failles de sécurité). Si vous avez des questions ou si vous cherchez des conseils la documentation est complète, en français, et vous trouverez sans doute votre bonheur sur de multiples forums à commencer par celui du site. Certains éditeurs d’applicatifs compatibles avec PostgreSQL assureront aussi 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 étant historiquement Dalibo.
PostgreSQL ayant le vent en poupe, certaines sociétés rêvent d’être l’équivalent pour PostgreSQL de Redhat 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. On parle ici de paiement de licences 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, ont du support en interne et il ne doit pas être simple de prouver qu’on apporte pour 5000 euros par processeur de valeur ajoutée.
EnterpriseDB c’est du sérieux au niveau technique PostgreSQL. Mais d’autres entreprises ont proposé une version propriétaire de PostgreSQL et, sur la durée, c’est la version communautaire qui est toujours 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. Si la raison est de pouvoir garder des (+) au niveau des jointures externes ce n’est peut-être pas judicieux par exemple. Ajouter le mot Enterprise et quelques fonctions de compatibilité ne transformera de toute façon pas PostgreSQL en Oracle ou SQL Server. Si vous avez vraiment besoin d’Oracle ou SQL Server dans leurs versions Enterprise pour des besoins qui ne sont pas couverts par la version communautaire de PostgreSQL -c’est de plus en plus rare mais c’est toujours possible- alors mieux vaut peut-être conserver ces outils sous peine de connaître des désillusions. On ne choisit pas un SGBD sur un coup de tête.
Mise à jour : 20/12/2015