ClickHouse

Cómo funciona

El almacenamiento columnar lee las columnas necesarias y comprime valores similares. En tablas de la familia MergeTree, el orden de los datos influye en cuánto debe leer cada consulta. Las vistas materializadas pueden preparar agregaciones al ingresar nuevos bloques.

Ejemplo: analizar errores por servicio

Sobre una tabla eventos que contiene servicio, nivel y fecha:

SELECT servicio, count() AS errores
FROM eventos
WHERE nivel = 'ERROR'
  AND fecha >= now() - INTERVAL 1 HOUR
GROUP BY servicio
ORDER BY errores DESC;

Diseño de una tabla MergeTree

CREATE TABLE eventos
(
    fecha      DateTime64(3, 'UTC'),
    servicio   LowCardinality(String),
    nivel      LowCardinality(String),
    trace_id   String,
    mensaje    String CODEC(ZSTD(3)),
    duracion_ms UInt32
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(fecha)
ORDER BY (servicio, nivel, fecha)
TTL toDateTime(fecha) + INTERVAL 90 DAY DELETE;

Elemento	Decisión
ORDER BY	Columnas por las que más se filtra, de menor a mayor cardinalidad
PARTITION BY	Por mes o día, para gestionar retención; no para acelerar consultas
LowCardinality	Diccionario para columnas con pocos valores distintos (servicio, país)
CODEC	Compresión adicional para texto o series numéricas
TTL	Borrado o movimiento automático a almacenamiento frío

El índice primario es disperso: guarda una entrada cada 8 192 filas (por defecto). Si la consulta filtra por las primeras columnas del ORDER BY, ClickHouse salta bloques enteros; si filtra por una columna que no está, lee toda la tabla.

Familia de motores

Motor	Uso
MergeTree	Base general para datos de eventos
ReplacingMergeTree	Conservar la última versión por clave (deduplicación eventual)
SummingMergeTree / AggregatingMergeTree	Agregados preparados mediante vistas materializadas
Replicated*	Réplicas en clústeres autogestionados

La deduplicación ocurre en las fusiones en segundo plano: hasta entonces pueden verse duplicados, salvo que se consulte con FINAL.

Vista materializada para agregados

CREATE TABLE errores_por_minuto
(minuto DateTime, servicio LowCardinality(String), errores UInt64)
ENGINE = SummingMergeTree ORDER BY (servicio, minuto);

CREATE MATERIALIZED VIEW mv_errores TO errores_por_minuto AS
SELECT toStartOfMinute(fecha) AS minuto, servicio, count() AS errores
FROM eventos WHERE nivel = 'ERROR'
GROUP BY minuto, servicio;

La vista actúa como un trigger de inserción: procesa cada bloque nuevo, no recalcula el histórico. Para datos anteriores hay que rellenar la tabla destino manualmente.

Buenas prácticas de ingesta

• Inserta en lotes grandes (miles a cientos de miles de filas) o activa async_insert; muchas inserciones pequeñas crean demasiadas parts.
• Evita UPDATE y DELETE frecuentes: son mutaciones costosas. Modela con versiones o borrados lógicos.
• Para ingesta desde Kafka, usa el motor Kafka con una vista materializada, ClickPipes o un conector.

Cuándo usarlo

Encaja	No encaja
Analítica de eventos, logs, métricas, clickstream	Cargas transaccionales con muchas actualizaciones
Dashboards con agregaciones sobre miles de millones de filas	Joins complejos entre muchas tablas grandes
Observabilidad (motor de SigNoz)	Consistencia fuerte por fila

Para datos transaccionales, PostgreSQL; para consultas federadas sobre un lakehouse, Trino.

Criterios de implementación

Diseña claves de orden y retención a partir de las consultas. Evita una partición por cada valor de alta cardinalidad. Revisa la semántica de inserciones y agregaciones antes de asumir que una vista materializada refleja cambios históricos.