Correspondance des types | ClickHouse Docs

Elasticsearch et ClickHouse prennent en charge une grande variété de types de données, mais leurs modèles de stockage sous-jacents et leurs modèles de requête sont fondamentalement différents. Cette section établit la correspondance entre les types de champ Elasticsearch couramment utilisés et leurs équivalents dans ClickHouse, lorsqu’ils existent, et fournit le contexte nécessaire pour guider les migrations. Lorsqu’aucun équivalent n’existe, des alternatives ou des remarques sont fournies dans les commentaires.

Type dans Elasticsearch	Équivalent ClickHouse	Commentaires
`boolean`	`UInt8` ou `Bool`	ClickHouse prend en charge `Boolean` comme alias de `UInt8` dans les versions récentes.
`keyword`	`String`	Utilisé pour le filtrage par correspondance exacte, le regroupement et le tri.
`text`	`String`	La recherche en texte intégral est limitée dans ClickHouse ; la tokenization nécessite une logique personnalisée à l’aide de fonctions telles que `tokens`, combinées à des array functions.
`long`	`Int64`	Entier signé sur 64 bits.
`integer`	`Int32`	Entier signé sur 32 bits.
`short`	`Int16`	Entier signé sur 16 bits.
`byte`	`Int8`	Entier signé sur 8 bits.
`unsigned_long`	`UInt64`	Entier non signé sur 64 bits.
`double`	`Float64`	Nombre à virgule flottante sur 64 bits.
`float`	`Float32`	Nombre à virgule flottante sur 32 bits.
`half_float`	`Float32` ou `BFloat16`	Équivalent le plus proche. ClickHouse ne dispose pas de flottant 16 bits. ClickHouse prend en charge `BFloat16` ; ce type diffère du half-float IEEE-754 : le half-float offre une précision plus élevée avec une plage plus réduite, tandis que le bfloat16 sacrifie de la précision au profit d’une plage plus large, ce qui le rend mieux adapté aux charges de travail de machine learning.
`scaled_float`	`Decimal(x, y)`	Stocke des numeric values à virgule fixe.
`date`	`DateTime`	Types de date équivalents avec une précision à la seconde.
`date_nanos`	`DateTime64`	ClickHouse prend en charge une précision à la nanoseconde avec `DateTime64(9)`.
`binary`	`String`, `FixedString(N)`	Nécessite un décodage base64 pour les champs binaires.
`ip`	`IPv4`, `IPv6`	Types `IPv4` et `IPv6` natifs disponibles.
`object`	`Nested`, `Map`, `Tuple`, `JSON`	ClickHouse peut modéliser des objets de type JSON à l’aide de `Nested` ou `JSON`.
`flattened`	`String`	Le type flattened dans Elasticsearch stocke des objets JSON entiers dans un seul champ, ce qui permet un accès flexible et sans schéma aux clés imbriquées sans mappage complet. Dans ClickHouse, une fonctionnalité similaire peut être obtenue à l’aide du type String, mais nécessite un traitement dans des materialized views.
`nested`	`Nested`	Les colonnes ClickHouse `Nested` offrent une sémantique similaire pour les sous-champs groupés, à condition d’utiliser `flatten_nested=0`.
`join`	NA	Il n’existe pas de concept direct de relation parent-enfant. Ce n’est pas nécessaire dans ClickHouse, car les jointures entre tables sont prises en charge.
`alias`	`Alias` modificateur de colonne	Les alias sont pris en charge via un modificateur de colonne. Des fonctions peuvent être appliquées à ces alias, par exemple `size String ALIAS formatReadableSize(size_bytes)`
`range` types (`*_range`)	`Tuple(start, end)` ou `Array(T)`	ClickHouse ne dispose pas de type range natif, mais les plages numériques et de dates peuvent être représentées à l’aide de structures `Tuple(start, end)` ou `Array`. Pour les plages IP (`ip_range`), stockez les valeurs CIDR sous forme de `String` et évaluez-les avec des fonctions comme `isIPAddressInRange()`. Vous pouvez également envisager des dictionnaires de recherche basés sur `ip_trie` pour un filtrage efficace.
`aggregate_metric_double`	`AggregateFunction(...)` et `SimpleAggregateFunction(...)`	Utilisez des aggregate function states et des vues matérialisées pour modéliser des métriques préagrégées. Toutes les fonctions d’agrégation prennent en charge les aggregate states.
`histogram`	`Tuple(Array(Float64), Array(UInt64))`	Représentez manuellement les buckets et les comptages à l’aide de tableaux ou de schémas personnalisés.
`annotated-text`	`String`	Aucune prise en charge intégrée de la recherche sensible aux entités ou des annotations.
`completion`, `search_as_you_type`	NA	Aucun moteur natif d’autocomplétion ou de suggestion. Peut être reproduit avec `String` et des fonctions de recherche.
`semantic_text`	NA	Aucune recherche sémantique native : générez des embeddings et utilisez la recherche vectorielle.
`token_count`	`Int32`	À utiliser lors de l’ingestion pour calculer manuellement le nombre de tokens, par exemple avec la fonction `length(tokens())`, notamment via une colonne matérialisée
`dense_vector`	`Array(Float32)`	Utilisez des tableaux pour stocker les embeddings
`sparse_vector`	`Map(UInt32, Float32)`	Simulez des vecteurs creux avec des `Map`. Aucune prise en charge native des vecteurs creux.
`rank_feature` / `rank_features`	`Float32`, `Array(Float32)`	Pas de pondération native à l’exécution des requêtes, mais cela peut être modélisé manuellement dans la logique de scoring.
`geo_point`	`Tuple(Float64, Float64)` ou `Point`	Utilisez un tuple de (latitude, longitude). `Point` est également disponible comme type ClickHouse.
`geo_shape`, `shape`	`Ring`, `LineString`, `MultiLineString`, `Polygon`, `MultiPolygon`	Prise en charge native des formes géospatiales et de l’indexation spatiale.
`percolator`	NA	Il n’existe pas de concept d’indexation de requêtes. Utilisez plutôt SQL standard + des vues matérialisées incrémentales.
`version`	`String`	ClickHouse n’a pas de type de version natif. Stockez les versions sous forme de chaînes et utilisez des UDF personnalisées pour effectuer des comparaisons sémantiques si nécessaire. Envisagez une normalisation vers des formats numériques si des requêtes par plage sont nécessaires.

Remarques

Tableaux : dans Elasticsearch, tous les champs prennent en charge les tableaux de manière native. Dans ClickHouse, les tableaux doivent être définis explicitement (par ex. Array(String)), avec l’avantage de pouvoir accéder à des positions spécifiques et les interroger, par ex. an_array[1].
Champs multiples : Elasticsearch permet d’indexer un même champ de plusieurs façons (par ex. à la fois comme text et comme keyword). Dans ClickHouse, ce schéma doit être modélisé à l’aide de colonnes ou de vues distinctes.
Types Map et JSON - Dans ClickHouse, le type Map est couramment utilisé pour modéliser des structures dynamiques clé-valeur telles que resourceAttributes et logAttributes. Ce type permet une ingestion flexible sans schéma en autorisant l’ajout de clés arbitraires à l’exécution — dans un esprit proche des objets JSON d’Elasticsearch. Il existe toutefois des limites importantes à prendre en compte :
- Types de valeurs uniformes : les colonnes Map dans ClickHouse doivent avoir un type de valeur cohérent (par ex. Map(String, String)). Les valeurs de types mixtes ne sont pas prises en charge sans coercition.
- Coût en performances : l’accès à n’importe quelle clé dans un Map nécessite de charger la map entière en mémoire, ce qui peut nuire aux performances.
- Pas de sous-colonnes : contrairement à JSON, les clés d’un Map ne sont pas représentées comme de véritables sous-colonnes, ce qui limite la capacité de ClickHouse à indexer, compresser et interroger efficacement.
En raison de ces limitations, ClickStack abandonne progressivement Map au profit du type JSON amélioré de ClickHouse. Le type JSON corrige bon nombre des limites de Map :
- Véritable stockage en colonnes : chaque chemin JSON est stocké sous forme de sous-colonne, ce qui permet une compression, un filtrage et une exécution vectorisée des requêtes efficaces.
- Prise en charge des types mixtes : différents types de données (par ex. entiers, chaînes, tableaux) peuvent coexister sous le même chemin sans coercition ni unification de type.
- Scalabilité du système de fichiers : des limites internes sur les clés dynamiques (max_dynamic_paths) et les types (max_dynamic_types) empêchent une explosion du nombre de fichiers de colonnes sur disque, même avec des ensembles de clés à forte cardinalité.
- Stockage dense : les valeurs nulles et les valeurs manquantes sont stockées de manière clairsemée afin d’éviter toute surcharge inutile.
  
  Le type JSON est particulièrement bien adapté aux charges de travail d’observabilité, en offrant la flexibilité d’une ingestion sans schéma avec les performances et la scalabilité des types natifs de ClickHouse — ce qui en fait un remplacement idéal de Map pour les champs d’attributs dynamiques.
  
  Pour plus de détails sur le type JSON, nous recommandons le guide JSON ainsi que "How we built a new powerful JSON data type for ClickHouse".