型の対応関係 | ClickHouse Docs

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" を参照することをおすすめします。