Tipos de mapeo | ClickHouse Docs

Elasticsearch y ClickHouse admiten una amplia variedad de tipos de datos, pero su almacenamiento subyacente y sus modelos de consulta son fundamentalmente distintos. En esta sección se muestran las correspondencias entre los tipos de campo de Elasticsearch más utilizados y sus equivalentes en ClickHouse, cuando existen, y se ofrece contexto para orientar las migraciones. Cuando no existe un equivalente, se incluyen alternativas o notas en los comentarios.

Tipo de Elasticsearch	Equivalente en ClickHouse	Comentarios
`boolean`	`UInt8` o `Bool`	ClickHouse admite `Boolean` como alias de `UInt8` en las versiones más recientes.
`keyword`	`String`	Se usa para filtrado por coincidencia exacta, agrupación y ordenación.
`text`	`String`	La búsqueda de texto completo es limitada en ClickHouse; la tokenización requiere lógica personalizada mediante funciones como `tokens` combinadas con funciones de arrays.
`long`	`Int64`	Entero con signo de 64 bits.
`integer`	`Int32`	Entero con signo de 32 bits.
`short`	`Int16`	Entero con signo de 16 bits.
`byte`	`Int8`	Entero con signo de 8 bits.
`unsigned_long`	`UInt64`	Entero sin signo de 64 bits.
`double`	`Float64`	Coma flotante de 64 bits.
`float`	`Float32`	Coma flotante de 32 bits.
`half_float`	`Float32` o `BFloat16`	Equivalente más cercano. ClickHouse no tiene un tipo de coma flotante de 16 bits. ClickHouse tiene `BFloat16`; este es distinto de Half-float IEE-754: half-float ofrece mayor precisión con un rango menor, mientras que bfloat16 sacrifica precisión a cambio de un rango más amplio, lo que lo hace más adecuado para cargas de trabajo de aprendizaje automático.
`scaled_float`	`Decimal(x, y)`	Almacena valores numéricos de punto fijo.
`date`	`DateTime`	Tipos de fecha equivalentes con precisión de segundos.
`date_nanos`	`DateTime64`	ClickHouse admite precisión de nanosegundos con `DateTime64(9)`.
`binary`	`String`, `FixedString(N)`	Requiere decodificación Base64 para los campos binarios.
`ip`	`IPv4`, `IPv6`	Tipos nativos `IPv4` y `IPv6` disponibles.
`object`	`Nested`, `Map`, `Tuple`, `JSON`	ClickHouse puede modelar objetos similares a JSON usando `Nested` o `JSON`.
`flattened`	`String`	El tipo flattened en Elasticsearch almacena objetos JSON completos como campos únicos, lo que permite acceso flexible y sin esquema a claves anidadas sin necesidad de un mapeo completo. En ClickHouse, puede lograrse una funcionalidad similar usando el tipo String, pero requiere que el procesamiento se realice en vistas materializadas.
`nested`	`Nested`	Las columnas `Nested` de ClickHouse proporcionan una semántica similar para subcampos agrupados, siempre que los usuarios usen `flatten_nested=0`.
`join`	NA	No existe un concepto directo de relaciones padre-hijo. No es necesario en ClickHouse, ya que se admiten JOIN entre tablas.
`alias`	`Alias` modificador de columna	Los alias son compatibles mediante un modificador de campo. Se pueden aplicar funciones a este alias, por ejemplo `size String ALIAS formatReadableSize(size_bytes)`
`range` types (`*_range`)	`Tuple(start, end)` o `Array(T)`	ClickHouse no tiene un tipo range nativo, pero los rangos numéricos y de fecha pueden representarse mediante estructuras `Tuple(start, end)` o `Array`. Para rangos IP (`ip_range`), almacene los valores CIDR como `String` y evalúelos con funciones como `isIPAddressInRange()`. Como alternativa, considere diccionarios de búsqueda basados en `ip_trie` para un filtrado eficiente.
`aggregate_metric_double`	`AggregateFunction(...)` y `SimpleAggregateFunction(...)`	Use estados de funciones de agregación y vistas materializadas para modelar métricas preagregadas. Todas las funciones de agregación admiten estados de agregación.
`histogram`	`Tuple(Array(Float64), Array(UInt64))`	Represente manualmente buckets y recuentos usando arrays o esquemas personalizados.
`annotated-text`	`String`	No hay soporte integrado para búsqueda con reconocimiento de entidades ni anotaciones.
`completion`, `search_as_you_type`	NA	No existe un motor nativo de autocompletado o sugerencias. Puede reproducirse con `String` y funciones de búsqueda.
`semantic_text`	NA	No hay búsqueda semántica nativa; genere embeddings y use búsqueda vectorial.
`token_count`	`Int32`	Úselo durante la ingestión para calcular manualmente el recuento de tokens, por ejemplo con la función `length(tokens())`, por ejemplo con una columna materializada
`dense_vector`	`Array(Float32)`	Use arrays para almacenar embeddings
`sparse_vector`	`Map(UInt32, Float32)`	Simule vectores dispersos con maps. No hay soporte nativo para vectores dispersos.
`rank_feature` / `rank_features`	`Float32`, `Array(Float32)`	No hay refuerzo nativo en tiempo de consulta, pero puede modelarse manualmente en la lógica de puntuación.
`geo_point`	`Tuple(Float64, Float64)` o `Point`	Use una tupla de (latitud, longitud). `Point` está disponible como tipo de ClickHouse.
`geo_shape`, `shape`	`Ring`, `LineString`, `MultiLineString`, `Polygon`, `MultiPolygon`	Soporte nativo para formas geoespaciales e indexación espacial.
`percolator`	NA	No existe el concepto de indexación de consultas. Use SQL estándar + vistas materializadas incrementales en su lugar.
`version`	`String`	ClickHouse no tiene un tipo de versión nativo. Almacene las versiones como cadenas y use funciones UDF personalizadas para realizar comparaciones semánticas si es necesario. Considere normalizarlas a formatos numéricos si se requieren consultas de rango.

Notas

Arrays: En Elasticsearch, todos los campos admiten arrays de forma nativa. En ClickHouse, los arrays deben definirse explícitamente (p. ej., Array(String)), con la ventaja de que se puede acceder a posiciones específicas y consultarlas, p. ej. an_array[1].
Campos múltiples: Elasticsearch permite indexar el mismo campo de varias formas (p. ej., tanto como text y como keyword). En ClickHouse, este patrón debe modelarse mediante columnas o vistas independientes.
Tipos Map y JSON - En ClickHouse, el tipo Map se usa habitualmente para modelar estructuras dinámicas de clave-valor, como resourceAttributes y logAttributes. Este tipo permite una ingestión flexible y sin esquema al admitir claves arbitrarias en tiempo de ejecución, de forma similar a los objetos JSON de Elasticsearch. Sin embargo, hay limitaciones importantes que conviene tener en cuenta:
- Tipos de valor uniformes: las columnas Map de ClickHouse deben tener un tipo de valor coherente (p. ej., Map(String, String)). Los valores de tipos mixtos no se admiten sin coerción.
- Coste en rendimiento: acceder a cualquier clave de un Map requiere cargar el mapa completo en memoria, lo que puede penalizar el rendimiento.
- Sin subcolumnas: a diferencia de JSON, las claves de un Map no se representan como subcolumnas reales, lo que limita la capacidad de ClickHouse para indexar, comprimir y consultar de forma eficiente.
Debido a estas limitaciones, ClickStack está dejando atrás Map en favor del tipo JSON mejorado de ClickHouse. El tipo JSON resuelve muchas de las limitaciones de Map:
- Almacenamiento columnar real: cada ruta JSON se almacena como una subcolumna, lo que permite compresión, filtrado y ejecución vectorizada de consultas de forma eficiente.
- Soporte para tipos mixtos: distintos tipos de datos (p. ej., enteros, cadenas y arrays) pueden coexistir bajo la misma ruta sin coerción ni unificación de tipos.
- Escalabilidad del sistema de archivos: los límites internos sobre claves dinámicas (max_dynamic_paths) y tipos (max_dynamic_types) evitan una explosión de archivos de columna en disco, incluso con conjuntos de claves de alta cardinalidad.
- Almacenamiento denso: los valores nulos y ausentes se almacenan de forma dispersa para evitar una sobrecarga innecesaria.
  
  El tipo JSON es especialmente adecuado para cargas de trabajo de observabilidad, ya que ofrece la flexibilidad de la ingestión sin esquema junto con el rendimiento y la escalabilidad de los tipos nativos de ClickHouse, lo que lo convierte en un reemplazo ideal para Map en campos de atributos dinámicos.
  
  Para obtener más información sobre el tipo JSON, recomendamos la guía de JSON y "How we built a new powerful JSON data type for ClickHouse".