型の対応関係

ClickHouse と Elasticsearch における型の対応関係

Elasticsearch と ClickHouse はどちらも幅広いデータ型をサポートしていますが、その基盤となるストレージやクエリのモデルは根本的に異なります。このセクションでは、一般的に使われる Elasticsearch のフィールド型を、対応するものがある場合は ClickHouse の同等の型に対応付け、移行の判断に役立つ補足情報も提供します。対応する型が存在しない場合は、代替案や補足事項をコメントに記載しています。

Elasticsearch の型	ClickHouse での対応	備考
boolean	UInt8 or Bool	新しいバージョンでは、ClickHouse は UInt8 の別名として Boolean をサポートしています。
keyword	String	完全一致でのフィルタリング、グループ化、ソートに使用されます。
text	String	ClickHouse の全文検索機能には制限があります。トークン化には、tokens などの関数と array functions を組み合わせたカスタムロジックが必要です。
long	Int64	64 ビット符号付き整数。
integer	Int32	32 ビット符号付き整数。
short	Int16	16 ビット符号付き整数。
byte	Int8	8 ビット符号付き整数。
unsigned_long	UInt64	符号なし 64 ビット整数。
double	Float64	64 ビット浮動小数点数。
float	Float32	32 ビット浮動小数点数。
half_float	Float32 or BFloat16	最も近い対応型です。ClickHouse には 16 ビット浮動小数点型はありません。ClickHouse には BFloat16 がありますが、これは IEEE-754 の half-float とは異なります。half-float はより狭い範囲で高い精度を提供する一方、bfloat16 は精度を犠牲にする代わりにより広い範囲を扱えるため、機械学習 workloads により適しています。
scaled_float	Decimal(x, y)	固定小数点数値を格納します。
date	DateTime	秒精度の日付型に相当します。
date_nanos	DateTime64	ClickHouse は DateTime64(9) によりナノ秒精度をサポートしています。
binary	String, FixedString(N)	バイナリフィールドでは base64 デコードが必要です。
ip	IPv4, IPv6	ネイティブの IPv4 および IPv6 型を利用できます。
object	Nested, Map, Tuple, JSON	ClickHouse では、Nested や JSON を使って JSON ライクなオブジェクトを表現できます。
flattened	String	Elasticsearch の flattened 型は、JSON オブジェクト全体を単一のフィールドとして格納し、完全なマッピングなしでネストされたキーに柔軟かつスキーマレスにアクセスできるようにします。ClickHouse では、同様の機能を String type で実現できますが、処理は materialized view で行う必要があります。
nested	Nested	ClickHouse の Nested カラムは、flatten_nested=0 を使用することを前提とすれば、グループ化されたサブフィールドに対して同様のセマンティクスを提供します。
join	NA	親子関係に相当する直接的な概念はありません。テーブル間の joins がサポートされているため、ClickHouse では不要です。
alias	Alias column modifier	別名はフィールド修飾子を通じて サポートされています。これらの alias には関数も適用できます。例: size String ALIAS formatReadableSize(size_bytes)
range types (*_range)	Tuple(start, end) or Array(T)	ClickHouse にはネイティブの range 型はありませんが、数値や日付の範囲は Tuple(start, end) または Array 構造で表現できます。IP 範囲 (ip_range) については、CIDR 値を String として格納し、isIPAddressInRange() のような関数で評価します。あるいは、効率的なフィルタリングのために ip_trie ベースの lookup dictionaries を検討してください。
aggregate_metric_double	AggregateFunction(...) and SimpleAggregateFunction(...)	集計関数の状態と materialized view を使用して、事前に集計されたメトリクスを表現します。すべての aggregation functions は aggregate states をサポートしています。
histogram	Tuple(Array(Float64), Array(UInt64))	buckets とカウントは、配列またはカスタムスキーマを使って手動で表現します。
annotated-text	String	entity-aware search や annotations は組み込みではサポートされていません。
completion, search_as_you_type	NA	ネイティブのオートコンプリート機能や suggester エンジンはありません。String と search functions を使って再現できます。
semantic_text	NA	ネイティブの semantic search はありません。embeddings を生成し、vector search を使用します。
token_count	Int32	インジェスト時に token count を手動で計算するために使用します。たとえば length(tokens()) 関数を Materialized column と組み合わせて使用します
dense_vector	Array(Float32)	embeddings の格納には配列を使用します
sparse_vector	Map(UInt32, Float32)	map を使ってスパースベクトルを表現します。ネイティブの sparse vector サポートはありません。
rank_feature / rank_features	Float32, Array(Float32)	クエリ時のネイティブなブースティングには対応していませんが、スコアリングロジックで手動で表現できます。
geo_point	Tuple(Float64, Float64) または Point	(緯度, 経度) のタプルを使用します。Point も ClickHouse の型として利用できます。
geo_shape, shape	Ring, LineString, MultiLineString, Polygon, MultiPolygon	Geo 形状と空間索引をネイティブでサポートしています。
percolator	NA	クエリを索引化するという概念はありません。代わりに、標準 SQL + インクリメンタルmaterialized view を使用してください。
version	String	ClickHouse にはネイティブのバージョン型はありません。バージョンは文字列として保存し、必要に応じてカスタム UDFs を使ってセマンティック比較を行ってください。範囲クエリが必要な場合は、数値フォーマットへの正規化を検討してください。

​

注意事項

• 配列: Elasticsearch では、すべてのフィールドがネイティブで配列をサポートしています。ClickHouse では、配列を明示的に定義する必要があります (例: Array(String)) 。一方で、特定の位置の要素にアクセスしてクエリできるという利点があり、たとえば an_array[1] のように扱えます。

• マルチフィールド: Elasticsearch では、同じフィールドを複数の方法で索引化 できます (例: text と keyword の両方) 。ClickHouse では、このパターンは個別のカラムやビューで表現する必要があります。

• Map と JSON 型 - ClickHouse では、Map 型は resourceAttributes や logAttributes のような動的なキー・バリュー構造を表現するためによく使われます。この型では任意のキーを実行時に追加できるため、柔軟なスキーマレス インジェストが可能で、考え方としては Elasticsearch の JSON オブジェクトに近いものです。ただし、考慮すべき重要な制約があります。

  • 値の型を統一する必要がある: ClickHouse の Map カラムでは、値の型を一貫させる必要があります (例: Map(String, String)) 。異なる型の値は、型変換なしではサポートされません。
  • 性能上のコスト: Map の任意のキーにアクセスするには、マップ全体をメモリに読み込む必要があるため、性能面で不利になる場合があります。
  • サブカラムがない: JSON とは異なり、Map のキーは真のサブカラムとして表現されないため、ClickHouse での効率的な索引化、圧縮、クエリに制約があります。

  こうした制約があるため、ClickStack は Map から、ClickHouse の強化された JSON 型への移行を進めています。JSON 型は、Map の多くの欠点を解消します。

  • 真の列指向ストレージ: 各 JSON パスはサブカラムとして保存されるため、効率的な圧縮、フィルタリング、ベクトル化クエリ実行が可能です。

  • 異種型のサポート: 異なるデータ型 (例: 整数、文字列、配列) を、型変換や型の統一なしで同じパス配下に共存させることができます。

  • ファイルシステムのスケーラビリティ: 動的キー (max_dynamic_paths) および型 (max_dynamic_types) に対する内部制限により、キー集合のカーディナリティが高い場合でも、ディスク上のカラムファイルの爆発的な増加を防げます。

  • 高密度な格納: null や欠損値はスパースに格納されるため、不要なオーバーヘッドを避けられます。

    JSON 型は、特にオブザーバビリティ ワークロードに適しており、スキーマレス インジェストの柔軟性と ClickHouse ネイティブ型の性能およびスケーラビリティを両立します。そのため、動的な属性フィールドにおける Map の理想的な置き換えとなります。

    JSON 型の詳細については、JSON ガイド および “How we built a new powerful JSON data type for ClickHouse” を参照することをおすすめします。