ClickHouse partition key selection - ApsaraDB for ClickHouse

Découvrez comment sélectionner les clés de partition des tables dans ApsaraDB for ClickHouse afin d'optimiser les performances et d'améliorer l'efficacité de la gestion des données.

Clés de partition

La fonctionnalité de partition organise les données en segments logiques basés sur des clés spécifiées, en divisant les données en fragments distincts (parts) selon la clé de partition.

Dans ApsaraDB for ClickHouse Enterprise Edition, lorsque vous insérez plusieurs lignes dans une table sans clé de partition, toutes les données sont écrites dans une seule nouvelle part de données. Lorsqu'une table utilise une clé de partition, le système effectue les opérations suivantes :

Vérifiez les valeurs de la clé de partition des lignes que vous insérez.
Créez une part de données dans le stockage pour chaque valeur unique de clé de partition.
Assignez les lignes aux parts de données correspondantes en fonction des valeurs de la clé de partition.

Table sans clé de partition

Table avec clé de partition

Principes fondamentaux

Pour réduire les requêtes d'écriture vers les buckets Object Storage Service qui stockent les données pour ApsaraDB for ClickHouse Enterprise Edition, choisissez des clés de partition à faible cardinalité (peu de valeurs distinctes) et des champs faciles à gérer, tels que le temps. Les clés primaires doivent couvrir les champs fréquemment filtrés dans un ordre logique. Évitez les champs à forte cardinalité, le partitionnement excessivement fin et les clés primaires non pertinentes pour tirer pleinement parti des performances de ClickHouse.

Le partitionnement est un outil de gestion des données

Utilisez le partitionnement pour l'expiration des données, le stockage par niveaux et la suppression par lot plutôt que comme outil d'optimisation des requêtes. Pour plus d'informations, consultez la page Choosing a Partitioning Key.
Choisissez un champ à faible cardinalité comme clé de partition

Maintenez le nombre de partitions entre 100 et 1 000. Évitez d'utiliser des champs à forte cardinalité (champs comportant de nombreuses valeurs distinctes, tels que user_id ou les numéros d'appareil) comme clés de partition. Dans le cas contraire, le nombre de parts risque d'augmenter de manière exponentielle, ce qui dégraderait les performances ou provoquerait des erreurs « too many parts ».
La méthode de partitionnement courante est basée sur le temps

Effectuez un partitionnement par mois ou par jour à l'aide de fonctions telles que toYYYYMM(date), toStartOfMonth(date) ou toDate(date). Cela simplifie la gestion du cycle de vie des données et le stockage par niveaux chaud/froid. Pour plus d'informations, consultez la page Custom Partitioning Key.
Les clés de partition doivent être étroitement alignées sur le cycle de vie des données, l'archivage, le nettoyage et d'autres exigences de gestion

Choisissez des dimensions qui prennent en charge la gestion par lot d'un point de vue métier. Pour plus d'informations, consultez la page Applications of partitioning.

Recommandations pour la conception des tables

Privilégiez le partitionnement basé sur le temps

Pour les scénarios de journalisation, de séries temporelles et de surveillance, effectuez un partitionnement par mois ou par jour. Par exemple, une table de journaux partitionnée par mois, où les données de chaque mois se trouvent dans une partition distincte, offre les avantages suivants :

Gestion efficace des données : supprimez, archivez ou déplacez les données par lot par partition. Par exemple, au lieu d'utiliser ALTER TABLE DELETE pour supprimer les données expirées, utilisez DROP PARTITION pour supprimer une partition entière sans analyser toute la table.
Mise en œuvre facile de la gestion du cycle de vie des données (TTL) : combinez les partitions avec des politiques TTL pour nettoyer automatiquement les données expirées, ce qui simplifie les opérations et la maintenance.
L'élimination des partitions améliore l'efficacité des requêtes : lorsque vous filtrez par temps, ClickHouse n'analyse que les partitions pertinentes, réduisant ainsi les E/S et accélérant les requêtes.

Évitez les champs à forte cardinalité pour le partitionnement

Évitez d'utiliser les ID utilisateur, les numéros de commande ou les numéros d'appareil comme clés de partition. Par exemple, si une table utilise user_id comme clé de partition, chaque utilisateur unique génère une partition distincte, ce qui entraîne les inconvénients suivants :

Explosion des partitions : chaque ID utilisateur unique génère une partition, dépassant largement la plage recommandée de 100 à 1 000, ce qui exerce une forte pression sur la gestion des métadonnées et le système de fichiers.
Échec de la fusion en arrière-plan : ClickHouse fusionne les parts uniquement au sein de la même partition. Un trop grand nombre de partitions empêche une fusion efficace, laissant de nombreuses petites parts qui dégradent les performances des requêtes et des écritures.
Dégradation des performances des requêtes : l'analyse d'une grande quantité de métadonnées de partition lors des requêtes réduit l'efficacité globale des requêtes.
Épuisement des ressources de l'instance : un nombre excessif de parts de partition consomme une grande quantité de mémoire et de descripteurs de fichiers, ce qui peut ralentir considérablement le démarrage de ClickHouse ou provoquer son échec total.

Évitez un partitionnement excessivement fin

Évitez le partitionnement par heure, minute ou seconde, sauf si le volume de données est extrêmement important et que des exigences spécifiques existent. Par exemple, un partitionnement par minute avec toYYYYMMDDhhmm(event_time) génère 1 440 partitions par jour et plus de 500 000 par an, avec les inconvénients suivants :

Trop de partitions : un partitionnement excessivement fin dépasse largement la plage recommandée de 100 à 1 000, augmentant considérablement la charge liée à la gestion des métadonnées et du système de fichiers.

Erreur typique : DB::Exception: Too many parts (N). Merges are processing significantly slower than inserts.
Échec de la fusion en arrière-plan : ClickHouse fusionne les parts uniquement au sein de la même partition. Un trop grand nombre de partitions empêche une fusion efficace, laissant de nombreuses petites parts qui dégradent les performances.
Dégradation des performances des requêtes et des écritures : l'analyse d'une grande quantité de métadonnées de partition réduit l'efficacité des requêtes, tandis que le nombre excessif de parts ralentit également les écritures.

Les clés de partition doivent être des champs originaux ou des expressions simples

Évitez les fonctions complexes afin que ClickHouse puisse appliquer efficacement l'élimination des partitions.

Concevez les clés de partition conjointement avec les clés primaires

Utilisez les clés primaires pour couvrir les champs de filtre fréquemment interrogés et les clés de partition pour la gestion des données.

Par exemple, pour une table de journaux fréquemment interrogée par plage de temps et nom de service et nécessitant un nettoyage périodique des données expirées :

Clé de partition : toYYYYMM(event_time) crée une partition par mois, permettant la suppression par lot mensuelle, l'archivage et le stockage par niveaux chaud/froid.
Clé primaire : (service_name, event_time) permet aux requêtes telles que WHERE service_name = 'A' AND event_time BETWEEN ... d'utiliser pleinement l'index de clé primaire pour une élimination efficace des données.

Exemples de conception de table

CREATE TABLE logs
(
    event_time DateTime,
    service_name String,
    log_level String,
    message String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)         -- Partition by month for easy data management
ORDER BY (service_name, event_time)       -- Primary key covers commonly filtered fields

Choix de clés de partition non recommandés

Clé de partition sous forme de user_id (forte cardinalité) : une partition par utilisateur, entraînant un trop grand nombre de partitions, l'échec de la fusion et des performances extrêmement médiocres.
Clé de partition sous forme de device_id (forte cardinalité) : comme ci-dessus, provoquant des erreurs « too many parts » et des partitions ingérables.
Clé de partition sous forme de order_id (forte cardinalité) : une partition par commande, fragmentation extrême.
Clé de partition sous forme de name (chaîne à forte cardinalité) : nombre de partitions incontrôlable, difficile à gérer.
Clé de partition sous forme de toHour(event_time) (trop fine) : 24 partitions par jour, nombre de partitions extrêmement élevé au fil du temps, échec de la fusion.
Clé de partition sous forme de toMinute(event_time) (extrêmement fine) : explosion des partitions, affectant gravement les performances.
Clé primaire sous forme de champ à forte cardinalité avec un ordre illogique : par exemple, ORDER BY (user_id, event_time), mais les requêtes portent souvent sur event_time, ce qui entraîne une faible utilisation de l'index de clé primaire.
Clé primaire avec trop de champs : par exemple, ORDER BY (a, b, c, d, e, f, g, h, i, j), entraînant une taille importante de l'index de clé primaire et une consommation élevée de mémoire.
Clé primaire sous forme de champ à faible cardinalité : par exemple, ORDER BY (status), avec seulement quelques valeurs de statut, ce qui entraîne une capacité d'élimination de l'index de clé primaire extrêmement médiocre.
Clé de partition et clé primaire totalement indépendantes, et aucune ne couvre les conditions de requête courantes : par exemple, la clé de partition est region, la clé primaire est type, mais les requêtes portent souvent sur event_time, ce qui signifie que ni la partition ni la clé primaire n'accélèrent les requêtes.