- Raw
-
Le codage brut est le codage par défaut pour les colonnes désignées comme des clés de tri et les colonnes définies comme BOOLEAN REAL DOUBLE PRECISION des types de données. Avec l’encodage brut, les données sont stockées dans un format brut, non compressé.
- AZ64
-
AZ64est un algorithme de codage par compression propriétaire conçu par Amazon pour atteindre un taux de compression élevé et améliorer le traitement des requêtes. À la base, l'AZ64algorithme compresse de petits groupes de valeurs de données et utilise une seule instruction, plusieurs instructions data (SIMD) pour le traitement en parallèle. AZ64À utiliser pour réaliser des économies de stockage importantes et des performances élevées pour les types de données numériques, de date et d'heure.
Vous pouvez l'utiliser AZ64 comme codage de compression lorsque vous définissez des colonnes à l'aide d'ALTERTABLEinstructions CREATE TABLE et contenant les types de données suivants :
SMALLINT
INTEGER
BIGINT
DECIMAL
DATE
TIMESTAMP
TIMESTAMPTZ
- Byte-dictionary
-
Avec l’encodage par dictionnaire d’octets, un dictionnaire distinct de valeurs uniques est créé pour chaque bloc de valeurs de colonne sur le disque. (Un bloc de disque Amazon Redshift occupe 1 Mo.) Le dictionnaire contient jusqu’à 256 valeurs d’un octet qui sont stockées sous forme d’index pour les valeurs de données originales. Si plus de 256 valeurs sont stockées dans un seul bloc, les valeurs supplémentaires sont écrites dans le bloc dans un format brut, non compressé. Le processus se répète pour chaque bloc de disque.
Ce codage est très efficace pour les colonnes de chaînes à faible cardinalité. Cet encodage est optimal lorsque le domaine de données d’une colonne est inférieur à 256 valeurs uniques.
Pour les colonnes dont le type de données est codé (CHARetVARCHAR) sous forme de chaîneBYTEDICT, Amazon Redshift effectue des analyses vectorisées et des évaluations de prédicats qui s'appliquent directement aux données compressées. Ces scans utilisent des instructions uniques spécifiques au matériel et des instructions multiples data (SIMD) pour le traitement en parallèle. Cela permet d’accélérer considérablement l’analyse des colonnes de chaînes de caractères. Le codage par dictionnaire d'octets est particulièrement économe en espace si une VARCHAR colonneCHAR/contient de longues chaînes de caractères.
Supposons qu'une table comporte une COUNTRY colonne avec un type de données CHAR (30). Lorsque les données sont chargées, Amazon Redshift crée le dictionnaire et remplit la COUNTRY colonne avec la valeur d'index. Le dictionnaire contient les valeurs uniques indexées, et la table elle-même contient uniquement les sous-scripts d’un octet des valeurs correspondantes.
Les espaces de fin sont stockés pour les colonnes de caractères de longueur fixe. Ainsi, dans une colonne CHAR (30), chaque valeur compressée permet d'économiser 29 octets de stockage lorsque vous utilisez le codage par dictionnaire d'octets.
Le tableau suivant représente le dictionnaire de la COUNTRY colonne.
| Valeur de données unique |
Index du dictionnaire |
Taille (longueur fixe, 30 octets par valeur) |
| England |
0 |
30 |
| United States of America |
1 |
30 |
| Venezuela |
2 |
30 |
| Sri Lanka |
3 |
30 |
| Argentina |
4 |
30 |
| Japan |
5 |
30 |
| Total |
|
180 |
Le tableau suivant représente les valeurs de la COUNTRY colonne.
| Valeur de données d’origine |
Taille d’origine (longueur fixe, 30 octets par valeur) |
Valeur compressée (index) |
Nouvelle taille (octets) |
| England |
30 |
0 |
1 |
| England |
30 |
0 |
1 |
| United States of America |
30 |
1 |
1 |
| United States of America |
30 |
1 |
1 |
| Venezuela |
30 |
2 |
1 |
| Sri Lanka |
30 |
3 |
1 |
| Argentina |
30 |
4 |
1 |
| Japan |
30 |
5 |
1 |
| Sri Lanka |
30 |
3 |
1 |
| Argentina |
30 |
4 |
1 |
| Total |
300 |
|
10 |
Dans cet exemple, la taille compressée totale est calculée comme suit : 6 entrées distinctes sont stockées dans le dictionnaire (6 * 30 = 180), et la table contient 10 valeurs compressées de 1 octet, soit un total de 190 octets.
- Delta
-
Les encodages Delta sont très utiles pour les colonnes de date et d’heure.
L’encodage Delta compresse les données en enregistrant la différence entre les valeurs qui se suivent dans la colonne. Cette différence est enregistrée dans un dictionnaire distinct pour chaque bloc de valeurs de la colonne sur le disque. (Un bloc de disque Amazon Redshift occupe 1 Mo.) Par exemple, supposons que la colonne contienne 10 entiers dans l’ordre de 1 à 10. Les premiers sont stockés sous la forme d’un entier de 4 octets (plus un indicateur de 1 octet). Les neuf suivants sont chacun stockés sous forme d’octet avec la valeur 1, ce qui indique qu’il est supérieur à la valeur précédente.
L’encodage Delta se décline en deux variations :
Si la plupart des valeurs de la colonne peuvent être comprimées en utilisant un seul octet, la variation d’un octet est très efficace. Cependant, si les deltas sont plus importants, cet encodage, dans le pire des cas, est un peu moins efficace que le stockage des données non compressées. Une logique similaire s’applique à la version de 16 bits.
Si la différence entre deux valeurs dépasse la plage de 1 octet (DELTA) ou de 2 octets (DELTA32K), la valeur d'origine complète est stockée, avec un indicateur de 1 octet en tête. La plage de 1 octet s’étend de -127 à 127, et la plage de 2 octets, de -32K à 32K.
Le tableau suivant présente le fonctionnement d’un encodage Delta pour une colonne numérique.
| Valeur de données d’origine |
Taille d’origine (octets) |
Différence (delta) |
Valeur compressée |
Taille compressée (octets) |
| 1 |
4 |
|
1 |
1 + 4 (indicateur + valeur réelle) |
| 5 |
4 |
4 |
4 |
1 |
| 50 |
4 |
45 |
45 |
1 |
| 200 |
4 |
150 |
150 |
1 + 4 (indicateur + valeur réelle) |
| 185 |
4 |
-15 |
-15 |
1 |
| 220 |
4 |
35 |
35 |
1 |
| 221 |
4 |
1 |
1 |
1 |
| Totaux |
28 |
|
|
15 |
- LZO
-
LZOle codage fournit un taux de compression très élevé avec de bonnes performances. LZOle codage fonctionne particulièrement bien pour CHAR les VARCHAR colonnes contenant de très longues chaînes de caractères. Ils sont particulièrement adaptés aux textes de forme libre, tels que les descriptions de produits, les commentaires des utilisateurs ou les JSON chaînes de caractères.
- Mostly
-
Les encodages Mostly sont utiles lorsque le type de données d’une colonne est plus volumineux que la plupart des valeurs stockées le nécessitent. En spécifiant un encodage Mostly pour ce type de colonne, vous pouvez compresser la majorité des valeurs de la colonne dans une taille de stockage standard inférieure. Les autres valeurs qui ne peuvent pas être compressées sont stockées dans leur format brut. Par exemple, vous pouvez compresser une colonne 16 bits, telle qu'une INT2 colonne, en stockage 8 bits.
En général, les encodages Mostly fonctionnent avec les types de données suivants :
-
SMALLINT/INT2(16 bits)
-
INTEGER/INT(32 bits)
-
BIGINT/INT8(64 bits)
-
DECIMAL/NUMERIC(64 bits)
Choisissez la variation appropriée de l’encodage Mostly en fonction de la taille du type de données de la colonne. Par exemple, appliquez MOSTLY8 à une colonne définie comme une colonne entière de 16 bits. L'application MOSTLY16 à une colonne avec un type de données 16 bits ou MOSTLY32 à une colonne avec un type de données 32 bits n'est pas autorisée.
Les encodages Mostly peuvent être moins efficaces qu’aucune compression du tout, si bon nombre des valeurs de la colonne ne peuvent pas être compressées. Avant d’appliquer l’un de ces encodages à une colonne, effectuez une vérification. La plupart des valeurs que vous allez charger maintenant (et que vous êtes susceptible de charger à l’avenir) devraient se situer dans les plages indiquées dans le tableau suivant.
| Encodage |
Taille de stockage compressée |
Plage de valeurs qui peuvent être compressées (les valeurs situées en dehors de la plage sont stockées dans un format brut) |
| MOSTLY8 |
1 octet (8 bits) |
-128 à 127 |
| MOSTLY16 |
2 octets (16 bits) |
-32768 à 32767 |
| MOSTLY32 |
4 octets (32 bits) |
-2147483648 à +2147483647 |
Pour les valeurs décimales, ignorez la virgule pour déterminer si la valeur correspond à la plage. Par exemple, 1 234,56 est traité comme 123 456 et peut être compressé dans une colonne. MOSTLY32
Par exemple, la VENUEID colonne de la VENUE table est définie comme une colonne d'entiers bruts, ce qui signifie que ses valeurs consomment 4 octets de stockage. Toutefois, la plage de valeurs actuelle de la colonne s’étend de 0 à 309. Par conséquent, la recréation et le rechargement de cette table avec le MOSTLY16 codage pour VENUEID réduiraient le stockage de chaque valeur de cette colonne à 2 octets.
Si les VENUEID valeurs référencées dans une autre table étaient pour la plupart comprises entre 0 et 127, il peut être judicieux de coder cette colonne de clé étrangère en tant que. MOSTLY8 Avant de faire votre choix, exécutez plusieurs requêtes sur les données de la table de référencement pour savoir si les valeurs se situent principalement dans une plage de 8, 16 ou 32 bits
Le tableau suivant indique les tailles compressées pour des valeurs numériques spécifiques lorsque les MOSTLY32 codages MOSTLY8MOSTLY16, et sont utilisés :
| Valeur d’origine |
Original INT ou BIGINT taille (octets) |
MOSTLY8taille compressée (octets) |
MOSTLY16taille compressée (octets) |
MOSTLY32taille compressée (octets) |
| 1 |
4 |
1 |
2 |
4 |
| 10 |
4 |
1 |
2 |
4 |
| 100 |
4 |
1 |
2 |
4 |
| 1 000 |
4 |
Identique à la taille des données brutes |
2 |
4 |
| 10 000 |
4 |
2 |
4 |
| 20 000 |
4 |
2 |
4 |
| 40 000 |
8 |
Identique à la taille des données brutes |
4 |
| 100 000 |
8 |
4 |
| 2 000 000 000 |
8 |
4 |
- Run length
-
L’encodage de la longueur d’exécution remplace une valeur qui est répétée de façon consécutive par un jeton composé de la valeur et d’un calcul du nombre d’occurrences consécutives (la longueur de l’exécution). Un dictionnaire distinct de valeurs uniques est créé pour chaque bloc de valeurs de la colonne sur le disque. (Un bloc de disque Amazon Redshift occupe 1 Mo.) Cet encodage est mieux adapté à une table dans laquelle les valeurs de données sont souvent répétées de façon consécutive, par exemple, lorsque la table est triée en fonction de ces valeurs.
Supposons, par exemple, qu'une colonne d'une table de grandes dimensions possède un domaine relativement petit, tel qu'une COLOR colonne contenant moins de 10 valeurs possibles. Ces valeurs sont susceptibles de tomber en longues séquences dans le tableau, même si les données ne sont pas triées.
Nous ne recommandons pas d’appliquer l’encodage de la longueur d’exécution sur une colonne désignée comme clé de tri. Les analyses restreintes à la plage sont plus performantes lorsque les blocs contiennent un nombre de lignes similaire. Si les colonnes de clés sont beaucoup plus compressées que les autres colonnes de la même requête, des analyses à plage restreintes peuvent avoir de mauvaises performances.
Le tableau suivant utilise l'exemple de COLOR colonne pour montrer le fonctionnement du codage de la longueur de série.
| Valeur de données d’origine |
Taille d’origine (octets) |
Valeur compressée (jeton) |
Taille compressée (octets) |
| Blue |
4 |
{2,bleu} |
5 |
| Blue |
4 |
0 |
| Green |
5 |
{3,vert} |
6 |
| Green |
5 |
0 |
| Green |
5 |
0 |
| Blue |
4 |
{1,Blue} |
5 |
| Yellow |
6 |
{4,Yellow} |
7 |
| Yellow |
6 |
0 |
| Yellow |
6 |
0 |
| Yellow |
6 |
0 |
| Total |
51 |
|
23 |
- Text255 and Text32k
-
Les codages Text255 et Text32k sont utiles pour compresser les VARCHAR colonnes dans lesquelles les mêmes mots se reproduisent souvent. Un dictionnaire distinct de mots uniques est créé pour chaque bloc de valeurs de la colonne sur le disque. (Un bloc de disque Amazon Redshift occupe 1 Mo.) Le dictionnaire contient les 245 premiers mots uniques de la colonne. Ces termes sont remplacés sur le disque par une valeur d’index d’un octet représentant l’une des 245 valeurs, et tous les mots qui ne sont pas représentées dans le dictionnaire sont stockés sous une forme décompressée. Le processus se répète pour chaque bloc de disque de 1 Mo. Si les mots indexés apparaissent fréquemment dans la colonne, celle-ci présente un taux de compression élevé.
Pour l’encodage text32k, le principe est le même, mais le dictionnaire de chaque bloc ne capture pas un nombre de mots spécifique. A la place, le dictionnaire indexe chaque mot unique qu’il trouve jusqu’à ce que les entrées combinées atteignent une longueur de 32K, moins le dépassement. Les valeurs d’index sont stockées dans deux octets.
Par exemple, considérez la VENUENAME colonne du VENUE tableau. Les mots comme Arena, Center et Theatre sont récurrents dans cette colonne et sont susceptibles de figurer parmi les 245 premiers mots rencontrés dans chaque bloc si la compression text255 est appliquée. Si c’est le cas, cette colonne bénéficie d’une compression. En effet, chaque fois que ces mots apparaissent, ils n’occupent qu’un seul octet de stockage (au lieu de 5, 6 ou 7 octets, respectivement).
- ZSTD
-
Le codage Zstandard (ZSTD) fournit un taux de compression élevé avec de très bonnes performances sur divers ensembles de données. ZSTDfonctionne particulièrement bien avec CHAR les VARCHAR colonnes qui stockent un large éventail de chaînes longues et courtes, telles que les descriptions de produits, les commentaires des utilisateurs, les journaux et les JSON chaînes. Lorsque certains algorithmes, tels que le codage Delta ou le codage principal, peuvent potentiellement utiliser plus d'espace de stockage que l'absence de compression, il ZSTD est peu probable qu'ils augmentent l'utilisation du disque.
ZSTDprend en charge SMALLINTINTEGER,BIGINT,DECIMAL,REAL,, DOUBLEPRECISION,BOOLEAN,CHAR,VARCHAR,, DATETIMESTAMP, et les types de TIMESTAMPTZ données.
