The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Para cargar datos a gran escala en ClickHouse, evita ejecutar un INSERT síncrono por cada fila. Agrupa filas en el cliente cuando puedas; si tienes muchos productores pequeños que no pueden agruparse entre sí, usa inserciones asíncronas para que el servidor acumule escrituras antes de vaciarlas. El rendimiento depende del esquema, las particiones, el formato, la red y los recursos disponibles: no existe una tasa universal.
Por qué insertar fila por fila perjudica el rendimiento
En tablas MergeTree, cada inserción escribe una o más partes de datos. ClickHouse las combina después mediante merges en segundo plano. Si la aplicación envía una fila —o muy pocas filas— por inserción, el servidor repite trabajo de escritura y gestión de partes, y los merges consumen CPU e I/O que podrían estar disponibles para consultas.
La guía oficial recomienda, como orientación general, lotes de al menos 1.000 filas y considera ideales los de 10.000 a 100.000 si la aplicación y la memoria lo permiten. No es una garantía ni un óptimo universal: el tamaño adecuado depende del ancho de las filas, la tabla y el entorno. La documentación de estrategias de inserción resume la prioridad: primero hay que agrupar los datos.
Elige dónde agrupar las filas
| Enfoque | Cuándo conviene | Ventaja principal | Consideración |
|---|---|---|---|
| Batch en el cliente | La aplicación controla la carga y puede retener filas hasta completar un lote. | Control explícito del tamaño y el momento de cada inserción. | Acumular filas puede añadir latencia y requiere memoria en el cliente. |
| Inserción asíncrona en el servidor | Hay muchos emisores pequeños o esporádicos que no pueden coordinar lotes. | ClickHouse acumula solicitudes en buffers antes de escribir. | Los buffers dependen de la forma de la consulta, los ajustes y el nodo; un flush puede crear varias partes. |
Cuando el cliente puede crear lotes
Envía menos inserciones con más datos en cada una. Para cargas desde archivos, el cliente oficial puede leer CSV en modo batch; también puedes enviar archivos comprimidos con INSERT ... FORMAT CSV. Para migraciones grandes, divide el trabajo en solicitudes o chunks que puedas reintentar por separado si falla una unidad. ClickPipes está documentado para replicación de PostgreSQL en ClickHouse Cloud; PeerDB se describe para despliegues autogestionados. La guía oficial de inserción cubre estos flujos.
Cuando los productores no pueden agruparse
Configura async_insert=1 para que ClickHouse acumule datos antes de escribirlos. El vaciado del buffer puede activarse por tiempo, tamaño acumulado o número de consultas. Esto reduce la frecuencia de escritura de partes en muchos escenarios, pero no crea un único buffer global para toda la tabla.
ClickHouse mantiene buffers según la forma de la consulta y los ajustes; en un clúster multinodo, los buffers son por nodo. Además, un vaciado puede producir varias partes si los datos abarcan varios valores de partición o exceden lo que cabe en una parte. La documentación sobre inserciones asíncronas explica estas limitaciones.
Decide cuándo confirmar las inserciones asíncronas
| Ajuste | Cuándo responde ClickHouse | Qué significa el acuse | Uso apropiado |
|---|---|---|---|
wait_for_async_insert=1 |
Después del flush del buffer. | El emisor puede recibir errores de inserción o de flush. | Preferible si necesitas una confirmación vinculada a la escritura completada. |
wait_for_async_insert=0 |
Antes de que termine el flush. | Confirma que los datos entraron en el buffer, no que la escritura a disco terminó; es un modo fire-and-forget. | Solo si aceptas una confirmación temprana y sus implicaciones para el seguimiento de entregas. |
La documentación recomienda wait_for_async_insert=1 como ajuste predeterminado. Comprueba la versión y configuración de tu instalación antes de asumir defaults: las notas de ClickHouse 26.3 LTS indican que las inserciones asíncronas se habilitan por defecto desde esa versión. Las mismas notas mencionan un timeout adaptativo desde 24.2 y deduplicación coherente para inserciones asíncronas con vistas materializadas desde 26.1; esos comportamientos dependen de la versión y del flujo de inserción. Consulta las notas oficiales de versiones.
Recommended Free Tools
Optimiza formato, compresión y orden
- Native con LZ4: es el punto de partida que la guía de ClickHouse recomienda para alto rendimiento y bajo coste de CPU.
- ZSTD: puede reducir más los datos transferidos cuando el ancho de banda importa, a cambio de más trabajo de compresión y descompresión.
- RowBinary: opción binaria orientada a filas que evita parte del coste de formatos de texto.
- JSONEachRow: puede simplificar la integración, especialmente cuando el caudal requerido es menor.
- Orden de entrada: si puedes ordenar los lotes por las columnas de la clave primaria, ClickHouse puede omitir el paso de ordenación.
Un benchmark de FastFormats citado por ClickHouse comparó una carga de 5,6 GiB: los inserts Native comprimidos con LZ4 redujeron el tamaño de los datos y el tiempo de ingestión en más de un 50%, y el tiempo bajó de 150 a 131 segundos. En esa misma prueba, ZSTD redujo los datos a 1,69 GiB con un ligero aumento del tiempo de proceso en el servidor. Son resultados de ese conjunto de datos y configuración, no una predicción para otras cargas. La guía de estrategias de inserción de ClickHouse ofrece el contexto del benchmark.
Añade paralelismo solo si el sistema puede sostenerlo
Varios workers pueden aumentar el caudal cuando los servidores, el almacenamiento y la red tienen recursos disponibles. ClickHouse describe el reparto paralelo de INSERT INTO SELECT FROM y señala que duplicar workers puede duplicar el caudal en las condiciones apropiadas; añadir workers no ayuda si el servidor o el almacenamiento ya son el cuello de botella.
En una prueba propia de ClickHouse con más de 600.000 millones de filas y 100 workers, aumentar de 3 a 6 servidores ClickHouse Cloud elevó el caudal medido de 4 a 8 millones de filas por segundo. Es una medición de esa prueba, no una tasa esperable para cualquier clúster. El artículo de carga masiva de ClickHouse describe su configuración.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Qué muestran —y qué no— los benchmarks de partes
En un benchmark de 2023 con la aplicación UpClick, 200 inserts cada 10 segundos llevaron la prueba síncrona a abortar tras cinco minutos al alcanzar el umbral de partes activas; el total llegó a casi 30.000 partes activas e inactivas. En la prueba asíncrona descrita por ClickHouse, las partes activas se mantuvieron por debajo de 8 y el total por debajo de 1.300. Son resultados de configuraciones concretas, no objetivos ni garantías para producción.
El mismo artículo describe un umbral de 300 partes activas dentro de una partición asociado al error Too many parts. No lo trates como un límite operativo recomendado: la cantidad adecuada de partes depende de la tabla y la carga. Lee el artículo de ClickHouse sobre inserciones asíncronas para ver las condiciones de esa prueba.
Quick Recap
Una ruta práctica para configurar la carga
- Si controlas al productor, agrupa en el cliente. Empieza con lotes de al menos 1.000 filas y evalúa si un tamaño mayor —dentro de la orientación general de 10.000 a 100.000— encaja con la memoria y la latencia aceptables.
- Si los emisores son pequeños y numerosos, activa inserciones asíncronas. Usa
async_insert=1y, salvo que tengas un motivo para aceptar acuses tempranos, manténwait_for_async_insert=1. - Elige un formato acorde con el flujo. Prueba Native con LZ4 como punto de partida para rendimiento; considera ZSTD si pesa más el tamaño transferido, y formatos como RowBinary o JSONEachRow según la integración.
- Ordena antes de enviar si resulta viable. Organiza los lotes según las columnas de clave primaria para que ClickHouse pueda evitar ordenar los datos de entrada.
- Escala workers de forma gradual. Aumenta el paralelismo solo mientras los servidores y la infraestructura mantengan recursos suficientes.
- Verifica el comportamiento en tu entorno. Evalúa partes, errores, latencia y caudal con tu esquema y carga reales; los números publicados no sustituyen esa validación.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
