Tu base de datos es 40 veces más lenta de lo que debería

Tus consultas analíticas probablemente se ejecutan mucho más lento de lo necesario. Considera una consulta de agregación en 100 millones de filas: con Postgres, esta operación toma unos impresionantes 9.7 segundos. DuckDB, una base de datos de column-store, completa la misma consulta en solo 0.24 segundos, demostrando una mejora de velocidad superior a 40x. Esta marcada diferencia revela un cuello de botella arquitectónico fundamental inherente en muchas bases de datos tradicionales.

Las bases de datos relacionales tradicionales como Postgres son row-stores. Organizan los datos en el disco por fila, lo que significa que se recupera una fila completa del almacenamiento incluso si una consulta solo necesita el valor de una columna de esa fila. Para cargas de trabajo analíticas que agregan datos a través de muchas filas pero pocas columnas, este diseño obliga a la base de datos a leer grandes cantidades de datos irrelevantes, desperdiciando valioso ancho de banda de E/S y ciclos de CPU.

Las bases de datos de tipo column-store como DuckDB y ClickHouse invierten este paradigma. Almacenan los datos agrupados por columna. Cuando una consulta de agregación apunta a una columna específica, la base de datos solo lee los datos de esa columna en particular desde el disco, omitiendo por completo todas las demás columnas de la tabla. Esto reduce drásticamente la cantidad de datos procesados, lo que lleva a las ganancias de rendimiento observadas.

Las bases de datos columnares logran su impresionante velocidad realizando órdenes de magnitud menos trabajo. En lugar de escanear cada fila, emplean estrategias inteligentes de indexación y metadatos para omitir datos irrelevantes. Esta eficiencia proviene de su almacenamiento orientado a columnas, que agrupa los datos por columna en lugar de por fila, optimizando las consultas analíticas que a menudo agregan subconjuntos de columnas.

ClickHouse, por ejemplo, no indexa filas individuales; se basa en una sparse primary key definida en una columna ordenada como una marca de tiempo (timestamp). A medida que se ingieren los datos, se ordenan y dividen en bloques de tamaño fijo de aproximadamente 8,192 filas, conocidos como granules. ClickHouse almacena solo la primera marca de tiempo de cada granule, creando alrededor de 12,000 pequeñas notas en memoria para un conjunto de datos de 100 millones de filas.

Cuando una consulta solicita datos para un período específico, como marzo, ClickHouse escanea rápidamente estas notas en memoria, identificando y leyendo solo los granules relevantes del disco. En nuestra prueba de rendimiento, esto significó leer solo 1,633 de los 12,208 bloques, ignorando más del 86% del conjunto de datos. DuckDB utiliza un truco similar y altamente efectivo: almacena min/max metadata para cada fragmento de columna. Esto permite a DuckDB demostrar que un fragmento es irrelevante para la consulta (por ejemplo, un fragmento que abarca de enero a febrero) y omitir su contenido por completo sin leerlo.

Las bases de datos columnares sobresalen en consultas de agregación, pero su arquitectura introduce compensaciones significativas para otras operaciones comunes. Una consulta de búsqueda puntual (point lookup), que recupera una sola fila por ID, revela este marcado contraste. Con Postgres, esto toma solo 2 milisegundos gracias a su binary tree index, que navega eficientemente a la página de datos exacta que contiene la fila solicitada.

ClickHouse, sin embargo, tiene dificultades con tales consultas, registrando 168 milisegundos. Su sparse primary key, ordenada por marca de tiempo y luego por ID, no ofrece un camino directo a un ID arbitrario sin escanear los 12,208 bloques de datos. Incluso después de localizar la fila, debe reconstruir el registro completo abriendo y uniendo los ocho archivos de columna, una sobrecarga considerable para una obtención aparentemente simple.

La actualización de una sola fila expone aún más la divergencia arquitectónica. Con Postgres, una actualización se completa en 5 milisegundos, reescribiendo una fila y actualizando una entrada de índice. ClickHouse, por el contrario, tarda unos asombrosos 5.8 segundos para la misma operación. Esto se debe a sus immutable data files; modificar un solo valor requiere reescribir todo el archivo de la columna de ingresos para ese fragmento de datos afectado.

Estas características de rendimiento no son fallas de diseño, sino especializaciones inherentes. Las bases de datos orientadas a filas como Postgres están optimizadas para transactional workloads (OLTP), donde las inserciones, actualizaciones y búsquedas frecuentes de una sola fila son primordiales. Las bases de datos columnares, por diseño, priorizan analytical workloads (OLAP), donde predominan las consultas agregadas sobre vastos conjuntos de datos, lo que hace que sus fortalezas y debilidades sean distintas según el caso de uso.

Existen dos opciones columnares distintas para acelerar las consultas analíticas: ClickHouse y DuckDB. Aunque ambos ofrecen mejoras de rendimiento impresionantes sobre Postgres para operaciones agregadas, sus filosofías arquitectónicas divergen significativamente, dictando aplicaciones ideales dispares.

ClickHouse opera como un sistema completo basado en servidor, diseñado específicamente para almacenes de datos de producción. Funciona de manera muy similar a Postgres, requiriendo una instancia de servidor en ejecución y admitiendo acceso concurrente multiusuario para entornos de análisis compartidos y robustos.

DuckDB, por el contrario, proporciona una experiencia de embedded library, similar a SQLite para cargas de trabajo analíticas. Se ejecuta en el proceso de su aplicación, almacenando toda su base de datos dentro de un solo archivo en el disco, lo que lo hace ideal para la manipulación de datos local y del lado del cliente.

Para un backend de análisis escalable y compartido que admita múltiples usuarios y grandes conjuntos de datos, ClickHouse es tu arma preferida. Maneja la ingesta de alto rendimiento y consultas agregadas complejas a través de petabytes de datos en un entorno de producción.

Elige DuckDB para potenciar el análisis de datos local, impulsar aplicaciones de un solo nodo o acelerar trabajos ETL ultrarrápidos. Su naturaleza en proceso y su base de datos de un solo archivo simplifican la implementación para científicos de datos individuales o herramientas internas a menor escala.

Si necesitas una plataforma de análisis multiusuario robusta, ignora DuckDB. Si tus necesidades se limitan al procesamiento local de un solo usuario, la sobrecarga del servidor de ClickHouse es innecesaria.

¿Cuál es la diferencia principal entre una base de datos columnar y una basada en filas?

Una base de datos basada en filas (como Postgres) almacena todos los datos de un solo registro juntos. Una base de datos columnar (como ClickHouse) almacena todos los valores de una sola columna juntos, lo cual es mucho más eficiente para consultas analíticas.

¿Cuándo debería usar una base de datos columnar?

Usa una base de datos columnar para cargas de trabajo analíticas (OLAP) que impliquen agregar o filtrar algunas columnas a través de millones o miles de millones de filas. Son ideales para paneles de control, inteligencia empresarial y plataformas de análisis.

¿Por qué las bases de datos columnares son lentas para las actualizaciones de una sola fila?

Sus archivos de datos están optimizados para la ingesta masiva y a menudo son inmutables. Actualizar un solo valor puede requerir reescribir un fragmento grande completo de un archivo de columna, lo que lo hace mucho más lento que las bases de datos transaccionales.

¿Es DuckDB un reemplazo para Postgres?

No, cumplen propósitos principales diferentes. DuckDB es una base de datos analítica integrada (como SQLite para análisis), ideal para el análisis de datos en proceso. Postgres es una base de datos transaccional de propósito general (OLTP) diseñada para ser un sistema de registro.