Test des encodages de compression - Amazon Redshift
Exemple

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 vous recommandons d'utiliser la COPY commande pour charger des données dans la mesure du possible et de permettre à la COPY commande de choisir les codages 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 un tableau et insérons des lignes à l'aide d'une instruction qui sélectionne l'un des deux tableaux ; VENUE etLISTING. Nous omettons la WHERE clause qui relierait normalement les deux tables. Le résultat est que chaque ligne du VENUE tableau est jointe à toutes les lignes du LISTING tableau, pour 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 INSERT commande 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 INSERT instruction comportant une SELECT clause. 

    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 MAX d'agrégation renvoie le numéro de bloc le plus élevé pour chaque colonne. La BLOCKLIST table STV _ inclut les détails de trois colonnes générées par le système. Cet exemple utilise la WHERE clause col < 6 in 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 constater que le BYTEDICT codage 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. LZOet le ZSTD codage a également produit d'excellents résultats. Des jeux de données différents produisent des résultats différents, bien sûr. Lorsqu'une colonne contient des chaînes de texte plus longues, LZO cela produit souvent les meilleurs résultats de compression.

     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 montre le codage recommandé pour une copie de la VENUE table, CARTESIAN _VENUE, qui contient 38 millions de lignes. Notez qu'il est ANALYZE COMPRESSION recommandé d'LZOencoder la VENUENAME colonne. ANALYZECOMPRESSIONchoisit une compression optimale en fonction de plusieurs facteurs, dont le pourcentage de réduction. Dans ce cas précis, BYTEDICT fournit une meilleure compression, mais produit LZO é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

Exemple

L'exemple suivant crée une CUSTOMER table comportant des colonnes contenant différents types de données. Cette CREATE TABLE instruction montre l'une des nombreuses combinaisons possibles d'encodages de compression pour ces colonnes. 

create table customer(
custkey int encode delta,
custname varchar(30) encode raw,
gender varchar(7) encode text255,
address varchar(200) encode text255,
city varchar(30) encode text255,
state char(2) encode raw,
zipcode char(5) encode bytedict,
start_date date encode delta32k);

Le tableau suivant indique les codages des colonnes qui ont été choisis pour le CUSTOMER tableau et explique les choix :

Colonne Type de données Encodage Explication
CUSTKEY int delta CUSTKEYse compose de valeurs entières consécutives uniques. Parce que les différences sont d'un octet, DELTA c'est un bon choix.
CUSTNAME varchar(30) raw CUSTNAMEpossède un domaine étendu avec peu de valeurs répétées. N’importe quel encodage de compression serait probablement inefficace.
GENDER varchar(7) text255 GENDERest un très petit domaine avec de nombreuses valeurs répétées. Text255 fonctionne bien avec les VARCHAR colonnes dans lesquelles les mêmes mots sont récurrents.
ADDRESS varchar(200) text255 ADDRESSest un vaste domaine, mais contient de nombreux mots répétés, tels que Street, Avenue, North, South, etc. Le texte 255 et le texte 32k sont utiles pour compresser les VARCHAR colonnes dans lesquelles les mêmes mots sont récurrents. La longueur de la colonne est courte, text255 est donc un bon choix.
CITY varchar(30) text255 CITYest un domaine de grande taille, avec quelques valeurs répétées. Certains noms de villes sont utilisés beaucoup plus fréquemment que d’autres. Text255 est un bon choix pour les mêmes raisons queADDRESS.
STATE char(2) raw Aux États-Unis, STATE il s'agit d'un domaine précis de 50 valeurs à deux caractères. L’encodage Bytedict entraînerait une compression, mais du fait que la taille de la colonne n’est que deux caractères, la compression ne vaut peut-être pas la surcharge que représente la décompression des données.
ZIPCODE char(5) bytedict ZIPCODEest un domaine connu contenant moins de 50 000 valeurs uniques. Certains codes postaux se répètent beaucoup plus souvent que d’autres. L’encodage bytedict est très efficace lorsqu’une colonne contient un nombre limité de valeurs uniques.
START_DATE date delta32k Les encodages delta sont très utiles pour les colonnes de date et d’heure, surtout si les lignes sont chargées dans l’ordre des dates.