Test des encodages de compression

Si vous souhaitez spécifier manuellement les encodages de colonnes, vous pouvez tester différents encodages avec vos données.

Note

Nous recommandons d’utiliser la commande COPY pour charger les données autant que possible et de permettre à la commande COPY de choisir les encodages optimaux en fonction de vos données. Vous pouvez également utiliser la commande ANALYZE COMPRESSION pour afficher les encodages suggérés pour les données existantes. Pour plus de détails sur la mise en œuvre de la compression automatique, consultez Chargement des tables avec compression automatique.

Pour effectuer un test pertinent de compression des données, vous devez disposer d’un grand nombre de lignes. Dans cet exemple, nous créons une table et insérons des lignes en utilisant une instruction qui effectue une sélection à partir de deux tables : VENUE et LISTING. Nous laissons de côté la clause WHERE qui devrait normalement joindre les deux tables. Le résultat est que chaque ligne de la table VENUE est jointe à toutes les lignes de la table LISTING, soit un total de plus de 32 millions de lignes. Cette méthode est connue sous le nom de jointure cartésienne et n’est normalement pas recommandée. Toutefois, dans le cas présent, il s’agit d’une méthode pratique pour créer de nombreuses lignes. Si vous disposez d’une table existante contenant des données que vous souhaitez tester, vous pouvez ignorer cette étape.

Après avoir obtenu une table avec des données types, nous créons une table avec sept colonnes. Chacune a un encodage de compression différent : raw, bytedict, lzo, run length, text255, text32k et zstd. Nous remplissons chaque colonne avec exactement les mêmes données en exécutant une commande INSERT qui sélectionne les données de la première table.

Pour tester les encodages de compression, procédez comme suit :

1. (Facultatif) Tout d’abord, utilisez une jointure cartésienne pour créer une table avec un grand nombre de lignes. Ignorez cette étape si vous voulez tester une table existante.

   create table cartesian_venue(
   venueid smallint not null distkey sortkey,
   venuename varchar(100),
   venuecity varchar(30),
   venuestate char(2),
   venueseats integer);
   
   insert into cartesian_venue
   select venueid, venuename, venuecity, venuestate, venueseats
   from venue, listing;

2. Ensuite, nous créons une table avec les encodages que vous voulez comparer.

   create table encodingvenue (
   venueraw varchar(100) encode raw,
   venuebytedict varchar(100) encode bytedict,
   venuelzo varchar(100) encode lzo,
   venuerunlength varchar(100) encode runlength,
   venuetext255 varchar(100) encode text255,
   venuetext32k varchar(100) encode text32k,
   venuezstd varchar(100) encode zstd);

3. Insérez les mêmes données dans toutes les colonnes à l’aide d’une instruction INSERT avec une clause SELECT.

   insert into encodingvenue
   select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as  venuetext32k, venuename as  venuetext255, venuename as venuezstd
   from cartesian_venue;

4. Vérifiez le nombre de lignes de la nouvelle table.

   select count(*) from encodingvenue
   
     count
   ----------
    38884394
   (1 row)

5. Interrogez la table système STV_BLOCKLIST pour comparer le nombre de blocs de disque de 1 Mo utilisés par chaque colonne.

   La fonction d’agrégation MAX renvoie le plus grand nombre de blocs pour chaque colonne. La table STV_BLOCKLIST inclut les détails de trois colonnes générées par le système. Cet exemple utilise col < 6 dans la clause WHERE pour exclure les colonnes générées par le système.

   select col, max(blocknum)
   from stv_blocklist b, stv_tbl_perm p
   where (b.tbl=p.id) and name ='encodingvenue'
   and col < 7
   group by name, col
   order by col;

   La requête renvoie les résultats suivants. Les colonnes sont numérotés en commençant par zéro. En fonction de la configuration de votre cluster, votre résultat peut comporter des nombres différents, mais les tailles relatives doivent être similaires. Vous pouvez voir que l’encodage BYTEDICT sur la deuxième colonne a produit les meilleurs résultats pour cet ensemble de données. Cette approche a un taux de compression supérieur à 20:1. Les encodages LZO et ZSTD produisent également d’excellents résultats. Des jeux de données différents produisent des résultats différents, bien sûr. LZO produit souvent les meilleurs résultats de compression, lorsqu’une colonne contient des chaînes de texte plus longues.

    col | max
   -----+-----
      0 | 203
      1 |  10
      2 |  22
      3 | 204
      4 |  56
      5 |  72
      6 |  20
   (7 rows)

Si vous disposez de données dans une table existante, vous pouvez utiliser la commande ANALYZE COMPRESSION pour afficher l’encodage suggéré pour la table. Par exemple, l’exemple suivant illustre l’encodage recommandé pour une copie de la table VENUE, CARTESIAN_VENUE, qui contient 38 millions de lignes. Notez que la commande ANALYZE COMPRESSION recommande l’encodage LZO pour la colonne VENUENAME. ANALYZE COMPRESSION choisit la compression optimale en fonction de plusieurs facteurs, notamment la réduction du pourcentage. Dans ce cas spécifique, BYTEDICT offre une meilleure compression, mais LZO produit également une compression supérieure à 90 %.

analyze compression cartesian_venue;

Table          | Column     | Encoding | Est_reduction_pct
---------------+------------+----------+------------------
reallybigvenue | venueid    | lzo      | 97.54            
reallybigvenue | venuename  | lzo      | 91.71            
reallybigvenue | venuecity  | lzo      | 96.01            
reallybigvenue | venuestate | lzo      | 97.68            
reallybigvenue | venueseats | lzo      | 98.21