Skip to main content
Las actualizaciones ligeras se encuentran actualmente en fase beta. Si tienes algún problema, abre una incidencia en el repositorio de ClickHouse.
La sentencia de actualización ligera UPDATE actualiza las filas de una tabla [db.]table que coinciden con la expresión filter_expr. Se denomina “actualización ligera” para diferenciarla de la consulta ALTER TABLE ... UPDATE, que es un proceso costoso que reescribe columnas completas en las partes de datos. Solo está disponible para la familia de motores de tabla MergeTree.
filter_expr debe ser de tipo UInt8. Esta consulta actualiza los valores de las columnas especificadas con los valores de las expresiones correspondientes en las filas en las que filter_expr toma un valor distinto de cero. Los valores se convierten al tipo de la columna mediante el operador CAST. No se admite la actualización de columnas utilizadas en el cálculo de las claves primarias o de partición.

​
Ejemplos

​
Las actualizaciones ligeras no actualizan los datos inmediatamente

La actualización ligera UPDATE se implementa mediante partes de parche, un tipo especial de parte de datos que contiene solo las columnas y filas actualizadas. Una actualización ligera UPDATE crea partes de parche, pero no modifica físicamente de inmediato los datos originales en el almacenamiento. El proceso de actualización es similar al de una consulta INSERT ... SELECT ..., pero la consulta UPDATE espera a que se complete la creación de la parte de parche antes de devolver el control. Los valores actualizados quedan:
  • Inmediatamente visibles en las consultas SELECT mediante la aplicación de parches
  • Materializados físicamente solo durante fusiones y mutaciones posteriores
  • Eliminados automáticamente una vez que todas las partes activas tienen los parches materializados

​
Requisitos de las actualizaciones ligeras

Las actualizaciones ligeras son compatibles con los motores MergeTree, ReplacingMergeTree, CollapsingMergeTree y VersionedCollapsingMergeTree, así como con sus versiones Replicated y Shared. Para usar actualizaciones ligeras, la materialización de las columnas _block_number y _block_offset debe habilitarse mediante las opciones de configuración de la tabla enable_block_number_column y enable_block_offset_column.

​
Eliminaciones ligeras

Una consulta de eliminación ligera DELETE puede ejecutarse como una actualización ligera UPDATE en lugar de una mutación ALTER UPDATE. La implementación de la eliminación ligera DELETE se controla mediante el ajuste lightweight_delete_mode.

​
Consideraciones de rendimiento

Ventajas de las actualizaciones ligeras:
  • La latencia de la actualización es comparable a la de la consulta INSERT ... SELECT ...
  • Solo se escriben las columnas y los valores actualizados, no columnas completas en las partes de datos
  • No es necesario esperar a que terminen las fusiones o mutaciones en ejecución; por lo tanto, la latencia de una actualización es predecible
  • Es posible ejecutar actualizaciones ligeras en paralelo
Posibles impactos en el rendimiento:
  • Añaden una sobrecarga a las consultas SELECT que necesitan aplicar parches
  • Los índices de omisión no se usarán para las columnas de partes de datos que tengan parches pendientes de aplicar. Las proyecciones no se usarán si la tabla tiene partes de parche, incluso en las partes de datos que no tengan parches pendientes de aplicar.
  • Las actualizaciones pequeñas demasiado frecuentes pueden provocar un error “Too many parts”. Se recomienda agrupar varias actualizaciones en una sola consulta, por ejemplo, incluyendo los ID de las actualizaciones en una sola cláusula IN dentro de la cláusula WHERE
  • Las actualizaciones ligeras están diseñadas para actualizar pequeñas cantidades de filas (hasta aproximadamente el 10 % de la tabla). Si necesita actualizar una cantidad mayor, se recomienda usar la mutación ALTER TABLE ... UPDATE

​
Operaciones concurrentes

Las actualizaciones ligeras, a diferencia de las mutaciones tradicionales, no esperan a que finalicen las fusiones/mutaciones que están en ejecución. La consistencia de las actualizaciones ligeras concurrentes se controla mediante la configuración update_sequential_consistency y update_parallel_mode.

​
Actualizar permisos

UPDATE requiere el privilegio ALTER UPDATE. Para habilitar las sentencias UPDATE en una tabla específica para un usuario concreto, ejecute:

​
Detalles de la implementación

Las partes de parche son iguales que las partes normales, pero contienen solo las columnas actualizadas, las columnas de la clave de ordenación de la tabla y las siguientes columnas del sistema:
  • _part - el nombre de la parte original
  • _block_number - el número de bloque de la fila en la parte original
  • _block_offset - el desplazamiento del bloque de la fila en la parte original
  • _data_version - la versión de los datos actualizados (número de bloque asignado a la consulta UPDATE)
Las columnas del sistema ayudan a localizar las filas de la parte original que deben actualizarse. Están relacionadas con las columnas virtuales de la parte original, que se añaden durante la lectura si deben aplicarse partes de parche. Las partes de parche se ordenan por la clave de ordenación de la tabla, seguida de las columnas _block_number y _block_offset. La sobrecarga de almacenamiento por fila actualizada depende del tamaño de los valores de las columnas de la clave de ordenación. Las partes de parche pertenecen a particiones distintas de la parte original. El ID de partición de la parte de parche es patch-<hash of the patch part structure>-<original_partition_id>. Por lo tanto, las partes de parche con columnas diferentes se almacenan en particiones distintas. Por ejemplo, tres actualizaciones SET x = 1 WHERE <cond>, SET y = 1 WHERE <cond> y SET x = 1, y = 1 WHERE <cond> crearán tres partes de parche en tres particiones distintas. Las partes de parche pueden fusionarse entre sí para reducir la cantidad de parches aplicados en las consultas SELECT y disminuir la sobrecarga. La fusión de partes de parche usa el algoritmo de fusión replacing con _data_version como columna de versión. Por lo tanto, las partes de parche siempre almacenan la versión más reciente de cada fila actualizada de la parte. Una parte de parche se aplica fusionándola con la parte de datos mediante la clave de ordenación de la tabla: una fila se actualiza si los valores de las columnas de la clave de ordenación, así como de las columnas _block_number y _block_offset, son iguales en la parte de datos y en la parte de parche. La aplicación de partes de parche requiere leer las columnas de la clave de ordenación de la parte de datos incluso si la consulta no las selecciona. El uso de memoria al aplicar una parte de parche está limitado por el mayor rango de filas con valores iguales de la clave de ordenación.

​
Formato de las partes de parche en clusters con versiones mixtas

El formato de las partes de parche recién escritas se controla mediante la configuración de tabla patch_parts_version. Las versiones de ClickHouse anteriores a la 26.8 solo admiten el formato heredado v1 y no pueden leer partes de parche en el formato actual v2 descrito anteriormente. Durante una actualización progresiva desde una de estas versiones, siga escribiendo en formato v1 hasta que se hayan actualizado todas las réplicas: configure patch_parts_version = 'v1' para las tablas con actualizaciones ligeras o establezca la configuración compatibility en la versión desde la que está actualizando. Una vez completada la actualización, elimine la sobrescritura para empezar a escribir partes de parche en formato v2. Las partes de parche de ambos formatos siguen pudiendo leerse y aplicarse independientemente del valor de la configuración.

​
Contenido relacionado

  • ALTER UPDATE - Operaciones UPDATE de alto costo
  • eliminación ligera - Operaciones de eliminación ligera con DELETE
  • APPLY PATCHES - Forzar la materialización física de los parches en las partes de datos (operación de mutación)
Última modificación el 18 de agosto de 2026