マッピングタイプ

ElasticsearchとClickHouseはさまざまなデータ型をサポートしていますが、その基盤となるストレージとクエリのモデルは根本的に異なります。このセクションでは、一般的に使用されるElasticsearchのフィールドタイプを、利用可能な場合はそれに対応するClickHouseの型にマッピングし、移行をガイドするためのコンテキストを提供します。対応するものが存在しない場合は、代替手段や注記がコメントに提供されます。

Elasticsearch Type	ClickHouse Equivalent	Comments
boolean	UInt8 または Bool	ClickHouseは新しいバージョンでUInt8のエイリアスとしてBooleanをサポートしています。
keyword	String	正確一致のフィルタリング、グルーピング、およびソートに使用されます。
text	String	ClickHouseのフルテキスト検索は限られており、トークン化にはtokensと配列関数を組み合わせたカスタムロジックが必要です。
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 または BFloat16	最も近い対応物。ClickHouseには16ビットの浮動小数点はありません。ClickHouseにはBFloat16があります - これは半浮動小数点IEEE-754とは異なります：半浮動小数点はより小さい範囲でより高い精度を提供しますが、bfloat16は精度を犠牲にして広い範囲を提供し、機械学習のワークロードにより適しています。
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のフラット化タイプは、単一のフィールドとしてJSONオブジェクト全体を保存し、ネストされたキーへの柔軟でスキーマレスなアクセスを可能にします。ClickHouseでは、String型を使用することで同様の機能が実現されますが、マテリアライズドビューでの処理が必要です。
nested	Nested	ClickHouseのNestedカラムは、ユーザーがflatten_nested=0を使用することを前提にしたグループ化されたサブフィールドに対して類似の意味論を提供します。
join	NA	親子関係の直接的な概念はありません。ClickHouseではテーブル間の結合がサポートされているので必要ありません。
alias	Alias カラム修飾子	エイリアスはフィールド修飾子を通じてサポートされています。これらのエイリアスに関数を適用することができます。例えば size String ALIAS formatReadableSize(size_bytes)
range types (*_range)	Tuple(start, end) または Array(T)	ClickHouseにはネイティブなレンジタイプがありませんが、数値および日付レンジはTuple(start, end)またはArray構造を使用して表現できます。IPレンジ（ip_range）については、CIDR値をStringとして保存し、isIPAddressInRange()のような関数で評価してください。あるいは、効率的なフィルタリングのためにip_trieベースのルックアップ辞書を検討してください。
aggregate_metric_double	AggregateFunction(...) および SimpleAggregateFunction(...)	集約関数の状態とマテリアライズドビューを使用して事前集約されたメトリックをモデル化します。すべての集約関数は集約状態をサポートしています。
histogram	Tuple(Array(Float64), Array(UInt64))	手動でバケットとカウントを配列またはカスタムスキーマを使用して表現します。
annotated-text	String	エンティティ認識の検索や注釈のためのビルトインサポートはありません。
completion, search_as_you_type	NA	ネイティブなオートコンプリートまたはサジェストエンジンはありません。Stringおよび検索関数で再現可能です。
semantic_text	NA	ネイティブなセマンティック検索はありません - 埋め込みを生成してベクトル検索を使用します。
token_count	Int32	インジェスト中に手動でトークンカウントを計算するために使用します。例：length(tokens())関数をご利用ください。例：マテリアライズドカラムで
dense_vector	Array(Float32)	埋め込みストレージのために配列を使用します。
sparse_vector	Map(UInt32, Float32)	マップを使用してスパースベクトルをシミュレートします。ネイティブなスパースベクトルのサポートはありません。
rank_feature / rank_features	Float32, Array(Float32)	ネイティブなクエリ時のブースティングはありませんが、スコアリングロジックで手動でモデル化できます。
geo_point	Tuple(Float64, Float64) または Point	(緯度、経度)のタプルを使用します。PointはClickHouseタイプとして利用可能です。
geo_shape, shape	Ring, LineString, MultiLineString, Polygon, MultiPolygon	ジオシェイプと空間インデックスのネイティブサポートがあります。
percolator	NA	クエリのインデックス化の概念はありません。代わりに標準SQL + 増分マテリアライズドビューを使用します。
version	String	ClickHouseにはネイティブなバージョンタイプはありません。バージョンを文字列として保存し、必要に応じてセマンティック比較を実行するためのカスタムUDF関数を使用します。範囲クエリが必要な場合は、数値フォーマットに正規化することを検討してください。

Notes

• 配列: Elasticsearchでは、すべてのフィールドがネイティブに配列をサポートしています。ClickHouseでは、配列は明示的に定義する必要があります（例：Array(String)）、特定の位置にアクセスしクエリすることが可能です。例：an_array[1]。

• マルチフィールド: Elasticsearchでは、同じフィールドを複数の方法でインデックス化できます（例：textとkeywordの両方）。ClickHouseでは、このパターンは別々のカラムまたはビューを使用してモデル化する必要があります。

• マップとJSONタイプ - ClickHouseでは、MapタイプがresourceAttributesやlogAttributesのような動的キーと値の構造をモデル化するために一般的に使用されます。このタイプにより、実行時に任意のキーが追加可能で、スキーマレスなインジェストが柔軟にでき、多くのエラスティックサーチの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ガイドおよび"ClickHouseに新しい強力なJSONデータ型を構築した方法"をお勧めします。