Skip to main content
Par défaut, ClickHouse utilise la compression lz4 dans la version autogérée et zstd dans ClickHouse Cloud. Pour les tables utilisant un moteur de la famille MergeTree, vous pouvez modifier la méthode de compression par défaut dans la section compression d’une configuration de serveur. Vous pouvez également définir la méthode de compression pour chaque colonne dans la requête CREATE TABLE.
Le codec Default peut être spécifié pour utiliser la compression par défaut, qui peut dépendre de différents paramètres (et des propriétés des données) au moment de l’exécution. Exemple : value UInt64 CODEC(Default) — équivaut à l’absence de spécification de codec. Voir aussi Sélection adaptative de codec. Vous pouvez également supprimer le CODEC actuel de la colonne et utiliser la compression par défaut définie dans config.xml :
Les codecs peuvent être combinés dans un pipeline de codecs, par exemple CODEC(Delta, Default).
Vous ne pouvez pas décompresser les fichiers de base de données ClickHouse à l’aide d’utilitaires externes tels que lz4. Utilisez plutôt l’utilitaire dédié clickhouse-compressor.
La compression est prise en charge par les moteurs de table suivants :
  • Famille MergeTree. Prend en charge les codecs de compression de colonnes et la sélection de la méthode de compression par défaut via les paramètres de compression.
  • Famille Log. Utilise par défaut la méthode de compression lz4 et prend en charge les codecs de compression de colonnes.
  • Set. Seule la compression par défaut est prise en charge.
  • Join. Seule la compression par défaut est prise en charge.
ClickHouse prend en charge les codecs à usage général et les codecs spécialisés.

Codecs à usage général

NONE

NONE — Aucune compression.

LZ4

LZ4Algorithme de compression de données sans perte utilisé par défaut. Utilise la compression rapide LZ4.

LZ4HC

LZ4HC[(level)] — algorithme LZ4 HC (haute compression) avec un niveau configurable. Niveau par défaut : 9. Si level <= 0, le niveau par défaut est appliqué. Niveaux possibles : [1, 12]. Plage de niveaux recommandée : [4, 9].

ZSTD

ZSTD[(level)]algorithme de compression ZSTD avec un level configurable. Niveaux possibles : [1, 22]. Niveau par défaut : 1. Les niveaux de compression élevés sont utiles dans les scénarios asymétriques, par exemple lorsqu’on compresse une fois et qu’on décompresse plusieurs fois. Des niveaux plus élevés offrent une meilleure compression, mais entraînent une utilisation plus importante du CPU.

ZXC

ZXC[(level)] — algorithme de compression zxc asymétrique avec un level configurable. Niveaux possibles : [1, 7]. Niveau par défaut : 3. ZXC sacrifie la vitesse de compression au profit d’une décompression très rapide, avec un taux de compression compris entre LZ4 et ZSTD. Il est bien adapté au modèle « compresser une fois, décompresser plusieurs fois » et offre les décompressions les plus rapides sur les cœurs ARM modernes. Des niveaux plus élevés améliorent la compression, mais la rendent plus lente, tandis que la décompression reste rapide.
Ce codec est expérimental et nécessite SET allow_experimental_codecs = 1 pour être utilisé.

Obsolète : ZSTD_QAT

Obsolète : DEFLATE_QPL

Codecs spécialisés

Ces codecs sont conçus pour améliorer l’efficacité de la compression en exploitant des caractéristiques spécifiques des données. Certains ne compressent pas directement les données, mais les prétraitent afin qu’une seconde étape de compression utilisant un codec générique permette d’atteindre un taux de compression plus élevé.

Delta

Delta(delta_bytes) — Méthode de compression dans laquelle les valeurs brutes sont remplacées par la différence entre deux valeurs consécutives, à l’exception de la première, qui reste inchangée. delta_bytes correspond à la taille maximale des valeurs brutes ; sa valeur par défaut est sizeof(type). Indiquer delta_bytes comme argument est obsolète et sa prise en charge sera supprimée dans une prochaine version. Delta est un codec de préparation des données ; il ne peut donc pas être utilisé seul.

DoubleDelta

DoubleDelta(bytes_size) — Calcule le delta des deltas et l’écrit sous forme binaire compacte. bytes_size a une signification similaire à delta_bytes dans le codec Delta. Indiquer bytes_size comme argument est obsolète et sa prise en charge sera supprimée dans une version ultérieure. Les meilleurs taux de compression sont obtenus pour les séquences monotones à pas constant, telles que les données de séries temporelles. Peut être utilisé avec tout type numérique. Implémente l’algorithme utilisé dans Gorilla TSDB, en l’étendant à la prise en charge des types 64 bits. Utilise 1 bit supplémentaire pour les deltas 32 bits : des préfixes de 5 bits au lieu de 4 bits. Pour plus d’informations, consultez l’article « Compressing Time Stamps » dans Gorilla: A Fast, Scalable, In-Memory Time Series Database. DoubleDelta est un codec de préparation des données, c’est-à-dire qu’il ne peut pas être utilisé seul.

GCD

GCD() - - Calcule le plus grand commun diviseur (GCD) des valeurs de la colonne, puis divise chaque valeur par le GCD. Peut être utilisé avec des colonnes d’entiers, de nombres décimaux et de date/heure. Ce codec est bien adapté aux colonnes dont les valeurs varient (augmentent ou diminuent) par multiples du GCD, par exemple 24, 28, 16, 24, 8, 24 (GCD = 4). GCD est un codec de préparation des données, c’est-à-dire qu’il ne peut pas être utilisé seul.

Gorilla

Gorilla(bytes_size) — Calcule le XOR entre la valeur à virgule flottante courante et la précédente, puis l’écrit sous une forme binaire compacte. Plus la différence entre les valeurs consécutives est faible, c’est-à-dire plus les valeurs de la série évoluent lentement, meilleur est le taux de compression. Implémente l’algorithme utilisé dans Gorilla TSDB et l’étend pour prendre en charge les types sur 64 bits. Les valeurs possibles de bytes_size sont 1, 2, 4 et 8 ; la valeur par défaut est sizeof(type) si elle est égale à 1, 2, 4 ou 8. Dans tous les autres cas, elle est de 1. Pour plus d’informations, consultez la section 4.1 de Gorilla: A Fast, Scalable, In-Memory Time Series Database.

ALP

ALP(variant) — Compression adaptative sans perte pour les données à virgule flottante. Prend en charge Float32 et Float64. Pour plus de détails, consultez ALP: Adaptive lossless floating-point compression. Le codec accepte un argument de variante facultatif :
  • ALP() ou ALP(AUTO) (par défaut) — Utilise STD et se rabat sur RD en fonction de la taille compressée estimée.
  • ALP(STD) — Variante ALP standard. Représente chaque valeur sous la forme d’un entier exact mis à l’échelle à l’aide de puissances de dix, puis compresse les entiers obtenus avec Frame-of-Reference et un empaquetage de bits. Les valeurs non représentables sont stockées sous forme d’exceptions brutes. Fonctionne mieux avec des nombres issus de valeurs décimales (par exemple, des mesures ou des prix).
  • ALP(RD) — Variante Real Doubles. Réinterprète la représentation binaire de chaque valeur et la divise en une partie haute (signe + exposant + bits de poids fort de la mantisse) et une partie basse. Les parties hautes sont encodées par dictionnaire (jusqu’à 8 entrées) et les parties basses sont empaquetées en bits. Fonctionne mieux lorsque de nombreuses valeurs partagent les mêmes bits de poids fort.
Ce codec est expérimental et nécessite SET allow_experimental_codecs = 1 pour être utilisé.

FPC

FPC(level, float_size) - Prédit de manière répétée la valeur à virgule flottante suivante de la séquence à l’aide du meilleur de deux prédicteurs, puis applique l’opération XOR entre la valeur réelle et la valeur prédite, avant de compresser le résultat en supprimant les zéros de tête. À l’instar de Gorilla, ce codec est efficace pour stocker une série de valeurs à virgule flottante qui évoluent lentement. Pour les valeurs de 64 bits (double), FPC est plus rapide que Gorilla ; pour les valeurs de 32 bits, les performances peuvent varier. Valeurs possibles de level : 1-28 ; la valeur par défaut est 12. Valeurs possibles de float_size : 4, 8 ; la valeur par défaut est sizeof(type) si le type est Float. Dans tous les autres cas, elle est de 4. Pour une description détaillée de l’algorithme, consultez High Throughput Compression of Double-Precision Floating-Point Data.

SZ3

SZ3 ou SZ3(algorithm, error_bound_mode, error_bound) - Un codec avec perte, mais à erreur bornée (compresseur avec perte SZ3), destiné aux colonnes de type Float32, Float64, Array(Float32) ou Array(Float64). Pour les colonnes de tableaux, la compression est plus efficace lorsque tous les tableaux ont la même longueur (ils sont alors compressés sous forme de vecteurs à largeur fixe) ; les tableaux de longueurs différentes sont également pris en charge et compressés comme une séquence de valeurs à plat. Le codec ne s’applique pas aux colonnes Map, car leurs clés seraient corrompues par la compression avec perte. Les valeurs prises en charge pour « algorithm » sont ALGO_LORENZO_REG, ALGO_INTERP_LORENZO et ALGO_INTERP. Les valeurs prises en charge pour « error_bound_mode » sont ABS, REL, PSNR et ABS_AND_REL. L’argument « error_bound » est l’erreur maximale et est de type Float64.
Ce codec est expérimental et nécessite SET allow_experimental_codecs = 1 pour être utilisé.

T64

T64 — Approche de compression qui élimine les bits de poids fort inutilisés des valeurs de types de données entiers (y compris Enum, Date et DateTime). À chaque étape de son algorithme, le codec prend un bloc de 64 valeurs, les place dans une matrice de bits 64x64, la transpose, élimine les bits inutilisés des valeurs et renvoie le reste sous forme de séquence. Les bits inutilisés sont ceux qui ne diffèrent pas entre les valeurs minimale et maximale de l’ensemble de la partie de données sur laquelle la compression est appliquée. Les codecs DoubleDelta et Gorilla sont utilisés dans Gorilla TSDB comme composants de son algorithme de compression. L’approche Gorilla est efficace lorsqu’une séquence de valeurs et leurs horodatages évoluent lentement. Les horodatages sont efficacement compressés par le codec DoubleDelta, tandis que les valeurs le sont par le codec Gorilla. Par exemple, pour stocker efficacement une table, vous pouvez la créer avec la configuration suivante :

Quantized

Quantized(method, dimensions[, ...]) — Codec spécialisé prenant en charge la recherche vectorielle approximative sur des colonnes de type Array(Float32), Array(Float64) ou Array(BFloat16). Il stocke les vecteurs d’origine en précision complète, ainsi qu’un code quantifié compact pour chaque vecteur. Sur les tables de la famille MergeTree, les requêtes de recherche vectorielle utilisant le paramètre vector_search_use_quantized_codes parcourent les codes quantifiés afin d’établir une liste restreinte, puis réévaluent les résultats par rapport aux vecteurs en précision complète. Cette recherche en deux étapes lit moins d’octets qu’un parcours ordinaire en précision complète, au prix d’un rappel moindre. dimensions correspond à la longueur du vecteur ; les valeurs method prises en charge sont rabitq, turboquant, int8, prefix et product, chacune offrant un compromis différent entre taille, précision et fonction de distance. Le codec peut uniquement être défini dans CREATE TABLE ; il ne peut pas être ajouté, supprimé ni modifié via ALTER TABLE, y compris avec ADD COLUMN ... CODEC(Quantized(...)). Il ne peut pas être chaîné avec un autre codec, pas même un codec de chiffrement tel que AES_128_GCM_SIV. Pour plus de détails, consultez Recherche vectorielle avec des codecs quantifiés.

Codecs de chiffrement

Ces codecs ne compressent pas réellement les données, mais les chiffrent sur le disque. Ils ne sont disponibles que lorsqu’une clé de chiffrement est définie dans les paramètres encryption. Notez que le chiffrement n’a de sens qu’à la fin des pipelines de codecs, car les données chiffrées ne peuvent généralement pas être compressées de manière pertinente. Codecs de chiffrement :

AES_128_GCM_SIV

CODEC('AES-128-GCM-SIV') — Chiffre les données avec AES-128 en mode GCM-SIV, conformément à la RFC 8452.

AES-256-GCM-SIV

CODEC('AES-256-GCM-SIV') — Chiffre les données avec AES-256 en mode GCM-SIV. Ces codecs utilisent un nonce fixe, ce qui rend le chiffrement déterministe. Ils sont donc compatibles avec les moteurs prenant en charge la déduplication, tels que ReplicatedMergeTree, mais présentent une faiblesse : lorsqu’un même bloc de données est chiffré deux fois, le texte chiffré obtenu est exactement identique. Un adversaire capable de lire le disque peut donc constater cette équivalence (sans toutefois en connaître le contenu).
La plupart des moteurs, y compris ceux de la famille “*MergeTree”, créent des fichiers d’index sur le disque sans appliquer de codecs. Du texte en clair apparaît donc sur le disque si une colonne chiffrée est indexée.
Si vous exécutez une requête SELECT mentionnant une valeur spécifique dans une colonne chiffrée (par exemple dans sa clause WHERE), cette valeur peut apparaître dans system.query_log. Vous pouvez envisager de désactiver la journalisation.
Exemple
Si la compression est requise, elle doit être spécifiée explicitement. Sinon, seules les données seront chiffrées.
Exemple

Sélection adaptative des codecs

Les codecs spécialisés ci-dessus peuvent considérablement réduire la taille des données, mais leur sélection exige une expertise, et aucun choix unique ne convient à une colonne dont les données évoluent au fil du temps. Lorsque le paramètre MergeTree allow_experimental_adaptive_codec_selection est activé, ClickHouse effectue ce choix pour vous. Pour les colonnes qui utilisent le codec par défaut (CODEC(Default) ou aucune clause CODEC), chaque bloc est écrit avec le codec qui offre la compression la plus efficace, choisi parmi le codec par défaut de la table, NONE et les codecs spécialisés adaptés au type de la colonne. Un bloc n’est jamais plus volumineux qu’il ne le serait avec le codec par défaut, et les données incompressibles sont stockées brutes (les compresser produirait un fichier légèrement plus volumineux et plus lent à lire). Ce travail s’effectue en arrière-plan, lors des merges et des mutations, où les données sont de toute façon recompressées. La vitesse d’insertion n’est pas affectée. Les requêtes sont souvent plus rapides : moins de données sont lues sur le disque, chaque bloc lu par une requête doit d’abord être décompressé, et les codecs spécialisés se décompressent plus rapidement que le codec par défaut LZ4. Chaque bloc enregistre le codec avec lequel il a été écrit, de sorte qu’aucun paramètre n’est nécessaire pour la lecture, et cette fonctionnalité peut être désactivée à tout moment sans compromettre la lisibilité des données.
Vous pouvez observer ce comportement avec la fonction de table mergeTreeCodecBlockCounts. Ici, time augmente régulièrement ; T64, qui ne stocke que les bits variant au sein d’un bloc, surpasse donc le codec par défaut dans chaque bloc. user_id contient des hashes qu’aucun codec ne peut compresser, ses blocs ont donc été stockés bruts :
La sélection s’applique actuellement aux colonnes de type entier : entiers, énumérations, dates et heures, Decimal32/Decimal64 et IPv4.
Dernière modification le 14 août 2026