Correspondance des types

Correspondance des types entre ClickHouse et Elasticsearch

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”.