Il s’agit de Fotolog, qui anime de très grandes communautés d’utilisateurs en amérique du sud et partout ailleurs dans le monde. Avec 32 millions d’utilisateurs, 1 milliard de photo et 10 milliards de commentaires, la migration à PostgreSQL était intéressante et mérite de s’y arrêter le temps d’un article et d’une conférence.

Nous parlons souvent de la versatilité de PostgreSQL : cette migration a montré à quel point il est important de pouvoir compter sur cette qualité du projet. En effet, nous avons pu utiliser l’intégration de Java en tant que language de procédure stockée (PL/Java) afin de traiter certains BLOBs et de les normaliser en les intégrant à nouveau dans le schéma de la base de données, par exemple.

Il est par ailleurs intéressant de noter que si les raisons pour lesquelles nous avons changé de MySQL pour lui préférer PostgreSQL sur ce site à fort trafic ne sont pas essentiellement techniques, les deux principaux acteurs des réseaux sociaux Facebook et Twitter ont chacun publié une série de correctifs (patches).

Ils utilisent donc en production une version personnalisée de MySQL, et dont seules les sources sont distribuées, sans soucis de maintenance tierce aucuns. Est-il nécessaire de constituer une équipe de développeurs de moteur de base de données et de maintenir sa propre version en interne afin de pouvoir utiliser MySQL pour de fortes volumétries ?

La dizaine de points choisis par Jeremiah Peschka dans l’article précédent s’éloigne parfois de la liste que j’aurais moi-même établie, aussi vais-je éviter de vous faire une traduction simple du contenu anglais mentionné. Plusieurs points méritent tout de même d’être mentionnés ici.

PostgreSQL stabilise et distribue une nouvelle version majeure de sa base de données chaque année. Le cycle de développement actuel (que nous connaissons bien ici, pour y participer) est composé de deux grandes étapes, six mois de développement suivis de six mois de relectures, tests, correctifs, polissages et améliorations de la documentation.

Cela permet d’obtenir de très bonnes versions point zéro autour du mois de septembre chaque année. Cela n’a pas toujours été le cas dans la gestion du projet PostgreSQL, mais ce modèle a été mis en place de manière professionnelle sur plusieurs années afin de pouvoir mieux accepter les améliorations apportées par plus de deux cents développeurs en moyenne.

Bien sûr, très peu de projets industriels peuvent se permettre de revoir leur architecture, leurs procédures et leur intégration SQL chaque année, et même dans le milieu très dynamique des services web cela n’arrive quasiment pas.Aussi les versions de PostgreSQL sont-elles maintenues pendant au moins cinq ans, les versions courantes de PostgreSQL sont donc au nombre de 5 à 7 selon les moments de l’année.

L’avantage n’est donc pas de pouvoir mettre à jour chaque année, mais bien de pouvoir en toute sérénité choisir la date de mise à jour de la version de PostgreSQL selon son propre calendrier de maintenance et d’évolutions avec la garantie de pouvoir à tout moment choisir une nouvelle version vieille au maximum d’un an.

Il existe ensuite de nombreux points techniques donnant un avantage très net à PostgreSQL, soit qu’il s’agisse d’innovations technologiques issues de la recherche, telles les « Serializable snapshot isolation » (ou SSI), ou bien la réplication synchrone contrôlable pour chaque transaction ; ou bien qu’il s’agisse de supports avancés aux développeurs, telles les recherches des plus proches voisins via un parcours d’index, les requêtes avancées en écriture (comparable au pipe sous unix, mais avec des ordres de lecture ou d’écriture SQL), ou bien le support avancé des types de données souvent utilisés.

Ces capacités avancées, cette souplesse d’utilisation et de paramétrage dynamique, associés à des caractéristiques de performance époustouflantes (dans la plupart des usages, dont très certainement le vôtre), la qualité de sa documentation, tout cela donne un avantage crucial à PostgreSQL : une réduction imbattable des coûts de développement et de maintenance de vos logiciels.

Vos développeurs peuvent écrire des requêtes complexes avec la garantie d’obtenir le bon résultat même dans une utilisation concurrente, faire des calculs de dates dans des timezones différentes et au milieu du changement d’heure (tous les mois ne font pas le même nombre de jours, tous les jours ne font pas 24 heures non plus, PostgreSQL le sait), exprimer des contraintes avancées (le même client ne doit pas réserver deux voitures différentes dans le même créneau horaire) qui doivent fonctionner systématiquement et sans verrous, etc.

Bénéficier de PostgreSQL pour résoudre cet ensemble de problème permet de ne pas avoir à les résoudre à nouveau dans votre application (quel jour serons-nous dans trois mois ? SELECT to_char(date 'today' + 3 * interval '1 month', 'Day'); est sûrement plus facile à utiliser que n’importe quel autre code, les développeurs lisant cela seront sûrement d’accord). Le temps passé à exploiter la documentation de PostgreSQL est un investissement facile à réutiliser et à rentabiliser, et c’est du temps de gagné dans le développement de ce qui fait la valeur ajoutée de votre application.

La raison pour laquelle nous aimons tant vanter les qualités techniques de PostgreSQL est simple. Il s’agit là d’un formidable levier vous permettant de produire des application meilleures car plus simple à développer, à faire évoluer, à maintenir, déployer et administrer.

Bien évidemment, tout cela sans s’acquitter de coûts de licence appliqués par serveur ou qui dépendent de la capacité et du nombre d’installations dont vous avez besoin pour déployer une architecture. Mettre en place une solution tolérante aux pannes, de la répartition de charge pour vos rapports hebdomadaires, des instances de tests ou d’exports de données devient une décision plus facile à prendre car elle ne dépend pas des coûts de licence.

Il reste à former une équipe compétente, ce qui à mon sens est une bien meilleure utilisation de votre budget, et ce qui bien souvent représente un coût moins élevé que les licences dépensées en pure perte… dès lors que vous pouvez obtenir le même service à moindre coût. Nous pouvons vous aider à déterminer si PostgreSQL est le moteur de bases de données le mieux adapté à votre projet.

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 ?

Cette conférence permet également de prendre part au futur du projet. Le marché de la base de données dans le monde est aujourd’hui estimé à quelques 26 milliards de dollars annuel, et suit une croissance à deux chiffres. Aujourd’hui PostgreSQL propose un jeu de fonctionnalités inégalé par les produits commerciaux : ils ne leur reste plus tellement d’avantage compétitifs, même sans parler coûts de licence.

D’autre part, le support de la communauté est imbattable : Bruce Momjian, pionnier du projet, membre de la core-team, l’a très clairement démontré. En plus de 10 conférences par ans depuis 15 ans il a rencontré beaucoup d’utilisateurs. La plupart ont la même expérience : les bugs soumis au projet sont le plus souvent corrigé dans les 24h, parfois en une semaine. Bruce n’a encore rencontré personne ayant du attendre plus d’un mois avant de bénéficier d’un correctif.

Le travail des entreprises de support est alors d’aider les entreprises à soumettre un rapport de bug le plus efficace possible puis à mettre en œuvre la version corrigée de PostgreSQL — il arrive qu’attendre la prochaine version mineure ne soit pas une option, il faut alors déployer une version intermédiaire.

L’une des présentations a détaillé le contexte économique et décisionnel des migrations depuis les SGBD propriétaires (auxquels nous pouvons ajouter les SGBD Open Source concurrents). Le retour sur investissement typique constaté d’une migration à PostgreSQL est de 2 à 8 mois, parfois moins. Le choix de PostgreSQL dans une infrastructure est aujourd’hui uniquement question de stratégie.

Avec un tel retour sur investissement, une bonne stratégie consiste à prévoir un budget de développement PostgreSQL : il est facile de participer au projet et d’orienter son développement de manière à couvrir parfaitement vos besoins, et nous sommes heureux d’implémenter vos fonctionnalités.

Cédric présentera un comparatif des dernières versions de Londiste et Slony.  Ces deux outils sont de plus en plus proches en terme de fonctionnalités et de coûts de maintenance, il nous expliquera comment s’y retrouver et comment choisir celui des deux qui fait le plus de sens pour votre projet et vos contraintes de qualité de service.

Quant à moi je vous présenterai comment utiliser les Extensions, fonctionnalité de PostgreSQL 9.1, de manière à mieux gérer les cycles de vies de vos procédures stockées, en particulier comment assurer le suivi de leurs déploiements en environnements de développement puis de production.

Beaucoup d’autre sujets seront abordés lors de cette conférence, nous vous recommandons en particulier la gestion de la durabilité des données grâce à la réplication synchrone, par Simon Riggs et Greg Smith, deux experts PostgreSQL travaillant chez 2ndQuadrant.

En espérant vous voir à Amsterdam, à bientôt!

Avec l’arrivée de la lignée 9.x, le système de gestion de base de données open source PostgreSQL passe de la situation où il était défini par comparaison aux systèmes propriétaires à la situation où il attire autant d’innovations que les autres solutions, et surpasse maintenant la concurrence sur bien des aspects.

L’implémentation de la réplication synchrone dans PostgreSQL 9.1 y apporte par exemple une valeur ajoutée déterminante : une réplication sans perte de données. Cette fonctionnalité majeure et bien d’autres, PostgreSQL les doit à 2ndQuadrant, désigné « Sponsor Platine » du projet PostgreSQL pour ses nombreuses contributions actives à son développement depuis la branche 7.x.

Cette multinationale implantée en France, propose l’un des plus larges catalogues de formation PostgreSQL au monde, couvrant tous les besoins dans les niveaux débutants à avancé. Le contenu de formation est rédigé par les experts PostgreSQL de 2ndQuadrant, qui ont déjà écrit et publié deux ouvrages de référence et guides d’utilisation de la technologie.

Simon Riggs, Contributeur Majeur de PostgreSQL et commiter du projet, supervise la conception et la rédaction des contenus de formations détaillées, techniques, constamment mis à jour et incluant des retours d’expériences de situations de production rencontrées par 2ndQuadrant, ainsi que des informations qui proviennent directement des sources de PostgreSQL.

Actuellement, 2ndQuadrant propose six volets de formations, allant de la compréhension pratique du langage SQL, des bases de données et de la théorie relationnelles, jusqu’aux entrepôts de données, partitionnement, réplication et restauration des données avec PostgreSQL 9.

De la réplication synchrone aux extensions en passant par les requêtes d’écritures complexes, nous avons également participé à quelques améliorations de performances.

Revenons un instant sur la réplication synchrone telle que nous l’avons réalisée pour PostgreSQL 9.1. Il s’agit en effet d’une première mondiale : avant PostgreSQL, il n’existait aucun système de réplication synchrone capable d’assurer la durabilité des données sur un autre nœud avec une granularité transactionnelle. Cela signifie que chaque transaction peut choisir ce niveau de garantie quelque soit la configuration globale du système.

La difficulté principale de la réplication synchrone est qu’elle apporte une garantie forte de durabilité des données au prix d’une latence plus élevée, de performances moindres, et d’un impact sensible sur la capacité de montée en charge de votre implémentation PostgreSQL. Nos clients voulaient la meilleure solution qui soit, nous l’avons implémentée dans PostgreSQL 9.1 : vous avez les moyens de décider, pour chaque transaction de votre système, si cette transaction vaut le coût de cette garantie de disponibilité des données. Cette décision peut même être prise dynamiquement par votre application, par exemple en fonction des montants en jeu.

Pour tous vos besoins PostgreSQL, adressez-vous à nos experts, ils sauront vous conseiller. Et lorsque la situation devient exigeante, nos experts continueront de vous accompagner, jusqu’à la création de solutions innovantes.

Par exemple, http://www.heroku.com/ nous a présenté son offre de plate forme d’applications hébergées, qui héberge aujourd’hui le plus grand nombre de bases de données PostgreSQL, avec plus de 175 milles instances.

Cette conférence était l’endroit où passer deux belles journées d’été si la haute disponibilité des services et des données vous intéresse, ou bien la répartition de charge en lecture, ou même en écriture.

Non content de présenter notre catalogue de formation, le site détaille également les missions d’ expertise PostgreSQL que nous réalisons typiquement pour nos clients. Nos spécialités sont bien sûr la Haute Disponibilite et le Mentoring, et nous traitons aussi vos ennuis d’ optimisation PostgreSQL ou encore de replication PostgreSQL.

Mais il ne s’agit pas que d’un catalogue en ligne des services d’expertise PostgreSQL ! Vous pourrez trouver une histoire de PostgreSQL qui met en avant nos contributions passées, ainsi qu’une revue plus détaillée de nos contributions parmi les fonctionalités de PostgreSQL 9.1.

Bien sûr, il nous faut présenter aussi le support 2ndQuadrant, dit « follow the sun » car notre répartition géographique et notre partenariat avec FAST (Fujitsu Australia) nous permet de toujours prendre vos appels au support en heures ouvrées — cela implique un support 24×7 de qualité, puisqu’il implique des développeurs du projet PostgreSQL, et un support en anglais.

Bonne navigation !

Visitez le site de http://2ndQuadrant.fr/ pour plus d’informations : que vous utilisiez déjà PostgreSQL ou bien envisagiez de l’utiliser dans le futur, nous vous aiderons à faire les bons choix.

Travaillez directement avec les développeurs de PostgreSQL !