Étude : où et comment sont stockées mes données avec PostGreSQL

SQLpro · 07/03/2013 12:50:11

Bonjour,

voici une nouvelle étude sur le stockage des données des bases avec PostGreSQL.
http://blog.developpez.com/sqlpro/p1182 … postgresql

Merci de vos commentaires.

kenrio · 08/03/2013 13:10:52

Bonjour,

en fait c'est juste un pdf pour dire(redire) que pgsql ne vaut pas un sgdb payant...

PostGreSQL ne permet pas de faire des opérations d’allocation de fichier à bas niveau, contrairement à Oracle ou SQL Server. Les fichiers sont donc créés ou le système trouve un peu de place et se trouvent donc fortement morcelés lors des opérations de croissance (voir ci avant).

Moi je pars du principe que ce n'est pas au sgbd de faire ça mais à l'os... donc je trouve normal que postgresql ne sache pas faire ça.
J'aimerais vraiment voir le gain réel de ce genre de "feature".

Une sécurité passoire !
Pour terminer, la sécurité des fichiers est faible en comparaison de ce que font Oracle ou MS SQL Server. Nous avons vu qu’il était possible de modifier ou supprimer un fichier d’une base de données sans que PostGreSQL ne s’en perçoive de prime abord.

en même temps un mec qui a les droits de faire ça sur le serveur il peut faire ce qu'il veut...

De plus PostGreSQL n’offre aucun moyen de crypter le stockage des données des bases contrairement à Oracle ou SQL Server

Et pourquoi l'OS le ferait pas ?

Faut-il miser sur PostGreSQL ?
Le professionnel que je suis déconseille l’utilisation de postGreSQL sur des bases fortement transactionnelles (site web marchand par exemple), comme sur des domaines sensibles sur le plan de la sécurité ou de la confidentialité, elles que la santé ou les finances.
En revanche PostGreSQL reste un bon choix pour des bases de données relationnelles de petite à moyenne taille (quelques dizaines à quelques centaines de Go) lorsque l’on en connait les limites et que l’on met en œuvre les moyens e se prémunir des quelques inconvénients du système

Cette conclusion...

MitsuTomoe · 08/03/2013 15:25:57

Je suis nouveau sur PostgreSQL (1 an), mais j'ai lu plusieurs articles de Frédéric Brouard.
A chaque fois, ça me semble juste techniquement et bien documenté, mais toujours biaisé en faveur de SQL Server
et d'Oracle. Le ton général semble être destiné à faire naitre la polémique, plutôt qu'à ouvrir un dialogue constructif.
De mon côté, j'ai connu RDB (sous OpenVMS) et Oracle (divers U*x) il y a quelques années (jusqu'en 2004) .
Dans Pg, je trouve des fonctionnalités avancées que je ne connaissais pas (fonctions window, data type interval, recherche textuelle...).
Bémol : c'est peut-être dû à l'ancienneté des versions d'autres SGBD que j'ai pratiqués, ou au manque de profondeur de mes compétences.
Mais ce qui me séduit surtout dans Pg, au delà des comparatifs difficilement objectifs, c'est le dynamisme de la communauté,
qui conduit à une rapide progression du produit, et un esprit de solidarité et de partage, toujours appréciable.

SQLpro · 09/03/2013 12:49:36

Rebonjour,

Tout le monde ici fait des papiers élogieux sur PostGreSQL et c'est bien normal. Il est normal que la communauté PostGreSQL fasse ressortir les bienfaits de PG. Pour autant PostgreSQL est loin d'être parfait.
Il est donc aussi normal de le comparer et j'ai personnellement choisit de dire de manière systématique ce qui me paraissait moins bon dans PostGreSQL en comparaison à d'autres SGBDR afin que chacun puisse faire un choix non biaisé en lisant les très nombreux articles de la communauté (Guillaume Lelarge, Bruce Momjan, Michael Stonebarker... et bien d'autres !) tous en faveur de PostgreSQL, et les rares miens en sa défaveur, afin d'avoir une vision claire des choses. Notez que je spécifie toujours dans mes études les articles sur lesquels je me base et les livres de référence qui m'ont servit à puiser les informations que je donne... Bref je n'invente rien ! Et mes tests le prouve...
J'aurais pu être beaucoup plus méchant en postant par exemple quelques extraits croustillants des forums et listes d'abonnement postgresql (par exemple pgsql-general@postgresql.org) dans lesquels les DBA sont confrontés à quelques un des problèmes que je cite, comme par exemple les blocage et deadlocks engendrés par la combinaison MVCC / VACUUM...

Je ne suis pas payé par un quelconque éditeur de SGBDR et mon seul revenu est le fruit du travail au sein de ma propre entreprise. Et même si j'ai l'étiquette de MVP Microsoft, c'est une distinction honorifique qui vient du fait que je publie régulièrement des articles et des études sur Microsoft SQL Server, et ce titre m'est donné par mes pairs pour un an seulement et renouvelé maintenant par vote depuis plus de 10 ans du fait de mes publications sur le sujet...
A quand d'ailleurs une communauté de "pairs" PostGreSQL pour honorer ses membres les plus compétents ? (Il y a des chances que je n'en fasse jamais partit tant la polémique est vive à chaque fois que je poste... ;-)
Il m'arrive aussi de conseiller PostGreSQL en remplacement de MySQL, SQL Server ou Oracle, dans des missions en clientèle et pour certains cas et bien sûr l'inverse (passer de PostGreSQL à SQL Server, par exemple comme ce fut le cas pour la gestion des crues du grand delta du Rhône pour la DDE du Gard dans le cadre du renouvellement de ce système de Paratronic http://www.postgresql.fr/temoignages:paratronic)

Je connais aussi assez bien Oracle (pas aussi profondément que SQL Server, c'est un fait), mais au contraire de SQL Server et PostgreSQL, je ne le pratique plus en entreprise depuis plus de 10 ans... (ce qui ne m'empêche pas d'avoir des confrères très pointus sur Oracle pour leur demander leurs avis afin d'éviter de dire des bêtises - Exemple, Stéphane Faroult...).

Enfin en ce qui concerne la richesse SQL de PostGreSQL, j'ai eu l'occasion maintes fois d'en dire du bien, car le SIG, comme certains fonctions avancées (les fonctions fenêtrées par exemple) ont été bien faites et souvent en avance sur certains concurrents (SQL Server en particulier... Lire mon papier à ce sujet.
Mais c'est curieux, le forum PostGreSQL semble agir plutôt à charge à mon encontre qu'à décharge ! (peut être le mérite-je... Mais dans ce cas ça ressemble à un procès d'intention ;-)

Reste qu'aujourd'hui Oracle, IBM DB2, SQL Server et PostGreSQL sont à peu près à même niveau sur le plan du langage SQL, mais pas du tout sur l'administration ou les outils périphériques... Et c'est cela qui peut faire la différence, car le cout d'exploitation ne sera pas du tout le même...
Un seul exemple : PostGreSQL ne dispose pas d'outil de CDC... Cela doit se traduit, pour l'implémentation d'un datawarehouse, par la suppression avec reconstruction totale du DW toutes les nuits. C'est donc totalement inexploitable pour de grosses bases (plusieurs To) ou l'on ne peut mettre plusieurs jours à reconstruire le DW et ou l'ion doit agir par différence, ce qui est le but de Change Data Capture...

A +

PS (pour MitsuTomoe) : Je regrette beaucoup DRB qui était l'un des SGBDR les plus avancés et les plus calé sur la norme SQL avec notamment les assertions, toujours pas implémentées sous PostGreSQL, ni d'ailleurs sous aucun autre SGBDR à ma connaissance (sauf Ocelot de mon ami Peter Gulutzan aujourd'hui chez MySQL) ! En revanche le Fulltext PG n'est pas conforme à la norme SQL et pose quelques petits soucis... Il faudra que je fasse un papier comparatif un de ces jours ! Celui de SQL Server l'est avec une richesse fonctionnelle largement supérieure (recherche sémantique en sus par exemple).

Dernière modification par SQLpro (09/03/2013 12:58:24)

SQLpro · 09/03/2013 13:01:44

kenrio a écrit :

...
J'aimerais vraiment voir le gain réel de ce genre de "feature".

je n'ai pas poussé mes test assez loin sur une config RAID adéquate par exemple. mais simplement sur mon PC de base, en forçant les écritures finales (CHECKPOINT). Config standard d'installation des deux côtés.

Avec une seule base et les mêmes données, on a déjà une différence de plus de 3 fois plus rapide pour SQL Server.. Une paille !

A +

Dernière modification par SQLpro (09/03/2013 17:35:39)

kenrio · 11/03/2013 12:02:02

J'ai du mal avec les comparaisons entre un logiciel gratuit et des logiciels payants (très cher)

Une société qui a un budget de plusieurs centaines de milliers d'euro n'a pas d’intérêt à prendre Postgresql autant prendre du msssql ou de l'oracle, c'est vrai c'est mieux mais c'est plus cher.

Donc dans votre conclusion j'aurais bien aimé voir : si vous n'avez pas 100 000 euros à mettre dans votre serveur de bdd vous pouvez prendre PostgreSQL.

SQLpro · 11/03/2013 15:07:22

kenrio a écrit :

J'ai du mal avec les comparaisons entre un logiciel gratuit et des logiciels payants (très cher)

Sans doute parce que vous ne savez pas vous y prendre.

Une société qui a un budget de plusieurs centaines de milliers d'euro n'a pas d’intérêt à prendre Postgresql autant prendre du msssql ou de l'oracle, c'est vrai c'est mieux mais c'est plus cher.
Donc dans votre conclusion j'aurais bien aimé voir : si vous n'avez pas 100 000 euros à mettre dans votre serveur de bdd vous pouvez prendre PostgreSQL.

Les choses ne sont pas aussi simple. Le coût des licence est un des choses parmi beaucoup d'autres comme le budget machine ou le temps passée en administration, les logiciels périphériques....

Par exemple dans le cadre du renouvellement du systèmes de gestion des crues du Rhône, auparavant en postGreSQL, l'absence des vues indexées, de la réplication, de la haute dispo et le coût d'administration a vite fait penché la balance en faveur de Microsoft, car il aurait fallut compenser en matériel (faible surcoût) mais surtout en hardware, infrastructure (ligne spécialisée à haut débit) et en logiciels de gestion de la haute dispo très couteux (réplication des IO disque alors que SQL Server dispose du mirroring et de la réplication de données intégrées...) Bref, 2,7 fois plus cher hors coût d'exploitation.

Et en cout d'exploitation, une société spécialisée avait prévue 1 jour par mois d'intervention pour administrer le serveur et les performances.

Après mise en route du système, nous avons fait une seule intervention de contrôle sur demande de la DDE en trois années, pour un système qui est ultra sensible, car simplement vital (24 morts lors des crues de 2002, la DDE ayant été inondé les systèmes, alors sous PostGreSQL, n'étaient plus entièrement opérationnels !). Depuis 2010 le système est redondé en asynchrone sur deux lieux distants de 100 km via SQL Server exclusivement (aucun matériel ni logiciel suplementaire...) malgré une ligne VPN à faible débit...

A +

Dernière modification par SQLpro (11/03/2013 15:07:56)

kenrio · 11/03/2013 15:50:18

SQLpro a écrit :

Les choses ne sont pas aussi simple. Le coût des licence est un des choses parmi beaucoup d'autres comme le budget machine ou le temps passée en administration, les logiciels périphériques....

Par exemple dans le cadre du renouvellement du systèmes de gestion des crues du Rhône, auparavant en postGreSQL, l'absence des vues indexées, de la réplication, de la haute dispo et le coût d'administration a vite fait penché la balance en faveur de Microsoft, car il aurait fallut compenser en matériel (faible surcoût) mais surtout en hardware, infrastructure (ligne spécialisée à haut débit) et en logiciels de gestion de la haute dispo très couteux (réplication des IO disque alors que SQL Server dispose du mirroring et de la réplication de données intégrées...) Bref, 2,7 fois plus cher hors coût d'exploitation.

Et en cout d'exploitation, une société spécialisée avait prévue 1 jour par mois d'intervention pour administrer le serveur et les performances.

Après mise en route du système, nous avons fait une seule intervention de contrôle sur demande de la DDE en trois années, pour un système qui est ultra sensible, car simplement vital (24 morts lors des crues de 2002, la DDE ayant été inondé les systèmes, alors sous PostGreSQL, n'étaient plus entièrement opérationnels !). Depuis 2010 le système est redondé en asynchrone sur deux lieux distants de 100 km via SQL Server exclusivement (aucun matériel ni logiciel suplementaire...) malgré une ligne VPN à faible débit...

A +

Vous utilisez un cas particulier pour démontrer votre point de vue, des cas inverses y en a beaucoup plus...

Tout ça c'est de l'époque pgsql 8.4 non ? car je vois pas ce que pgsql ne peux pas faire dans ce que vous dites et surtout en étant plus cher...

SQLpro · 12/03/2013 18:49:22

kenrio a écrit :

Vous utilisez un cas particulier pour démontrer votre point de vue, des cas inverses y en a beaucoup plus...
Tout ça c'est de l'époque pgsql 8.4 non ? car je vois pas ce que pgsql ne peux pas faire dans ce que vous dites et surtout en étant plus cher...

Les vues indexées n'existent toujours pas sous PostGreSQL. Le mirroring synchrone avec basculement automatique n'existe toujours pas (PG Pool nécessite plus de machine et c'est plus du load balancing, et plus de machine, c'est donc plus cher !). Il n'y a toujours pas de mécanisme intégré de réplication des données (quelques tables répliquée d'une base X vers une base Y en transactionnel par exemple) ....
Donc tout cela coute fort cher à implémenter manuellement lorsque l'on a ce besoin et que l'on choisit PostGreSQL....

A +

#1 07/03/2013 12:50:11

Étude : où et comment sont stockées mes données avec PostGreSQL

#2 08/03/2013 13:10:52

Re : Étude : où et comment sont stockées mes données avec PostGreSQL

#3 08/03/2013 15:25:57

Re : Étude : où et comment sont stockées mes données avec PostGreSQL

#4 09/03/2013 12:49:36

Re : Étude : où et comment sont stockées mes données avec PostGreSQL

#5 09/03/2013 13:01:44

Re : Étude : où et comment sont stockées mes données avec PostGreSQL

#6 11/03/2013 12:02:02

Re : Étude : où et comment sont stockées mes données avec PostGreSQL

#7 11/03/2013 15:07:22

Re : Étude : où et comment sont stockées mes données avec PostGreSQL

#8 11/03/2013 15:50:18

Re : Étude : où et comment sont stockées mes données avec PostGreSQL

#9 12/03/2013 18:49:22

Re : Étude : où et comment sont stockées mes données avec PostGreSQL

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux