- DETACH PARTITION|PART — パーティションまたはパーツを
detachedディレクトリに移動し、管理対象から外します。 - DROP PARTITION|PART — パーティションまたはパーツを削除します。
- DROP DETACHED PARTITION|PART -
detachedからパーツ、またはパーティション内のすべてのパーツを削除します。 - FORGET PARTITION — 空の場合、ZooKeeper からパーティションのメタデータを削除します。
- ATTACH PARTITION|PART —
detachedディレクトリからパーティションまたはパーツをテーブルに追加します。 - ATTACH PARTITION FROM — あるテーブルから別のテーブルへデータパーティションをコピーして追加します。
- REPLACE PARTITION — あるテーブルから別のテーブルへデータパーティションをコピーして置き換えます。
- MOVE PARTITION TO TABLE — データパーティションをあるテーブルから別のテーブルへ移動します。
- CLEAR COLUMN IN PARTITION — パーティション内の指定したカラムの値をリセットします。
- CLEAR INDEX IN PARTITION — パーティション内の指定した二次索引をリセットします。
- FREEZE PARTITION — パーティションのバックアップを作成します。
- UNFREEZE PARTITION — パーティションのバックアップを削除します。
- FETCH PARTITION|PART — 別のサーバーからパーツまたはパーティションをダウンロードします。
- MOVE PARTITION|PART — パーティションまたはデータパーツを別のディスクまたはボリュームへ移動します。
- UPDATE IN PARTITION — 条件に基づいてパーティション内のデータを更新します。
- DELETE IN PARTITION — 条件に基づいてパーティション内のデータを削除します。
- REWRITE PARTS — テーブル内のパーツ (または特定のパーティション内のパーツ) を完全に書き換えます。
DETACH PARTITION|PART
detachedディレクトリに移動します。サーバーは、デタッチされたデータパーティションを存在しないものとして扱い、認識しなくなります。ATTACHクエリを実行するまで、サーバーはこのデータを認識しません。
例:
detached ディレクトリ内のデータを自由に扱えます。ファイルシステムから削除しても、そのまま残しておいてもかまいません。
このクエリはレプリケートされるため、すべてのレプリカ上でデータが detached ディレクトリに移動されます。このクエリを実行できるのは、リーダー レプリカ上だけである点に注意してください。レプリカがリーダーかどうかを確認するには、system.replicas テーブルに対して SELECT クエリを実行します。あるいは、すべてのレプリカで DETACH クエリを実行するほうが簡単です。リーダー レプリカ以外のすべてのレプリカは例外をスローします (複数のリーダーを許可できるためです) 。
DROP PARTITION|PART
DROP DETACHED PARTITION|PART
detachedから削除します。
パーティション式の設定について詳しくは、パーティション式の指定方法のセクションを参照してください。
FORGET PARTITION
ATTACH PARTITION|PART
detached ディレクトリからテーブルにデータを追加します。パーティション全体のデータ、または個々のパーツのデータを追加できます。例:
detached ディレクトリにデータがあるかどうかを確認します。
データが存在する場合、クエリはその整合性を検証します。問題がなければ、そのデータをテーブルに追加します。
ATTACH コマンドを受け取った非イニシエーターのレプリカは、自身の detached ディレクトリ内に正しいチェックサムを持つパーツを見つけた場合、他のレプリカから取得することなくそのデータをアタッチします。
正しいチェックサムを持つパーツがない場合、データはそのパーツを持ついずれかのレプリカからダウンロードされます。
1 つのレプリカの detached ディレクトリにデータを配置し、ALTER ... ATTACH クエリを使用して、すべてのレプリカ上のテーブルに追加できます。
ATTACH PARTITION FROM
table1 から table2 にコピーします。
注意:
table1とtable2のどちらからもデータは削除されません。table1は一時テーブルでもかまいません。
- 両方のテーブルの構造が同一である必要があります。
- 両方のテーブルが同じパーティションキー、同じ ORDER BY キー、同じ主キーを持っている必要があります。
- 両方のテーブルが同じストレージポリシーを持っている必要があります。
- 宛先テーブルには、コピー元テーブルのすべての索引とプロジェクションが含まれている必要があります。宛先テーブルで
enforce_index_structure_match_on_partition_manipulation設定が有効になっている場合、索引とプロジェクションは完全に一致している必要があります。そうでない場合、宛先テーブルはコピー元テーブルの索引およびプロジェクションの上位集合を持つことができます。
REPLACE PARTITION
table1 から table2 にコピーし、table2 内の既存のパーティションを置き換えます。この操作はアトミックです。
次の点に注意してください。
table1からデータが削除されることはありません。table1には一時テーブルを使用できます。
- 両方のテーブルが同じ構造である必要があります。
- 両方のテーブルが、同じパーティションキー、同じ ORDER BY キー、および同じ主キーを持っている必要があります。
- 両方のテーブルが同じストレージポリシーを持っている必要があります。
- 宛先テーブルには、ソーステーブルのすべての索引とプロジェクションが含まれている必要があります。宛先テーブルで
enforce_index_structure_match_on_partition_manipulation設定が有効になっている場合、索引とプロジェクションは完全に同一である必要があります。そうでない場合、宛先テーブルはソーステーブルの索引とプロジェクションの上位集合を持つことができます。
MOVE PARTITION TO TABLE
table_source のデータを削除し、データパーティションを table_source から table_dest へ移動します。
このクエリを正常に実行するには、次の条件を満たしている必要があります。
- 両方のテーブルの構造が同一であること。
- 両方のテーブルが同じパーティションキー、同じ ORDER BY キー、および同じ主キーを持つこと。
- 両方のテーブルが同じストレージポリシーを持つこと。
- 両方のテーブルが同じエンジンファミリー (replicated または non-replicated) であること。
- 宛先テーブルに、ソーステーブルのすべての索引とプロジェクションが含まれていること。宛先テーブルで
enforce_index_structure_match_on_partition_manipulation設定が有効になっている場合、索引とプロジェクションは完全に一致している必要があります。そうでない場合、宛先テーブルにはソーステーブルの索引とプロジェクションの上位集合を含めることができます。
CLEAR COLUMN IN PARTITION
DEFAULT 句が定義されている場合、このクエリはカラムの値を指定したデフォルト値に設定します。
例:
FREEZE PARTITION
PARTITION 句を省略すると、すべてのパーティションのバックアップが一度に作成されます。
バックアップ処理全体は、サーバーを停止せずに実行されます。
2019) を指定できます。その場合、このクエリは対応するすべてのパーティションのバックアップを作成します。パーティション式の設定については、パーティション式の指定方法 の節を参照してください。
実行時には、データのスナップショットを取得するために、このクエリはテーブルデータへのハードリンクを作成します。ハードリンクは /var/lib/clickhouse/shadow/N/... ディレクトリに配置されます。ここで:
/var/lib/clickhouse/は、設定ファイルで指定された ClickHouse の作業ディレクトリです。Nはバックアップの連番です。WITH NAMEパラメータが指定されている場合は、連番の代わりに'backup_name'パラメータの値が使用されます。
テーブルのデータ保存用ディスクのセットを使用している場合、
shadow/N ディレクトリは各ディスク上に作成され、PARTITION 式に一致したデータパーツが保存されます。/var/lib/clickhouse/ 配下と同じディレクトリ構造が作成されます。このクエリはすべてのファイルに対して chmod を実行し、それらへの書き込みを禁止します。
バックアップを作成した後、/var/lib/clickhouse/shadow/ からリモートサーバーにデータをコピーし、その後ローカルサーバーから削除できます。ALTER t FREEZE PARTITION クエリはレプリケートされないことに注意してください。ローカルサーバー上にのみローカルバックアップを作成します。
このクエリはバックアップをほぼ瞬時に作成します (ただし最初に、対応するテーブルに対して現在実行中のクエリが終了するのを待ちます) 。
ALTER TABLE t FREEZE PARTITION は、テーブルのメタデータではなくデータのみをコピーします。テーブルのメタデータもバックアップするには、/var/lib/clickhouse/metadata/database/table.sql ファイルをコピーしてください。
バックアップからデータを復元するには、次の手順を実行します。
- テーブルが存在しない場合は作成します。クエリを確認するには .sql ファイルを使用します (その中の
ATTACHをCREATEに置き換えます) 。 - バックアップ内の
data/database/table/ディレクトリから/var/lib/clickhouse/data/database/table/detached/ディレクトリにデータをコピーします。 ALTER TABLE t ATTACH PARTITIONクエリを実行して、データをテーブルに追加します。
max_threads 設定によって制御されます。
バックアップとデータの復元について詳しくは、“ClickHouse のバックアップと復元” の節を参照してください。
UNFREEZE PARTITION
frozenパーティションをディスクから削除します。PARTITION句を省略すると、すべてのパーティションのバックアップが一度に削除されます。
CLEAR INDEX IN PARTITION
CLEAR COLUMN と同様に機能しますが、カラムデータではなく索引をリセットします。
FETCH PARTITION|PART
- 指定した分片からパーティション|パーツ をダウンロードします。‘path-in-zookeeper’ には、ZooKeeper 内のその分片へのパスを指定する必要があります。
- 次に、このクエリはダウンロードしたデータを
table_nameテーブルのdetachedディレクトリに配置します。データをテーブルに追加するには、ATTACH PARTITION|PART クエリを使用します。
- FETCH PARTITION
- FETCH PART
ALTER ... FETCH PARTITION|PARTクエリはレプリケートされません。パーツ またはパーティションは、ローカルサーバー上のdetachedディレクトリにのみ配置されます。ALTER TABLE ... ATTACHクエリはレプリケートされます。データはすべてのレプリカに追加されます。あるレプリカにはdetachedディレクトリから追加され、その他のレプリカには近隣のレプリカから追加されます。
ALTER TABLE と呼ばれていますが、テーブル構造を変更するわけではなく、テーブルで利用可能なデータも直ちには変更しません。
MOVE PARTITION|PART
MergeTree エンジンのテーブルで、パーティションまたはデータパーツを別のボリュームまたはディスクへ移動します。詳しくは、データストレージに複数のブロックデバイスを使用するを参照してください。
ALTER TABLE t MOVE クエリ:
- レプリケートされません。レプリカごとに異なるストレージポリシーを設定できるためです。
- 指定したディスクまたはボリュームが設定されていない場合は、エラーを返します。また、ストレージポリシーで指定されたデータ移動の条件を適用できない場合も、クエリはエラーを返します。
- 移動対象のデータが、バックグラウンドプロセス、同時実行の
ALTER TABLE t MOVEクエリ、またはバックグラウンドでのデータマージによってすでに移動されている場合にも、エラーが返されることがあります。この場合、ユーザーが追加の操作を行う必要はありません。
UPDATE IN PARTITION
例
関連項目
DELETE IN PARTITION
例
パーツを最初から書き換える
use_const_adaptive_granularity のようなテーブルレベルの設定は、デフォルトでは新たに書き込まれるパーツにしか適用されないため、これは理にかなっています。
例
関連項目
パーティション式の指定方法
ALTER ... PARTITION クエリでは、パーティション式をさまざまな方法で指定できます。
system.partsテーブルのpartitionカラムの値として指定します。たとえば、ALTER TABLE visits DETACH PARTITION 201901です。- キーワード
ALLを使用します。これは DROP/DETACH/ATTACH/ATTACH FROM でのみ使用できます。たとえば、ALTER TABLE visits ATTACH PARTITION ALLです。 - テーブルのパーティションキーのタプルに (型の上で) 一致する、式または定数のタプルとして指定します。パーティションキーが単一要素の場合は、式を
tuple (...)関数で囲む必要があります。たとえば、ALTER TABLE visits DETACH PARTITION tuple(toYYYYMM(toDate('2019-01-25')))です。 - パーティション ID を使用します。パーティション ID はパーティションの文字列識別子 (可能であれば人が読める形式) で、ファイルシステムおよび ZooKeeper 上でのパーティション名として使用されます。パーティション ID は、
PARTITION IDclause で単一引用符付きで指定する必要があります。たとえば、ALTER TABLE visits DETACH PARTITION ID '201901'です。 - ALTER ATTACH PART および DROP DETACHED PART クエリでパーツ名を指定するには、system.detached_parts テーブルの
nameカラムの値を使った文字列リテラルを使用します。たとえば、ALTER TABLE visits ATTACH PART '201901_1_1_0'です。
String 型では名前を引用符 (') で囲んで指定する必要があります。Date 型および Int* 型では引用符は不要です。
上記のルールはすべて OPTIMIZE クエリにも当てはまります。パーティション化されていないテーブルを最適化する際に唯一のパーティションを指定する必要がある場合は、式 PARTITION tuple() を設定します。たとえば:
IN PARTITION は、ALTER TABLE クエリによって UPDATE または DELETE の式が適用されるパーティションを指定します。新しいパーツは、指定したパーティションからのみ作成されます。このため、テーブルが多数のパーティションに分割されていて、データを個別に更新するだけでよい場合、IN PARTITION は負荷の軽減に役立ちます。
ALTER ... PARTITION クエリの例は、テスト 00502_custom_partitioning_local と 00502_custom_partitioning_replicated_zookeeper に示されています。