Set up docs MCPデータベースの概念とClickHouse用語の用語集です。一般的なデータベース用語がClickHouseではどのように異なるかも説明します。
「」に一致する用語はありません。
アトミック性
アトミック性とは、操作が完全に反映されるか、まったく反映されないかのいずれかであることを意味します。ClickHouse では、MergeTree ファミリーの単一テーブルの単一パーティションへの挿入は、その行が単一のブロックとして書き込まれる場合にアトミックになります。複数のパーティションにまたがる挿入はパーティションごとに、分散テーブルへの挿入は分片ごとに、それぞれ個別にアトミックとなります。マルチステートメントトランザクションは依然として実験的であり、利用に制限があります。
ブロック
ブロックとは、クエリ処理およびデータ転送に使用される、自己記述的な列指向の行のバッチです。ブロックはランタイムおよびワイヤ上の単位であり、データパーツやグラニュールはこれとは別の、ストレージおよび索引付けに関する概念です。ブロック単位でカラム値を処理することで、ベクトル化実行が可能になります。
クラスター
データの保存と処理を連携して行うノード (サーバー) の集合です。
CMEK
ClickHouse Cloud では、カスタマー管理暗号化キー (CMEK) を使用することで、顧客のキー管理サービス (KMS) のキーによって、保存データ (data at rest) の暗号化に使用されるデータ暗号化キー (DEK) を保護できます。
削除
MergeTree ファミリーのテーブルにおける行の削除には、DELETE FROM で行を削除済みとしてマークする方法、ALTER TABLE ... DELETE で該当するデータパーツを書き換える方法、パーティション全体を効率的に削除する方法があります。論理削除では、バックグラウンドマージ時にデータが物理的に削除されるまでの間、対象の行が以降のクエリから見えなくなります。
重複排除
重複排除は、ClickHouse では複数の異なる仕組みを指す場合があります。行バージョンの重複排除では、ReplacingMergeTree などのエンジンがソートキーによって重複するバージョンを特定し、パーティション内のバックグラウンドマージ時にそれらを解決します。一方、Replicated テーブルエンジンでは、これとは別に、再試行された挿入ブロックをブロック識別子に基づいて重複排除できます。
Dictionary
Dictionary は、インメモリまたは外部のソースにある参照データに対して、キー・バリュー形式のアクセスを提供します。キーに基づくルックアップが適用できる場合、Dictionary 関数や Dictionary への直接の JOIN を使うことで、参照テーブルを繰り返しスキャンせずに済みます。
分散テーブル
ClickHouse の分散テーブルは、自身はデータを保持せず、クラスター内の複数のサーバーにまたがる分散クエリ処理のための統一されたビューを提供する特別な種類のテーブルです。
FINAL
FINAL は、保存されているパーツを物理的にマージすることなく、データの読み取り時にエンジンのマージ時の変換を適用するクエリ修飾子です。バックグラウンドマージの完了を待たずに、ReplacingMergeTree などのエンジンからリコンサイルされた結果を返せますが、その分クエリ実行時のコンピュートとメモリを追加で消費します。
Granule
グラニュール (granule) とは、ClickHouse がプライマリインデックスによるプルーニングのために読み取る最小の論理的な行グループです。デフォルトでは最大 8,192 行を含みますが、アダプティブインデックス粒度によってより小さなグラニュールが作成されることもあります。プライマリインデックスは通常、グラニュールごとに 1 つのエントリを保持します。
インクリメンタルmaterialized view
インクリメンタルmaterialized viewは、ソーステーブルにデータが挿入されるタイミングでクエリを実行し、その結果をターゲットテーブルに書き込みます。処理対象となるのは新しく挿入されたblockのみで、ソーステーブルの現在の全データではありません。また、joinしているright-sideのテーブルが変更されても、再実行のトリガーにはなりません。
JSON
JSON 型は、行ごとにパスや型が異なりうる半構造化ドキュメントを格納します。ClickHouse は検出されたパスをサブカラムとして格納するため、クエリは個々のフィールドを効率的に読み取れます。スキーマが安定している場合は、型付きカラムや Tuple などの構造型を使用してください。
マークファイル
mark file には、圧縮されたカラムデータ内の granule の位置を特定するための offset が格納されます。各 mark は、圧縮ファイル内の offset と、対応する展開後の block 内の offset を記録します。これにより ClickHouse は、カラム全体を読み取ることなく目的の granule へ直接 seek できます。
Materialized view
ClickHouse には2種類の materialized view のモデルがあります。インクリメンタル materialized view は insert-time のトリガーのように動作し、新たに挿入された block を処理します。一方、リフレッシャブル materialized view は、データセット全体に対して定期的にクエリを再実行します。他のデータベースで似た名前を持つ機能はこれらの動作を組み合わせている場合があるため、必ずしも1対1で対応するとは限りません。
マージ
ClickHouse におけるマージとは、同一パーティション内の小さなイミュータブルなデータパーツを、より大きなパーツへと統合するバックグラウンドのストレージ操作です。テーブルエンジンによっては、マージ時に行の集約、折りたたみ、置換が行われることもあります。これはトランザクショナルな SQL の MERGE ステートメントとは別のものです。
MergeTree
ClickHouse の MergeTree は、高いデータ取り込みレートと大量のデータを扱うために設計されたテーブルエンジンです。ClickHouse の中核となるストレージエンジンであり、列指向ストレージ、カスタムのパーティション化、スパースプライマリインデックス、バックグラウンドでのデータマージのサポートといった機能を提供します。
ミューテーション
MergeTree ファミリーのテーブルでは、mutation は ALTER TABLE ... UPDATE や ALTER TABLE ... DELETE などのコマンドによって既存のデータを変更または削除します。OLTP における行単位の更新とは異なり、影響を受ける data parts を書き換える方式であり、通常は非同期で処理が進みます。パーツは準備が整ったものから順に置き換えられるため、この操作はテーブル全体を対象とするアトミックなトランザクションではありません。
Nullable カラム
0 や空文字列を含む型 T の通常の値と NULL を区別するには、カラムで Nullable(T) を使用する必要があります。ClickHouse は null マスクを別途保持するため、ストレージと処理のオーバーヘッドが増加します。そのため、nullable カラムはデフォルトの選択肢とするのではなく、欠損値が意味を持つ場合にのみ使用してください。
On-the-fly mutation
mutation とその後の読み取りの両方で apply_mutations_on_fly が有効になっている場合、ClickHouse は SELECT クエリの実行時に保留中の更新や削除を適用するため、保存済みのパーツが書き換えられる前でもその結果を参照できます。mutation 自体は、引き続きバックグラウンドで非同期にマテリアライズされます。
パーツ
データパートとは、テーブルの行の一部を格納した、ストレージ上のイミュータブルなファイル群です。パーツは挿入によって作成され、パーティション内でバックグラウンドマージによって結合されます。データの論理的なグループ化であるパーティションとは異なり、パーツは ClickHouse が管理する物理的なストレージ単位です。
パーティション
パーティションとは、MergeTree ファミリーのテーブルにおける data parts を論理的にまとめた単位です。パーティション化は主に、データのグループ単位での削除、移動、保持ポリシーの適用といったデータ管理操作のために用いられます。パーティションプルーニングは、少数のパーティションのみを対象とするクエリでは効果がありますが、クエリパフォーマンスにおいては通常、ソートキーと主キーの方が重要です。
パーティショニングキー
パーティショニングキーとは、テーブルの PARTITION BY 句に指定する式のことです。同じパーティション ID になる行は同一の論理パーティションに属しますが、挿入が別々に行われた場合は、そのパーティション内に別々のデータパーツが作成されることがあります。このようにグループ化しておくことで、パーティション単位での削除、移動、アーカイブといった操作が可能になります。
主キー
多くのトランザクション型データベースの主キーとは異なり、ClickHouse の主キーは行レベルの一意性制約ではありません。主キーは、読み取り時に ClickHouse が granule をスキップできるようにするスパースプライマリインデックスのカラムを定義するものです。デフォルトでは ORDER BY で定義された sorting key と一致し、個別に定義する場合は sorting key のプレフィックスである必要があります。
プロジェクション
PROJECTION とは、テーブルのデータを別の並び順、一部のカラム、または事前に計算された集約として保持する、自動的に維持される表現です。ClickHouse は元のテーブルへのクエリ実行時に、PROJECTION を自動的に選択できます。PROJECTION は保存データを重複して持つため書き込みのオーバーヘッドが増える可能性がありますが、_part_offset を用いた PROJECTION では、基となるテーブルからの追加の読み取りと引き換えにストレージ使用量を抑えられます。
リフレッシャブルmaterialized view
リフレッシャブルmaterialized viewは、データセット全体に対してクエリを定期的に再実行し、スケジュールに従って保存済みの結果を置き換えるか追記します。インクリメンタルmaterialized viewとは異なり、挿入されたblockごとにトリガーされることはなく、複雑なクエリも使用できます。SELECTの結果をマテリアライズするスケジュール実行クエリの代わりとして利用できますが、任意のDDLやDMLステートメントを実行する汎用のスケジューラーではありません。
ReplacingMergeTree
ReplacingMergeTree は、同じソートキーを持つ行の複数バージョンを受け入れ、バックグラウンドマージの際に 1 つのバージョンだけを残すことで、更新や upsert を表現します。重複排除は挿入時点で一意性を保証するものではなく、最終的に収束する形で行われます。そのため、FINAL や同等のクエリロジックを使用するか、該当するパーツがマージされるまでは、クエリ結果に複数のバージョンが現れることがあります。
レプリカ
レプリカとは、可用性とクエリ処理能力を確保するために、他のレプリカと同一の論理テーブルデータを保持する、あるいはそのデータにアクセスするサーバーまたはコンピュートインスタンスです。ReplicatedMergeTree では、各レプリカがデータの独立したコピーを保持します。一方、SharedMergeTree を使用する ClickHouse Cloud のレプリカは、オブジェクトストレージを共有します。
セカンダリ索引
ClickHouse において、従来のセカンダリ索引に最も近い存在は、通常データスキッピングインデックスです。B-tree で個々の行を特定するのではなく、granule のまとまりごとにメタデータを保持することで、一致する値を含み得ない block の読み取りを ClickHouse が回避できるようにします。
分片
シャードとは、分散デプロイメントにおいて1つのサーバーまたはレプリカグループに割り当てられる、テーブルデータの論理的な部分集合です。シャーディングによってデータとクエリ処理が複数のサーバーに分散され、レプリカは各シャード内のデータに対する冗長なアクセスまたは並列アクセスを提供します。
スキップ索引
データスキッピングインデックスは、連続する 1 つ以上の granule についてコンパクトなメタデータを保持し、クエリに一致し得ない block の読み取りを ClickHouse がスキップできるようにします。インデックス対象の値がテーブルのソート順と相関している場合に最も効果を発揮し、一致する値がインデックス対象の block の大半に出現する場合はほとんど効果がありません。
ソートキー
MergeTree ファミリーのテーブルでは、ORDER BY 句がソートキー、すなわち各データパート内での物理的な行の並び順を定義します。これは他の分析データベースにおけるクラスタリングカラムやクラスタリングキーと似た役割を果たしますが、ClickHouse ではこれを用いて明確な辞書順の行順序を維持します。主キーを別途指定しない場合、ソートキーがそのまま主キーになります。両者は関連していますが、必ずしも同一である必要はありません。
スパースインデックス
スパースプライマリインデックスは、行ごとに1つのエントリを保持するのではなく、granuleごとにキー値を格納します。ClickHouseはこれらのエントリをもとに候補となるgranuleを特定し、その行を読み取ります。サイズは行数ではなくgranule数に比例するため、この索引は通常メモリ上に保持できる程度に小さく収まります。
テーブルエンジン
ClickHouse のテーブルエンジンは、データの書き込み方法、保存方法、アクセス方法を決定します。最も一般的なテーブルエンジンは MergeTree で、大量のデータを高速に挿入でき、挿入されたデータはバックグラウンドで処理されます。
トランザクション
ClickHouse では、トランザクション保証の適用範囲が一般的な OLTP データベースとは異なります。条件を満たす挿入はブロック単位またはパーティション単位でアトミックに実行されますが、COMMIT と ROLLBACK を用いる従来型のマルチステートメントトランザクションは依然として実験的な機能であり、大きな制約があります。
有効期限 (TTL)
TTL ルールは、式が条件を満たした時点でデータの移動、削除、またはロールアップを行います。ただし、有効期限切れは即座に反映されるわけではありません。ClickHouse は通常、バックグラウンドマージの際に期限切れデータに対する処理を適用するため、該当するパーツがマージで処理されるまでの間、期限切れの行がディスク上に残り、クエリの結果として返されることがあります。
更新
ClickHouse は、頻繁なインプレースでの行更新ではなく、イミュータブルで追記中心のデータ向けに最適化されています。更新は一般的に、専用のテーブルエンジンで新しいバージョンを挿入する形でモデル化するか、対象のデータパーツを書き換える mutation として実行します。
Upsert
MergeTreeファミリーのテーブルは、トランザクションによるINSERT ... ON CONFLICTのupsertをサポートしていません。upsertは通常、ReplacingMergeTreeなどのエンジンに、より新しいバージョンの行を挿入する形でモデル化します。古いバージョンはバックグラウンドマージの際に解決されるため、マージが実行されるまではクエリ側でFINALまたは同等のロジックが必要になる場合があります。
ウェアハウス
ClickHouse Cloud におけるウェアハウスとは、同一のデータを共有しながら、それぞれ独立したコンピュートリソースとエンドポイントを持つサービスの集合です。ウェアハウスが 1 つのコンピュートクラスターを意味するシステムでは、個々の ClickHouse サービスの方が近い概念にあたり、ClickHouse のウェアハウスは複数のサービスをまとめたものに相当します。