El volumen de datos en IT ha crecido exponencialmente, generando logs, métricas y trazas que requieren gestión eficiente. Para aprovechar al máximo esta información, es clave consultarla de forma rápida y flexible. Las tecnologías OLAP (Procesamiento Analítico en Línea) permiten realizar análisis multidimensionales, optimizar consultas y generar informes dinámicos, potenciando la toma de decisiones basada en datos.
¿Qué significa OLAP?
Según el tipo de cargas de trabajo que soportan, podríamos clasificar los sistemas de gestión de bases de datos (DBMS) en dos tipos:
OLTP
OLAP
OLTP (Online Transactional Processing)
- Optimizado para transacciones breves y frecuentes, como registrar una compra o actualizar el perfil de un usuario.
- Diseñado para la integridad y consistencia de los datos.
OLAP (Online Analytical Processing)
- Enfocado en la ejecución de consultas complejas y agregaciones masivas sobre millones de filas.
- Ideal para análisis de datos, generación de informes y soporte a la toma de decisiones.
En la práctica, muchos sistemas intentan equilibrar ambos mundos, pero cada uno tiene compromisos técnicos que afectan su rendimiento según el tipo de carga.
Normalmente los sistemas de gestión de bases de datos se centran en un caso de uso u otro, ya que hay muchos aspectos en los que favorecer el enfoque OLTP perjudica o complica los casos de uso OLAP, y viceversa, aunque en la práctica se intentan cubrir los máximos casos de uso posibles y los sistemas se van moldeando para adoptar características del otro tipo con el fin de ganar más adopción.
Casos de uso reales de OLAP
Un caso de uso perfecto que ilustra la necesidad de OLAP es la observabilidad de sistemas.En entornos distribuidos modernos la monitorización tradicional que comprueba si un error conocido ha ocurrido ya no es suficiente.
Los técnicos necesitan explorar libremente los datos (logs, trazas, métricas) para entender comportamientos inesperados, haciendo preguntas que no sabían que necesitaban hacer de antemano, como: «¿Cuál es la latencia media de las peticiones para los usuarios de un cliente concreto que utilizaron una versión específica de la aplicación móvil durante el pico de tráfico de ayer?». Esta es una consulta OLAP pura: compleja, sobre un gran volumen de datos y que requiere una respuesta rápida para ser útil.
¿Qué es ClickHouse y cómo revoluciona el OLAP?
ClickHouse es un sistema de gestión de bases de datos columnar, de código abierto, concebido específicamente para el Procesamiento Analítico en Línea (OLAP). Aunque también trata poco a poco de implementar nuevas funcionalidades que le acerquen al mundo OLTP, como es el intento de soporte de transacciones tradicionales, que actualmente está en modo beta.
Ventajas técnicas de ClickHouse para análisis de datos
Algunos de los aspectos técnicos que permiten a ClickHouse ser tan bueno en OLAP son los siguientes:
- Almacenamiento Columnar: A diferencia de las bases de datos tradicionales que almacenan los datos por filas, ClickHouse lo hace por columnas. Esto se traduce en que cada columna es guardada en ficheros diferentes. Cuando ejecutas una consulta analítica que solo necesita 3 columnas de una tabla que tiene 50, ClickHouse lee únicamente los datos de esas 3 columnas. Esto reduce drásticamente la cantidad de datos leídos del disco (I/O), que suele ser uno de los principales cuellos de botella. Además, el hecho de que los datos se guarden por columnas hace que sean mucho más homogéneos y los algoritmos de compresión funcionen bastante mejor. ClickHouse utiliza códecs modernos como LZ4 y ZSTD para alcanzar ratios de compresión muy altos. En realidad, cuando hacemos analítica, este caso de uso en el que sólo necesitamos procesar alguna de las columnas es bastante habitual, por lo que usar bases de datos columnares puede mejorar mucho el rendimiento de las consultas. No obstante, esto también puede ser ineficiente si necesitamos leer todas las columnas de un único o unos pocos documentos, pues tendremos que abrir 50 ficheros distintos para leer unos pocos datos.
- Procesamiento Vectorizado: ClickHouse no procesa los datos valor por valor. En su lugar, opera sobre lotes o «vectores» de valores de una columna, aprovechando al máximo la eficiencia de las CPUs modernas para procesar datos en bloque.
- Índices Dispersos (Sparse Indexes): En lugar de indexar cada fila, ClickHouse sólo guarda una marca (o «mark») por cada gran bloque de datos (por ejemplo, cada 8192 filas). Para que funcione, los datos deben estar ordenados físicamente en el disco según una clave (ORDER BY). Estos índices dispersos permiten que, aunque tengamos muchos documentos, el índice sea suficientemente pequeño para caber en memoria, y por tanto permite la búsqueda selectiva rápida de bloques de documentos. Sin embargo, aunque esto funciona muy bien al procesar grandes cantidades de datos, si, por ejemplo, queremos buscar un documento específico, como no tenemos indexado documento a documento, necesitamos cargar el bloque entero de miles de documentos, y por tanto vamos a leer un montón de documentos que no nos interesaban realmente (tal y cómo hemos comentado anteriormente, favorecer casos de uso OLAP u OLTP generalmente implica buscar compromisos, y esto es un ejemplo de cómo una decisión técnica que favorece casos de uso OLAP nos perjudica en otros casos de uso más típicos de OLTP).
ClickHouse también tiene otras desventajas
Aunque ClickHouse es increíblemente rápido procesando grandes cantidades de datos, también tiene sus propios talones de Aquiles. Los datos en ClickHouse se escriben en disco en partes o bloques inmutables. Una vez escritos, no se pueden cambiar. Por tanto, cuando se lanza una operación UPDATE o DELETE, ClickHouse no busca la fila y la modifica. En su lugar, inicia un proceso asíncrono y pesado llamado «mutación». Este proceso reescribe por completo cada bloque de datos que contenga filas que necesiten ser modificadas, aplicando los cambios en la nueva copia y marcando los bloques antiguos para su posterior eliminación. Es una operación costosa y lenta, y está diseñada para ser usada con poca frecuencia. No obstante, desde hace un par de años, ClickHouse introdujo los “lightweight DELETEs”, que funcionan de una forma similar a otras bases de datos: Las filas pueden ser marcadas para eliminación, de forma que las queries filtrarán esas filas, y en el futuro, si se hacen “merges” de bloques, esas filas se descartarán.
¿Cómo se compara ClickHouse con otros sistemas?
En el blog oficial de ClickHouse decidieron hacer una comparativa entre ClickHouse y otros sistemas de gestión de bases de datos: The billion docs JSON Challenge. La idea era comparar cómo las distintas tecnologías guardan mil millones de documentos json y también evaluar el rendimiento de distintas agregaciones sobre estos datos. Respecto al uso de disco, así quedó la comparativa:
Como podemos ver a la izquierda, los ficheros JSON en crudo ocupan 482 GB. Si aplicamos el algoritmo de compresión, ocupan 124 GB. Respecto a las bases de datos, sería lógico que los documentos ocupasen más, incluso usando el mismo algoritmo ZSTD, ya que las bases de datos deben almacenar otros metadatos y estructuras de datos adicionales como los índices. ¡Sin embargo, vemos que en ClickHouse los datos ocupan incluso menos que comprimiendo los ficheros originales! El motivo de esto es que, tal y como hemos comentado antes, ClickHouse es una base de datos columnar, y eso facilita que los datos se compriman mejor. Además, recordamos que ClickHouse usa unos índices dispersos que generan una entrada para cada número de miles de documentos, por lo que los índices ocupan menos espacio que en otros sistemas. Por otra parte, MongoDB consigue comprimir bastante también, pero no llega al nivel de ClickHouse, pues MongoDB no es una base de datos columnar y los índices que usa ocupan más espacio. Respecto a Elasticsearch, en esta comparativa intentaron tunear varios parámetros para que la comparación fuera más justa, pero en realidad sigue sin ser del todo justa, pues al final elasticsearch está optimizado para la búsqueda de texto, y eso implica ciertas decisiones de diseño y metadatos que tiene que guardar de más. Por último, respecto a PostgreSQL, hay que decir que por defecto no suele usar compresión de datos salvo que las columnas sean muy grandes, y no es el caso de esta comparativa, donde los campos del documento JSON eran pequeños, por tanto podría decirse que PostgreSQL no usa compresión, y por tanto la base de datos ocupa lo mismo que los JSON sin comprimir más espacio adicional para índices y otros metadatos.
ClickHouse también fue la tecnología más rápida al ejecutar ciertas agregaciones (el resultado de estas agregaciones fue calculado usando el mejor tipo de compresión). Por ejemplo, éstos son los resultados al ejecutar una query que calcula cuántos posts escriben, “repostean” o dan a “like” los usuarios de BlueSky por cada hora del día:
Por último, también podemos añadir que hay otras opciones que podrían competir contra ClickHouse en esta comparativa. Por ejemplo, PostgreSQL tiene una extensión llamada TimescaleDB, que nos permite obtener lo mejor de los dos mundos. Inicialmente los datos se guardan de forma más o menos normal, pero más tarde, en base a políticas definidas, pueden pasar a columnstore, donde los datos se guardan de forma columnar. Algunas comparativas han mostrado que TimescaleDB puede funcionar mejor que ClickHouse para ciertos casos de uso. Pero las dos tienen sus puntos fuertes.
Conclusión
ClickHouse es un sistema de gestión de bases de datos principalmente pensado para casos de uso OLAP, siendo muy bueno almacenando y procesando grandes cantidades de datos. No obstante, para conseguirlo se adoptan ciertas decisiones técnicas, como el hecho de almacenar la información de forma columnar o los índices dispersos, que nos ayudan a conseguir un gran rendimiento almacenando y procesando grandes cantidades de datos, pero que también lastran otros casos de uso OLTP, donde quizás algo tan sencillo como actualizar constantemente documentos individuales puede ser bastante ineficiente.
En un momento en el que la capacidad de analizar rápidamente grandes volúmenes de datos es más crítica que nunca para casos de uso como la observabilidad, el Business Intelligence o la analítica de producto, entender las fortalezas y los compromisos de herramientas como ClickHouse es fundamental para construir arquitecturas de datos que sean potentes, escalables y eficientes.
