ALTER TABLE ... DELETE または ALTER TABLE ... UPDATE を使用します。これらのステートメントは標準的な SQL 操作に似て見えるかもしれませんが、内部の仕組みは本質的に異なります。
ClickHouse のミューテーションは、行をその場で変更するのではなく、変更の影響を受けるデータパーツ 全体を書き換える非同期のバックグラウンド処理として実行されます。このアプローチは、ClickHouse のカラム指向かつイミュータブルなストレージモデル上では必要なものであり、大量の I/O やリソース消費につながる可能性があります。
ミューテーションが発行されると、ClickHouse は新しいミューテーション済みパーツの作成をスケジュールし、新しいパーツの準備が整うまで元のパーツはそのまま残されます。準備が完了すると、ミューテーション済みパーツが元のパーツをアトミックに置き換えます。ただし、この処理ではパーツ全体を書き換えるため、わずかな変更 (たとえば 1 行だけの更新) でも、大規模な書き換えや過度な書き込み増幅が発生することがあります。
大規模なデータセットでは、これによってディスク I/O が大きく増加し、クラスター全体のパフォーマンスが低下するおそれがあります。マージとは異なり、ミューテーションは一度送信するとロールバックできず、明示的にキャンセルしない限り、サーバーの再起動後も実行され続けます。詳細は KILL MUTATION を参照してください。
ミューテーションは厳密に順序付けされます。つまり、ミューテーションが発行される前に挿入されたデータには適用されますが、それ以降に挿入された新しいデータには影響しません。挿入をブロックすることはありませんが、進行中のほかのクエリと並行して実行されることはあります。ミューテーション実行中の SELECT は、ミューテーション済みパーツと未変更のパーツが混在した状態を読み取る可能性があり、その結果、実行中はデータの見え方に不整合が生じることがあります。ClickHouse はミューテーションをパーツ単位で並列実行するため、特に複雑なサブクエリ (x IN (SELECT …) のようなもの) が含まれる場合には、メモリ使用量や CPU 使用率がさらに高まることがあります。
原則として、頻繁なミューテーションや大規模なミューテーションは避けてください。特に高ボリュームのテーブルでは重要です。代わりに、ReplacingMergeTree や CollapsingMergeTree のような代替テーブルエンジンの使用を検討してください。これらは、クエリ時またはマージ時に、より効率的にデータ修正を処理できるよう設計されています。どうしてもミューテーションが必要な場合は、system.mutations テーブルを使って注意深く監視し、処理が停止している、または異常な動作をしている場合は KILL MUTATION を使用してください。ミューテーションを不適切に使うと、パフォーマンスの低下、過剰なストレージの入れ替わり、さらにはサービスの不安定化につながる可能性があるため、慎重に、かつ必要最小限にとどめて適用してください。
データ削除については、論理削除 や、パーティション を通じたデータ管理も検討できます。これにより、パーツ全体を効率的に削除できます。