Tipos de mapeo

Tipos de mapeo en ClickHouse y Elasticsearch

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