Discussion :

[Bruno]

PostgreSQL aurait commencé à travailler sur le support de la compression Zstandard,
pour compléter toutes les possibilités de LZ4 que l'on trouve actuellement dans PostgreSQL 14

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

[SQLpro]

Ils sont quand même à cent mille lieux des algorithmes de compressions en œuvre dans Oracle, DB2 ou SQL Server qui ne nécessitent aucune décompression pour lire les données !!!

Affligeant !

[gabriel21]

Question : tu fais comment pour lire une donnée compressée sans la décompresser auparavant. A ma connaissance, il n'existe aucun algorithme qui le permette. Si c'était le cas la totalité des OS l'aurait implémenté pour le stockage ainsi que les protocoles réseaux. Dès que tu fais de la compression, tu doit décompressé pour accéder à la donnée. Il existe de nombreuses astuce pour donner l'illusion à l'utilisateur du temps réel, ou bien les systèmes utilisent des composants dédié qui gèrent l’algorithme de compression et de décompression en temps réel. C'est souvent le cas pour les équipement réseaux, les cartes graphiques, les coprocesseurs vidéo qui implémentent directement certains CODEC vidéo. Et encore en réseau, pour ne pas surcharger les systèmes, seule la charge utile est compressée, les en tête ne le sont pas pour permettre un acheminement plus simple, bien que certains systèmes fasse une compression complète avec chiffrement et qui dans ce cas là nécessite en bout de liaison le même équipement. C'est utilisé sur des système point à point avec ligne dédiée (aucun équipement de routage entre les deux, seulement des répéteurs) ou des liaisons satellite quand il y a une forte contrainte de sécurité et de bande passante.

[SQLpro]

...A ma connaissance, il n'existe aucun algorithme qui le permette.

La R&D des grands éditeurs de SGBDR (Oracle, IBM DB2, Microsoft Research) ont travaillé depuis le début des années 90 sur ce sujet avec les universités...

Les principales techniques mises en jeu sont les suivantes :

1) élimination des octets de stockage pour les données NULL
2) réduction de la taille de certains types de données (en particulier FLOAT et DECIMAL) en fonction de la valeur stockée
Ceci existe depuis 2005 dans SQL Server (sparce columns, vardecimal).
PostGreSQL a donc au moins 19 ans de retard sur ces techniques

3) compression par dictionnaire (élimination des redondances) intéressant pour la BI et présent de manière automatique dans Oracle BI et SQL Server Analysis Services
PostGreSQL n'utilise même pas ce principe alors que cela existe dans SQL Server 2000 soit depuis 22 ans.... (SSAS)

4) conversion automatique des données de taille fixe en taille variable
5) compression de type racine avec méthode du dictionnaire partiel + complément (pour les chaines de caractères)
Ceci existe depuis la version 2008 de SQL Server sous le nom de DATA_COMPRESSION = ROW et DATA_COMPRESSION = PAGE
PostGreSQL a donc là aussi au moins 14 ans de retard et cet article ne parle pas du tout de ce genre de technique de compression !

Un exemple de compression de table :

Ou la compression, non seulement est de 6,5 pour la table, mais améliore grandement les temps de réponse...

Et comment ça marche :
https://docs.microsoft.com/en-us/sql...ql-server-2017
Cela utilise plus de CPU mais moins d'accès. Sur de grande tables, cela est plus rapide pour les requêtes. Sur de petite table, aucun intérêt !


6) le stockage vertical des données des tables appelé COLUMSTORE (en lieu et place du stockage horizontal par ligne appelé ROWSTORE)
Disponible dans SQL Server depuis la version 2012
N'existe pas dans le libre, mais certains éditeurs le font payer 500 $ par mois ! (swarm64, Citus...) pour PostGreSQL alors que cela existe, même pour la version gratuite, dans SQL Server !!!
PostGreSQL a donc là aussi au moins beaucoup de retard et aucune vision de le faire :
https://wiki.postgresql.org/wiki/ColumnOrientedSTorage

Le problème des tenants du libre c'est qu'ils se focalisent sur le libre croyant que c'est le Graal alors que les entreprise privée font de la R&D... La seule chose que fait le libre c'est de copier en plus mal et avec beaucoup de peine et de retard ce que font les autres... Par exemple PostGreSQL copie toute ce que fait Oracle en pire au lieu de prendre le meilleur de la techno de chaque SGBDR ! Un exemple flagrant dans PostGreSQL est la méthode inepte de partitionnement pompée d'Oracle mais en pire !

Voici quelques uns des papiers de recherche sur le sujet :
Data Compression in Database Systems (1998)
Query Optimization In Compressed Database Systems (2001)
Data Compression in Oracle
Integrating Compression and Execution in ColumnOriented Database Systems (2006)
Compression Aware Physical Database Design (2011)

Le problème c'est que le design d'un SGBDR comme Oracle ou SQL Server c'est environ 10 000 années homme en R&D... Le libre n'en a ni les moyens ni l’organisation.

Rappelons que pour information, PostGreSQL à corrompu des milliers de bases de données sous Linux à cause de sa mauvaise implémentation de FSync sans jamais s'en apercevoir... !

A +

[gabriel21]

Merci pour ces informations.
Certaines des techniques ne sont pas à proprement parler de la compression, mais des optimisations de la mémoire. Je ne connaissais pas d'ailleurs certaines d'entre elle.
Mais je comprends maintenant le sens de ta phrase. Nous ne parlions tout simplement pas de la même chose. Mais il est vrai que l'utilisation du mot compression dans la documentation Microsoft pour les deux, peut laisser un doute.

[SQLpro]

À moins que je ne soit débile, il s'agit tout à fait de compression. Je pense que tu n'a lu aucun des papiers de recherche que j'ai mis en référence...
Voici une définition tirée du dictionnaire ROBERT du terme compression, avec une entrée spéciale pour l'informatique :
Traitement mathématique permettant de réduire la taille d'un ensemble de données, pour en faciliter le stockage, la transmission…
https://dictionnaire.lerobert.com/de...on/compression

Or toutes les techniques que je viens de te montrer réduisent bien la taille des données. Par conséquent, toutes sont de la compression, et dans la littérature professionnelle, on parle systématiquement de compression pour tous les sujets que je viens de t'évoquer... Lis donc les papiers dont j'ai donné les URL !

A +

[gabriel21]

Or toutes les techniques que je viens de te montrer réduisent bien la taille des données. Par conséquent, toutes sont de la compression, et dans la littérature professionnelle, on parle systématiquement de compression pour tous les sujets que je viens de t'évoquer... Lis donc les papiers dont j'ai donné les URL !

Je les ai lu. La plupart étant en anglais, je peux avoir fait des contre sens.
Oui et non. Lorsque tu compresses (destructif ou non) tu réduis la taille des données. Quand tu optimises, tu réduis les espaces perdu du fait du fonctionnement des mémoires (volatile ou non) donc tu augmentes le nombre de données que tu peux stocker ou tu réduis le nombre de pages mémoire demandée (consommation de RAM inférieure pour un même volume de donnée) et quand tu commences à travailler avec des bases de plusieurs téraoctets en RAM et sur les disques, ces optimisations deviennent très vite indispensable. Effectivement certains utilisent le mot compactage de mémoire en lieu et place d'optimisation. Et on peut traduire le compression anglais en compactage. Nous touchons là un problème de langue.
Je reconnais que je n'ai vu passer ce type de différenciation que dans des cours d'architecture systèmes ou de développement C ou C++. Les langages de haut niveau tel que java ou python ne sont pas impacté du fait que ces problèmes sont gérés par la machine virtuelle ou l’interpréteur. Il n'est pas effectivement nécessaire de connaître le fonctionnement intime des ordinateurs pour utiliser un SGBD. Par contre pour le développer oui, et cela confirme que les développeur de Microsoft connaissent leur sujet.

La compression par dictionnaire est bel et bien un compression qui nécessite une opération de décompression pour être lu. Même si certaines optimisations du dictionnaire à base de pointeur ou de référence permette de réduire le temps de traitement. Et c'était là tout mon propos, même si la décompression est faite en temps réelle, elle est quand même là. Je reconnais que Microsoft utilise le verbe "to retrieve" pour signaler la décompression, ce qui peut laisser un doute.

Le fait de réduire le nombre d'octet que prends l'information dans une page mémoire, en n'utilisant que les octets significatif est quand à lui bien une optimisation de la mémoire. Ce type de technique demande plus de ressource en terme de puissance de calcul puisque l'on casse les alignements et qu'il faut le signaler au processeur. Ces alignements sont des contraintes techniques des processeurs et des mémoires volatile ou non. Contrainte que l'on peux dépasser sous certaines conditions, mais qui nécessite une très bonne connaissances des architectures techniques et des noyaux. Cette problématique se retrouve aussi dans les systèmes de fichiers. Sur Windows, dans les propriétés d'un fichier, tu as la taille du fichier et la taille réelle sur le disque. Pour les gros fichiers, la différence est minime, pour les petits fichiers elle peut être importante (ratio) du fait du fonctionnement de NTFS (https://docs.microsoft.com/fr-fr/win.../ntfs-overview). Raison pour laquelle, la majorité des SGBD demandent généralement des accès en donnée brute (RAW) aux stockages non volatile. Le système exploitation n'a alors aucune idée de comment sont organisé les données dans les fichiers de la base de donnée. Ce ne sont que des suites de 0 et 1. Tout comme il n'a aucune idée de comment sont organisé les données en RAM, il sait seulement que les pages mémoire X appartiennent au programme A et les pages mémoires Y au programme B. La seule chose qui lui importe est de savoir si le programme a le droit d'accéder ou pas d'accéder à cette page mémoire et qu'il ne dépasse pas sur une page voisine. Ce type de problématique est extrêmement important dans les développements en C et C++ (très probablement en C#, mais je n'en ai pas fait) qui sont de tête les langages utilisé par Microsoft pour développer MS-SQL ainsi que leur OS.

[SQLpro]

...je peux avoir fait des contre sens.

Oui

Lorsque tu compresses (destructif ou non) tu réduis la taille des données.

Oui

Quand tu optimises, tu réduis les espaces perdu du fait du fonctionnement des mémoires (volatile ou non) donc tu augmentes le nombre de données que tu peux stocker ou tu réduis le nombre de pages mémoire demandée (consommation de RAM inférieure pour un même volume de donnée) et quand tu commences à travailler avec des bases de plusieurs téraoctets en RAM et sur les disques, ces optimisations deviennent très vite indispensable. Effectivement certains utilisent le mot compactage de mémoire en lieu et place d'optimisation. Et on peut traduire le compression anglais en compactage.

Non. L'optimisation dans un SGBDR n'a rien à voir avec la compression. En règle générale, la compression, qu'elle quelle soit fait perdre des performances. Soit au moment de stocker la données, soit au moment de l'exploiter. Elle peut aussi en faire gagner, mais très peu, par le simple fait de la réduction du volume à parcourir... Mais l'optimisation ce sont par exemple :

• l'emploi d'un index en mode recherche (seek) en lieu et place d'un balayage de toutes les lignes de la table (scan)
• le fait que l'optimiseur décide d'utiliser tel ou tel algorithme de jointure en fonction des cardinalités en jeu
• La récrite des requêtes par factorisation, simplification, modification de l'enchainement des différentes tâches en jeu dans la requête.

Tout cela étant le fait de l'optimiseur

La compression par dictionnaire est bel et bien un compression qui nécessite une opération de décompression pour être lu.

Non.
Un simple exemple. Si je cherche quel est l'age d'une personne nommé DUPONT Alain, l'information se trouve bien telle qu'elle dans la base et ne nécessite pas de décompression. Même si les données sont réparties à différents endroit, c'est une seule lecture que l'on effectue. Dans tous les cas l'information d'un ensemble de ligne, sans aucune méthode de compression, réparti à différents endroit qu'il faut recoller pour apporter l'information au dataset. Mieux encore, l'utilisation d'un index impose souvent une double lecture (index + table) qui est bien plus pénalisante que de recoller différents éléments d'une même ligne de données situé dans la même page et dans le même "slot" de ligne. Pour information, je te montre comment les lignes des tables sont structurées dans MS SQL Server


Etrait de mon livre "SQL Server 2014" - Eyrolles éditions

Tu verras que toutes les colonnes de type fixe (CHAR, DATE, INT...) sont stockés en premier et toutes les données de taille variable (VARCHAR notamment) sont stockées en dernier pour des raisons d'efficacité d'accès. Doit on parler de compression dans ce cas ? Évidemment non. Pourtant il faut bien aller chercher les colonnes que l'on souhaite voir figurer dans le dataset à différents endroits.

... Je reconnais que Microsoft utilise le verbe "to retrieve" pour signaler la décompression, ce qui peut laisser un doute.

C'est pour cela qu'il n'y a pas décompression de l'information pour la lire...

Le fait de réduire le nombre d'octet que prends l'information dans une page mémoire, en n'utilisant que les octets significatif est quand à lui bien une optimisation de la mémoire. Ce type de technique demande plus de ressource en terme de puissance de calcul puisque l'on casse les alignements et qu'il faut le signaler au processeur.

Ce que l'on ne fait jamais pour les SGBDR car sinon, certains algorithmes ne fonctionnerait plus (tris, groupage, dédoublonnement avec distinct en particulier qui nécessite un alignement pour des raisons d'efficacité !

... Raison pour laquelle, la majorité des SGBD demandent généralement des accès en donnée brute (RAW) aux stockages non volatile.

Oui.

A +