PostGreSQL vs Microsoft SQL Server - Partie 1 : performances des commandes pour le DBA

Version imprimable

Voir 40 message(s) de cette discussion en une page

14/04/2021, 17h45
SQLpro

Citation:

Envoyé par chrtophe

Le fait qu'il y ai plus de CVE déclarés sur PostGresSQL ne veut pas forcément dire qu'il est plus vulnérable que SQL-Server. Les sources PosGresSQL sont libre et donc consultables, il est donc plus facile d'y trouver des failles que sur un code fermé.

Sauf que si je voulais péter un sql server, j'attaquerais plutôt par RDP, ou dernièrement les failles Exchange et là on inverse complètement la situation.

Je pose donc deux simples questions :
1) quel est la proportion d'utilisateur PostGreSQL qui va lire le code pour voir ou se trouve le bug qu'il vient de découvrir ?
2) pensez vous que 20 ans soit une bonne moyenne pour découvrir un bug gravissime (corruption de données) et 2 ans pour tenter de corriger ce même bug dans PostGreSQL système libre et ouvert, donc selon vous plus facile à maintenir ?

RÉPONSE 1, à mon avis 0,01 %

RÉPONSE 2, voir : https://www.developpez.com/actu/2457...u-FOSDEM-2019/
Toujours pas corrigé à ce jour !

Bref, je vous en présenterais d'autres bug PG dont la correction a été pour le moins pittoresque !

A +

PS : suite aux prochains épisodes...
14/04/2021, 21h06
Christophe

En réponse :

Je répondrais combien pour le code d'SQL-Server ? on ne sait pas, et uniquement des gens de Microsoft. Mais il me semble qu'ils fournissent un accès aux sources en vue d'audit.
Et avec les produits Microsoft, comme déjà dit, tu as un combo : attaque possible par les CVE d'SQL-Server, mais aussi les autres CVE Exchange, RDS, etc.

Sur l'aspect du bug fsync PostGres, de ce que j'en ai compris, il ne s'agit pas d'un bug Postgres, la fonction du noyau retourne OK alors que les données ne sont pas forcément encore écrite sur le disque, à cause du cache. Et quand on utilise du cache, l'écriture est décalée et il y a un risque, mais on gagne en rapidité car le processus effectuant l'écriture n'attend pas la confirmation de la réelle écriture. C'est la même chose sur Windows, avec comme différence que SQL-Server utilise peut-être ses propres drivers pour écrire sur le disque, plus efficace ou prioritaire que les drivers OS.

Et des failles non corrigés depuis 20 ans, tu en trouve dans tous les environnements. Et si tu veux jouer ça, veux-tu que l'on parle de badtunnel, faille présente de Windows 95 à Windows 10 :) (patché)
23/04/2021, 09h43
SQLpro

Citation:

Envoyé par chrtophe

... Sur l'aspect du bug fsync PostGres, de ce que j'en ai compris, il ne s'agit pas d'un bug Postgres, la fonction du noyau retourne OK alors que les données ne sont pas forcément encore écrite sur le disque, à cause du cache. Et quand on utilise du cache, l'écriture est décalée et il y a un risque, mais on gagne en rapidité car le processus effectuant l'écriture n'attend pas la confirmation de la réelle écriture.

Non, pas du tout... fsync est une primitive d'écriture des fichiers comme on en trouve dans la plupart des OS, et elle convient à la majorité des fichiers qui doivent être écrit sur disque. Effectivement elle fait du cache. Mais le problème des bases de données relationnelles est qu'il existe systématiquement au moins deux fichiers qui doivent impérativement être synchronisés : les fichiers de données d'un côté, le journal de transaction de l'autre. Les données reçoivent une marque dite LSN (Lof Segment Number) qui est un point d'entrée dans le journal de transaction, pour savoir ou ils en sont des données réellement écrites. Le journal de transaction étant composé d'entrée séquentielle identifiées par ce fameux LSN. Une même transaction étant découpées en différents LSN au fur et à mesure de son avancement et les transactions étant entrelacées du fait de la concurrence.
Ce qui peut arriver de pire dans un SGBDR est la désynchronisation de ces LSN conduisant à la corruption des données. Et c'est exactement ce qui se passe avec le fsync de Linux. Dans ce cas la base de donnée contient des données qui sont corrompues car il est impossible de savoir ce qui a été réellement mis à jour et ce qui ne l'a pas été...

Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les écritures de PostGreSQL à Linux par défaut. Tous les grand éditeurs de SGBD Relationnel (donc transactionnels) le savent ! Cela a même été noté dans les articles écrit par Stonebraker (le père de Ingres et de PostGreSQL) dans ce livre : "The Ingres Papers: Anatomy of a Relational Database System" - Addison Weslay - 1985
Le fait pour PostGreSQL de l'avoir ignoré relève que l'équipe de développement actuelle n'est pas sérieuse !

Quelques éléments à ce sujet :
https://postgresqlco.nf/doc/fr/param/fsync/
https://wiki.postgresql.org/wiki/Fsync_Errors

Apparemment ce bug vient enfin d'être corrigé 2 ans après sa découverte et 22 ans après que des données corrompues se soient propagée dans les bases...

A +
23/04/2021, 11h59
Christophe

Merci pour l'explication sur les LSN.

Par contre si je prend l'explication :

Citation:

Si ce paramètre est activé, le serveur PostgreSQL tente de s'assurer que les mises à jour sont écrites physiquement sur le disque à l'aide d'appels système fsync() ou de méthodes équivalentes (voir wal_sync_method). Cela permet de s'assurer que le cluster de bases de données peut revenir à un état cohérent après une panne matérielle ou du système d'exploitation.
Bien que désactiver fsync améliore fréquemment les performances, cela peut avoir pour conséquence une corruption des données non récupérables dans le cas d'une perte de courant ou d'un crash du système. Donc, il est seulement conseillé de désactiver fsync si vous pouvez facilement recréer la base de données complète à partir de données externes.

Je ne comprend pas d’où vient le problème avec PostGres

Citation:

As of this PostgreSQL 12 commit, PostgreSQL will now PANIC on fsync() failure.

c'est donc ça la correction ?

Si le paramètre de contrôle fsync est activé, et que le fsync échouait la base continuait à fonctionner (donc dans un état potentiellement instable) c'est ça ?

Citation:

Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les écritures de PostGreSQL à Linux par défaut.

Là je comprend : défaut de conception.

extrait de la discussion sur la mauvaise utilisation fsync avec postgresql

Citation:

Sinon, pour la petite histoire, Microsoft a fait la même erreur en portant SQL Server sur Linux, car les fichiers étaient ouverts en O_DIRECT seulement. Ils ont vite corrigé ça dès SQL Server 2017 CU8 (https://support.microsoft.com/en-us/...-2017-on-linux).

Ce qui me fait dire que c'est un peu plus compliqué que ça. Si même Microsoft a fait de cette façon au départ.
Après il est plus facile d'optimiser les écritures IO directes quand on fait à la fois le SGBD, l'OS, et le filesystem.
23/04/2021, 13h58
Invité

Bonjour,

Citation:

Envoyé par SQLpro

Non, pas du tout... fsync est une primitive d'écriture des fichiers comme on en trouve dans la plupart des OS, et elle convient à la majorité des fichiers qui doivent être écrit sur disque. Effectivement elle fait du cache. Mais le problème des bases de données relationnelles est qu'il existe systématiquement au moins deux fichiers qui doivent impérativement être synchronisés : les fichiers de données d'un côté, le journal de transaction de l'autre. Les données reçoivent une marque dite LSN (Lof Segment Number) qui est un point d'entrée dans le journal de transaction, pour savoir ou ils en sont des données réellement écrites. Le journal de transaction étant composé d'entrée séquentielle identifiées par ce fameux LSN. Une même transaction étant découpées en différents LSN au fur et à mesure de son avancement et les transactions étant entrelacées du fait de la concurrence.
Ce qui peut arriver de pire dans un SGBDR est la désynchronisation de ces LSN conduisant à la corruption des données. Et c'est exactement ce qui se passe avec le fsync de Linux. Dans ce cas la base de donnée contient des données sont corrompues car il est impossible de savoir ce qui a été réellement mis à jour et ce qui ne l'a pas été...

Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les écritures de PostGreSQL à Linux par défaut. Tous les grand éditeurs de SGBD Relationnel (donc transactionnels) le savent ! Cela a même été noté dans les articles écrit par Stonebarker (le père de Ingres et de PostGreSQL) dans ce livre : "The Ingres Papers: Anatomy of a Relational Database System" - Addison Weslay - 1985
Le fait pour PostGreSQL de l'avoir ignoré relève que l'équipe de développement actuelle n'est pas sérieuse !

Quelques éléments à ce sujet :
https://postgresqlco.nf/doc/fr/param/fsync/
https://wiki.postgresql.org/wiki/Fsync_Errors

Apparemment ce bug vient enfin d'être corrigé 2 ans après sa découverte et 22 ans après sue des données corrompues se soient propagée dans les bases...

A +

Merci pour ces infos. Je comprend mieux que PostGre soit décrié du coup :?
25/04/2021, 11h15
SQLpro

Citation:

Envoyé par SQLpro

Non, pas du tout... fsync est une primitive d'écriture des fichiers comme on en trouve dans la plupart des OS, et elle convient à la majorité des fichiers qui doivent être écrit sur disque. Effectivement elle fait du cache. Mais le problème des bases de données relationnelles est qu'il existe systématiquement au moins deux fichiers qui doivent impérativement être synchronisés : les fichiers de données d'un côté, le journal de transaction de l'autre. Les données reçoivent une marque dite LSN (Lof Segment Number) qui est un point d'entrée dans le journal de transaction, pour savoir ou ils en sont des données réellement écrites. Le journal de transaction étant composé d'entrée séquentielle identifiées par ce fameux LSN. Une même transaction étant découpées en différents LSN au fur et à mesure de son avancement et les transactions étant entrelacées du fait de la concurrence.
Ce qui peut arriver de pire dans un SGBDR est la désynchronisation de ces LSN conduisant à la corruption des données. Et c'est exactement ce qui se passe avec le fsync de Linux. Dans ce cas la base de donnée contient des données sont corrompues car il est impossible de savoir ce qui a été réellement mis à jour et ce qui ne l'a pas été...

Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les écritures de PostGreSQL à Linux par défaut. Tous les grand éditeurs de SGBD Relationnel (donc transactionnels) le savent ! Cela a même été noté dans les articles écrit par Stonebarker (le père de Ingres et de PostGreSQL) dans ce livre : "The Ingres Papers: Anatomy of a Relational Database System" - Addison Weslay - 1985
Le fait pour PostGreSQL de l'avoir ignoré relève que l'équipe de développement actuelle n'est pas sérieuse !

Quelques éléments à ce sujet :
https://postgresqlco.nf/doc/fr/param/fsync/
https://wiki.postgresql.org/wiki/Fsync_Errors

Apparemment ce bug vient enfin d'être corrigé 2 ans après sa découverte et 22 ans après que des données corrompues se soient propagée dans les bases...

A +
16/04/2024, 19h44
SQLpro

Citation:

Envoyé par pokap

...
Je voulais ajouter mon grain de sel à la discussion car on parle de pur performance mais il faut bien comprendre (pour ceux qui vont me lire) que ça n'a aucune valeur de qualité pour le choix d'une base de donnée.

J'ai lu beaucoup de conneries dans ma vie, mais des aussi grosses... Rarement !

En quoi le fait d'être plus performant serait moins bon ?

Le fait d'être plus performant économise des ressources et permet de faire des économies à tous les niveaux : électricité, refroidissement, ingénieries, maintenance... Cela s'appelle de l'écologie.... Mais visiblement ce n'est pas le fort des informaticiens, qui, il n'y a pas si longtemps, préférait le langage Python le pire de tous les langages en termes de consommation d'énergie....

Citation:

... je voudrais signaler aux développeur.ses qui cherchent une base de donnée de considérer la performance comme tertiaire à votre choix, si vous prenez une bdd uniquement sur ces performances vous allez planter votre projet c'est garanti.

Un argument aussi stupide et aucunement étayé méritait une exergue !

A +

Voir 40 message(s) de cette discussion en une page