Categoría: Bases de datos
ClickHouse gestionado: analítica en tiempo real en vuestra propia cuenta
Consultas sobre miles de millones de filas en segundos, en un ClickHouse que vive en vuestra cuenta cloud, con réplicas, copias que se restauran y un diseño de tablas pensado para vuestras consultas reales.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Open source, Apache 2.0
En resumen
ClickHouse es una base de datos analítica de código abierto, orientada a columnas, que responde consultas sobre grandes volúmenes de datos en tiempo real. La instalamos y operamos en vuestra cuenta cloud: diseño de tablas MergeTree, réplicas con ClickHouse Keeper, copias a S3 restauradas en pruebas, retención con TTL, límites de recursos, métricas y actualizaciones, todo en código en vuestro repositorio.
¿Qué nos encargamos de mantener?
ClickHouse es muy rápido cuando las tablas están bien diseñadas y muy frustrante cuando no. Buena parte de nuestro trabajo es ese diseño; el resto es lo de cualquier base de datos en producción: réplicas, copias, límites y actualizaciones.
Tablas MergeTree
Motor, ORDER BY y particiones elegidos según vuestras consultas.
Réplicas y Keeper
ReplicatedMergeTree coordinado por ClickHouse Keeper en tres nodos.
Copias
BACKUP completo e incremental a S3, con restauración de prueba.
Límites
Perfiles, cuotas y memoria máxima por consulta y por usuario.
Métricas
Tablas de sistema y punto de métricas para Prometheus.
En código
Configuración y esquemas versionados en vuestro repositorio.
¿Cómo diseñamos las tablas?
En la familia MergeTree, ORDER BY define cómo se ordenan los datos en disco y el índice disperso que permite saltarse bloques enteros. Ponemos primero las columnas por las que más filtráis, de menor a mayor variedad, y la fecha cerca del final. La partición, normalmente por mes, sirve para borrar o mover datos antiguos de golpe, no para acelerar consultas: particiones demasiado finas dan problemas.
Según el caso usamos variantes: ReplacingMergeTree para quedarse con la última versión de cada fila, AggregatingMergeTree con vistas materializadas para tener totales precalculados, o TTL para borrar o mover a almacenamiento en frío los datos que ya no se consultan cada día.
¿Qué arquitectura recomendamos?
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Analítica interna, se tolera un rato de corte | Un servidor y copias diarias a S3 | Rápido y sencillo; la recuperación está probada |
| Producción que no puede parar | Dos réplicas y ClickHouse Keeper en tres nodos | Si cae una réplica, la otra sigue respondiendo |
| Volumen que no cabe en un servidor | Varios fragmentos con réplica y una tabla Distributed | Reparte datos y consultas entre servidores |
Keeper va siempre en número impar, tres como mínimo, y preferiblemente en máquinas separadas de ClickHouse cuando la carga es alta. Una réplica no protege de un DROP TABLE por error: el borrado se replica, así que las copias son independientes de las réplicas.
¿Qué problemas encontramos más a menudo?
- Demasiadas partes: inserciones pequeñas y constantes que saturan las fusiones y acaban rechazando escrituras.
- ORDER BY copiado de otra base de datos: un identificador único primero, y cada consulta lee la tabla entera.
- Consultas sin límite de memoria: un informe con un JOIN enorme deja sin memoria al servidor y a todos los demás.
- Keeper en un solo nodo: si cae, las tablas replicadas pasan a solo lectura.
- Sin retención: el disco se llena con datos de hace años que nadie consulta.
- Copias que nunca se han restaurado: la documentación oficial avisa de que, si no lo habéis probado, probablemente no funcionará cuando haga falta.
¿Cómo hacemos las copias y las actualizaciones?
Usamos el comando BACKUP de ClickHouse con destino S3: una copia base periódica y copias incrementales que solo guardan lo nuevo. El almacenamiento está en otra cuenta o en otro proveedor y con reglas que impiden borrarlo antes de tiempo. Cada cierto tiempo hacemos RESTORE en un servidor aparte, comparamos recuentos de filas con producción y apuntamos cuánto tarda.
ClickHouse publica versiones cada mes y, dos veces al año, versiones LTS con soporte más largo. En producción recomendamos LTS. Actualizamos réplica a réplica, comprobamos que se pone al día y seguimos con la siguiente. Antes revisamos los cambios incompatibles de cada versión y lanzamos vuestras consultas reales contra una copia.
¿Cómo encaja con lo que ya tenéis?
ClickHouse se alimenta de lo que ya produce vuestro sistema: eventos de la aplicación, colas, exportaciones de PostgreSQL o logs. Montamos la ingesta por lotes, supervisamos las fusiones y conectamos Grafana para los paneles. Si los datos vienen de una base de datos relacional, la gestionamos como en el PostgreSQL gestionado, y las métricas de ClickHouse van a la monitorización con Grafana y Prometheus.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores dedicados o cloud con ClickHouse y ClickHouse Keeper en red privada. Copias y almacenamiento en frío en Object Storage de Hetzner, compatible con S3. | Sin servicio gestionado; los dedicados con discos NVMe dan mucho rendimiento analítico por el coste. |
| AWS | EC2 con discos gp3 o NVMe locales, Keeper en tres instancias y copias a S3. | AWS no tiene ClickHouse propio; ClickHouse Cloud se contrata aparte, con su propia cuenta. |
| Google Cloud | Compute Engine con discos persistentes, Keeper en tres máquinas y copias a Cloud Storage por su interfaz compatible con S3. | Sin servicio propio de Google; ClickHouse Cloud también se ofrece sobre Google Cloud. |
| Azure | Máquinas virtuales con discos gestionados y copias a Azure Blob Storage, que ClickHouse admite como destino. | Sin servicio propio de Microsoft; ClickHouse Cloud está disponible en Azure. |
| DigitalOcean | Droplets con almacenamiento en bloque y copias a Spaces, compatible con S3. | Sin ClickHouse gestionado; encaja para volúmenes moderados. |
| OVH | ClickHouse gestionado de OVHcloud Public Cloud, o instancias y dedicados con ClickHouse montado por nosotros. | |
| Servidor propio | ClickHouse en vuestros servidores con discos rápidos, Keeper en tres máquinas y copias a un almacenamiento S3 externo. | ClickHouse aprovecha bien el hardware propio; la copia tiene que salir del edificio. |
Qué incluye
- ClickHouse en vuestra cuenta cloud o en vuestros servidores, con la configuración en Terraform o Ansible en vuestro repositorio.
- Diseño o revisión de tablas: motor MergeTree adecuado, ORDER BY según vuestras consultas y particiones razonables.
- Réplicas con ReplicatedMergeTree y ClickHouse Keeper en tres nodos, y fragmentos cuando el volumen lo pide.
- Copias con BACKUP a un almacenamiento S3, completas e incrementales, y restauración de prueba medida.
- Retención con TTL: borrado o paso a almacenamiento barato de los datos antiguos.
- Usuarios, perfiles y cuotas por aplicación para que una consulta no tumbe el servidor.
- Métricas en Prometheus y alertas de partes, réplicas retrasadas, memoria y disco.
- Actualizaciones a versiones LTS, réplica a réplica, ensayadas antes con una copia.
Preguntas frecuentes
¿ClickHouse Cloud o ClickHouse en nuestra cuenta?
ClickHouse Cloud es cómodo y separa almacenamiento y cómputo. En vuestra cuenta tenéis los datos donde vosotros decidís, sin un tercero más en la cadena, y con un volumen estable soléis pagar menos. A cambio, alguien tiene que operar réplicas, copias y actualizaciones, que es lo que hacemos nosotros.
¿Se puede migrar de ClickHouse Cloud a nuestra propia cuenta?
Sí. Recreamos las tablas, cambiando el motor propio de Cloud por ReplicatedMergeTree, y copiamos los datos partición a partición con la función remoteSecure, comprobando recuentos. Mientras tanto la carga sigue llegando a Cloud y al final cambiamos el destino de las inserciones.
¿Por qué aparece el error de demasiadas partes?
Casi siempre por insertar fila a fila o en lotes muy pequeños: cada inserción crea una parte nueva y las fusiones no dan abasto. Lo arreglamos agrupando inserciones, activando las inserciones asíncronas o revisando una partición demasiado fina.
¿Sirve ClickHouse para logs y métricas?
Sí, es uno de sus usos más habituales: guarda mucho volumen comprimido y responde rápido a consultas por tiempo. Lo combinamos con TTL para que los datos antiguos se borren o pasen a almacenamiento barato.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el