PostgreSQL 2013

08-01-2013
PostgreSQL 2013

Bonne Année 2013 à tous !

Le changement de calendrier civil est un moment privilégié pour faire le bilan de l’année passée et quelques prévisions pour l’année à venir. La rétrospective 2012 de PostgreSQL présente un très bon bilan, avec la mise à disposition de la version 9.2 dont l’adoption est en pleine croissance. Ce décalage entre la date de sortie d’une version et son adoption à grande échelle fait que 2012 est l’année où la version PostgreSQL 9.1 a été fortement déployée en production.

En ce qui concerne les conférences, nos experts ont profité de 2012 pour faire un petit tour du monde de PostgreSQL : nous avons en effet eu l’opportunité de présenter nos travaux en Belgique, au Canada, aux États Unis, en République Tchèque et plusieurs fois en France, à Lyon. Nous avons parlé des nouvelles fonctionnalités dont nous participons au développement (les Extensions, les Triggers étendus), les architectures que nous avons mises en place pour répondre à des besoins de Haute-Disponibilité, de Répartition de Charge, mais surtout de Durabilité des Données ; sans oublier bien sûr les aspects de mesures et améliorations des performances. Les contenus que nous avons utilisés lors de ces conférences sont bien sûr disponibles en ligne!

Ce tour du monde nous a permis de constater que PostgreSQL est de mieux en mieux équipé pour répondre à vos problématiques de garanties de données et de continuité des services, en particulier avec les version 9.1 et 9.2. Le circuit des conférences de la communauté PostgreSQL est un lieu d’échange très riche, où nous avons plaisir à rencontrer les utilisateurs et à écouter leur besoin, à prendre en compte leur point de vue pour les prochaines versions de votre moteur de base données préféré.

La prochaine conférence PostgreSQL organisée par la communauté Européenne de PostgreSQL se tient en belgique, à Bruxelles, le vendredi 1er février, en ouverture du FOSDEM. Je vous encourage fortement à vous y inscrire et à nous rejoindre!

Qu’attendre donc de 2013, après une telle année 2012 pour PostgreSQL ?

Suite à la circulaire de notre Premier Ministre, je pense que nous allons assister à un mouvement continu de migrations vers PostgreSQL, cette tendance me semble loin d’être arrivée en bout de course. L’arrivée sur le marché de solutions dites NoSQL se transforme doucement en « Not Only SQL », et PostgreSQL est prêt à s’intégrer dans des environnements de production hétérogènes complexes, en particulier avec ses Foreign Data Wrappers.

La période où l’on écrit sa lettre au père noël est bien évidemment terminée, mais si je pouvais émettre un voeux pour 2013… il concernerait la version de PostgreSQL qui sortira en 2014 et que nous allons commencer à préparer dès mars ou avril prochain. J’aimerais que cette version inclue une nouvelle approche plus simple et plus efficace pour résoudre le problème des tables à grands nombres de ligne, où la solution actuelle consister à créer des partitions de manière explicite. N’hésitez pas à nous contacter si vous partagez ce problème !

PostgreSQL fait sa rentrée

01-10-2012
PostgreSQL fait sa rentrée

La bousculade de la rentrée retombe comme un bon soufflet, il est temps de prendre un peu de recul sur cette période mouvementée.

Une nouvelle version de PostgreSQL est maintenant disponible, il s’agit de la 9.2. C’est une version qui apporte de nouvelles fonctionnalités dans les domaines de la modélisation de données, de l’efficacité des requêtes, de la réplication de données et des performances en lecture et en écriture avec un grand nombre de clients connectés. Autant dire qu’il s’agit d’une nouvelle version majeure à ne manquer sous aucun prétexte!

Postgres Open

Nous avons eu l’occasion de revenir en détails sur plusieurs de ces fonctionnalités lors de la conférence américaine Postgres Open à Chicago. Dimitri a eu le plaisir d’y présenter une migration de grande échelle depuis MySQL vers PostgreSQL. Nous aurons une prochaine conférence au contenu comparable en Europe à Prague très bientôt, avec PostgreSQL Conference Europe 2012. Si vous n’êtes pas encore inscrits, pensez à le faire rapidement, les places partent vraiment très vite cette année! Nous espérons avoir le plaisir de vous y croiser, en particulier lors de l’une de nos présentations.

Cédric Villemain expliquera comment obtenir et valider les métriques de performances de vos installation PostgreSQL et Dimitri Fontaine présentera comment exploiter les techniques de réplication et de durabilité des données proposées par PostgreSQL afin d’atteindre les objectifs de fiabilité requis par votre projet.

Enfin, un grand merci au gouvernement français, qui vient par cette circulaire intitulée Orientation Pour l’Usage des Logiciels Libres dans l’Administration de reconnaître la place toute particulière de PostgreSQL au sein des institutions françaises. Nous sommes fiers de participer à la mise au point de ce logiciel, ainsi qu’à ses déploiements en production, et sommes heureux de pouvoir renouveler notre engagement dans une solution plébicitée par Monsieur le Premier Ministre, en tant que contributeurs et en tant qu’experts.

Conserver un tel rythme après la rentrée ne sera pas une mince affaire !

Conférence PostgreSQL à Lyon

04-06-2012
Conférence PostgreSQL à Lyon

Le mois dernier se déroulait la Conférence PostgreSQL internationale pgcon, à Ottawa, au Canada. C’est l’occasion d’une réunion privilégiée où les principaux participants au développement de PostgreSQL se réunissent pour une journée complète dans la même salle afin de conclure sur l’année écoulée et de préparer au mieux la suivante. Cette fois nous avons revu notre processus de développement et parlé des fonctionnalités que nous voudrions développer au sein de PostgreSQL 9.3. Parmi la sélection des 20 développeurs les plus influents de la version 9.2 se trouvaient 4 développeurs 2ndQuadrant!

Lors de la conférence elle-même, j’ai eu le plaisir de présenter un cas d’usage de migration de MySQL à PostgreSQL que j’avais déjà évoqué ici, vous saurez tout sur la page dédiée à cette présentation : Large Scale Migration From MySQL to PostgreSQL.

À peine de retour de la conférence et nous voilà déjà dans l’organisation de la suivante. Il s’agit de la Conférence PostgreSQL Française qui a lieu cette année à Lyon. Et qui surtout, à lieu jeudi. Ce jeudi 7 juin 2012, en effet! Il reste quelques dernières places, aussi n’hésitez pas à vous inscrire si vous êtes tentés par le programme.

Cédric Villemain présentera l’utilisation de l’outil Tsung afin de réaliser des validations des performances d’une installation PostgreSQL ; j’aurai quant à moi le plaisir de vous parler de plusieurs cas d’usage de la réplication, dans une présentation intitulée Disponibilité et Durabilité, Architectures et Réplications. Nous détaillerons un projet typique de taille moyenne et les différents besoins associés, et surtout les outils et méthodes à mettre en place avec PostgreSQL afin d’y répondre.

Migration de MySQL vers PostgreSQL

Rédigé par Dimitri Fontaine dans Conférence, Expertise, Migration, news 1 Commentaires »
11-04-2012
Migration de MySQL vers PostgreSQL

La conférence annuelle des développeurs PostgreSQL a lieu cette année encore à Ottawa, au Canada, et nous y serons présent. J’aurai le plaisir de raconter une migration MySQL effectuée cet hivers, pour un site de type réseau social dont l’heure de gloire l’a placé dans les 10 sites les plus visités sur internet.

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 ?

Pourquoi choisir PostgreSQL plutôt que SQL Server?

12-12-2011
Pourquoi choisir PostgreSQL plutôt que SQL Server?

Un article récent en anglais propose dix bonnes raisons de choisir PostgreSQL plutôt que SQL Server dans le cadre d’un nouveau projet, ce qui nous offre une belle occasion de revenir sur notre publication précédente qui ciblait la migration vers PostgreSQL. Nous pouvons donc cette fois nous intéresser de plus prêt aux particularités de PostgreSQL !

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.

Oracle, SQL Server, PostgreSQL

Rédigé par Dimitri Fontaine dans Contributions, Expertise, Migration, news, Réplication 6 Commentairess »
17-11-2011
Oracle, SQL Server, PostgreSQL

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 ?

De retour d’Amsterdam

Rédigé par Dimitri Fontaine dans Conférence, Expertise, Migration, news Pas de Commentairess »
24-10-2011
De retour d'Amsterdam

La conférence PostgreSQL Europe à Amsterdam s’est déroulée la semaine dernière et a réunit un grand nombre de professionnels du secteur. Il était facile de constater que les membres de la communauté des développeurs du produit Open Source sont des professionnels sérieux et aguerris. Non seulement leurs interventions l’ont souligné, mais leur disponibilité dans les couloirs ne peut laisser la place au doute. Nous avons bien à faire avec PostgreSQL à une base de données Open Source Professionnelle, et cela n’a rien d’une contradiction.

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.

PostgreSQL Conference, Amsterdam

Rédigé par Dimitri Fontaine dans Conférence, news, Réplication Pas de Commentairess »
06-10-2011
PostgreSQL Conference, Amsterdam

Chaque année est organisée une conférence Européenne réunissant développeurs et utilisateurs de PostgreSQL.  Cette année la conférence a lieu à Amsterdam, aux Pays-bas. Nos experts seront présent à la fois comme sponsors de l’évènement via 2ndQuadrant, mais aussi bien sûr pour présenter des technologies liées à PostgreSQL.

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!

Nos formations PostgreSQL

21-09-2011
Nos formations PostgreSQL

2ndQuadrant : des experts PostgreSQL qui participent au développement du SGBD et offrent un très large catalogue de formation PostgreSQL à découvrir.

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.

PostgreSQL 9.1

12-09-2011
PostgreSQL 9.1

La nouvelle version de PostgreSQL a été publiée ce lundi 12 septembre 2011, et comme nous pouvons le lire sur l’article les fonctionnalités de PostgreSQL 9.1, nos experts PostgreSQL ont beaucoup contribué à cette nouvelle version.

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.

X Fermer
Contactez Nous

Pour toutes questions, suggestions ou renseugnements sur notre entreprise ou sur nos activités, n'hésitez pas a nous contacter via ce formulaire, ou en visiant notre Page Contact