削除の概要

ClickHouseでデータを削除する方法はいくつかあり、それぞれに利点とパフォーマンス特性があります。データモデルと削除予定のデータ量に応じて、適切な方法を選択してください。

以下に、ClickHouseでデータを削除するさまざまな方法の概要を示します。

論理削除では、行は直ちに削除済みとしてマークされ、以降のすべての SELECT クエリで自動的に除外されます。これらの削除済み行はその後、通常のマージサイクルの中で削除されるため、I/O の負荷を抑えられます。そのため、一定期間は、データが実際にストレージから削除されず、削除済みとしてマークされているだけの場合があります。データが確実に削除される必要がある場合は、上記の ミューテーション コマンドを検討してください。

-- 論理削除を使用して2018年のすべてのデータを削除する。非推奨。
DELETE FROM posts WHERE toYear(CreationDate) = 2018

大量のデータを論理削除の DELETE ステートメントで削除すると、SELECT クエリのパフォーマンスにも悪影響を与える可能性があります。また、このコマンドはプロジェクションを持つテーブルとは互換性がありません。

この操作では、削除された行をマークする (_row_exists カラムを追加する) ためにミューテーションが使用されるため、一定の I/O が発生する点に注意してください。

一般に、削除されたデータがディスク上に残っていても許容できる場合 (たとえば、コンプライアンス要件に関わらないケース) は、ミューテーションよりも論理削除を優先すべきです。ただし、すべてのデータを削除する必要がある場合は、この方法も避けるべきです。

論理削除の詳細をご覧ください。

削除ミューテーションは、たとえば ALTER TABLE ... DELETE コマンドを使用して発行できます。

-- delete all data from 2018 with a mutation. Not recommended.
ALTER TABLE posts DELETE WHERE toYear(CreationDate) = 2018

これらは、同期的に (non-replicated の場合はデフォルト) または非同期的に (mutations_sync 設定で決まります) 実行できます。これらは非常に I/O 負荷が高く、WHERE 式に一致するすべてのパーツを書き換えます。この処理にはアトミック性がありません。ミューテーション後のパーツは準備ができ次第すぐに置き換えられるため、ミューテーションの実行中に開始された SELECT クエリでは、すでにミューテーション済みのパーツのデータと、まだミューテーションされていないパーツのデータの両方が見えることになります。ユーザーは system.mutations テーブルで進行状況を追跡できます。これらは I/O 負荷の高い操作であり、クラスターの SELECT パフォーマンスに影響する可能性があるため、使用は最小限にとどめるべきです。

削除ミューテーション の詳細を参照してください。

テーブル内のすべてのデータを削除する必要がある場合は、以下に示す TRUNCATE TABLE コマンドを使用します。これは軽量な処理です。

TRUNCATE TABLE posts

TRUNCATE TABLE の詳細については、こちらをご覧ください。

データにカスタムのパーティションキーを指定している場合は、パーティションを効率的に削除できます。カーディナリティの高いパーティション化は避けてください。

ALTER TABLE posts (DROP PARTITION '2008')

DROP PARTITION の詳細については、こちらをご覧ください。

• ClickHouse における更新および削除の処理