Elastic Stack vs ClickStack
- UI y alertas: herramientas para consultar datos, crear dashboards y gestionar alertas.
- Almacenamiento y motor de consultas: los sistemas de backend responsables de almacenar datos de observabilidad y servir consultas analíticas.
- Recopilación de datos y ETL: agentes y canalizaciones que recopilan datos de telemetría y los procesan antes de la ingestión.
| Rol | Elastic Stack | ClickStack | Comentarios |
|---|---|---|---|
| UI y alertas | Kibana — dashboards, búsqueda y alertas | ClickStack UI (HyperDX) — UI en tiempo real, búsqueda y alertas | Ambos sirven como interfaz principal para los usuarios, incluidas las visualizaciones y la gestión de alertas. La UI de ClickStack está diseñada específicamente para la observabilidad y estrechamente acoplada a la semántica de OpenTelemetry. |
| Almacenamiento y motor de consultas | Elasticsearch — almacén de documentos JSON con índice invertido | ClickHouse — base de datos orientada a columnas con motor vectorizado | Elasticsearch usa un índice invertido optimizado para búsquedas; ClickHouse usa almacenamiento columnar y SQL para analítica de alta velocidad sobre datos estructurados y semiestructurados. |
| Recopilación de datos | Elastic Agent, Beats (p. ej., Filebeat, Metricbeat) | OpenTelemetry Collector (edge + gateway) | Elastic admite shippers personalizados y un agente unificado gestionado por Fleet. ClickStack se basa en OpenTelemetry, lo que permite una recopilación y un procesamiento de datos independientes del proveedor. |
| SDKs de instrumentación | Elastic APM agents (propietarios) | OpenTelemetry SDKs (distribuidos por ClickStack) | Los SDKs de Elastic están vinculados al stack de Elastic. ClickStack se basa en los SDKs de OpenTelemetry para logs, métricas y traces en los principales lenguajes. |
| ETL / Procesamiento de datos | Logstash, canalizaciones de ingestión | OpenTelemetry Collector + vistas materializadas de ClickHouse | Elastic usa canalizaciones de ingestión y Logstash para la transformación. ClickStack desplaza el procesamiento al momento de inserción mediante vistas materializadas y procesadores del OTel collector, que transforman los datos de forma eficiente e incremental. |
| Filosofía de arquitectura | Integración vertical, agentes y formatos propietarios | Componentes basados en estándares abiertos y débilmente acoplados | Elastic crea un ecosistema estrechamente integrado. ClickStack enfatiza la modularidad y los estándares (OpenTelemetry, SQL, almacenamiento de objetos) para ofrecer flexibilidad y eficiencia de costos. |
Elasticsearch vs ClickHouse
Conceptos estructurales principales
| Elasticsearch | ClickHouse / SQL | Descripción |
|---|---|---|
| Campo | Columna | La unidad básica de los datos, que contiene uno o más valores de un tipo específico. Los campos de Elasticsearch pueden almacenar tipos primitivos, así como arrays y objetos. Los campos solo pueden tener un tipo. ClickHouse también admite arrays y objetos (Tuples, Maps, Nested), además de tipos dinámicos como Variant y Dynamic, que permiten que una columna tenga varios tipos. |
| Documento | Fila | Una colección de campos (columnas). De forma predeterminada, los documentos de Elasticsearch son más flexibles, ya que se pueden añadir nuevos campos dinámicamente en función de los datos (el tipo se infiere a partir de ). En cambio, las filas de ClickHouse están sujetas a un esquema por defecto, por lo que los usuarios deben insertar todas las columnas de una fila o solo un subconjunto. El tipo JSON de ClickHouse admite una creación equivalente de columnas dinámicas semiestructuradas a partir de los datos insertados. |
| Índice | Tabla | La unidad de ejecución de consultas y de almacenamiento. En ambos sistemas, las consultas se ejecutan sobre índices o tablas, que almacenan filas/documentos. |
| Implícito | Esquema (SQL) | Los esquemas SQL agrupan tablas en espacios de nombres y suelen usarse para el control de acceso. Elasticsearch y ClickHouse no tienen esquemas, pero ambos admiten seguridad a nivel de fila y de tabla mediante roles y RBAC. |
| Clúster | Clúster / Base de datos | Los clústeres de Elasticsearch son instancias en tiempo de ejecución que gestionan uno o varios índices. En ClickHouse, las bases de datos organizan tablas dentro de un espacio de nombres lógico, lo que proporciona la misma agrupación lógica que un clúster en Elasticsearch. Un clúster de ClickHouse es un conjunto distribuido de nodos, similar al de Elasticsearch, pero está desacoplado y es independiente de los propios datos. |
Modelado de datos y flexibilidad
Dynamic, Variant y JSON. Estos permiten la ingestión de datos semiestructurados, con creación dinámica de columnas e inferencia de tipos similar a Elasticsearch. Del mismo modo, el tipo Map permite almacenar pares clave-valor arbitrarios, aunque se aplica un único tipo tanto para la clave como para el valor.
El enfoque de ClickHouse respecto a la flexibilidad de tipos es más transparente y controlado. A diferencia de Elasticsearch, donde los conflictos de tipos pueden causar errores de ingestión, ClickHouse permite datos de tipos mixtos en columnas Variant y admite la evolución del esquema mediante el uso del tipo JSON.
Si no se usa JSON, el esquema se define estáticamente. Si no se proporcionan valores para una fila, estos se definirán como Nullable (no se usa en ClickStack) o volverán al valor predeterminado del tipo; por ejemplo, un valor vacío para String.
Ingestión y transformación
enrich, rename, grok) para transformar documentos antes de indexarlos. En ClickHouse, una funcionalidad similar se consigue mediante vistas materializadas incrementales, que pueden filtrar y transformar, o enriquecer los datos entrantes e insertar los resultados en tablas de destino. También puede insertar datos en un motor de tabla Null si solo necesita almacenar la salida de la vista materializada. Esto significa que solo se conservan los resultados de las vistas materializadas, mientras que los datos originales se descartan, lo que ahorra espacio de almacenamiento.
Para el enriquecimiento, Elasticsearch admite procesadores enrich específicos para añadir contexto a los documentos. En ClickHouse, los diccionarios pueden utilizarse tanto en tiempo de consulta como en tiempo de ingestión para enriquecer filas; por ejemplo, para asociar IP con ubicaciones o aplicar búsquedas de user-agent al insertar.
Lenguajes de consulta
ES|QL. ClickHouse admite la sintaxis SQL completa, incluidos todos los tipos de join, funciones de ventana, subconsultas (incluidas las correlacionadas) y CTE. Esto supone una gran ventaja si necesita correlacionar señales de observabilidad con datos de negocio o de infraestructura.
En ClickStack, la UI proporciona una interfaz de búsqueda compatible con Lucene para facilitar la transición, junto con compatibilidad completa con SQL a través del backend de ClickHouse. Esta sintaxis es comparable a la sintaxis de query string de Elastic. Para ver una comparación exacta de esta sintaxis, consulte “Searching in ClickStack and Elastic”.
Formatos de archivo e interfaces
Indexación y almacenamiento
segmentación es fundamental en el modelo de escalabilidad de Elasticsearch. Cada ① índice se divide en segmentos, cada uno de los cuales es un índice físico de Lucene almacenado como segmentos en disco. Un segmento puede tener una o más copias físicas, llamadas segmentos de réplica, para aportar resiliencia. Para escalar, los segmentos y las réplicas pueden distribuirse entre varios nodos. Un solo segmento ② consta de uno o más segmentos inmutables. Un segmento es la estructura básica de indexación de Lucene, la biblioteca de Java que proporciona las funciones de indexación y búsqueda en las que se basa Elasticsearch.
Procesamiento de inserciones en ElasticsearchⒶ Los documentos recién insertados Ⓑ pasan primero a un búfer de indexación en memoria que, de forma predeterminada, se vacía una vez por segundo. Se utiliza una fórmula de enrutamiento para determinar el segmento de destino de los documentos volcados, y se escribe un nuevo segmento para ese segmento en disco. Para mejorar la eficiencia de las consultas y permitir la eliminación física de los documentos eliminados o actualizados, los segmentos se fusionan continuamente en segundo plano en segmentos más grandes hasta alcanzar un tamaño máximo de 5 GB. No obstante, es posible forzar la fusión en segmentos aún mayores.
segmentación al escalado, ya que se requieren más segmentos (y nodos) para aumentar el rendimiento.
Elasticsearch indexa todos los campos en índices invertidos para acelerar las búsquedas, y puede usar opcionalmente doc values para agregaciones, ordenación y acceso a campos mediante scripts. Los campos numéricos y geográficos utilizan árboles Block K-D para búsquedas sobre datos geoespaciales y sobre rangos numéricos y de fechas.
Es importante destacar que Elasticsearch almacena el documento original completo en _source (comprimido con LZ4, Deflate o ZSTD), mientras que ClickHouse no almacena una representación independiente del documento. Los datos se reconstruyen a partir de las columnas en tiempo de consulta, lo que ahorra espacio de almacenamiento. Esta misma capacidad también es posible en Elasticsearch mediante Synthetic _source, con algunas restricciones. Deshabilitar _source también tiene implicaciones que no se aplican a ClickHouse.
En Elasticsearch, los mapeos de índice (equivalentes a los esquemas de tabla en ClickHouse) controlan el tipo de campos y las estructuras de datos utilizadas para esta persistencia y consulta.
ClickHouse, en cambio, es orientado a columna: cada columna se almacena de forma independiente, pero siempre ordenada según la clave primaria o clave de ordenación de la tabla. Esta ordenación permite índices primarios dispersos, que permiten a ClickHouse omitir datos de forma eficiente durante la ejecución de consultas. Cuando las consultas filtran por campos de la clave primaria, ClickHouse lee solo las partes relevantes de cada columna, lo que reduce significativamente la E/S de disco y mejora el rendimiento, incluso sin un índice completo en cada columna.
ClickHouse también admite índices de omisión, que aceleran el filtrado al precalcular datos de índice para las columnas seleccionadas. Deben definirse explícitamente, pero pueden mejorar significativamente el rendimiento. Además, ClickHouse permite especificar codecs de compresión y algoritmos de compresión por columna, algo que Elasticsearch no admite (su compresión solo se aplica al almacenamiento JSON de _source).
ClickHouse también admite sharding, pero su modelo está diseñado para favorecer el escalado vertical. Un solo segmento puede almacenar billones de filas y seguir ofreciendo un buen rendimiento siempre que la memoria, la CPU y el disco lo permitan. A diferencia de Elasticsearch, no existe un límite estricto de filas por segmento. Los segmentos en ClickHouse son lógicos — en la práctica, tablas individuales — y no requieren particionamiento a menos que el conjunto de datos supere la capacidad de un solo nodo. Esto suele ocurrir por limitaciones de espacio en disco, y el sharding ① se introduce solo cuando es necesario escalar horizontalmente, lo que reduce la complejidad y la sobrecarga. En este caso, al igual que en Elasticsearch, un segmento contendrá un subconjunto de los datos. Los datos dentro de un único segmento se organizan como una colección de ② partes de datos inmutables que contienen ③ varias estructuras de datos.
El procesamiento dentro de un segmento de ClickHouse está totalmente paralelizado, y se recomienda a los usuarios escalar verticalmente para evitar los costes de red asociados al movimiento de datos entre nodos.
Procesamiento de inserciones en ClickHouseLas inserciones en ClickHouse son sincrónicas de forma predeterminada — la escritura solo se confirma tras el commit — pero pueden configurarse como inserciones asíncronas para ajustarse al almacenamiento en búfer y la agrupación por lotes al estilo de Elastic. Si se usan inserciones de datos asíncronas, Ⓐ las filas recién insertadas pasan primero a un Ⓑ búfer de inserción en memoria, que se vacía de forma predeterminada cada 200 milisegundos. Si se usan varios segmentos, se utiliza una tabla distribuida para dirigir las filas recién insertadas a su segmento de destino. Se escribe una nueva parte en disco para el segmento.
Distribución y replicación
SELECT a todos los segmentos y fusionando los resultados. Para las operaciones INSERT, equilibran la carga distribuyendo los datos de manera uniforme entre segmentos. La replicación de ClickHouse es muy flexible: cualquier réplica (una copia de un segmento) puede aceptar escrituras, y todos los cambios se sincronizan de forma asíncrona con las demás. Esta arquitectura permite seguir sirviendo consultas sin interrupciones durante fallos o tareas de mantenimiento, con la resincronización gestionada automáticamente, lo que elimina la necesidad de imponer un esquema primario-secundario en la capa de datos.
ClickHouse CloudEn ClickHouse Cloud, la arquitectura introduce un modelo de cómputo shared-nothing en el que un único segmento se respalda en almacenamiento de objetos. Esto sustituye la alta disponibilidad tradicional basada en réplicas, lo que permite que el segmento pueda leerse y escribirse desde varios nodos simultáneamente. La separación entre almacenamiento y cómputo permite un escalado elástico sin necesidad de gestionar réplicas explícitamente.
- Elastic: Los segmentos son estructuras físicas de Lucene vinculadas a la memoria de la JVM. Un exceso de segmentación introduce penalizaciones de rendimiento. La replicación es síncrona y está coordinada por un nodo maestro.
- ClickHouse: Los segmentos son lógicos y escalables verticalmente, con una ejecución local muy eficiente. La replicación es asíncrona (aunque puede ser secuencial), y la coordinación es ligera.
Deduplicación y enrutamiento
_id y los enruta a los segmentos correspondientes. ClickHouse no almacena un identificador de fila predeterminado, pero admite la deduplicación durante la inserción, lo que permite a los usuarios reintentar inserciones fallidas de forma segura. Para un mayor control, ReplacingMergeTree y otros motores de tabla permiten la deduplicación por columnas específicas.
El enrutamiento de índices en Elasticsearch garantiza que determinados documentos siempre se enruten a segmentos específicos. En ClickHouse, puede definir claves de segmento o usar tablas Distributed para lograr una localidad de datos similar.
Agregaciones y modelo de ejecución
SELECT count(*) FROM ... GROUP BY ... es la agregación de términos, que es una agregación de buckets de Elasticsearch.
El GROUP BY de ClickHouse con count(*) y la agregación de términos de Elasticsearch suelen ser equivalentes en funcionalidad, pero difieren mucho en su implementación, rendimiento y calidad de resultados.
En Elasticsearch, esta agregación estima los resultados en consultas “top-N” (por ejemplo, los 10 hosts principales por recuento) cuando los datos consultados abarcan múltiples segmentos. Esta estimación mejora la velocidad, pero puede comprometer la precisión. Puede reducir este error inspeccionando doc_count_error_upper_bound y aumentando el parámetro shard_size, a costa de un mayor uso de memoria y un peor rendimiento de la consulta.
Elasticsearch también requiere un ajuste size para todas las agregaciones en buckets: no hay forma de devolver todos los grupos únicos sin establecer explícitamente un límite. Las agregaciones de alta cardinalidad corren el riesgo de alcanzar los límites de max_buckets o requieren paginación con una agregación compuesta, lo que suele ser complejo e ineficiente.
ClickHouse, en cambio, realiza agregaciones exactas de forma predeterminada. Funciones como count(*) devuelven resultados precisos sin necesidad de ajustar la configuración, lo que hace que el comportamiento de las consultas sea más simple y predecible.
ClickHouse no impone límites de tamaño. Puede realizar consultas de agrupación sin límites sobre grandes conjuntos de datos. Si se superan los umbrales de memoria, ClickHouse puede volcar datos a disco. Las agregaciones que agrupan por un prefijo de la clave primaria son especialmente eficientes y a menudo se ejecutan con un consumo de memoria mínimo.
Modelo de ejecución
LIMIT.
La ejecución de consultas se paraleliza aún más mediante:
- Vectorización SIMD: las operaciones sobre datos columnares utilizan instrucciones SIMD de CPU (p. ej., AVX512), lo que permite procesar valores por lotes.
- Paralelismo a nivel de clúster: en configuraciones distribuidas, cada nodo realiza el procesamiento de consultas localmente. Los estados parciales de agregación se transmiten al nodo que inicia la consulta y se fusionan. Si las claves de
GROUP BYde la consulta están alineadas con las claves de sharding, la fusión puede reducirse al mínimo o evitarse por completo.
Este modelo permite escalar de forma eficiente entre núcleos y nodos, lo que hace que ClickHouse sea muy adecuado para análisis a gran escala. El uso de estados parciales de agregación permite fusionar resultados intermedios de distintos hilos y nodos sin pérdida de precisión. Elasticsearch, por el contrario, asigna un hilo por segmento para la mayoría de las agregaciones, independientemente de cuántos núcleos de CPU haya disponibles. Estos hilos devuelven resultados top-N locales por segmento, que se fusionan en el nodo coordinador. Este enfoque puede infrautilizar los recursos del sistema e introducir posibles imprecisiones en las agregaciones globales, especialmente cuando los términos frecuentes se distribuyen entre varios segmentos. La precisión puede mejorarse aumentando el parámetro
shard_size, pero esto tiene el coste de un mayor uso de memoria y una mayor latencia de consulta.
En resumen, ClickHouse ejecuta agregaciones y consultas con un paralelismo más granular y un mayor control sobre los recursos de hardware, mientras que Elasticsearch se basa en una ejecución por segmentos con restricciones más rígidas.
Para obtener más detalles sobre la mecánica de las agregaciones en estas tecnologías, recomendamos la entrada del blog “ClickHouse vs. Elasticsearch: la mecánica de las agregaciones de conteo”.
Gestión de datos
Gestión del ciclo de vida de índices vs. TTL nativo
Niveles de almacenamiento y arquitecturas hot-warm
MergeTree, que pueden mover automáticamente los datos más antiguos entre distintos volúmenes (por ejemplo, de SSD a HDD y a almacenamiento de objetos) según reglas personalizadas. Esto puede reproducir el enfoque hot-warm-cold de Elastic, pero sin la complejidad de gestionar múltiples roles de nodo o clústeres.
ClickHouse CloudEn ClickHouse Cloud, esto es aún más transparente: todos los datos se almacenan en almacenamiento de objetos (p. ej., S3), y el cómputo está desacoplado. Los datos pueden permanecer en el almacenamiento de objetos hasta que se consultan; en ese momento, se recuperan y se almacenan en caché localmente (o en una caché distribuida), lo que ofrece el mismo perfil de coste que el nivel frozen de Elastic, con mejores características de rendimiento. Este enfoque significa que no es necesario mover datos entre niveles de almacenamiento, por lo que las arquitecturas hot-warm se vuelven redundantes.
Rollups vs agregaciones incrementales
blue (11, 12 y 13) que existen desde el checkpoint anterior. Por lo tanto, el índice de origen se filtra para incluir todos los documentos blue existentes y, con una agregación compuesta (para aprovechar la paginación de resultados), se recalculan los valores agregados (y el índice de destino se actualiza con un documento que sustituye al que contenía los valores de agregación anteriores). Del mismo modo, en ② y ③, se procesan nuevos checkpoints comprobando si hay cambios y recalculando los valores agregados a partir de todos los documentos existentes que pertenecen al mismo bucket blue.
ClickHouse adopta un enfoque fundamentalmente distinto. En lugar de volver a agregar los datos periódicamente, ClickHouse admite vistas materializadas incrementales, que transforman y agregan los datos en el momento de la inserción. Cuando se escriben nuevos datos en una tabla de origen, una vista materializada ejecuta una consulta SQL de agregación predefinida solo sobre los nuevos bloques insertados y escribe los resultados agregados en una tabla de destino.
Este modelo es posible gracias al soporte de ClickHouse para estados parciales de agregación, representaciones intermedias de funciones de agregación que pueden almacenarse y fusionarse posteriormente. Esto permite mantener resultados parcialmente agregados que son rápidos de consultar y baratos de actualizar. Dado que la agregación se produce a medida que llegan los datos, no es necesario ejecutar tareas recurrentes costosas ni volver a resumir datos antiguos.
A continuación esbozamos de forma abstracta el funcionamiento de las vistas materializadas incrementales (ten en cuenta que usamos el color azul para todas las filas que pertenecen al mismo grupo para el que queremos precalcular valores agregados):
En el diagrama anterior, la tabla de origen de la vista materializada ya contiene una parte de datos que almacena algunas filas blue (de la 1 a la 10) que pertenecen al mismo grupo. Para este grupo, también existe ya una parte de datos en la tabla de destino de la vista que almacena un estado parcial de agregación para el grupo blue. Cuando se producen inserciones ① ② ③ en la tabla de origen con nuevas filas, se crea una parte de datos correspondiente en la tabla de origen para cada inserción y, en paralelo, (solo) para cada bloque de filas recién insertadas, se calcula un estado parcial de agregación y se inserta, en forma de parte de datos, en la tabla de destino de la vista materializada. ④ Durante las fusiones de partes en segundo plano, los estados parciales de agregación se fusionan, lo que da como resultado una agregación incremental de datos.
Ten en cuenta que todas las funciones de agregación (más de 90), incluidas sus combinaciones con combinadores de funciones de agregación, admiten estados parciales de agregación.
Para ver un ejemplo más concreto de Elasticsearch frente a ClickHouse para agregaciones incrementales, consulta este ejemplo.
Las ventajas del enfoque de ClickHouse incluyen:
- Agregados siempre actualizados: las vistas materializadas siempre están sincronizadas con la tabla de origen.
- Sin procesos en segundo plano: las agregaciones se realizan en el momento de la inserción en lugar de en tiempo de consulta.
- Mejor rendimiento en tiempo real: ideal para cargas de trabajo de observabilidad y análisis en tiempo real en los que se necesitan agregados recientes de inmediato.
- Combinables: las vistas materializadas pueden encadenarse o unirse con otras vistas y tablas para estrategias más complejas de aceleración de consultas.
- TTL distintos: se pueden aplicar configuraciones de TTL diferentes a la tabla de origen y a la tabla de destino de la vista materializada.
Soporte para lakehouse
- Integración con catálogos de datos: ClickHouse admite la integración con catálogos de datos como AWS Glue, lo que permite descubrir automáticamente tablas en almacenamiento de objetos y acceder a ellas.
- Compatibilidad con almacenamiento de objetos: compatibilidad nativa para consultar datos ubicados en S3, GCS y Azure Blob Storage sin necesidad de mover los datos.
- Federación de consultas: capacidad para correlacionar datos de múltiples fuentes, incluidas tablas de lakehouse, bases de datos tradicionales y tablas de ClickHouse, mediante diccionarios externos y funciones de tabla.
- Carga incremental: compatibilidad con la carga continua desde tablas de lakehouse hacia tablas locales MergeTree, mediante funcionalidades como S3Queue y ClickPipes.
- Optimización del rendimiento: ejecución distribuida de consultas sobre datos de lakehouse mediante funciones de clúster para mejorar el rendimiento.