ClickHouse

La base de datos OLAP columnar que escanea miles de millones de filas por segundo.

Database #analytics#olap#columnar

ClickHouse es una base de datos de analítica en tiempo real que usa almacenamiento columnar, compresión agresiva, ejecución vectorizada y procesamiento paralelo para entregar consultas sub-segundo sobre tablas con cientos de miles de millones de filas. Usado por Cloudflare, Uber, eBay, Bloomberg, Yandex.

Desplegar con Pier

1 Abre el panel de Pier y haz clic en Add service.
2 Elige ClickHouse en la lista de plantillas.
3 Elige la versión, asigna un nombre al servicio y Pier provisionará automáticamente el contenedor, el almacenamiento y los puertos.
4 Vincula un dominio si quieres HTTPS. Traefik genera el certificado de Let's Encrypt automáticamente.

¿Qué es ClickHouse?

ClickHouse es una base de datos OLAP columnar construida originalmente en Yandex (release open-source 2016) para alimentar Yandex Metrica — un servicio de web analytics procesando cientos de miles de millones de eventos al día. Hoy respalda las analytics Edge de Cloudflare, el data warehouse de eBay, los logs de Uber, los datos de mercado de Bloomberg y la mayor parte del stack moderno de observabilidad open-source (SigNoz, PostHog, Tinybird, Plausible).

La elección arquitectónica — almacenamiento columnar + ejecución vectorizada + compresión agresiva — hace que las consultas de agregación sean 10–100× más rápidas que en row stores como PostgreSQL o MySQL en tablas anchas de eventos. El trade-off: semántica transaccional más débil, sin UPDATE/DELETE a nivel de fila (las mutations son batches asíncronos) y un modelo mental que requiere ajuste si vienes de OLTP.

Cómo lo despliega Pier

Pier usa la imagen Docker oficial clickhouse/clickhouse-server, exponiendo los puertos 8123 (HTTP) y 9000 (TCP nativo). El volumen de datos se monta en /var/lib/clickhouse. La versión por defecto es latest; 25-alpine, 24-alpine y 23-alpine son variantes LTS-ish fijadas.

El modo clúster soporta 2–5 nodos para read-scale y replicación. El sharding vía motor Distributed sigue requiriendo macros + configuración de réplicas manual tras levantar el clúster.

Los backups usan clickhouse-backup y pueden subirse a cualquier almacenamiento compatible con S3.

Cuándo NO usar ClickHouse

Para OLTP — Postgres o MySQL. Para lookups single-row — KV stores. Para búsqueda full-text — Elasticsearch. ClickHouse es para cargas analíticas a escala; por debajo de ~50GB y unos millones de filas, bases de datos más simples suelen ser bastante rápidas.

Características clave

Almacenamiento columnar

Almacena cada columna en un archivo separado con compresión por diccionario, delta y LZ4/ZSTD. Las agregaciones escanean solo las columnas que necesitan — órdenes de magnitud menos I/O que bases de datos row-store.

Ejecución vectorizada de queries

Instrucciones SIMD procesan lotes de valores por ciclo de CPU. Un solo core maneja decenas de millones de filas por segundo en agregaciones.

Motor de almacenamiento MergeTree

Motor sort-merge optimizado para datos de series temporales y eventos append-heavy. Los merges en background mantienen los datos físicamente ordenados por primary key.

SQL con extensiones

ANSI SQL más extensiones específicas de ClickHouse — arrays como first-class, lambdas, cuantiles aproximados, sketches (HyperLogLog, T-Digest), window functions y ASOF JOINs.

Queries distribuidas (modo clúster)

Capa de queries federadas sobre múltiples shards y réplicas. Pier soporta clústers de 2–5 nodos para read-scale shardeado.

Ingesta en tiempo real

INSERTs bulk a millones de filas por segundo por nodo. HTTP, TCP nativo, protocolo MySQL, protocolo PostgreSQL, motor Kafka — elige tu camino de ingesta.

Casos de uso

Web analytics y telemetría de producto

Yandex Metrica (el caso original), PostHog, Plausible, Tinybird — toda plataforma de web analytics moderna corre sobre ClickHouse.

Observabilidad de aplicación

SigNoz, Highlight, Uptrace almacenan traces, logs y métricas en ClickHouse. Más rápido y barato que Elasticsearch para ingesta de logs de alto volumen.

Dashboards BI en tiempo real

Respuestas sub-segundo sobre cientos de millones de filas — perfecto para dashboards operativos en vivo alimentados por Grafana, Metabase, Superset.

AdTech y atribución marketing

Agregación de click-stream, análisis de cohortes, queries de funnel — cargas donde columnar gana por 100×+ sobre row stores.

Datos de mercados financieros

Almacenamiento de ticks, replay de order book, backtesting — ASOF JOIN encuentra coincidencias cercanas en el tiempo sin window functions.

Ejemplos de código

Crear una tabla MergeTree sql

CREATE TABLE events (
  ts          DateTime64(3) CODEC(Delta, ZSTD),
  user_id     UInt64,
  event_type  LowCardinality(String),
  properties  Map(String, String),
  country     LowCardinality(FixedString(2))
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
ORDER BY (event_type, user_id, ts);

Agregar mil millones de filas en segundos sql

SELECT toStartOfHour(ts) AS hour,
       event_type,
       count() AS n,
       uniqExact(user_id) AS unique_users
FROM events
WHERE ts > now() - INTERVAL 7 DAY
GROUP BY hour, event_type
ORDER BY hour;

Cuantiles aproximados (HyperLogLog + T-Digest) sql

SELECT
  quantilesTDigest(0.5, 0.9, 0.99)(response_ms) AS p50_p90_p99,
  uniqHLL12(user_id) AS approx_unique_users
FROM events
WHERE ts > now() - INTERVAL 1 HOUR;

ASOF JOIN (estilo financiero nearest-in-time) sql

SELECT t.ts, t.symbol, t.price, q.bid, q.ask
FROM trades t
ASOF LEFT JOIN quotes q
  ON t.symbol = q.symbol
 AND t.ts >= q.ts;

Comparativa

vs PostgreSQL	Postgres gana en transacciones, joins, mutabilidad y estándar SQL. ClickHouse gana por 10–100× en agregaciones analíticas sobre tablas anchas de eventos. Muchos stacks usan ambos.
vs TimescaleDB	TimescaleDB mantiene la ergonomía Postgres con hypertables y agregados continuos. ClickHouse es más agresivo — ganancias OLAP más amplias, más débil en consistencia, joins y mutabilidad.
vs Elasticsearch	Elastic destaca en full-text y consultas JSON dinámicas. ClickHouse es 10× más barato almacenando y consultando datos de eventos estructurados. Muchos stacks de observabilidad migraron logs de Elastic a ClickHouse.
vs Snowflake / BigQuery	OLAP columnar gestionado — misma familia arquitectónica. ClickHouse autohospedado es dramáticamente más barato para cargas predecibles. Gestionado en cloud gana en cero-admin y elasticidad.

Preguntas frecuentes

¿ClickHouse es compatible con SQL?

Principalmente — ANSI SQL con extensiones ClickHouse. Los JOINs funcionan pero no son su fuerte; las agregaciones OLAP y operaciones sobre arrays/maps sí lo son. No esperes semántica transaccional (históricamente solo INSERT, sin UPDATE/DELETE a nivel de fila; las mutations existen pero son asíncronas).

¿Puertos por defecto?

8123/tcp para HTTP, 9000/tcp para protocolo TCP nativo. Pier expone ambos. Los drivers JDBC/ODBC usan HTTP; el `clickhouse-client` oficial usa 9000 nativo.

¿El modo clúster requiere config manual?

Pier soporta clústers de 2–5 nodos para read-scale y replicación. El sharding y tablas distribuidas siguen requiriendo algo de configuración manual tras el deploy — ver docs de ClickHouse.

¿Las mutations son seguras en producción?

ALTER TABLE ... DELETE / UPDATE son asíncronas y caras. Prefiere diseñar schemas donde los DELETEs sean por drop de partición (ALTER TABLE ... DROP PARTITION) y los updates sean append-then-deduplicate vía ReplacingMergeTree.

¿Conexión desde herramientas BI?

Grafana, Metabase, Superset, Tableau todas tienen conectores ClickHouse nativos. JDBC para Java/Kotlin. ODBC para Power BI/Excel.

¿Backups?

Pier incluye backups programados vía `clickhouse-backup` para dumps completos o por base de datos. Puede subir a cualquier store compatible con S3.

¿Cuándo NO usarlo?

Cargas transaccionales — elige Postgres. Lookups single-row por clave — elige Postgres o un KV store. Búsqueda full-text — elige Elasticsearch. Datasets sub-100GB — las queries analíticas de Postgres suelen ser lo bastante rápidas.

Servicios relacionados

Desplegar en tu VPS

Desplegar este servicio →