ClickHouse se vuelve más perezoso y más rápido: introduce la optimización de carga diferida

(clickhouse.com)

6 puntos por GN⁺ 2025-04-24 | 2 comentarios | Compartir por WhatsApp

ClickHouse introdujo una nueva técnica de optimización, lazy materialization, que mejora el rendimiento de las consultas Top N hasta 1,500 veces
La estrategia de leer los datos de columnas solo cuando se necesitan minimiza el I/O de disco
Junto con las técnicas existentes de almacenamiento columnar, índices y PREWHERE, forma una pila jerárquica de optimización de I/O
Carga de forma diferida los datos de columnas según el plan de ejecución de la consulta, por lo que resulta especialmente efectiva en consultas con cláusula LIMIT
Está habilitada por defecto, así que se puede obtener una mejora de rendimiento sin cambiar el código

La estrategia de optimización diferida de ClickHouse: Lazy Materialization

Concepto clave

ClickHouse maximiza el rendimiento evitando leer datos innecesarios
lazy materialization carga los datos de columnas solo en el momento en que realmente se necesitan durante la ejecución de la consulta
Funciona de manera independiente de las técnicas existentes de optimización de I/O, a la vez que ofrece mejoras de rendimiento complementarias

Tecnologías existentes de optimización de I/O

Almacenamiento basado en columnas: lee solo las columnas necesarias
Sparse Index / Skipping Index / Projections: lee solo los granules que coinciden con las condiciones filtradas
PREWHERE: filtra temprano columnas no indexadas
Query Condition Cache: almacena en caché los resultados de consultas repetidas para evitar reprocesar los mismos granules

Cómo funciona Lazy Materialization

Mientras que las técnicas anteriores se enfocaban en reducir I/O mediante filtrado, lazy materialization pospone la lectura hasta el momento del procesamiento
Lee de inmediato solo las columnas que necesita la siguiente etapa de la consulta, y deja el resto para después de LIMIT, cuando haga falta
Es especialmente útil en consultas Top N, porque solo se revisan algunas columnas y por eso casi no necesita leer columnas de texto grandes

Es una optimización posible gracias al almacenamiento independiente por columnas, y un enfoque imposible en bases de datos orientadas a filas

Ejemplo real: conjunto de datos de reseñas de Amazon

150M rows, 70GB sin comprimir, 30GB comprimidos
Ejemplo de consulta Top N:
```
SELECT helpful_votes  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;  
```
- Tiempo de ejecución: 0.07 segundos
- Procesamiento rápido al consultar una sola columna
Ejemplo de consulta de una columna de texto grande:
```
SELECT review_body  
FROM amazon.amazon_reviews  
FORMAT Null;  
```
- Tiempo de ejecución: 176 segundos
- Aunque es una sola columna, al tener 56GB genera un cuello de botella de I/O de disco

Comparación de rendimiento según la capa de optimización aplicada

1. Sin optimización (Baseline)

Tiempo de ejecución: 219 segundos
Volumen procesado: 72GB, 150M rows
Lee y ordena todas las columnas completas

2. Con Primary Key Index

Tiempo de ejecución: 96 segundos
Volumen procesado: 28GB, 53M rows
El filtrado de granules basado en PK reduce el tiempo en más de 50%

3. Agregando PREWHERE

Tiempo de ejecución: 61 segundos
Volumen procesado: 16GB
Reduce aún más el I/O al aplicar también condiciones de filtro no indexadas

4. Activando Lazy Materialization

Tiempo de ejecución: 0.18 segundos
Volumen procesado: 807MB
Al final, solo carga desde las columnas grandes las 3 rows realmente necesarias

En total, más de 1,200 veces de mejora de rendimiento y más de 150 veces menos uso de memoria

También es efectiva en consultas Top N sin filtros

En una consulta de ordenamiento completo sin filtros:

SELECT helpful_votes, product_title, review_headline, review_body  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;

Antes de lazy materialization: 219 segundos
Después de lazy materialization: 0.139 segundos
1,576 veces más rápida, 40 veces menos I/O y 300 veces menos uso de memoria

Verificación del plan de ejecución

EXPLAIN actions = 1  
SELECT helpful_votes, product_title, review_headline, review_body  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3  
SETTINGS query_plan_optimize_lazy_materialization = true;

Resultado:

Lazily read columns: review_headline, review_body, product_title   
  Limit                    
    Sorting                             
      ReadFromMergeTree

Las columnas grandes se cargan solo después del ordenamiento y LIMIT

Conclusión

Se completa la pila de optimización de I/O de ClickHouse: Index → PREWHERE → Lazy Materialization
Sin cambiar el código, solo con la forma de ejecutar la consulta, el rendimiento puede mejorar de cientos a miles de veces
Es ideal especialmente para patrones Top N, columnas de gran tamaño y consultas con LIMIT
Está habilitada por defecto, así que se aplica automáticamente sin que el usuario tenga que configurarla

El mismo SQL, la misma máquina, resultados distintos
Más rápido = menos lectura = ClickHouse

2 comentarios

zihado 2025-04-24

> Me pregunto si alguien ha comparado ClickHouse con StarRocks; hace unos meses, el rendimiento de los joins de StarRocks parecía mejor.
https://d2.naver.com/helloworld/1168674

GN⁺ 2025-04-24

Comentarios de Hacker News

Esta optimización probablemente ofrecerá mejoras dramáticas de velocidad al extraer muestras aleatorias de conjuntos de datos grandes, especialmente cuando las columnas de interés puedan contener valores grandes
- La receta básica de SQL usa una cláusula LIMIT para determinar qué filas se incluirán en la muestra
- La nueva optimización promete retrasar la lectura de las columnas grandes hasta que la cláusula LIMIT filtre el conjunto de datos a unas pocas filas
- Me pregunto si alguien puede confirmar si esta optimización acelera este tipo de consultas en ClickHouse
Realmente me encanta ClickHouse
- Lo descubrí hace poco, y se siente como una bocanada de aire fresco comparado con soluciones ineficientes para análisis
- Es muy rápido y la CLI también es un placer de usar
No puedo entender los sitios web que no se pueden desplazar
- Apenas haces un poco de scroll y salta hacia arriba, así que resulta imposible de usar
Materialización tardía, 19 años después
- Se comparte un enlace relacionado
No está relacionado con la nueva opción de materialización, pero esta parte me llamó la atención
- La consulta tarda 70 milisegundos en ordenar 150 millones de valores y devolver los 3 primeros
- Necesito actualizar mi modelo mental de lo que es una consulta lenta en hardware y software modernos
- Ordenar 150 millones de enteros en 70 milisegundos no deja de ser sorprendente
- El uso máximo de memoria es de 3.59 MiB
- Es un artículo excelente, explicado con claridad e incluye buenos diagramas
Si ClickHouse tuviera una versión nativa para Windows que no requiriera WSL ni una máquina virtual de Linux, probablemente sería más popular que DuckDB
- Una de las razones por las que MySQL fue más popular que PostgreSQL es que MySQL tenía un instalador para Windows
A pesar del drama del aeropuerto, estoy planeando unas vacaciones en la playa
- La información técnica y los diagramas eran de primer nivel, pero la historia lo hizo aún mejor
ClickHouse es una obra maestra de la ingeniería moderna
- Hay una atención absoluta al rendimiento
Me pregunto si alguien ha comparado ClickHouse con StarRocks
- Hace unos meses, el rendimiento de los joins en StarRocks parecía mejor
Es sorprendente cómo estas bases de datos demuestran lo equivocado que estaba todo en las bases de datos orientadas a filas
- No se puede acercar a estas velocidades con una estructura de índices btree
- Es impresionante ver qué tan rápidas son las máquinas modernas
- Parece que ni siquiera comprimieron correctamente el conjunto de datos
- Leer los datos es más lento que descomprimirlos
- Me recuerda un artículo de Cloudflare, con la idea de que el cifrado es gratis
- Es sorprendente que usen el motor de cómputo (chdb)