変更を避ける

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 を使用してください。ミューテーションの誤用は、パフォーマンスの低下や過剰なストレージの消費、潜在的なサービスの不安定性を引き起こす可能性がありますので、注意して稀に適用してください。

データを削除するために、ユーザーは軽量削除やパーティションを介したデータの管理を考慮することもでき、これにより全体のパーツを効率的にドロップできます。