Atomic

Atomic エンジンは、非ブロッキングの DROP TABLE および RENAME TABLE クエリと、アトミックな EXCHANGE TABLES クエリをサポートします。Atomic データベースエンジンはデフォルトで使用されます。

Atomic エンジンは、非ブロッキングの DROP TABLE および RENAME TABLE クエリと、アトミックな EXCHANGE TABLES クエリをサポートします。オープンソース版 ClickHouse では、Atomic データベースエンジンがデフォルトで使用されます。

ClickHouse Cloud では、Shared データベースエンジン がデフォルトで使用されており、 上記の操作もサポートしています。

​

データベースの作成

CREATE DATABASE test [ENGINE = Atomic] [SETTINGS name = value, ...];

ENGINE = Atomic はデフォルトであるため省略できます。SETTINGS 句には、データベースエンジンの設定 (disk や max_tables など) と通常のクエリ設定の両方を指定でき、各名前は、そのいずれに属するかに応じて送出されます。

​

詳細と推奨事項

​

テーブル UUID

Atomic データベース内の各テーブルには永続的な UUID が割り当てられており、そのデータは次のディレクトリに保存されます。

/clickhouse_path/store/xxx/xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/

ここで、xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy はテーブルの UUID を表します。

デフォルトでは、UUID は自動的に生成されます。ただし、テーブルの作成時に UUID を明示的に指定することもできますが、これは推奨されません。

たとえば:

CREATE TABLE name UUID '28f1c61c-2970-457a-bffe-454156ddcfef' (n UInt64) ENGINE = ...;

UUID を SHOW CREATE クエリで表示するには、show_table_uuid_in_table_create_query_if_not_nil 設定を使用できます。

​

RENAME TABLE

RENAME クエリでは、UUID は変更されず、テーブルデータも移動されません。これらのクエリは即座に実行され、対象のテーブルを使用中の他のクエリの完了を待ちません。

​

DROP/DETACH TABLE

DROP TABLE を使用しても、データは削除されません。Atomic エンジンは、メタデータを /clickhouse_path/metadata_dropped/ に移動してテーブルを drop 済みとしてマークし、バックグラウンドスレッドに通知するだけです。最終的にテーブルデータが削除されるまでの遅延は、database_atomic_delay_before_drop_table_sec 設定で指定します。 SYNC 修飾子を使用すると、同期モードを指定できます。これを行うには、database_atomic_wait_for_drop_and_detach_synchronously 設定を使用します。この場合、DROP は、そのテーブルを使用している実行中の SELECT、INSERT、およびその他のクエリが終了するまで待機します。テーブルは、使用されなくなった時点で削除されます。

​

EXCHANGE TABLES/辞書

EXCHANGEクエリは、テーブルまたは辞書をアトミックに入れ替えます。たとえば、次のような非アトミックな操作ではなく:

Non-atomic

RENAME TABLE new_table TO tmp, old_table TO new_table, tmp TO old_table;

Atomic データベースを使用できます。

Atomic

EXCHANGE TABLES new_table AND old_table;

​

Atomic データベース内の ReplicatedMergeTree

ReplicatedMergeTree テーブルでは、ZooKeeper 内のパスとレプリカ名についてエンジンパラメータを指定しないことを推奨します。この場合、設定パラメータ default_replica_path と default_replica_name が使用されます。エンジンパラメータを明示的に指定する場合は、{uuid} マクロを使用することを推奨します。これにより、ZooKeeper 内で各テーブルに対して一意のパスが自動的に生成されます。

​

メタデータディスク

SETTINGS で disk を指定すると、そのディスクはテーブルのメタデータファイルの保存に使用されます。 単一のテーブルの場合と同様に、サーバー設定で定義されたディスクを名前で指定することも、disk 関数でインラインに定義することもできます:

CREATE DATABASE db SETTINGS disk = 'db_disk';
CREATE DATABASE db SETTINGS disk = disk(type = 'local', path = '/var/lib/clickhouse-disks/db_disk');

指定しない場合、デフォルトでは database_disk.disk に定義されたディスクが使用されます。

同じ SETTINGS 句は ATTACH DATABASE でも使用でき、メタデータファイルが別のディスク上にあるデータベースをサーバーにアタッチする際は、この方法を用います。その場合、Atomic ではデータベースの UUID を明示的に指定する必要があります:

ATTACH DATABASE db UUID '28f1c61c-2970-457a-bffe-454156ddcfef'
SETTINGS disk = disk(type = 'local', path = '/var/lib/clickhouse-disks/db_disk');

​

テーブル数の制限

max_tables 設定は、データベース に含めることができるテーブル数を制限します。0 (デフォルト) は無制限を意味します。通常のテーブル、view、materialized view、CREATE DICTIONARY で作成された Dictionary など、テーブルに類するすべての object がこの制限の対象となります。制限に達すると、CREATE TABLE、CREATE DICTIONARY、ATTACH TABLE は TOO_MANY_TABLES 例外をスローします。

CREATE DATABASE db ENGINE = Atomic SETTINGS max_tables = 100;

既存のデータベースの上限は、ALTER DATABASE で変更できます:

ALTER DATABASE db MODIFY SETTING max_tables = 200;

上限を現在のテーブル数より低く設定しても、テーブルは削除されません。テーブル数が再び上限を下回るまで、新しいテーブルを作成できなくなるだけです。

CREATE OR REPLACE TABLE は、置き換え用のテーブルを一時的な名前で作成してから入れ替えるため、データベースのテーブル数がちょうど max_tables に達している場合は、最終的なテーブル数が増えない場合でも TOO_MANY_TABLES によりテーブルの置き換えに失敗します。RENAME TABLE または RENAME DICTIONARY でオブジェクトをデータベースに移動する場合も、この上限の対象となります。

TO 句を指定せずに作成した materialized view には、独自のテーブルとして上限にカウントされる隠し内部テーブルがあります。

上限は操作の開始前にチェックされるため、ベストエフォートです。同時実行クエリによって、データベースのテーブル数が上限をわずかに超える可能性があります。

この設定は、テーブルをメモリ内に保持し、メタデータをローカルの .sql ファイルに保存するオンディスクのデータベースエンジン (Atomic および Ordinary) で使用できます。Replicated エンジンではサポートされていません。

​

関連項目

• system.databases システムテーブル