`OPTIMIZE FINAL`を避ける

ClickHouseでOPTIMIZE FINAL句を避けるべき理由を説明するページ

MergeTree engine を使用する ClickHouse テーブルでは、データが挿入されるたびに作成される 不変のパーツ として、データがディスクに保存されます。

各 insert では、ソートおよび圧縮されたカラムファイルに加え、索引やチェックサムなどのメタデータを含む新しいパーツが作成されます。パーツの構造や生成方法の詳細については、このガイドを参照することをお勧めします。

時間の経過とともに、バックグラウンドプロセスによって小さなパーツがより大きなパーツへとマージされ、断片化が抑えられ、クエリのパフォーマンスが向上します。

ただし、次を使ってこのマージを手動でトリガーしたくなるかもしれません。

OPTIMIZE TABLE <table> FINAL;

ほとんどの場合、OPTIMIZE FINAL の実行は避けるべきです。これは、 クラスターのパフォーマンスに影響を及ぼしかねない、リソース負荷の高い処理を開始するためです。

OPTIMIZE FINAL と FINAL

OPTIMIZE FINAL は FINAL と同じではありません。ReplacingMergeTree のように、 重複のない結果を得るために FINAL の使用が必要になる場合があります。一般に、 クエリが主キーに含まれるものと同じカラムでフィルタしているのであれば、FINAL を使用しても問題ありません。

​

避けるべき理由

​

コストが高くつきます

OPTIMIZE FINAL を実行すると、たとえ大規模なマージがすでに行われていても、ClickHouse はアクティブなすべてのパーツを1つのパーツへ強制的にマージします。これには次の処理が伴います。

1. すべてのパーツの圧縮解除
2. データのマージ
3. 再圧縮
4. 最終的なパーツのディスクまたはオブジェクトストレージへの書き込み

これらの処理は CPU と I/O の負荷が高く、特に大規模なデータセットを扱う場合には、システムに大きな負担をかける可能性があります。

​

安全上の制限を無視する

通常、ClickHouse は ~150 GB を超えるパーツのマージを避けます (max_bytes_to_merge_at_max_space_in_pool で設定可能) 。しかし、OPTIMIZE FINAL はこの安全策を無視するため、次のようなことが起こりえます。

• 150 GB のパーツを複数、1 つの巨大なパーツにマージしようとする可能性があります
• その結果、マージに長時間かかる、メモリ負荷が高まる、さらにはメモリ不足エラーが発生することがあります
• こうした大きなパーツはさらにマージしにくくなり、つまり上記の理由から、その後のマージも失敗する可能性があります。クエリ時に正しい動作をさせるためにマージが必要な場合、これは ReplacingMergeTree で重複が蓄積する などの望ましくない結果を招き、クエリ時のパフォーマンス低下につながる可能性があります。

​

バックグラウンドマージに任せる

ClickHouse は、ストレージとクエリ効率を最適化するために、すでに高度なバックグラウンドマージを実行しています。これらの処理は増分的に行われ、リソース状況を考慮し、設定されたしきい値にも従います。よほど特殊な要件 (たとえば、テーブルを凍結したりエクスポートしたりする前にデータを確定する必要がある場合) がない限り、マージは ClickHouse に任せるのが最善です。