Pour les options de compression de colonne, PostgreSQL 14 fournit une nouvelle méthode de compression LZ4. Par rapport à la méthode de compression PGLZ existante dans TOAST, la compression LZ4 est plus rapide. Cet article explique comment utiliser l'intégralité de l'option et comparer ses performances avec d'autres algorithmes de compression.
fond
Dans PG, la page est l'unité de stockage des données et la valeur par défaut est 8 Ko. En général, une ligne de données n'est pas autorisée à être stockée sur plusieurs pages. Cependant, il existe certains types de données de longueur variable et les données stockées peuvent dépasser une page de l'université. Afin de surmonter toute la limitation, le grand champ sera compressé ou divisé en plusieurs lignes physiques. Cette technique est TOAST :
Par défaut, s'il y a des colonnes de longueur variable dans la table et que la taille des données de ligne dépasse TOAST_TUPLE_THRESHOLD (2 Ko par défaut), TOAST sera déclenché. Tout d'abord, les données seront compressées en premier ; s'il est encore trop volumineux après compression, le stockage débordera. Il est à noter que si la stratégie de stockage des colonnes spécifie EXTERNAL/PLAIN, la compression sera interdite.
Avant PG14, TOAST ne prend en charge qu'un seul algorithme de compression PGLZ (algorithme intégré PG). Mais d'autres algorithmes de compression peuvent être plus rapides que PGLZ ou avoir un taux de compression plus élevé. Il existe une nouvelle option de compression compression LZ4 dans PG14, qui est un algorithme de compression sans perte connu pour sa vitesse. Nous pouvons donc nous attendre à ce qu'il contribue à augmenter la vitesse de compression et de décompression de TOAST.
Comment utiliser LZ4 ?
Pour utiliser la fonction de compression LZ4, vous devez spécifier -with-lz4 lors de la compilation et suivre la bibliothèque LZ4 dans le système d'exploitation. L'algorithme de compression par défaut TOAST de l'instance PG peut être spécifié via le paramètre GUC default_toast_compression. Peut être dans postgresql. Configurez dans conf, vous pouvez également modifier uniquement la connexion actuelle via la commande SET :
postgres＝＃ SET default＿toast＿compression＝lz4；
SET
Spécifiez l'algorithme de compression de colonne lors de la création d'une table dans CREATE TABLE :
Nous pouvons utiliser la commande d+ pour voir l'algorithme de compression pour toutes les colonnes. Si la colonne ne prend pas en charge ou ne spécifie pas l'algorithme de compression, un espace sera affiché dans la colonne Compression. Dans l'exemple ci-dessus, la colonne id ne prend pas en charge l'algorithme de compression, la colonne col1 utilise PGLZ, col2 utilise LZ4 et col3 ne spécifie pas l'algorithme de compression, elle utilisera alors l'algorithme de compression par défaut.
Vous pouvez modifier l'algorithme de compression de colonne via ALTER TABLE, mais il convient de noter que l'algorithme modifié n'affecte les données d'insertion qu'une fois la commande entière exécutée.
postgres＝＃ INSÉRER DANS LES VALEURS tbl （1， répéter（＇abc＇，1000）， répéter（＇abc＇，1000），répéter（＇abc＇，1000））；
INSÉRER 0 1
postgres＝＃ ALTER TABLE tbl ALTER COLUMN col1 SET COMPRESSION lz4；
ALTER TABLE
postgres＝＃ INSÉRER DANS LES VALEURS tbl （2， répéter（＇abc＇，1000）， répéter（＇abc＇，1000），répéter（＇abc＇，1000））；
INSÉRER 0 1
postgres＝＃ SELECT ID，
postgres－＃ pg＿column＿compression（id） AS compression＿colid，
postgres－＃ pg＿column＿compression（col1） AS compression＿col1，
postgres－＃ pg＿column＿compression（col2） AS compression＿col2，
postgres－＃ pg＿column＿compression（col3）Compression AS＿col3
postgres－＃ DE tbl；
identifiant ｜ compression＿colid ｜ compression＿col1 ｜ compression＿col2 ｜ compression＿col3
??
1 ｜ ｜ pglz lz4 ｜ lz4
2 ｜ ｜ lz4 lz4 ｜ lz4
（2 rangées）
Vous pouvez voir que pour les lignes insérées avant de modifier l'algorithme de compression, col1 utilise toujours l'algorithme de compression PGLZ, même si l'algorithme de compression est modifié de PGLZ à LZ4. (Alors, quel algorithme doit être utilisé pour la décompression après modification ?)
Notez que si vous scannez les données d'une autre table et que vous les insérez dans cette table, comme CREATE TABLE. . . COMME. . . Ou INSÉRER DANS. . . SÉLECTIONNER. . . , L'algorithme de compression utilisé par les données insérées utilise toujours la méthode de compression des données d'origine. pg_dump et pg_dumpall ont également ajouté l'option-no-toast-compuression. Après avoir utilisé l'intégralité de l'option, l'option de compression TOAST ne sera pas supprimée.
Comparaison des performances
Testé le taux de compression et la vitesse de compression de LZ4 et PGLZ. Et ajouté les résultats des tests de données non compressées (la stratégie de stockage spécifiée est EXTERNE). Pour les données non compressées, il n'y a pas de compression et de décompression chronophage, mais le temps de lecture et d'écriture des données augmentera.
Données utilisées dans le test : documents PG (un fichier HTML par ligne de données) ; données fournies par SilesiaCorpus, y compris HTML, texte, code source, fichiers binaires exécutables et images
Tester l'utilisation de la machineIntel? Xéon ? Argent 4210 Processeur ＠2．20GHz avec 10 cœurs／20 threads／2 sockets。
Utilisez pgbench pour tester le temps d'exécution de l'instruction SQL, et pg_table_size pour vérifier la table universitaire (exécutez VACUUM FULL avant chaque exécution pour éliminer l'influence des enregistrements morts).
Ratio de compression
Les taux de compression de PGLZ et LZ4 dépendent tous deux de données répétées. Plus les tuples sont répétés, plus le taux de compression est élevé. Cependant, si PG évalue qu'un tel taux de compression n'est pas bon, la compression ne sera pas effectuée, même si la taille des données atteint le seuil. Étant donné que la compression n'économise pas efficacement l'espace disque, elle entraîne également une consommation de temps et de ressources supplémentaire pour les verrous de décompression.
Dans le PG14 actuel, PGLZ nécessite un taux de compression d'au moins 25 %, tandis que LZ n'est plus petit que lorsque les données ne sont pas compressées. J'ai comparé les tailles des tables LZ4, PGLZ et des tables non compressées. On peut voir que dans la plupart des scénarios, le taux de compression de PGLZ est légèrement meilleur, le taux de compression est évalué à 2.23 et le taux de compression de LZ4 est de 2.07. Cela signifie que PGLZ peut économiser 7% d'espace disque.
Figure 1 － Comparaison des tailles de table en Ko）
Vitesse de compression/décompression
Les données TOAST seront compressées et décompressées lors de l'insertion et de la requête. Par conséquent, j'ai exécuté des instructions SQL pour voir l'impact des différents algorithmes de compression.
Tout d'abord, comparez les performances de l'instruction INSERT lorsque vous utilisez LZ, PGLZ et non la compression. On peut voir que par rapport aux données non compressées, LZ4 prend un peu plus de temps et PGLZ prend plus de temps. Le temps de compression du LZ4 est inférieur de 20 % à celui du PGLZ en moyenne. Il s'agit d'une amélioration très significative.
Figure 2 － Comparaison des performances de l'INSERT
Comparez SELECT ci-dessous. Par rapport à PGLZ, LZ4 peut gagner 20% de temps, et il n'y a pas beaucoup de différence par rapport aux données non compressées. Le coût de la décompression a été réduit à un niveau très bas.
Figure 3 － Comparaison des performances de SELECT
Comparez les instructions INSERT simultanées de 16 clients. Par rapport à PGLZ, les performances de compression de fichiers volumineux uniques (HTML, texte anglais, code source, fichiers exécutables binaires, images) à l'aide de LZ4 sont 60 à 70 % plus rapides. Insérez plusieurs petits fichiers (fichiers PG), les performances ne sont pas améliorées. Par rapport aux données non compressées, il y a une énorme amélioration. On suppose que l'utilisation de la compression réduit la quantité de données écrites sur le disque.
Figure 4 － Comparaison des performances d'INSERT avec 16 clients
Avec 16 clients SELECT, LZ4 fonctionne mieux que PGLZ dans la plupart des scénarios :
Figure 5 － Comparaison des performances de SELECT avec 16 clients
Il compare également la vitesse de traitement de texte à l'aide des fonctions de chaîne SELECT et UPDATE. LZ4 est meilleur que PGLZ dans toute la scène. Par rapport aux données non compressées, les données de l'algorithme de compression LZ4 ont presque la même vitesse de traitement de fonction, et l'algorithme LZ4 affecte à peine la vitesse de fonctionnement de la chaîne.
Figure 6 － Comparaison des performances à l'aide de fonctions de chaîne
Par rapport à PGLZ, LZ4 compresse et décompresse les données TOAST plus efficacement et offre de bonnes performances. Par rapport aux données non compressées, la vitesse de requête est presque la même, et par rapport à PGLZ, l'insertion est 80 % plus rapide. Bien sûr, le taux de compression n'est pas très bon dans certains scénarios, mais si vous souhaitez augmenter la vitesse d'exécution, il est fortement recommandé d'utiliser l'algorithme LZ4.
Vous devez également faire attention, vous devez déterminer si les données du tableau sont adaptées à la compression. Si le taux de compression n'est pas bon, il essaiera toujours de compresser le nombre puis abandonnera.RAMGaspillage de ressources, et affecte considérablement la vitesse d'insertion des données.
avenir
LZ4 a considérablement amélioré les performances de compression et de décompression de TOAST. En plus de LZ4, il existe de nombreux autres algorithmes de compression tels que Zstandard. Les utilisateurs qui prennent en charge Zstandard peuvent obtenir un meilleur taux de compression que PGLZ. Le LZ4 HC a une vitesse de compression de 98.5% par rapport à la décompression LZ4, mais il peut augmenter considérablement le taux de compression. Espérons que la future version de PG puisse utiliser plus d'algorithmes de compression.
En plus de TOAST, d'autres scènes doivent également être compressées. Pour autant que je sache, la version de développement actuelle prend déjà en charge la compression LZ4 de WAL, ce qui est une fonctionnalité intéressante.