データ型
数値型
Float64 型は、
精度を犠牲にする代わりに、より広い値の範囲を提供します。
これに対して ClickHouse では、浮動小数点数と整数について、
符号付き・符号なしそれぞれに複数の精度が用意されています。これにより、
ストレージやメモリのオーバーヘッドを最適化するために、整数に必要な精度を
明示的に指定できます。Snowflake の Number 型に相当する
Decimal 型では、さらにその 2 倍となる 76 桁の
精度と scale がサポートされています。同様の Float64 に加えて、
ClickHouse は、精度がそれほど重要ではなく、
圧縮を優先したい場合のために Float32 も提供しています。
文字列
VARCHAR は UTF-8 の Unicode 文字を保持し、ユーザーは
最大長を指定できます。この長さはストレージや
パフォーマンスには影響せず、文字列の保存には常に必要最小限のバイト数が使用されます。これは主に、下流のツールで役立つ制約を与えるためのものです。Text や NChar などの他の型は、
単にこの型の別名です。一方 ClickHouse では、
String
型によって すべての文字列データを生のバイト列として 保存し (長さの指定は不要) 、
エンコーディングの扱いはユーザーに委ねられます。その代わり、異なるエンコーディング向けの
クエリ時関数
を利用できます。その理由については、“Opaque data argument”
を参照してください。したがって ClickHouse の String は、実装上
Snowflake の Binary 型により近いものです。Snowflake
と ClickHouse は
どちらも「照合順序」をサポートしており、文字列のソート方法や比較方法をユーザーが上書きできます。
半構造化型
VARIANT、OBJECT、ARRAY 型をサポートしています。
ClickHouse では、これに相当する Variant、
Object (現在はネイティブ JSON 型が推奨されており、非推奨) および Array
型を提供しています。さらに、ClickHouse には JSON
型があり、これは現在非推奨の Object('json') 型に代わるもので、特に
他のネイティブ JSON 型と比べて高い性能と優れたストレージ効率を備えています。
ClickHouse は、名前付き Tuple と Tuple の配列も
Nested 型を通じてサポートしており、
入れ子構造を明示的にマッピングできます。これにより、Snowflake とは異なり、
階層全体にわたってコーデックや型の最適化を適用できます。Snowflake では、外側の
オブジェクトに OBJECT、VARIANT、ARRAY 型を使用する必要があり、
内部の型を明示的に指定することはできません。
この内部型付けにより、ClickHouse ではネストされた数値に対するクエリも簡潔になり、
CAST する必要がなく、索引定義でも使用できます。
ClickHouse では、コーデックと最適化された型をサブ構造にも適用できます。
これには、ネスト構造を持つデータでも圧縮効率を非常に高く保てるという利点があり、
フラット化されたデータと同等の圧縮が可能です。これに対して Snowflake では、
サブ構造に特定の型を適用できないため、最適な圧縮を実現するにはデータを
フラット化することが推奨されています。
また Snowflake では、これらのデータ型に対して
サイズ制限も設けられています。
型のリファレンス
最後に、ClickHouse には
集約関数の状態を保存できるという独自の機能があります。これは
実装固有の状態ですが、集約結果を保存し、
後からクエリできるようにします (対応する merge 関数を使用) 。通常、この
機能は materialized view を通じて利用され、以下で示すように、
挿入されたデータに対するクエリの増分結果を保存することで、
ストレージコストを最小限に抑えながら特定のクエリのパフォーマンスを向上させることができます
(詳細はこちら) 。