変異を避ける

In ClickHouse、ミューテーション はテーブル内の既存データを変更または削除する操作を指します - 通常は ALTER TABLE ... DELETE または ALTER TABLE ... UPDATE を使用します。これらのステートメントは標準SQL操作と似ているように見えますが、内部的には根本的に異なります。

ClickHouseのミューテーションは、行をその場で変更するのではなく、変更の影響を受ける全ての データパーツ を再書き込みする非同期のバックグラウンドプロセスです。このアプローチはClickHouseの列指向で不変なストレージモデルに必要ですが、重要なI/Oおよびリソース使用につながる可能性があります。

ミューテーションが発行されると、ClickHouseは新しい ミューテーションパーツ の作成をスケジュールし、新しいパーツが準備できるまで元のパーツはそのままにします。新しいパーツが準備できると、ミューテーションパーツは原本を原子的に置き換えます。しかし、操作が全てのパーツを再書き込むため、一つの行を更新するような小さな変更でさえ、大規模な再書き込みや過剰な書き込み増幅を引き起こす可能性があります。

大規模なデータセットの場合、これはディスクI/Oに大きなスパイクをもたらし、クラスタ全体のパフォーマンスを低下させる可能性があります。マージとは異なり、ミューテーションは一度提出されるとロールバックできず、サーバー再起動後も明示的にキャンセルしない限り実行を続けます - KILL MUTATION を参照してください。

ミューテーションは 完全に順序付けられています：それはミューテーションが発行される前に挿入されたデータに適用されますが、新しいデータには影響を与えません。挿入をブロックすることはありませんが、他の進行中のクエリと重なることがあります。ミューテーション中に実行されるSELECTクエリは、ミューテーションされた部分とミューテーションされていない部分が混在して読み込まれる可能性があり、実行中にデータの一貫性のないビューをもたらすことがあります。ClickHouseはパートごとにミューテーションを並行して実行するため、特に複雑なサブクエリ（例えば x IN (SELECT ...)）が関与する場合は、メモリとCPUの使用がさらに激化する可能性があります。

基本的に、頻繁または大規模なミューテーションは避けるべきです、特に高ボリュームのテーブルでは。代わりに、ReplacingMergeTree や CollapsingMergeTree のような代替テーブルエンジンを使用することをお勧めします。これらはクエリ時間やマージ中のデータ修正をより効率的に処理するように設計されています。ミューテーションが絶対に必要な場合は、system.mutationsテーブルを使用して注意深く監視し、プロセスがスタックしたり不具合を起こした場合は KILL MUTATION を使用してください。ミューテーションの誤使用はパフォーマンスの低下、過剰なストレージの変動、サービスの不安定さを引き起こす可能性があるため、注意して稀に使用してください。

データを削除するために、ユーザーは Lightweight deletes や パーティション を通じてデータを管理することを検討することもできます。これにより、全てのパーツを 効率的に削除する ことができます。