MergeTree エンジンおよび MergeTree ファミリーの他のエンジン (例: ReplacingMergeTree、AggregatingMergeTree) は、ClickHouse で最も広く使われている、最も堅牢なテーブルエンジンです。
MergeTree-family table engines は、高いデータ取り込みレートと膨大なデータ量に対応できるように設計されています。
insert 操作ではテーブルパーツが作成され、これらはバックグラウンドプロセスによって他のテーブルパーツとマージされます。
MergeTree-family table engines の主な特長:
- テーブルの主キーは、各テーブルパーツ内のソート順 (クラスター化索引) を決定します。また、主キーは個々の行ではなく、granules と呼ばれる 8192 行のブロックを参照します。これにより、巨大なデータセットの主キーでもメインメモリに保持できるほど小さく保ちながら、ディスク上のデータに高速にアクセスできます。
- テーブルは任意の partition expression を使ってパーティション化できます。partition pruning により、クエリで可能な場合は対象のパーティションの読み取りが省略されます。
- データは、高可用性、フェイルオーバー、無停止アップグレードを実現するために、複数のクラスター ノード間でレプリケーションできます。詳しくは Data replication を参照してください。
-
MergeTreetable engines は、クエリ最適化に役立つさまざまな statistics の種類や sampling 手法をサポートしています。
名前は似ていますが、Merge エンジンは
*MergeTree エンジンとは別物です。テーブルの作成
クエリの句
ENGINE
ENGINE — エンジンの名前とパラメータです。ENGINE = MergeTree(). MergeTree エンジンにはパラメータはありません。
ORDER BY
ORDER BY — ソートキーです。
カラム名または任意の式からなるタプル。例: ORDER BY (CounterID + 1, EventDate)。
主キーが定義されていない場合 (つまり PRIMARY KEY が指定されていない場合) 、ClickHouse はソートキーを主キーとして使用します。
ソートが不要な場合は、ORDER BY tuple() 構文を使用できます。
また、設定 create_table_empty_primary_key_by_default が有効な場合は、CREATE TABLE ステートメントに ORDER BY () が暗黙的に追加されます。主キーの選択を参照してください。
PARTITION BY
PARTITION BY — パーティションキーです。省略可能です。ほとんどの場合、パーティションキーは必要ありません。パーティション化が必要な場合でも、通常は月単位より細かいパーティションキーは不要です。パーティション化によってクエリが高速化されることはありません (ORDER BY 式とは対照的です) 。細かすぎるパーティション化は絶対に避けてください。クライアント識別子や名前でデータをパーティション化しないでください (代わりに、クライアント識別子または名前を ORDER BY 式の先頭のカラムにしてください) 。
月単位でパーティション化するには、toYYYYMM(date_column) 式を使用します。ここで、date_column は Date 型の日付カラムです。この場合のパーティション名は "YYYYMM" フォーマットになります。
PRIMARY KEY — ソートキーと異なる場合の主キーです。省略可能です。
ソートキー (ORDER BY 句) を指定すると、主キーも暗黙的に指定されます。
通常は、ソートキーとは別に主キーを指定する必要はありません。
SAMPLE BY
SAMPLE BY — サンプリング式。省略可能です。
指定する場合は、主キーに含まれている必要があります。
サンプリング式の結果は、符号なし整数でなければなりません。
例: SAMPLE BY intHash32(UserID) ORDER BY (CounterID, EventDate, intHash32(UserID)).
有効期限 (TTL)
TTL — 行の保存期間と、ディスクおよびボリューム間でのパーツの自動移動のロジックを指定するルールの一覧です。省略可能です。
式は Date または DateTime になる必要があります。例: TTL date + INTERVAL 1 DAY。
ルールの型 DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'|GROUP BY は、式の条件が満たされた場合 (現在時刻に達した場合) に、そのパーツに対して実行するアクションを指定します。具体的には、期限切れの行の削除、パーツの移動 (パーツ内のすべての行で式が満たされた場合) を指定したディスク (TO DISK 'xxx') またはボリューム (TO VOLUME 'xxx') へ行うこと、あるいは期限切れの行の値を集計することです。ルールのデフォルトの型は削除 (DELETE) です。複数のルールを指定できますが、DELETE ルールは 1 つまでです。
詳細は、カラムおよびテーブルの TTL を参照してください
設定
CounterID と EventDate ごとに疑似ランダム化できます。データを選択する際に SAMPLE 句を指定すると、ClickHouse はユーザーの一部に対して、均等に疑似ランダム化されたデータサンプルを返します。
index_granularity 設定は、8192 がデフォルト値なので省略できます。
データストレージ
(CounterID, Date) の場合、パーツ内のデータは CounterID でソートされ、各 CounterID ごとに Date の順で並びます。
異なるパーティションに属するデータは、別々のパーツに分けて格納されます。ClickHouse は、より効率よく保存できるよう、バックグラウンドでデータパーツをマージします。異なるパーティションに属するパーツ同士はマージされません。なお、このマージの仕組みによって、同じ主キーを持つすべての行が同じデータパーツに入ることが保証されるわけではありません。
データパーツは Wide または Compact フォーマットで保存できます。Wide フォーマットでは各カラムがファイルシステム上の個別のファイルに保存され、Compact フォーマットではすべてのカラムが 1 つのファイルに保存されます。Compact フォーマットは、小さなデータを高頻度で挿入する場合のパフォーマンス向上に利用できます。
データの保存フォーマットは、テーブルエンジンの min_bytes_for_wide_part および min_rows_for_wide_part 設定によって制御されます。データパーツ内のバイト数または行数が対応する設定値より小さい場合、そのパーツは Compact フォーマットで保存されます。それ以外の場合は Wide フォーマットで保存されます。これらの設定がどちらも設定されていない場合、データパーツは Wide フォーマットで保存されます。
各データパーツは、論理的に granule に分割されます。granule は、ClickHouse がデータを選択する際に読み取る最小の不可分なデータセットです。ClickHouse は行や値を分割しないため、各 granule には常に整数個の行が含まれます。granule の先頭行には、その行の主キーの値が mark として記録されます。各データパーツについて、ClickHouse は mark を保存する索引ファイルを作成します。さらに、主キーに含まれるかどうかにかかわらず、各カラムについても同じ mark が保存されます。これらの mark によって、カラムファイル内のデータを直接見つけることができます。
granule のサイズは、テーブルエンジンの index_granularity および index_granularity_bytes 設定によって制限されます。granule 内の行数は、行のサイズに応じて [1, index_granularity] の範囲になります。1 行のサイズが設定値より大きい場合、granule のサイズが index_granularity_bytes を超えることがあります。この場合、granule のサイズはその行のサイズと等しくなります。
クエリにおける主キーと索引
(CounterID, Date) を主キーの例として考えます。この場合のソート順と索引は、次のようになります。
CounterID in ('a', 'h')の場合、サーバーはマークの範囲[0, 3)および[6, 8)のデータを読み取ります。CounterID IN ('a', 'h') AND Date = 3の場合、サーバーはマークの範囲[1, 3)および[7, 8)のデータを読み取ります。Date = 3の場合、サーバーはマークの範囲[1, 10]のデータを読み取ります。
index_granularity * 2 行の余分な行が読み取られる可能性があります。
スパースインデックスを使用すると、非常に多くのテーブルの行を扱えます。これは、ほとんどの場合、このような索引がコンピューターの RAM に収まるためです。
ClickHouse では、一意な主キーは必須ではありません。同じ主キーを持つ複数の行を挿入できます。
PRIMARY KEY 句および ORDER BY 句では Nullable 型の式を使用できますが、これは強く非推奨です。この機能を有効にするには、allow_nullable_key 設定を有効にしてください。ORDER BY 句の NULL 値には、NULLS_LAST の原則が適用されます。
主キーの選択
-
索引の性能を向上できる。
主キーが
(a, b)の場合、次の条件を満たしていれば、さらにカラムcを追加することで性能が向上します。- カラム
cに対する条件を含むクエリがある。 (a, b)に同じ値を持つ長いデータ範囲 (index_granularityの数倍の長さ) がよくある。つまり、別のカラムを追加することで、かなり長いデータ範囲をスキップできる場合です。
- カラム
- データ圧縮を改善できる。 ClickHouse は主キーでデータをソートするため、一貫性が高いほど圧縮効率も向上します。
- CollapsingMergeTree および SummingMergeTree エンジンでデータパーツをマージする際に、追加のロジックを利用できる。 この場合は、主キーとは異なる ソートキー を指定するのが適切です。
SELECT クエリ実行時の ClickHouse の性能には影響しません。
ORDER BY tuple() 構文を使用すると、主キーなしでテーブルを作成できます。この場合、ClickHouse はデータを挿入順に格納します。INSERT ... SELECT クエリでデータを挿入する際にデータの順序を保持したい場合は、max_insert_threads = 1 を設定してください。
初期の順序でデータを選択するには、single-threaded SELECT クエリを使用します。
ソートキーと異なる主キーを選択する
GROUP BY と次元によるフィルタリングを用いて、メジャーカラムの値を集約します。SummingMergeTree と AggregatingMergeTree は、ソートキーの値が同じ行を集約するため、そこにすべての次元を追加するのが自然です。その結果、キー式は長いカラム一覧で構成されることになり、新たな次元が追加されるたびにこの一覧を頻繁に更新しなければなりません。
このような場合は、効率的な範囲スキャンに必要な少数のカラムだけを主キーに残し、残りの次元カラムをソートキーのタプルに追加するのが合理的です。
ソートキーの ALTER は軽量な操作です。これは、新しいカラムをテーブルとソートキーに同時に追加しても、既存のパーツを変更する必要がないためです。古いソートキーは新しいソートキーのプレフィックスであり、新たに追加されたカラムにはデータが存在しないため、テーブルの変更時点ではデータは古いソートキーと新しいソートキーの両方に対してソート済みの状態になっています。
クエリにおける索引とパーティションの利用
SELECTクエリでは、ClickHouse は索引を利用できるかどうかを解析します。WHERE/PREWHERE 句に、等価比較または不等価比較を表す式が (AND 条件の一部として、または式全体として) 含まれている場合や、主キーまたはパーティションキーに含まれるカラムや式、それらのカラムに対する特定の部分反復的な関数、あるいはそれらの式の論理的な組み合わせに対して、固定プレフィックス付きの IN または LIKE が含まれている場合は、索引を利用できます。
そのため、主キーの1つまたは複数の範囲に対するクエリを高速に実行できます。この例では、特定のトラッキングタグ、特定のタグと日付範囲、特定のタグと日付、複数のタグと日付範囲などを条件にしたクエリは高速に実行されます。
次のように設定されたエンジンを見てみましょう。
主キー内の決定論的な式に対する索引の利用
length(), toDate(), lower(), left(), cityHash64(), toUUID()。now() や rand() とは異なります) 。主キーに決定論的な式が含まれている場合、ClickHouse はそれらをクエリ内の定数値に適用し、その結果を使って主キー索引に対する条件を構築できます。これにより、=, IN, has のような述語でデータスキッピングを行えるようになります。
一般的なユースケースとしては、主キーをコンパクトに保ちつつ (たとえば、長い String の代わりにハッシュを保存する) 、元のカラムに対する述語でも索引を利用できるようにすることが挙げられます。
決定論的 (ただし単射ではない) な主キーの例:
length('alice') (および他の定数) を一度だけ計算し、その長さの値を使って主キー索引内の範囲を絞り込みます。文字列の長さは単射ではないため、異なる user_id 文字列が同じ長さになることがあり、その結果、索引が余分なグラニュール (偽陽性) を読み込む可能性があります。元の述語 (user_id = ...、IN など) は読み込み後にも引き続き適用されるため、結果は正しいままです。
決定論的な式がさらに単射でもある場合 (使用される引数の型において、異なる入力が同じ出力を生成しない場合) 、ClickHouse は否定形の !=、NOT IN、NOT has(...) に対しても索引を効果的に利用できます。たとえば、reverse(p) と hex(p) は String に対して単射です。
単射な主キーの例:
部分単調な主キーに対する索引の使用
データスキッピングインデックス
CREATEクエリのカラムセクションで行います。
*MergeTree ファミリーのテーブルでは、データスキッピングインデックスを指定できます。
これらの索引は、指定した式について、granularity_value 個の granule で構成される block ごとの情報を集約します (granule のサイズは、テーブルエンジンの index_granularity 設定で指定します) 。その後、これらの集約情報は SELECT クエリで使用され、where 条件を満たしえない大きなデータ block をスキップすることで、ディスクから読み取るデータ量を削減します。
GRANULARITY 句は省略でき、granularity_value のデフォルト値は 1 です。
例
スキップ索引の種類
MergeTree テーブルエンジンは、次の種類のスキップ索引をサポートしています。
スキップ索引をパフォーマンス最適化にどのように活用できるかについて詳しくは、
“ClickHouseのデータスキッピングインデックスを理解する”
を参照してください。
MinMax索引Set索引bloom_filter索引ngrambf_v1索引 (非推奨)tokenbf_v1索引 (非推奨)text索引vector_similarity索引
MinMax スキップ索引
tuple の場合は、各タプル要素について最小値と最大値を格納します。)
Syntax
Set
max_rows 個まで格納できます。
max_rows = 0 は “すべての一意な値を格納する” ことを意味します。
Syntax
ブルームフィルタ
Syntax
false_positive_rate パラメータには 0 から 1 までの値を指定でき (デフォルトは 0.025) 、陽性判定が発生する確率を指定します (この値が増えると、読み取るデータ量も増加します) 。
次のデータ型がサポートされています。
(U)Int*Float*EnumDateDateTimeStringFixedStringArrayLowCardinalityNullableUUIDMap
JSON データ型: JSON パスの索引作成
JSON データ型では、JSONAllPaths 関数を使用して、パスの集合に bloom filter 索引を作成できます。これにより、クエリ対象の JSON パスが存在しない granule をスキップできます。詳細については、JSON のデータスキッピングインデックス を参照してください。N-gramブルームフィルタ (非推奨)
ClickHouseバージョン26.2で
text 索引が一般提供 (GA) となったため、ngrambf_v1 索引は全文検索には推奨されなくなりました。詳細については、“テキスト索引による全文検索” のページを参照してください。Syntax
| Parameter | Description |
|---|---|
n | ngram のサイズ |
size_of_bloom_filter_in_bytes | ブルームフィルタのサイズ (バイト単位) 。圧縮効率が高いため、ここでは 256 や 512 のような大きな値を使用できます。 |
number_of_hash_functions | ブルームフィルタで使用するハッシュ関数の数。 |
random_seed | ブルームフィルタのハッシュ関数に使用するシード。 |
ngrambf_v1 のパラメータを見積もるには、次の User Defined Functions (UDFs) を使用できます。
UDFs for ngrambf_v1
total_number_of_all_gramsprobability_of_false_positives
4300 個の N-gram が含まれており、偽陽性率を 0.0001 未満にしたいとします。
その場合、残りのパラメータは次のクエリを実行して推定できます。
トークンブルームフィルタ
ClickHouse 26.2 で
text 索引が一般提供 (GA) されたため、tokenbf_v1 索引は全文検索では推奨されなくなりました。詳細は”テキスト索引を使用した全文検索”のページを参照してください。Syntax
スパースグラム・ブルームフィルタ
ngrambf_v1 に似ていますが、N-gram の代わりに スパースグラムトークン を使用します。
Syntax
テキスト索引
ベクトル類似度
関数のサポート
WHERE 句の条件には、カラムに対して動作する関数呼び出しが含まれます。カラムが索引の一部である場合、ClickHouse はそれらの関数の実行時にこの索引を使用しようとします。ClickHouse は、索引の利用に対応する関数の部分集合を複数サポートしています。
set 型の索引は、すべての関数で利用できます。その他の索引型については、以下の関数がサポートされています。
| 関数 (operator) / 索引 | 主キー | minmax | ngrambf_v1 | tokenbf_v1 | bloom_filter | sparse_grams | text |
|---|---|---|---|---|---|---|---|
| 等しい (=, ==) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| notEquals(!=, <>) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✗ |
| like | ✔ | ✔ | ✔ | ✔ | ✗ | ✔ | ✔ |
| notLike | ✔ | ✔ | ✔ | ✔ | ✗ | ✔ | ✗ |
| match | ✗ | ✗ | ✔ | ✔ | ✗ | ✔ | ✔ |
| startsWith | ✔ | ✔ | ✔ | ✔ | ✗ | ✔ | ✔ |
| endsWith | ✗ | ✗ | ✔ | ✔ | ✗ | ✔ | ✔ |
| multiSearchAny | ✗ | ✗ | ✔ | ✗ | ✗ | ✗ | ✗ |
| in | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| notIn | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✗ |
less (<) | ✔ | ✔ | ✗ | ✗ | ✗ | ✗ | ✗ |
greater (>) | ✔ | ✔ | ✗ | ✗ | ✗ | ✗ | ✗ |
lessOrEquals (<=) | ✔ | ✔ | ✗ | ✗ | ✗ | ✗ | ✗ |
greaterOrEquals (>=) | ✔ | ✔ | ✗ | ✗ | ✗ | ✗ | ✗ |
| empty | ✔ | ✔ | ✗ | ✗ | ✗ | ✗ | ✗ |
| notEmpty | ✗ | ✔ | ✗ | ✗ | ✗ | ✔ | ✗ |
| has | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| hasAny | ✗ | ✗ | ✔ | ✔ | ✔ | ✔ | ✗ |
| hasAll | ✗ | ✗ | ✔ | ✔ | ✔ | ✔ | ✗ |
| hasToken | ✗ | ✗ | ✗ | ✔ | ✗ | ✗ | ✔ |
| hasTokenOrNull | ✗ | ✗ | ✗ | ✔ | ✗ | ✗ | ✔ |
hasTokenCaseInsensitive (*) | ✗ | ✗ | ✗ | ✔ | ✗ | ✗ | ✗ |
hasTokenCaseInsensitiveOrNull (*) | ✗ | ✗ | ✗ | ✔ | ✗ | ✗ | ✗ |
| hasAnyTokens | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✔ |
| hasAllTokens | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✔ |
| pointInPolygon | ✔ | ✔ | ✗ | ✗ | ✗ | ✗ | ✗ |
| mapContains (mapContainsKey) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✔ |
| mapContainsKeyLike | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✔ |
| mapContainsValue | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✔ |
| mapContainsValueLike | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✔ |
ngrambf_v1 によるクエリ最適化には使用できません。
(*) hasTokenCaseInsensitive と hasTokenCaseInsensitiveOrNull を有効にするには、tokenbf_v1 索引を小文字化したデータに対して作成する必要があります。たとえば、INDEX idx (lower(str_col)) TYPE tokenbf_v1(512, 3, 0) のようにします。
ブルームフィルタは偽陽性の一致を返す可能性があるため、
ngrambf_v1、tokenbf_v1、sparse_grams、bloom_filter の索引は、関数の結果が false になることが想定されるクエリの最適化には使用できません。たとえば:- 最適化可能:
s LIKE '%test%'NOT s NOT LIKE '%test%'s = 1NOT s != 1startsWith(s, 'test')
- 最適化不可:
NOT s LIKE '%test%'s NOT LIKE '%test%'NOT s = 1s != 1NOT startsWith(s, 'test')
プロジェクション
プロジェクションを実装する際は、force_optimize_projection 設定も考慮してください。
SELECT ステートメントではサポートされていません。
プロジェクションクエリ
プロジェクション索引
_part_offset として保存されます。つまり、SELECT _part_offset ORDER BY <index_expr> です。
構文
索引の種類
- basic: 式に対する通常の MergeTree 索引と同等です。
プロジェクションストレージ
MergeTree テーブルのパートを格納するサブディレクトリを含みます。このテーブルは、プロジェクションの定義クエリによって導出されます。GROUP BY 句がある場合、基盤となるストレージエンジンは AggregatingMergeTree になり、すべての集約関数は AggregateFunction に変換されます。ORDER BY 句がある場合、MergeTree テーブルはそれを主キー式として使用します。マージ処理中、プロジェクションパートはそのストレージのマージルーチンを通じてマージされます。親テーブルのパートのチェックサムは、プロジェクションのパートのチェックサムと結合されます。その他のメンテナンスジョブは、スキップ索引と同様です。
クエリ解析
- プロジェクションを使って指定されたクエリに対応できるか、つまり基となるテーブルに対してクエリを実行した場合と同じ結果を返せるかを確認します。
- 読み取るグラニュール数が最も少ない、実行可能な最適候補を選択します。
- プロジェクションを使うクエリパイプラインは、元のパーツを使う場合のものとは異なります。一部のパーツにプロジェクションがない場合は、その場でプロジェクションを作成するパイプラインを追加できます。
同時データアクセス
カラムとテーブルの有効期限 (TTL)
TTL 句は、テーブル全体にも、個々のカラムにも設定できます。テーブルレベルの TTL では、ディスクやボリューム間でのデータの自動移動や、すべてのデータの有効期限が切れたパーツの再圧縮のロジックも指定できます。
式は、Date、Date32、DateTime または DateTime64 のデータ型を返す必要があります。
構文
カラムの有効期限 (TTL) を設定する場合:
interval を定義するには、時間間隔 演算子を使用します。例:
カラム 有効期限 (TTL)
有効期限 (TTL) 句はキーカラムには使用できません。
例
有効期限 (TTL) を設定したテーブルの作成:
既存テーブルのカラムに有効期限 (TTL) を追加する
カラムの有効期限 (TTL) の変更
テーブルの 有効期限 (TTL)
有効期限 (TTL) 式の条件を満たしている必要があります。
DELETE- 期限切れの行を削除します (デフォルトのアクション) 。RECOMPRESS codec_name-codec_nameを使用してデータパートを再圧縮します。TO DISK 'aaa'- パートをディスクaaaに移動します。TO VOLUME 'bbb'- パートをディスクbbbに移動します。GROUP BY- 期限切れの行を集約します。
DELETE アクションは WHERE 句と組み合わせて使用でき、フィルタリング条件に基づいて、期限切れの行の一部のみを削除できます。
GROUP BY 式は、テーブルの主キーのプレフィックスでなければなりません。
あるカラムが GROUP BY 式に含まれず、SET 句でも明示的に設定されていない場合、結果の行にはグループ化された行のいずれかの値が格納されます (そのカラムに集約関数 any が適用された場合と同様です) 。
例
有効期限 (TTL) を設定したテーブルの作成:
テーブルの有効期限 (TTL)を変更する:
期限切れの行を再圧縮するテーブルの作成:
x にはグループ化された行の最大値、y には最小値、d にはグループ化された行のいずれかの値が入ります。
期限切れデータの削除
有効期限 (TTL) により有効期限切れになったデータは、ClickHouse がデータパーツをマージするときに削除されます。
ClickHouse はデータの有効期限切れを検出すると、通常のスケジュール外でマージを実行します。この種のマージの頻度は、merge_with_ttl_timeout で制御できます。値が低すぎると、リソースを大量に消費するスケジュール外マージが頻繁に実行される可能性があります。
マージの合間に SELECT クエリを実行すると、期限切れのデータが返されることがあります。これを避けるには、SELECT の前に OPTIMIZE クエリを使用してください。
関連項目
ディスクの種類
s3は S3 および MinIO 用gcsは GCS 用blob_storage_diskは Azure Blob Storage 用hdfsは HDFS 用webは Web からの読み取り専用用cacheはローカル cache 用s3_plainは S3 へのバックアップ用s3_plain_rewritableは S3 上の不変な非レプリケートテーブル用
データ保存に複数のブロックデバイスを使用する
はじめに
MergeTree ファミリーのテーブルエンジンでは、複数のブロックデバイスにデータを保存できます。たとえば、あるテーブルのデータが暗黙的に「ホット」と「コールド」に分かれている場合に役立ちます。最新のデータは頻繁に参照されますが、必要な容量はわずかです。一方、裾野の広い履歴データは参照頻度が低くなります。複数のディスクが利用可能な場合、「ホット」データは高速なディスク (たとえば NVMe SSD やメモリ) に配置し、「コールド」データは比較的低速なディスク (たとえば HDD) に配置できます。
これは、S3 やその他のオブジェクトストレージディスクを含む、すべてのディスク種別に当てはまります。たとえば、1 つのボリューム内で複数の S3 バケットにデータを分散したり、ローカルディスクから S3 にデータを移動する階層型ポリシーを作成したりできます。詳しくは、複数のボリュームで S3 ディスクを使用するを参照してください。
データパートは、MergeTree エンジンのテーブルにおける移動可能な最小単位です。1 つのパートに属するデータは 1 つのディスクに保存されます。データパートは、バックグラウンドで (ユーザー設定に従って) ディスク間を移動できるほか、ALTER クエリを使用して移動することもできます。
用語
- ディスク — ファイルシステムにマウントされたブロックデバイス。
- デフォルトディスク — サーバー設定 path で指定されたパスを保存するディスク。
- ボリューム — 同種のディスクを順序付けた集合 (JBOD に類似) 。
- ストレージポリシー — ボリュームの集合と、それらの間でデータを移動するためのルール。
MergeTree エンジンファミリーのテーブルで storage_policy 設定を使用します。
設定
config.d ディレクトリ内のファイルで <storage_configuration> タグ内に定義する必要があります。
設定の構造:
<disk_name_N>— ディスク名。すべてのディスクで異なる名前にする必要があります。path— サーバーがデータ (dataおよびshadowフォルダー) を保存するパス。末尾は ’/’ で終わる必要があります。keep_free_space_bytes— 予約しておく空きディスク容量。
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 つのボリュームに同じ優先順位の値を設定することはできません。
hdd_in_order ポリシーは ラウンドロビン 方式を実装しています。つまり、このポリシーでは 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 つを適用できます。
default ストレージポリシーは、<path> で指定された 1 つのディスクだけで構成される、1 つのボリュームのみを使用することを意味します。
テーブル作成後でも、[ALTER TABLE … MODIFY SETTING] クエリを使用してストレージポリシーを変更できます。新しいポリシーには、同じ名前の既存のすべてのディスクとボリュームが含まれている必要があります。
データパーツのバックグラウンド移動を実行するスレッド数は、background_move_pool_size 設定で変更できます。
詳細
MergeTree テーブルでは、データはさまざまな方法でディスクに書き込まれます。
- insert (
INSERTクエリ) の結果として。 - バックグラウンドのマージおよびmutationsの実行時。
- 別のレプリカからダウンロードするとき。
- パーティションの凍結 ALTER TABLE … FREEZE PARTITION の結果として。
- パーツを保存するのに十分なディスク容量があり (
unreserved_space > current_part_size) 、かつ指定サイズのパーツの保存が許可されている (max_data_part_size_bytes > current_part_size) 最初のボリューム (定義順) が選択されます。 - このボリューム内では、直前のデータ chunk の保存に使用されたディスクの次にあたり、かつパーツサイズを上回る空き容量がある (
unreserved_space - keep_free_space_bytes > current_part_size) ディスクが選択されます。
move_factor パラメータ) に基づき、設定ファイルで宣言されたボリュームの順序に従ってボリューム間を移動します。
データが最後のボリュームから転送されたり、最初のボリュームに転送されたりすることはありません。バックグラウンドでの移動の監視には、システムテーブル system.part_log (フィールド type = MOVE_PART) および system.parts (フィールド path と disk) を使用できます。また、詳細な情報はサーバーログでも確認できます。
ユーザーは、クエリ ALTER TABLE … MOVE PART|PARTITION … TO VOLUME|DISK … を使用して、パーツまたはパーティションをあるボリュームから別のボリュームへ強制的に移動できます。この場合も、バックグラウンド処理に対するすべての制限が考慮されます。このクエリは独自に移動を開始し、バックグラウンド処理の完了は待機しません。十分な空き容量がない場合や、必要な条件のいずれかが満たされていない場合、ユーザーはエラーメッセージを受け取ります。
データの移動はデータのレプリケーションに影響しません。したがって、同じテーブルに対して異なるレプリカごとに別々のストレージポリシーを指定できます。
バックグラウンドのマージおよび mutations の完了後、古いパーツが削除されるのは一定時間 (old_parts_lifetime) が経過してからです。
この間、それらが他のボリュームやディスクに移動されることはありません。したがって、パーツが最終的に削除されるまでは、使用済みディスク容量の評価対象に引き続き含まれます。
ユーザーは、min_bytes_to_rebalance_partition_over_jbod 設定を使用して、JBOD ボリューム内の異なるディスクに新しい大きなパーツをバランスよく割り当てることができます。
データ保存に外部ストレージを使用する
s3、azure_blob_storage、hdfs のディスクを使用して、データを S3、AzureBlobStorage、HDFS に保存できます。詳細については、外部ストレージオプションの設定を参照してください。
タイプが s3 のディスクを使用して、S3 を外部ストレージとして利用する例を示します。
設定マークアップ:
複数のボリュームで S3 ディスクを使用する
S3 認証で
use_environment_credentials を使用する場合、環境認証情報 (AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN) はすべての S3 ディスクで共有されます。ディスクごとに異なる環境認証情報を使用することはできません。S3 ディスクごとに異なる認証情報が必要な場合は、代わりに各ディスクで access_key_id と secret_access_key を明示的に設定してください。table_disk = true を使用すること) が必要です。refresh_parts_interval and table_disk を参照してください。
cache 構成ClickHouse のバージョン 22.3 から 22.7 では、異なる cache 構成が使用されます。これらのバージョンを使用している場合は、using local cache を参照してください。
仮想カラム
_part— パート名。_part_index— クエリ結果内のパートの連番インデックス。_part_starting_offset— クエリ結果内における、そのパートの累積開始行。_part_offset— パート内の行番号。_part_granule_offset— パート内のグラニュール番号。_partition_id— パーティション名。_part_uuid— パートの一意な識別子 (MergeTree settingassign_part_uuidsが有効な場合) 。_part_data_version— パートのデータバージョン (最小ブロック番号または mutation バージョン) 。_partition_value—partition by式の値 (タプル) 。_sample_factor— サンプル係数 (クエリ由来) 。_block_number— insert 時に行へ割り当てられた元の block 番号。settingenable_block_number_columnが有効な場合、merge 後も保持されます。_block_offset— insert 時に block 内の行へ割り当てられた元の行番号。settingenable_block_offset_columnが有効な場合、merge 後も保持されます。_disk_name— ストレージに使用されるディスク名。
カラム STATISTICS
*MergeTree* ファミリーのテーブルに対する CREATE クエリのカラム定義セクションで行います。
ALTER 文を使って統計情報を操作することもできます:
set use_statistics = 1 を有効にした場合にのみ、PREWHERE 最適化に使用できます。
統計情報を用いたパーツ剪枝
use_statistics_for_part_pruning が有効になっている場合、統計情報をパーツ剪枝に利用できます。
現在、パーツ剪枝に対応している統計情報は MinMax と NullCount です。カラムに MinMax 統計情報が定義されている場合、ClickHouse は各パーツについてそのカラムの最小値と最大値を追跡します。Nullable カラムに NullCount 統計情報が定義されている場合、ClickHouse は各パーツ内の NULL 値の数を追跡します。これにより、IS NULL / IS NOT NULL 述語に基づく剪枝が可能になり、NULL 値を含むカラムに対する範囲フィルタの剪枝精度も向上します。
パーツ剪枝では、そのパーツ内のどの行もクエリのフィルタ条件に一致しないことが分かっている場合、データパーツ全体の読み取りをスキップできます。
例:
利用可能なカラム STATISTICS の種類
-
MinMaxカラムの最小値と最大値です。数値カラムに対する範囲フィルタの選択性を推定するのに役立ちます。 構文:minmax -
TDigest数値カラムの近似パーセンタイル (例: 90 パーセンタイル) を計算できる TDigest スケッチです。 構文:tdigest -
Uniqカラムに含まれる異なる値の数を推定できる HyperLogLog スケッチです。 構文:uniq -
NullCountNullableカラム内のNULL値の数を追跡します。PREWHERE optimization におけるIS NULL/IS NOT NULL述語の選択性を正確に推定するために使用され、NULL の有無に基づくパーツ剪枝も可能にします。 構文:nullcount -
CountMinカラム内の各値の出現頻度を近似的に数えられる CountMin スケッチです。 構文countmin
サポートされているデータ型
| (U)Int*, Float*, Decimal(), Date, Boolean, Enum* | String or FixedString | Nullable() / LowCardinality(Nullable()) | |
|---|---|---|---|
| CountMin | ✔ | ✔ | ✗ |
| MinMax | ✔ | ✗ | ✔ |
| NullCount | ✗ | ✗ | ✔ |
| TDigest | ✔ | ✗ | ✔ |
| Uniq | ✔ | ✔ | ✔ |
対応する操作
| 等値フィルター (==) | 範囲フィルター (>, >=, <, <=) | IS NULL / IS NOT NULL | |
|---|---|---|---|
| CountMin | ✔ | ✗ | ✗ |
| MinMax | ✗ | ✔ | ✗ |
| NullCount | ✗ | ✗ | ✔ |
| TDigest | ✗ | ✔ | ✗ |
| Uniq | ✔ | ✗ | ✗ |
カラムレベルの設定
max_compress_block_size— テーブルに書き込む際、圧縮前の非圧縮データブロックの最大サイズ。min_compress_block_size— 次のマークを書き込む際に圧縮を行うために必要な、非圧縮データブロックの最小サイズ。
- カラム定義から
SETTINGSを削除するには、次のようにします:
- 設定を変更する:
- 1 つ以上の設定をリセットし、テーブルの CREATE クエリ内のカラム式にある設定宣言も削除します。