Discussion :

[redcurve]

Bonjour,

Dans le cadre d'un projet nous devons sélectionner une base de données, je voudrais donc avoir vos avis concernant PostgreSQL.

Le contexte nous travaillons sur une application distribuée fonctionnant actuellement sur une dizaine de serveurs. A terme elle tournera sur plus d'une centaine de machines, afin de stocker certaines informations nous employons actuellement SQL server 2008 x64. Concernant la charge il y aura environs 1million de transaction XA avec différents niveaux d'isolation et plusieurs Go d'écriture (ça peut aller jusqu'au To).

Autant dire que la base sera mise à rude épreuve.

On nous a demandé d'évaluer plusieurs bases de données afin de réduire les coûts (perso j'adore SQL server mais bon ...), je voudrais donc avoir vos avis concernant PostgreSQLen terme de performance, concurrence, de support du language sql, de fiabilité.

Cordialement.

[SQLpro]

Au niveau des transaction PG ne permet pas de les piloter directement dans des procédures comme le fait SQL Server. En effet le BEGIN TRANSACTIOn n'existe pas et PG considère toujours qu'une fonction (il n'y a pas de procédure dans PG) est atomique...

De plus PG fonctionne nativement en mode de verrouillage optimiste et ne supporte que 2 niveaux d'isolation équivalent au READ COMMITTED SNAPSHOT et au SERIALIZABLE de SQL Server.

En sus, du fait du verrouillage optimiste, PG gère le magasin de ligne (row versionning) à l'intérieur de chaque page ce qui augmente de façon très sensible le volume des données. Pour nettoyer cela il faut faire passer l'outil VACUUM régulièrement ou le mettre en AUTOVACUUM, mais dans ce cas, avec une forte activité transactionnelle on obtient des ralentissements considérables et des deadlocks !

Au niveau de la journalisation des transactions, PG utilise un seul journal par instance pour toutes les bases ce qui créé un point de contention globale. Même si vous n'avez qu'une seule base de production, le fait que les objets temporaires de SQL Server soient créés dans une base différentes, permet, avec un placement et dimensionnement judicieux des fichiers d'obtenir des performances très supérieures, les journaux de transactions étant toujours le premier point de contention des SGBDR....

Seul avantage au niveau de PG, c'est la possibilité de faire de la journalisation asynchrone (mais danger..) ce que vient d'ailleurs de reprendre SQL Server en version 2014 via la "delayed durability".

Enfin au niveau des performances transactionnelle intrinsèques, intéressez vous à SQL Server 2014 et les tables "In Memory" ainsi que les procédures compilées nativement, ce qui permet souvent de booster les performances d'un facteur de 8 à 50 dans certains cas de figure, donc une réelle économie d'échelle !

A +