Skip to main content

Que sont les parts de table dans ClickHouse ?


Les données de chaque table de la famille de moteurs MergeTree de ClickHouse sont organisées sur disque sous forme d’une collection de data parts immuables. Pour l’illustrer, nous utilisons cette table (adaptée du jeu de données sur les prix de l’immobilier au Royaume-Uni) qui recense la date, la ville, la rue et le prix des biens vendus au Royaume-Uni :
Vous pouvez interroger cette table dans notre ClickHouse SQL Playground. Une data part est créée chaque fois qu’un ensemble de lignes est inséré dans la table. Le schéma suivant l’illustre :
Lorsqu’un serveur ClickHouse traite l’exemple d’insertion avec 4 lignes (par ex. via une instruction INSERT INTO) illustré dans le schéma ci-dessus, il effectue plusieurs étapes : Tri : Les lignes sont triées selon la clé de tri de la table (town, street), et un index primaire sparse est généré pour les lignes triées. Découpage : Les données triées sont réparties en colonnes. Compression : Chaque colonne est compressée. Écriture sur disque : Les colonnes compressées sont enregistrées sous forme de fichiers binaires de colonnes dans un nouveau répertoire représentant la data part de l’insertion. L’index primaire sparse est également compressé et stocké dans le même répertoire. Selon le moteur spécifique de la table, des transformations supplémentaires peuvent avoir lieu en parallèle du tri. Les data parts sont autonomes et incluent toutes les métadonnées nécessaires pour interpréter leur contenu sans nécessiter de catalogue central. Au-delà de l’index primaire sparse, les parts contiennent des métadonnées supplémentaires, telles que des index secondaires de saut de données, des statistiques de colonnes, des checksums, des index min-max (si le partitionnement est utilisé), et plus encore.

Fusions de parts

Pour gérer le nombre de parts par table, une tâche de fusion en arrière-plan combine périodiquement les petites parts en parts plus volumineuses jusqu’à atteindre une taille compressée configurable (généralement ~150 Go). Les parts fusionnées sont marquées comme inactives puis supprimées après un intervalle de temps configurable. Au fil du temps, ce processus crée une structure hiérarchique de parts fusionnées, d’où le nom de table MergeTree :
Pour réduire au minimum le nombre de parts initiales et le surcoût des fusions, les clients de base de données sont encouragés soit à insérer des tuples en bloc, par exemple 20 000 lignes à la fois, soit à utiliser le mode d’insert asynchrone, dans lequel ClickHouse met en tampon les lignes de plusieurs INSERT vers la même table et ne crée une nouvelle part qu’une fois que la taille du tampon dépasse un seuil configurable ou qu’un timeout expire.

Surveillance des parts de table

Vous pouvez interroger la liste de toutes les parts actives existantes de notre table d’exemple à l’aide de la colonne virtuelle _part:
La requête ci-dessus récupère les noms des répertoires sur le disque, chaque répertoire représentant une data part active de la table. Les éléments qui composent ces noms de répertoire ont une signification précise, documentée ici pour ceux qui souhaitent approfondir. Sinon, ClickHouse conserve des informations sur toutes les parts de toutes les tables dans la table système system.parts, et la requête suivante renvoie, pour notre table d’exemple ci-dessus, la liste de toutes les parts actuellement actives, leur niveau de fusion et le nombre de lignes stockées dans ces parts :
Le niveau de fusion augmente d’une unité à chaque fusion supplémentaire de la part. Un niveau de 0 indique qu’il s’agit d’une nouvelle part qui n’a pas encore été fusionnée.
Dernière modification le 3 juillet 2026