La partie de PostgreSQL que nous détestons le plus (2023)

La partie que nous détestons le plus dans PostgreSQL

• PostgreSQL s'est imposé ces cinq dernières années comme le SGBD le plus apprécié sur Internet. Cela s'explique par sa fiabilité, ses fonctionnalités, son extensibilité et son adéquation à la plupart des charges de travail en production.
• Cependant, son implémentation du contrôle de concurrence multiversion (MVCC) est considérée comme la pire parmi les SGBD relationnels.

Qu'est-ce que le contrôle de concurrence multiversion ?

• L'objectif du MVCC est de permettre à plusieurs requêtes de lire et d'écrire dans la base de données en même temps sans interférer les unes avec les autres.
• Le SGBD ne remplace pas les lignes existantes, mais conserve plusieurs versions afin que les requêtes puissent choisir la version appropriée pour satisfaire leur demande.
• Cette approche évite d'avoir besoin de verrous explicites sur les enregistrements et permet aux requêtes d'observer un snapshot de la base de données.

Le contrôle de concurrence multiversion de PostgreSQL

• Lorsqu'il met à jour une ligne existante, PostgreSQL utilise un mode de stockage des versions append-only qui crée une nouvelle version pour appliquer les modifications.
• Cette approche entraîne plusieurs problèmes complexes.

Stockage multiversion

• PostgreSQL stocke toutes les versions d'une ligne dans le même espace de stockage.
• Lors d'une mise à jour, il alloue un nouvel emplacement de version, copie la version existante, puis applique les modifications.
• PostgreSQL utilise une chaîne de versions pour enregistrer la relation entre les versions.

Vacuum des versions

• PostgreSQL utilise une procédure de vacuum pour supprimer les anciennes versions.
• L'autovacuum s'exécute régulièrement pour retirer les versions expirées et réutiliser l'espace.

Pourquoi le MVCC de PostgreSQL est le pire

• L'implémentation du MVCC dans PostgreSQL repose sur une conception des années 1980, peu adaptée aux modèles modernes des systèmes log-structured.
• Le texte explique quatre problèmes majeurs provoqués par le MVCC de PostgreSQL.

Problème 1 : copie des versions

• PostgreSQL copie toutes les colonnes dans la nouvelle version, ce qui augmente la duplication des données et les besoins de stockage.
• MySQL et Oracle évitent ce problème en stockant des deltas.

Problème 2 : gonflement des tables

• Les versions expirées de PostgreSQL occupent de l'espace et, si l'autovacuum ne parvient pas à les supprimer, la base de données continue de grossir.
• Cela dégrade les performances des requêtes.

Problème 3 : maintenance des index secondaires

• PostgreSQL doit mettre à jour tous les index à chaque mise à jour.
• Cela dégrade les performances des requêtes.

Problème 4 : gestion du vacuum

• Les performances de PostgreSQL dépendent fortement de l'efficacité de l'autovacuum.
• Si l'autovacuum ne fonctionne pas correctement, des problèmes de performance apparaissent.

Résumé de GN⁺

• PostgreSQL reste un SGBD très apprécié, mais son implémentation du MVCC n'est pas moderne.
• Résoudre les problèmes de MVCC de PostgreSQL demande beaucoup de temps et d'efforts.
• Il est possible d'améliorer les performances en optimisant les réglages de l'autovacuum de PostgreSQL.
• MySQL et Oracle peuvent être envisagés comme alternatives pour résoudre les problèmes de MVCC de PostgreSQL.

[GN⁺]

Avis Hacker News

• OrioleDB a essayé de résoudre le problème avec un nouveau moteur de stockage

  • Si les opérations sont principalement des INSERT, aucun espace supplémentaire n'est nécessaire
  • Il existe une limite au nombre d'instructions dans une transaction, mais on peut l'éviter avec COPY FROM
  • Du point de vue du DBA, il n'est pas nécessaire de gérer séparément l'espace de rollback/undo

• La conception de PostgreSQL n'est pas mauvaise sur tous les plans

  • MySQL et Oracle stockent des deltas compressés entre la nouvelle version et la version actuelle
  • git ne stocke pas de diff et, comme PostgreSQL, stocke l'objet entier

• Les implémentations MVCC d'Oracle et de MySQL ne stockent pas l'adresse physique de la nouvelle version

  • À la place, elles stockent un identifiant logique qui permet au SGBD de retrouver l'adresse physique de la version actuelle
  • Cela peut ralentir les lectures d'index secondaires, mais réduit la surcharge grâce à d'autres avantages

• Dans MySQL, pour mettre à jour une seule ligne, SELECT id WHERE something; UPDATE what WHERE id=id est bien plus rapide

  • Dans les opérations courantes, cette approche n'est pas utilisée, ce qui ralentit les DML ponctuels

• Dans les années 2010, MongoDB était perçu comme "webscale" à cause des écritures non durables

  • C'était le résultat du marketing

• Pas d'accord avec l'explication concernant pg_repack

  • VACUUM FULL est lourd, mais repack est une alternative plus rapide et plus légère

• PostgreSQL a gagné en popularité pour les raisons suivantes

  • sécurité des données, ACID, similarité avec Oracle, MVCC, respect du standard SQL, équipe Postgres, communauté, types de données, hautes performances, flexibilité BSD
  • PostgreSQL continue d'évoluer et la communauté y joue un grand rôle

• Une question est posée sur le fait de savoir si le stockage complet de chaque nouvelle version de row tuple dans PostgreSQL est une propriété du moteur de stockage par défaut

• L'article était bien écrit, facile à lire et à comprendre

  • Il a aidé à comprendre les problèmes liés au vacuum, et les diagrammes étaient bons