```
例:
```sql theme={null}
CREATE TABLE example
(
id UInt64,
region String,
user_id UInt32,
PROJECTION region_proj INDEX region TYPE basic,
PROJECTION uid_proj INDEX user_id TYPE basic
)
ENGINE = MergeTree
ORDER BY id;
```
#### 索引の種類
現在サポートされているのは次のとおりです。
* **basic**: 式に対する通常の MergeTree 索引と同等です。
このフレームワークでは、今後さらに多くの索引タイプを追加できます。
### プロジェクションストレージ
プロジェクションはパートディレクトリ内に格納されます。索引に似ていますが、匿名の `MergeTree` テーブルのパートを格納するサブディレクトリを含みます。このテーブルは、プロジェクションの定義クエリによって導出されます。`GROUP BY` 句がある場合、基盤となるストレージエンジンは [AggregatingMergeTree](/docs/ja/reference/engines/table-engines/mergetree-family/aggregatingmergetree) になり、すべての集約関数は `AggregateFunction` に変換されます。`ORDER BY` 句がある場合、`MergeTree` テーブルはそれを主キー式として使用します。マージ処理中、プロジェクションパートはそのストレージのマージルーチンを通じてマージされます。親テーブルのパートのチェックサムは、プロジェクションのパートのチェックサムと結合されます。その他のメンテナンスジョブは、スキップ索引と同様です。
### クエリ解析
1. プロジェクションを使って指定されたクエリに対応できるか、つまり基となるテーブルに対してクエリを実行した場合と同じ結果を返せるかを確認します。
2. 読み取るグラニュール数が最も少ない、実行可能な最適候補を選択します。
3. プロジェクションを使うクエリパイプラインは、元のパーツを使う場合のものとは異なります。一部のパーツにプロジェクションがない場合は、その場でプロジェクションを作成するパイプラインを追加できます。
## 同時データアクセス
テーブルへの同時アクセスには、マルチバージョニングを使用します。つまり、テーブルに対して同時に読み取りと更新が行われている場合でも、データはクエリ実行時点で有効なパーツの集合から読み取られます。長時間保持されるロックはありません。insert も読み取り処理の妨げにはなりません。
テーブルからの読み取りは自動的に並列化されます。
## カラムとテーブルの有効期限 (TTL)
値の保持期間を決定します。
`TTL` 句は、テーブル全体にも、個々のカラムにも設定できます。テーブルレベルの `TTL` では、ディスクやボリューム間でのデータの自動移動や、すべてのデータの有効期限が切れたパーツの再圧縮のロジックも指定できます。
式は、[Date](/docs/ja/reference/data-types/date)、[Date32](/docs/ja/reference/data-types/date32)、[DateTime](/docs/ja/reference/data-types/datetime) または [DateTime64](/docs/ja/reference/data-types/datetime64) のデータ型を返す必要があります。
**有効期限 (TTL) 式では非決定論的関数を避けてください**
有効期限 (TTL) は挿入時ではなく、バックグラウンドマージ時に評価されます。
`rand()`、`now()`、`now64()` のような関数は、マージのたびに再評価されるため、予測不能な削除動作につながります。
ClickHouse はカラムにまったく依存しない式をブロックしますが、現在のところ、カラム参照と組み合わせた非決定論的関数 (例: `ts + rand()`) は拒否しません。予測可能な結果を得るため、有効期限 (TTL) 式は決定論的で、カラムから導出される値のみに基づいて記述してください。
**構文**
カラムの有効期限 (TTL) を設定する場合:
```sql theme={null}
TTL time_column
TTL time_column + interval
```
`interval` を定義するには、[時間間隔](/docs/ja/reference/operators/index#operators-for-working-with-dates-and-times) 演算子を使用します。例:
```sql theme={null}
TTL date_time + INTERVAL 1 MONTH
TTL date_time + INTERVAL 15 HOUR
```
### カラム 有効期限 (TTL)
カラム内の値が期限切れになると、ClickHouse はそれらをそのカラムのデータ型のデフォルト値に置き換えます。データパート内のそのカラムの値がすべて期限切れになった場合、ClickHouse はファイルシステム上のデータパートからそのカラムを削除します。
`有効期限 (TTL)` 句はキーカラムには使用できません。
**例**
#### `有効期限 (TTL)` を設定したテーブルの作成:
```sql theme={null}
CREATE TABLE tab
(
d DateTime,
a Int TTL d + INTERVAL 1 MONTH,
b Int TTL d + INTERVAL 1 MONTH,
c String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d;
```
#### 既存テーブルのカラムに有効期限 (TTL) を追加する
```sql theme={null}
ALTER TABLE tab
MODIFY COLUMN
c String TTL d + INTERVAL 1 DAY;
```
#### カラムの有効期限 (TTL) の変更
```sql theme={null}
ALTER TABLE tab
MODIFY COLUMN
c String TTL d + INTERVAL 1 MONTH;
```
### テーブルの 有効期限 (TTL)
テーブルには、有効期限が切れた行を削除するための式と、[ディスクまたはボリューム](#table_engine-mergetree-multiple-volumes)間でパーツを自動的に移動するための複数の式を設定できます。テーブル内の行が期限切れになると、ClickHouse は該当するすべての行を削除します。パーツの移動または再圧縮では、パーツ内のすべての行が `有効期限 (TTL)` 式の条件を満たしている必要があります。
```sql theme={null}
TTL expr
[DELETE|RECOMPRESS codec_name1|TO DISK 'xxx'|TO VOLUME 'xxx'][, DELETE|RECOMPRESS codec_name2|TO DISK 'aaa'|TO VOLUME 'bbb'] ...
[WHERE conditions]
[GROUP BY key_expr [SET v1 = aggr_func(v1) [, v2 = aggr_func(v2) ...]] ]
```
各 有効期限 (TTL) 式の後には、有効期限 (TTL) ルールの種類を指定できます。これは、式の条件が満たされた時点 (現在時刻に達した時点) で実行されるアクションに影響します。
* `DELETE` - 期限切れの行を削除します (デフォルトのアクション) 。
* `RECOMPRESS codec_name` - `codec_name` を使用してデータパートを再圧縮します。
* `TO DISK 'aaa'` - パートをディスク `aaa` に移動します。
* `TO VOLUME 'bbb'` - パートをディスク `bbb` に移動します。
* `GROUP BY` - 期限切れの行を集約します。
`DELETE` アクションは `WHERE` 句と組み合わせて使用でき、フィルタリング条件に基づいて、期限切れの行の一部のみを削除できます。
```sql theme={null}
TTL time_column + INTERVAL 1 MONTH DELETE WHERE column = 'value'
```
`GROUP BY` 式は、テーブルの主キーのプレフィックスでなければなりません。
あるカラムが `GROUP BY` 式に含まれず、`SET` 句でも明示的に設定されていない場合、結果の行にはグループ化された行のいずれかの値が格納されます (そのカラムに集約関数 `any` が適用された場合と同様です) 。
**例**
#### 有効期限 (TTL) を設定したテーブルの作成:
```sql theme={null}
CREATE TABLE tab
(
d DateTime,
a Int
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d
TTL d + INTERVAL 1 MONTH DELETE,
d + INTERVAL 1 WEEK TO VOLUME 'aaa',
d + INTERVAL 2 WEEK TO DISK 'bbb';
```
#### テーブルの`有効期限 (TTL)`を変更する:
```sql theme={null}
ALTER TABLE tab
MODIFY TTL d + INTERVAL 1 DAY;
```
1 か月後に行の有効期限が切れるテーブルを作成します。有効期限が切れた行のうち、日付が月曜日のものは削除されます。
```sql theme={null}
CREATE TABLE table_with_where
(
d DateTime,
a Int
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d
TTL d + INTERVAL 1 MONTH DELETE WHERE toDayOfWeek(d) = 1;
```
#### 期限切れの行を再圧縮するテーブルの作成:
```sql theme={null}
CREATE TABLE table_for_recompression
(
d DateTime,
key UInt64,
value String
) ENGINE MergeTree()
ORDER BY tuple()
PARTITION BY key
TTL d + INTERVAL 1 MONTH RECOMPRESS CODEC(ZSTD(17)), d + INTERVAL 1 YEAR RECOMPRESS CODEC(LZ4HC(10))
SETTINGS min_rows_for_wide_part = 0, min_bytes_for_wide_part = 0;
```
期限切れの行が集計されるテーブルを作成します。結果の行では、`x` にはグループ化された行の最大値、`y` には最小値、`d` にはグループ化された行のいずれかの値が入ります。
```sql theme={null}
CREATE TABLE table_for_aggregation
(
d DateTime,
k1 Int,
k2 Int,
x Int,
y Int
)
ENGINE = MergeTree
ORDER BY (k1, k2)
TTL d + INTERVAL 1 MONTH GROUP BY k1, k2 SET x = max(x), y = min(y);
```
### 期限切れデータの削除
`有効期限 (TTL)` により有効期限切れになったデータは、ClickHouse がデータパーツをマージするときに削除されます。
ClickHouse はデータの有効期限切れを検出すると、通常のスケジュール外でマージを実行します。この種のマージの頻度は、`merge_with_ttl_timeout` で制御できます。値が低すぎると、リソースを大量に消費するスケジュール外マージが頻繁に実行される可能性があります。
マージの合間に `SELECT` クエリを実行すると、期限切れのデータが返されることがあります。これを避けるには、`SELECT` の前に [OPTIMIZE](/docs/ja/reference/statements/optimize) クエリを使用してください。
**関連項目**
* [ttl\_only\_drop\_parts](/docs/ja/reference/settings/merge-tree-settings#ttl_only_drop_parts) 設定
## ディスクの種類
ローカルのブロックデバイスに加えて、ClickHouse は次のストレージタイプをサポートしています。
* [`s3` は S3 および MinIO 用](#table_engine-mergetree-s3)
* [`gcs` は GCS 用](/docs/ja/integrations/connectors/data-sources/gcs#creating-a-disk)
* [`blob_storage_disk` は Azure Blob Storage 用](/docs/ja/concepts/features/configuration/server-config/storing-data#azure-blob-storage)
* [`hdfs` は HDFS 用](/docs/ja/reference/engines/table-engines/integrations/hdfs)
* [`web` は Web からの読み取り専用用](/docs/ja/concepts/features/configuration/server-config/storing-data#web-storage)
* [`cache` はローカル cache 用](/docs/ja/concepts/features/configuration/server-config/storing-data#using-local-cache)
* [`s3_plain` は S3 へのバックアップ用](/docs/ja/concepts/features/backup-restore/local-disk)
* [`s3_plain_rewritable` は S3 上の不変な非レプリケートテーブル用](/docs/ja/concepts/features/configuration/server-config/storing-data#s3-plain-rewritable-storage)
## データ保存に複数のブロックデバイスを使用する
### はじめに
`MergeTree` ファミリーのテーブルエンジンでは、複数のブロックデバイスにデータを保存できます。たとえば、あるテーブルのデータが暗黙的に「ホット」と「コールド」に分かれている場合に役立ちます。最新のデータは頻繁に参照されますが、必要な容量はわずかです。一方、裾野の広い履歴データは参照頻度が低くなります。複数のディスクが利用可能な場合、「ホット」データは高速なディスク (たとえば NVMe SSD やメモリ) に配置し、「コールド」データは比較的低速なディスク (たとえば HDD) に配置できます。
これは、S3 やその他のオブジェクトストレージディスクを含む、すべてのディスク種別に当てはまります。たとえば、1 つのボリューム内で複数の S3 バケットにデータを分散したり、ローカルディスクから S3 にデータを移動する階層型ポリシーを作成したりできます。詳しくは、[複数のボリュームで S3 ディスクを使用する](#s3-multiple-volumes)を参照してください。
データパートは、`MergeTree` エンジンのテーブルにおける移動可能な最小単位です。1 つのパートに属するデータは 1 つのディスクに保存されます。データパートは、バックグラウンドで (ユーザー設定に従って) ディスク間を移動できるほか、[ALTER](/docs/ja/reference/statements/alter/partition) クエリを使用して移動することもできます。
### 用語
* ディスク — ファイルシステムにマウントされたブロックデバイス。
* デフォルトディスク — サーバー設定 [path](/docs/ja/reference/settings/server-settings/settings#path) で指定されたパスを保存するディスク。
* ボリューム — 同種のディスクを順序付けた集合 ([JBOD](https://en.wikipedia.org/wiki/Non-RAID_drive_architectures) に類似) 。
* ストレージポリシー — ボリュームの集合と、それらの間でデータを移動するためのルール。
ここで説明したエンティティの名前は、システムテーブル [system.storage\_policies](/docs/ja/reference/system-tables/storage_policies) および [system.disks](/docs/ja/reference/system-tables/disks) で確認できます。設定済みのストレージポリシーのいずれかをテーブルに適用するには、`MergeTree` エンジンファミリーのテーブルで `storage_policy` 設定を使用します。
### 設定
ディスク、ボリューム、ストレージポリシーは、`config.d` ディレクトリ内のファイルで `` タグ内に定義する必要があります。
ディスクは、クエリの `SETTINGS` セクションで定義することもできます。これは、
たとえば URL でホストされているディスクを一時的にアタッチして、その場限りの分析を行う場合に便利です。
詳細については、[dynamic storage](/docs/ja/concepts/features/configuration/server-config/storing-data#dynamic-configuration) を参照してください。
設定の構造:
```xml theme={null}
/mnt/fast_ssd/clickhouse/
/mnt/hdd1/clickhouse/
10485760
/mnt/hdd2/clickhouse/
10485760
...
...
```
タグ:
* `` — ディスク名。すべてのディスクで異なる名前にする必要があります。
* `path` — サーバーがデータ (`data` および `shadow` フォルダー) を保存するパス。末尾は '/' で終わる必要があります。
* `keep_free_space_bytes` — 予約しておく空きディスク容量。
ディスク定義の順序は重要ではありません。
ストレージポリシー設定のマークアップ:
```xml theme={null}
...
disk_name_from_disks_configuration
1073741824
round_robin
0.2
...
```
タグ:
* `policy_name_N` — ポリシー名。ポリシー名は一意である必要があります。
* `volume_name_N` — ボリューム名。ボリューム名は一意である必要があります。
* `disk` — ボリューム内のディスク。
* `max_data_part_size_bytes` — ボリューム内の任意のディスクに保存できるパーツの最大サイズ。マージ後のパーツの推定サイズが `max_data_part_size_bytes` を超える場合、そのパーツは次のボリュームに書き込まれます。つまり、この機能を使うと、新しい小さなパーツはホット (SSD) ボリュームに保持し、十分に大きくなったらコールド (HDD) ボリュームに移動できます。ポリシー内のボリュームが 1 つだけの場合、この設定は使用しないでください。
* `move_factor` — 利用可能な空き容量がこの係数を下回ると、データは自動的に次のボリューム (存在する場合) へ移動し始めます (デフォルトは 0.1)。ClickHouse は既存のパーツをサイズの大きい順 (降順) にソートし、`move_factor` の条件を満たすのに十分な合計サイズとなるパーツを選択します。すべてのパーツの合計サイズでも不足する場合は、すべてのパーツが移動されます。
* `perform_ttl_move_on_insert` — データパーツの INSERT 時に TTL による移動を無効にします。デフォルトでは (有効時)、TTL move ルールですでに期限切れになっているデータパーツを insert すると、move ルールで指定されたボリューム/ディスクに即座に書き込まれます。宛先のボリューム/ディスクが低速な場合 (たとえば S3)、insert が大幅に遅くなる可能性があります。無効にすると、すでに期限切れのデータパーツはいったんデフォルトのボリュームに書き込まれ、その直後に TTL ボリュームへ移動されます。
* `load_balancing` - ディスクの負荷分散ポリシー。`round_robin` または `least_used`。
* `least_used_ttl_ms` - すべてのディスクの利用可能な空き容量を更新する timeout (ミリ秒) を設定します (`0` - 常に更新、`-1` - 更新しない、デフォルトは `60000`)。なお、そのディスクを ClickHouse だけが使用し、オンラインで filesystem の拡張/縮小が行われない場合は `-1` を使用できます。それ以外の場合は推奨されません。最終的に空き容量の配分が不正確になるためです。
* `prefer_not_to_merge` — この設定は使用しないでください。このボリューム上でのデータパーツのマージを無効にします (有害であり、パフォーマンス低下につながります)。この設定を有効にすると (しないでください)、このボリューム上でのデータのマージは許可されなくなります (望ましくありません)。これにより ClickHouse の低速ディスクの扱いを制御できますが、その必要はありません。ClickHouse に任せるべきなので、この設定は使わないでください。
* `volume_priority` — ボリュームが使用される優先順位 (順序) を定義します。値が小さいほど優先順位は高くなります。パラメータ値は自然数で、1 から N までの範囲を欠番なしで全体としてカバーしている必要があります (N が最も低い優先順位)。
* *すべての* ボリュームにタグが付いている場合、指定された順序で優先されます。
* *一部の* ボリュームにのみタグが付いている場合、タグのないボリュームが最も低い優先順位となり、config で定義された順序で優先されます。
* *どの* ボリュームにもタグが付いていない場合、優先順位は configuration で宣言された順序に応じて設定されます。
* 2 つのボリュームに同じ優先順位の値を設定することはできません。
設定例:
```xml theme={null}
...
disk1
disk2
fast_ssd
1073741824
disk1
0.2
jbod1
external
...
```
この例では、`hdd_in_order` ポリシーは [ラウンドロビン](https://en.wikipedia.org/wiki/Round-robin_scheduling) 方式を実装しています。つまり、このポリシーでは 1 つのボリューム (`single`) だけを定義し、データパーツはその配下のすべてのディスクに順番に格納されます。このようなポリシーは、同種のディスクがシステムに複数マウントされている一方で、RAID が構成されていない場合に特に有用です。ただし、個々のディスクドライブ自体の信頼性は高くないため、レプリケーション係数を 3 以上にして補うことを検討してください。
システムで異なる種類のディスクが利用できる場合は、代わりに `moving_from_ssd_to_hdd` ポリシーを使用できます。`hot` ボリュームは SSD ディスク (`fast_ssd`) で構成されており、このボリュームに格納できるパーツの最大サイズは 1GB です。サイズが 1GB を超えるすべてのパーツは、HDD ディスク `disk1` を含む `cold` ボリュームに直接格納されます。
また、`fast_ssd` ディスクの使用率が 80% を超えると、バックグラウンドプロセスによってデータが `disk1` に移動されます。
ストレージポリシー内でのボリュームの列挙順は、一覧にあるボリュームの少なくとも 1 つに明示的な `volume_priority` パラメータがない場合に重要になります。
ボリュームの容量が上限に達すると、データは次のボリュームへ移動されます。ディスクの列挙順も同様に重要です。データはそれらのディスクに順番に格納されるためです。
テーブルの作成時には、設定済みのストレージポリシーのいずれか 1 つを適用できます。
```sql theme={null}
CREATE TABLE table_with_non_default_policy (
EventDate Date,
OrderID UInt64,
BannerID UInt64,
SearchPhrase String
) ENGINE = MergeTree
ORDER BY (OrderID, BannerID)
PARTITION BY toYYYYMM(EventDate)
SETTINGS storage_policy = 'moving_from_ssd_to_hdd'
```
`default` ストレージポリシーは、`` で指定された 1 つのディスクだけで構成される、1 つのボリュームのみを使用することを意味します。
テーブル作成後でも、\[ALTER TABLE ... MODIFY SETTING] クエリを使用してストレージポリシーを変更できます。新しいポリシーには、同じ名前の既存のすべてのディスクとボリュームが含まれている必要があります。
データパーツのバックグラウンド移動を実行するスレッド数は、[background\_move\_pool\_size](/docs/ja/reference/settings/server-settings/settings#background_move_pool_size) 設定で変更できます。
### 詳細
`MergeTree` テーブルでは、データはさまざまな方法でディスクに書き込まれます。
* insert (`INSERT` クエリ) の結果として。
* バックグラウンドのマージおよび[mutations](/docs/ja/reference/statements/alter/index#mutations)の実行時。
* 別のレプリカからダウンロードするとき。
* パーティションの凍結 [ALTER TABLE ... FREEZE PARTITION](/docs/ja/reference/statements/alter/partition#freeze-partition) の結果として。
これらのケースのうち、mutations とパーティションの凍結を除いて、パーツは指定されたストレージポリシーに従ってボリュームとディスクに保存されます。
1. パーツを保存するのに十分なディスク容量があり (`unreserved_space > current_part_size`) 、かつ指定サイズのパーツの保存が許可されている (`max_data_part_size_bytes > current_part_size`) 最初のボリューム (定義順) が選択されます。
2. このボリューム内では、直前のデータ chunk の保存に使用されたディスクの次にあたり、かつパーツサイズを上回る空き容量がある (`unreserved_space - keep_free_space_bytes > current_part_size`) ディスクが選択されます。
内部的には、mutations とパーティションの凍結には[ハードリンク](https://en.wikipedia.org/wiki/Hard_link)が使われます。異なるディスク間のハードリンクはサポートされていないため、このような場合、生成されるパーツは元のパーツと同じディスクに保存されます。
バックグラウンドでは、パーツは空き容量の量 (`move_factor` パラメータ) に基づき、設定ファイルで宣言されたボリュームの順序に従ってボリューム間を移動します。
データが最後のボリュームから転送されたり、最初のボリュームに転送されたりすることはありません。バックグラウンドでの移動の監視には、システムテーブル [system.part\_log](/docs/ja/reference/system-tables/part_log) (フィールド `type = MOVE_PART`) および [system.parts](/docs/ja/reference/system-tables/parts) (フィールド `path` と `disk`) を使用できます。また、詳細な情報はサーバーログでも確認できます。
ユーザーは、クエリ [ALTER TABLE ... MOVE PART|PARTITION ... TO VOLUME|DISK ...](/docs/ja/reference/statements/alter/partition) を使用して、パーツまたはパーティションをあるボリュームから別のボリュームへ強制的に移動できます。この場合も、バックグラウンド処理に対するすべての制限が考慮されます。このクエリは独自に移動を開始し、バックグラウンド処理の完了は待機しません。十分な空き容量がない場合や、必要な条件のいずれかが満たされていない場合、ユーザーはエラーメッセージを受け取ります。
データの移動はデータのレプリケーションに影響しません。したがって、同じテーブルに対して異なるレプリカごとに別々のストレージポリシーを指定できます。
バックグラウンドのマージおよび mutations の完了後、古いパーツが削除されるのは一定時間 (`old_parts_lifetime`) が経過してからです。
この間、それらが他のボリュームやディスクに移動されることはありません。したがって、パーツが最終的に削除されるまでは、使用済みディスク容量の評価対象に引き続き含まれます。
ユーザーは、[min\_bytes\_to\_rebalance\_partition\_over\_jbod](/docs/ja/reference/settings/merge-tree-settings#min_bytes_to_rebalance_partition_over_jbod) 設定を使用して、[JBOD](https://en.wikipedia.org/wiki/Non-RAID_drive_architectures) ボリューム内の異なるディスクに新しい大きなパーツをバランスよく割り当てることができます。
## データ保存に外部ストレージを使用する
[MergeTree](/docs/ja/reference/engines/table-engines/mergetree-family/mergetree) ファミリーのテーブルエンジンでは、タイプがそれぞれ `s3`、`azure_blob_storage`、`hdfs` のディスクを使用して、データを `S3`、`AzureBlobStorage`、`HDFS` に保存できます。詳細については、[外部ストレージオプションの設定](/docs/ja/concepts/features/configuration/server-config/storing-data#configuring-external-storage)を参照してください。
タイプが `s3` のディスクを使用して、[S3](https://aws.amazon.com/s3/) を外部ストレージとして利用する例を示します。
設定マークアップ:
```xml theme={null}
...
s3
true
https://clickhouse-public-datasets.s3.amazonaws.com/my-bucket/root-path/
your_access_key_id
your_secret_access_key
Authorization: Bearer SOME-TOKEN
your_base64_encoded_customer_key
your_kms_key_id
your_kms_encryption_context
true
http://proxy1
http://proxy2
10000
5000
10
4
1000
/var/lib/clickhouse/disks/s3/
false
cache
s3
/var/lib/clickhouse/disks/s3_cache/
10Gi
...
```
あわせて参照 [外部ストレージ オプションの設定](/docs/ja/concepts/features/configuration/server-config/storing-data#configuring-external-storage)。
### 複数のボリュームで S3 ディスクを使用する
S3 (およびその他のオブジェクトストレージ) ディスクは、ローカルディスクと同様に、マルチディスクおよびマルチボリュームのストレージポリシーで使用できます。これにより、単一のボリューム内で複数の S3 バケットにデータを分散させる (JBOD 形式) ことや、S3 ボリュームを使用した階層型ストレージポリシーを設定したりできます。
たとえば、2 つの S3 バケットにラウンドロビン方式でデータを分散させるには、次のようにします。
```xml theme={null}
s3
https://s3.amazonaws.com/bucket-1/data/
your_access_key_id
your_secret_access_key
s3
https://s3.amazonaws.com/bucket-2/data/
your_access_key_id
your_secret_access_key
s3_bucket1
s3_bucket2
```
ローカルボリュームとS3ボリュームは、階層型ポリシーで組み合わせることもできます。たとえば、データの経過に応じてローカルSSDからS3へ移動するようにできます:
```xml theme={null}
/mnt/fast_ssd/clickhouse/
s3
https://s3.amazonaws.com/cold-storage/data/
your_access_key_id
your_secret_access_key
local_ssd
1073741824
s3_cold
0.2
```
S3 認証で `use_environment_credentials` を使用する場合、環境認証情報 (`AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY`、`AWS_SESSION_TOKEN`) はすべての S3 ディスクで共有されます。ディスクごとに異なる環境認証情報を使用することはできません。S3 ディスクごとに異なる認証情報が必要な場合は、代わりに各ディスクで `access_key_id` と `secret_access_key` を明示的に設定してください。
共有ストレージ上では、1 つのライターと多数のリーダーという構成で、レプリケーションなしの MergeTree テーブルをセットアップできます。これは、リーダー側で設定できるパーツ一覧の自動更新によって実現されます。これには、レプリカ間でファイルシステムのメタデータが共有されていること (または、テーブルローカルなディスクで `table_disk = true` を使用すること) が必要です。[refresh\_parts\_interval and table\_disk](/docs/ja/concepts/features/configuration/server-config/storing-data#refresh-parts-interval-and-table-disk) を参照してください。
**cache 構成**
ClickHouse のバージョン 22.3 から 22.7 では、異なる cache 構成が使用されます。これらのバージョンを使用している場合は、[using local cache](/docs/ja/concepts/features/configuration/server-config/storing-data#using-local-cache) を参照してください。
## 仮想カラム
* `_part` — パート名。
* `_part_index` — クエリ結果内のパートの連番インデックス。
* `_part_starting_offset` — クエリ結果内における、そのパートの累積開始行。
* `_part_offset` — パート内の行番号。
* `_part_granule_offset` — パート内のグラニュール番号。
* `_partition_id` — パーティション名。
* `_part_uuid` — パートの一意な識別子 (MergeTree setting `assign_part_uuids` が有効な場合) 。
* `_part_data_version` — パートのデータバージョン (最小ブロック番号または mutation バージョン) 。
* `_partition_value` — `partition by` 式の値 (タプル) 。
* `_sample_factor` — サンプル係数 (クエリ由来) 。
* `_block_number` — insert 時に行へ割り当てられた元の block 番号。setting `enable_block_number_column` が有効な場合、merge 後も保持されます。
* `_block_offset` — insert 時に block 内の行へ割り当てられた元の行番号。setting `enable_block_offset_column` が有効な場合、merge 後も保持されます。
* `_disk_name` — ストレージに使用されるディスク名。
## カラム STATISTICS
統計の宣言は、`*MergeTree*` ファミリーのテーブルに対する `CREATE` クエリのカラム定義セクションで行います。
```sql theme={null}
CREATE TABLE tab
(
a Int64 STATISTICS(tdigest, uniq),
b Float64
)
ENGINE = MergeTree
ORDER BY a
```
`ALTER` 文を使って統計情報を操作することもできます:
```sql theme={null}
ALTER TABLE tab ADD STATISTICS b TYPE tdigest, uniq;
ALTER TABLE tab DROP STATISTICS a;
```
これらの軽量な統計は、カラム内の値の分布に関する情報を集約したものです。統計は各パートに保存され、INSERT のたびに更新されます。
これらは、`set use_statistics = 1` を有効にした場合にのみ、PREWHERE 最適化に使用できます。
#### 統計情報を用いたパーツ剪枝
`use_statistics_for_part_pruning` が有効になっている場合、統計情報をパーツ剪枝に利用できます。
現在、パーツ剪枝に対応しているのは `basic` 統計情報 (および非推奨の `minmax` 統計情報) のみです。このような統計情報がカラムに定義されている場合、ClickHouse は各パーツについてそのカラムの最小値と最大値を追跡します。
パーツ剪枝では、そのパーツ内のどの行もクエリのフィルタ条件に一致しないことが分かっている場合、データパーツ全体の読み取りをスキップできます。
**例:**
```sql theme={null}
-- Create a table with basic statistics on the 'value' column
CREATE TABLE test_stats
(
id UInt64,
value Int64 STATISTICS(basic)
)
ENGINE = MergeTree
ORDER BY id;
SYSTEM STOP MERGES test_stats;
-- Insert data in separate inserts to create multiple parts
INSERT INTO test_stats SELECT number, number FROM numbers(1000); -- Part 1: value range [0, 999]
INSERT INTO test_stats SELECT number, number + 10000 FROM numbers(1000); -- Part 2: value range [10000, 10999]
SET use_statistics_for_part_pruning = 1;
-- This query will skip Part 1 entirely because its max value (999) < 5000
SELECT count() FROM test_stats WHERE value > 5000;
-- Use EXPLAIN to see the pruning effect
EXPLAIN indexes = 1 SELECT count() FROM test_stats WHERE value > 5000;
-- The output will show "Parts: 1/2" indicating one part was pruned
```
### 利用可能なカラム STATISTICS の種類
* `basic`
カラムから導出される単一値サマリーをコンパクトにまとめたものです。カラム型に応じて、次の情報が格納されます:
* 値が数値で表現される任意のカラム (整数、浮動小数点数、`Decimal*`、`Date*`、`DateTime*`、`Enum*`、`IPv4` など) の場合: 最小値と最大値。これにより、範囲フィルターの選択性を推定でき、パーツ剪枝も可能になります。
* `String` および `FixedString` カラムの場合: `NULL` ではない値の合計バイト長 (ここから平均文字列長を導き出せます) 。
* `Nullable` および `LowCardinality(Nullable)` カラムの場合: `NULL` 値の件数。オプティマイザはこれを使って、選択性の推定から `NULL` 行を除外します。
単一の `basic` 統計で、これらのうち複数を同時に格納できます。たとえば `Nullable(UInt32)` カラムでは、数値の最小値/最大値と `NULL` 件数の両方を追跡します。`minmax` と比べると、`basic` は `String` / `FixedString` カラムでも利用でき、`UUID` や `IPv6` のような型の `Nullable` ラッパーに対しても、`NULL` 件数だけを追跡する目的で宣言できます。
* `minmax` (非推奨)
`minmax` 統計は非推奨であり、現在は作成できません (`CREATE TABLE ... STATISTICS(minmax)` および `ALTER TABLE ... ADD/MODIFY STATISTICS ... TYPE minmax` はエラーを返します)。`minmax` 統計を持つ既存のテーブルおよびパーツは引き続き動作します。代わりに `basic` 統計を使用してください。
* `tdigest`
`tdigest` 型の統計は作成コストが高く、データの取り込みが遅くなる可能性があります。
数値カラムの近似パーセンタイル (例: 90 パーセンタイル) を計算できる [TDigest](https://github.com/tdunning/t-digest) スケッチです。
* `uniq`
カラムに含まれる異なる値の数を推定できる [BJKST](https://people.iith.ac.in/aravind/Files-CS5120/pc-lec14-BJKST.pdf) スケッチです。内部では [`uniq`](/docs/ja/reference/functions/aggregate-functions/uniq) を使用します。
* `uniq_v2`
`uniq` と似ていますが、内部では [`uniqCombined`](/docs/ja/reference/functions/aggregate-functions/uniqCombined)`(12)` ([HyperLogLog](https://en.wikipedia.org/wiki/HyperLogLog) の一種) を使用します。`uniq` より少ないメモリで済み、より高速にビルドできます。
* `countmin`
`countmin` 型の統計は作成コストが高く、データの取り込みが遅くなる可能性があります。
カラム内の各値の出現頻度を近似的に数えられる [CountMin](https://en.wikipedia.org/wiki/Count%E2%80%93min_sketch) スケッチです。
### サポートされているデータ型
| | (U)Int\*, Float\*, Decimal(*), Date*, Boolean, Enum\* | IPv4 | String or FixedString |
| -------- | ----------------------------------------------------- | ---- | --------------------- |
| basic | ✔ | ✔ | ✔ |
| countmin | ✔ | ✔ | ✔ |
| minmax | ✔ | ✔ | ✗ |
| tdigest | ✔ | ✗ | ✗ |
| uniq | ✔ | ✔ | ✔ |
| uniq\_v2 | ✔ | ✔ | ✔ |
上記はいずれも、列挙された型の `Nullable` および `LowCardinality(Nullable)` ラッパーを受け付けます。`Basic` はさらに、null の件数のみを追跡する目的で、`UUID` や `IPv6` などの型の `Nullable` ラッパーに対して宣言することもできます。
### サポートされる操作
| | 等値フィルター (==) | 範囲フィルター (`>, >=, <, <=`) |
| -------- | ------------ | ------------------------ |
| basic | ✗ | ✔ (数値カラムのみ) |
| countmin | ✔ | ✗ |
| minmax | ✗ | ✔ (数値カラムのみ) |
| tdigest | ✗ | ✔ (数値カラムのみ) |
| uniq | ✔ | ✗ |
| uniq\_v2 | ✔ | ✗ |
`String` / `FixedString` カラムに対する `basic` では、統計情報として記録されるのは、非 NULL の合計
バイト長 (平均文字列長の推定に使用) と NULL の件数のみです。
範囲フィルターやパーツ剪枝には使用されません。
## カラムレベルの設定
一部のMergeTree設定は、カラムレベルで上書きできます：
* `max_compress_block_size` — テーブルに書き込む際、圧縮前の非圧縮データブロックの最大サイズ。
* `min_compress_block_size` — 次のマークを書き込む際に圧縮を行うために必要な、非圧縮データブロックの最小サイズ。
例：
```sql theme={null}
CREATE TABLE tab
(
id Int64,
document String SETTINGS (min_compress_block_size = 16777216, max_compress_block_size = 16777216)
)
ENGINE = MergeTree
ORDER BY id
```
カラムレベルの設定は、たとえば [ALTER MODIFY COLUMN](/docs/ja/reference/statements/alter/column) を使用して変更または削除できます。
* カラム定義から `SETTINGS` を削除するには、次のようにします:
```sql theme={null}
ALTER TABLE tab MODIFY COLUMN document REMOVE SETTINGS;
```
* 設定を変更する:
```sql theme={null}
ALTER TABLE tab MODIFY COLUMN document MODIFY SETTING min_compress_block_size = 8192;
```
* 1 つ以上の設定をリセットし、テーブルの CREATE クエリ内のカラム式にある設定宣言も削除します。
```sql theme={null}
ALTER TABLE tab MODIFY COLUMN document RESET SETTING min_compress_block_size;
```