OPTIMIZE TABLE ... FINAL (voir cette documentation), car son usage relève de l’administration et non des opérations quotidiennes.
OPTIMIZE ne peut pas corriger l’erreur Too many parts.OPTIMIZE est prise en charge pour la famille MergeTree (y compris les vues matérialisées) ainsi que pour les moteurs Buffer. Les autres moteurs de table ne sont pas pris en charge.
Lorsque OPTIMIZE est utilisé avec la famille de moteurs de table ReplicatedMergeTree, ClickHouse crée une tâche de fusion et attend son exécution sur toutes les répliques (si le paramètre alter_sync est défini sur 2) ou sur la réplique actuelle (si le paramètre alter_sync est défini sur 1).
- Si
OPTIMIZEn’effectue pas de fusion pour quelque raison que ce soit, il n’en informe pas le client. Pour activer les notifications, utilisez le paramètre optimize_throw_if_noop. - Si vous spécifiez un
PARTITION, seule la partition indiquée est optimisée. Comment définir l’expression de partition. - Si vous spécifiez
FINALouFORCE, l’optimisation est effectuée même lorsque toutes les données se trouvent déjà dans une seule part. Vous pouvez contrôler ce comportement avec optimize_skip_merged_partitions. De plus, la fusion est forcée même si des fusions concurrentes sont en cours. - Si vous spécifiez
DEDUPLICATE, les lignes complètement identiques (sauf si une clause BY est spécifiée) seront dédupliquées (toutes les colonnes sont comparées) ; cela n’a de sens que pour le moteur MergeTree.
OPTIMIZE à l’aide du paramètre replication_wait_for_inactive_replica_timeout.
Si
alter_sync est défini sur 2 et que certaines répliques restent inactives au-delà du délai spécifié par le paramètre replication_wait_for_inactive_replica_timeout, une exception UNFINISHED est levée.DRY RUN
DRY RUN simule une fusion des parts spécifiées sans enregistrer le résultat. La part fusionnée est écrite dans un emplacement temporaire, validée, puis supprimée. Les parts d’origine et les données de la table restent inchangées.
Cela est utile pour :
- Tester la validité des fusions entre différentes versions de ClickHouse.
- Reproduire de manière déterministe des bogues liés aux fusions.
- Évaluer les performances des fusions.
DRY RUN n’est pris en charge que pour les tables de la famille MergeTree. Le mot-clé PARTS, accompagné d’une liste de noms de parts, est requis. Toutes les parts spécifiées doivent exister, être actives et appartenir à la même partition.
DRY RUN est incompatible avec FINAL et PARTITION. Il peut être combiné avec DEDUPLICATE (avec spécification facultative des colonnes) et CLEANUP (pour les tables ReplacingMergeTree).
Syntaxe
CHECK TABLE. Ce comportement est contrôlé par le paramètre optimize_dry_run_check_part (activé par défaut). Le désactiver permet d’ignorer cette validation, ce qui peut être utile pour évaluer les performances de la fusion elle-même.
Exemple
Expression BY
*, COLUMNS ou EXCEPT. La liste de colonnes, qu’elle soit explicitement écrite ou implicitement développée, doit inclure toutes les colonnes spécifiées dans l’expression d’ordonnancement des lignes (à la fois la clé primaire et la clé de tri), ainsi que dans l’expression de partitionnement (clé de partitionnement).
Notez que
* se comporte exactement comme dans SELECT : les colonnes MATERIALIZED et ALIAS ne sont pas utilisées lors de l’expansion.De plus, spécifier une liste vide de colonnes, écrire une expression qui aboutit à une liste vide de colonnes ou effectuer une déduplication sur une colonne ALIAS constitue une erreur.Query
Query
Query
Response
DEDUPLICATE
Query
Query
Response
DEDUPLICATE BY *
ALIAS ni MATERIALIZED. Dans la table ci-dessus, il s’agit des colonnes primary_key, secondary_key, value et partition_key :
Query
Query
Response
DEDUPLICATE BY * EXCEPT
ALIAS ni MATERIALIZED, à l’exclusion explicite de value : les colonnes primary_key, secondary_key et partition_key.
Query
Query
Response
DEDUPLICATE BY <list of columns>
primary_key, secondary_key et partition_key :
Query
Query
Response
DEDUPLICATE BY COLUMNS(<regex>)
primary_key, secondary_key et partition_key :
Query
Query
Response