Optimize Finalを避ける
ClickHouse テーブルは MergeTree エンジン を使用して、ディスク上に 不変のパーツ としてデータを保存します。これは、データが挿入されるたびに作成されます。
各挿入は、インデックスやチェックサムなどのメタデータとともに、ソートされた圧縮カラムファイルを含む新しいパーツを作成します。パーツの構造と形成方法についての詳細な説明については、この ガイド をお勧めします。
時間が経つにつれて、バックグラウンドプロセスが小さなパーツを大きなパーツにマージして、断片化を減らし、クエリパフォーマンスを向上させます。
次のコマンドを使用して、手動でこのマージをトリガーしたくなるかもしれませんが：
ほとんどの場合、この操作は避けるべきです。なぜなら、これはリソース集約的な操作を開始し、クラスターのパフォーマンスに影響を与える可能性があるからです。
なぜ避けるべきか？
高コストである
OPTIMIZE FINAL を実行すると、ClickHouse は すべての アクティブなパーツを 単一のパーツ にマージすることを強制します。これは、すでに大きなマージが行われている場合でも行われます。これには以下が含まれます：
- すべてのパーツの解凍
- データのマージ
- 再圧縮
- 最終パーツをディスクやオブジェクトストレージに書き込む
これらのステップは CPU と I/O 集約型 であり、大規模なデータセットが関与する場合、システムに大きな負担をかける可能性があります。
安全制限を無視する
通常、ClickHouse は ~150 GB より大きいパーツのマージを避けます（これは max_bytes_to_merge_at_max_space_in_pool を介して設定可能です）。しかし、OPTIMIZE FINAL は この保護機能を無視します。これは以下を意味します：
- 複数の 150 GB パーツ を1つの巨大なパーツにマージしようとする可能性があります。
- これにより 長いマージ時間、メモリプレッシャー、さらには メモリエラー が発生する可能性があります。
- これらの大きなパーツはマージが困難になる可能性があり、上記の理由によりそれらをさらにマージしようとする試みが失敗します。クエリの時間の正しい動作のためにマージが必要な場合、これは望ましくない結果をもたらす可能性があります。例えば、ReplacingMergeTree 用の重複排除 により、クエリのパフォーマンスが低下することがあります。
バックグラウンドマージに作業を任せる
ClickHouse はすでにストレージとクエリの効率を最適化するために、スマートなバックグラウンドマージを実行しています。これらは段階的で、リソースを考慮し、設定された閾値を尊重します。非常に特定のニーズがない限り（例：テーブルの凍結前にデータを確定する、またはエクスポートするなど）、ClickHouse にマージを自動的に管理させる方が良いです。
