Alors que PostgreSQL a supporté la compression avec son stockage TOAST et qu'au cours de l'année dernière, il a développé le support de la compression LZ4, ainsi que la compression du WAL, la compression des sauvegardes et d'autres utilisations, les développeurs de PostgreSQL se préparent à étendre davantage leurs capacités de compression avec le support de Zstandard (ZSTD).Le codage ZSTD prend en charge les types de données SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE PRECISION, BOOLEAN, CHAR, VARCHAR, DATE, TIMESTAMP et TIMESTAMPTZ et offre un taux de compression élevé avec de très bonnes performances sur divers ensembles de données. Le ZSTD fonctionne particulièrement bien avec les colonnes CHAR et VARCHAR qui stockent un large éventail de chaînes longues et courtes, comme les descriptions de produits, les commentaires des utilisateurs, les journaux et les chaînes JSON.
Alors que certains algorithmes, tels que l'encodage Delta ou l'encodage Mostly, peuvent potentiellement utiliser plus d'espace de stockage que l'absence de compression, ZSTD est très peu susceptible d'augmenter l'utilisation du disque.
Cette semaine, une discussion a été lancée entre les développeurs de PostgreSQL pour ajouter Zstd comme algorithme de compression supporté par ce serveur de base de données open source largement utilisé. Cette discussion s'est avérée favorable et déjà avec PostgreSQL Git il y a maintenant un support pour construire PostgreSQL avec Zstd inclus.
Bien que cela ajoute l'option --with-zstd build-time et permette de construire avec la bibliothèque de compression Zstd, pour le moment, cela ne permet aucune utilisation réelle de Zstd dans PostgreSQL. Des commits de suivi sont attendus prochainement pour commencer à permettre à PostgreSQL de tirer parti des capacités de compression rapide de Zstandard.
« ZStandard est un algorithme de compression développé par Facebook qui est complètement et totalement génial. Une fois, j'ai évalué plusieurs algorithmes de compression pour compresser environ 10 Go de données. La compression la plus élevée que j'ai obtenue était de l'ordre de 750 Mo avec LZMA, mais la décompression prenait environ 1,25 minute et la compression prenait environ une demi-heure. Avec ZStd (multiple threads) au niveau 9 de compression, j'ai atteint 1GB avec 3 minutes de compression et 24 secondes de décompression », déclare un Internaute. « LZ4 était un peu plus rapide au moins pour la compression, mais les fichiers résultants faisaient presque 2GB », ajoute-t-il.
C'est formidable de voir toute l'adoption autour de Zstd grâce à son bon taux de compression tout en offrant une décompression (et une compression) très rapide pour ce projet sous double licence (BSD et GPLv2) et centré sur Facebook. Au moment où PostgreSQL 15 sortira, il semble que le support de Zstd sera disponible pour compléter toutes les possibilités de LZ4 que l'on trouve actuellement dans PostgreSQL 14.
Compression LZ4 TOAST dans PostgreSQL 14
PostgreSQL 14 fournit l'option de compression LZ4 pour les colonnes. Elle permet une compression plus rapide par rapport à la méthode PGLZ existante dans TOAST.
Rappelons que, dans PostgreSQL, une page est l'unité de base pour stocker des données, et la taille de chaque page est de 8 kB par défaut. Fondamentalement, les données d'une ligne ne sont pas autorisées à être stockées sur plusieurs pages. Cependant, certains types de données ont une longueur variable et peuvent dépasser la taille d'une page. Pour surmonter cette limitation, les valeurs des champs de grande taille sont comprimées et/ou réparties sur plusieurs lignes physiques. Cette technique est connue sous le nom de TOAST (The Oversized-Attribute Storage Technique).
Par défaut, TOAST n'est déclenché que si une table comporte des colonnes de longueur variable et que la taille des données de la ligne dépasse TOAST_TUPLE_THRESHOLD (normalement 2 ko). Dans un premier temps, les données sont compressées. Ensuite, si les données sont encore trop volumineuses, elles seront stockées hors ligne.
Avant PostgreSQL 14, TOAST ne supportait qu'un seul algorithme de compression : le PGLZ, un algorithme intégré à PostgreSQL. Mais d'autres algorithmes de compression peuvent être plus rapides ou avoir des taux de compression plus élevés que PGLZ.
Mais à partir de PostgreSQL 14, le SGBD propose une autre option : la compression LZ4 est un algorithme de compression sans perte connu pour sa rapidité. Afin d'utiliser la nouvelle fonctionnalité de compression LZ4 dans PostgreSQL14, vous devrez installer les bibliothèques liées à LZ4 dans le système d'exploitation, et spécifier l'option --with-lz4 lors de la compilation et du packaging de PostgreSQL.
Les taux de compression de PGLZ et LZ4 sont liés aux données dupliquées, plus il y a d'éléments dupliqués, plus le taux de compression est élevé. Cependant, la compression ne sera pas effectuée dans les cas où PostgreSQL évalue que le ratio résultant ne serait pas bon, même si la taille des données atteint le seuil. En effet, la compression ne permettrait pas d'économiser efficacement de l'espace disque, et entraînerait au contraire un temps et des ressources supplémentaires pour la décompression.
Selon le code source actuel de PostgreSQL14, PGLZ exige un taux de compression d'au moins 25 %, tandis que LZ4 exige seulement que les données compressées ne soient pas plus grandes que les données non compressées.
Source : PostgreSQL
Et vous ?
Selon vous, pourquoi PostgreSQL doit-il prendre en charge la compression lui-même ? N'est-il pas plus logique de fournir la compression à partir du système de fichiers ? Y a-t-il un avantage particulier à ce que PostgreSQL réimplante sa propre compression ?Voir aussi :
PostgreSQL 10 est disponible en téléchargement : quelles sont les nouveautés de la dernière version du SGBD libre ? Disponibilité générale de PostgreSQL 11 : un aperçu des principales fonctionnalités du SGBDRO libre OpenZFS 2.0 est disponible avec la prise en charge de Linux et FreeBSD et apporte de nouvelles fonctionnalités comme la compression ZStandard Ubuntu 18.10 est disponible, embarque GNOME 3.30 pour une nouvelle apparence et s'installe plus vite grâce à l'algorithme de compression Zstandard 
Envoyé par gabriel21
