メインコンテンツまでスキップ
メインコンテンツまでスキップ

Optimize Finalを避ける

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

各挿入は、インデックスやチェックサムなどのメタデータとともに、ソートされた圧縮カラムファイルを含む新しいパーツを作成します。パーツの構造と形成方法についての詳細な説明については、この ガイド をお勧めします。

時間が経つにつれて、バックグラウンドプロセスが小さなパーツを大きなパーツにマージして、断片化を減らし、クエリパフォーマンスを向上させます。

次のコマンドを使用して、手動でこのマージをトリガーしたくなるかもしれませんが:

ほとんどの場合、この操作は避けるべきです。なぜなら、これはリソース集約的な操作を開始し、クラスターのパフォーマンスに影響を与える可能性があるからです。

なぜ避けるべきか?

高コストである

OPTIMIZE FINAL を実行すると、ClickHouse は すべての アクティブなパーツを 単一のパーツ にマージすることを強制します。これは、すでに大きなマージが行われている場合でも行われます。これには以下が含まれます:

  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 にマージを自動的に管理させる方が良いです