Saltar al contenido principal
Los datos procesados en ClickHouse suelen almacenarse en el sistema de archivos local de la máquina en la que se ejecuta el servidor de ClickHouse. Esto requiere discos de gran capacidad, que pueden resultar costosos. Para evitar almacenar los datos localmente, se admiten varias opciones de almacenamiento:
  1. Almacenamiento de objetos Amazon S3.
  2. Azure Blob Storage.
  3. No compatible: Hadoop Distributed File System (HDFS)

ClickHouse también admite motores de tabla externos, que son distintos de la opción de almacenamiento externo descrita en esta página, ya que permiten leer datos almacenados en formatos de archivo genéricos (como Parquet). En esta página describimos la configuración de almacenamiento para las tablas de la familia MergeTree o de la familia Log.
  1. para trabajar con datos almacenados en discos Amazon S3, use el motor de tabla S3.
  2. para trabajar con datos almacenados en Azure Blob Storage, use el motor de tabla AzureBlobStorage.
  3. para trabajar con datos en Hadoop Distributed File System (no compatible), use el motor de tabla HDFS.

Configurar almacenamiento externo

Los motores de tabla de la familia MergeTree y Log pueden almacenar datos en S3, AzureBlobStorage y HDFS (no compatible) usando un disco de tipo s3, azure_blob_storage o hdfs (no compatible), respectivamente. La configuración del disco requiere:
  1. Una sección type, igual a uno de s3, azure_blob_storage, hdfs (no compatible), local_blob_storage, web.
  2. La configuración de un tipo específico de almacenamiento externo.
A partir de la versión 24.1 de ClickHouse, es posible usar una nueva opción de configuración. Requiere especificar:
  1. Un type igual a object_storage
  2. object_storage_type, igual a uno de s3, azure_blob_storage (o simplemente azure a partir de 24.3), hdfs (no compatible), local_blob_storage (o simplemente local a partir de 24.3), web.

Opcionalmente, se puede especificar metadata_type (su valor predeterminado es local), pero también puede establecerse en plain, web y, a partir de 24.4, plain_rewritable. El uso del tipo de metadatos plain se describe en la sección sobre almacenamiento plain; el tipo de metadatos web solo puede usarse con el tipo de almacenamiento de objetos web; el tipo de metadatos local almacena los archivos de metadatos localmente (cada archivo de metadatos contiene la asignación a archivos en el almacenamiento de objetos y cierta metainformación adicional sobre ellos). Por ejemplo:
equivale a la siguiente configuración (a partir de la versión 24.1):
La siguiente configuración:
es igual a:
Un ejemplo de una configuración de almacenamiento completa sería:
A partir de la versión 24.1, también puede tener este aspecto:
Para establecer como opción predeterminada un tipo específico de almacenamiento para todas las tablas MergeTree, agregue la siguiente sección al archivo de configuración:
Si quieres configurar una política de almacenamiento específica para una tabla concreta, puedes definirla en la cláusula SETTINGS al crear la tabla:
También puede usar disk en lugar de storage_policy. En este caso, no es necesario tener la sección storage_policy en el archivo de configuración; basta con una sección disk.

refresh_parts_interval y table_disk

Esta configuración está pensada para tablas MergeTree no replicadas en las que las partes pueden escribirse externamente y la detección de metadatos debe actualizarse desde el almacenamiento. La configuración de MergeTree refresh_parts_interval permite actualizar periódicamente la lista de partes de datos desde el almacenamiento subyacente (por ejemplo, para detectar partes escritas externamente). La distinción importante es entre metadatos compartidos entre réplicas y metadatos locales de cada réplica (por ejemplo, S3 con metadatos locales por réplica): solo cuando los metadatos se comparten las partes nuevas serán visibles para todas las réplicas. Usar solo almacenamiento de objetos no implica metadatos compartidos.
  • Almacenamiento de objetos (por ejemplo, disk = 's3') no implica metadatos compartidos. Cuando los metadatos se almacenan localmente en cada réplica (el comportamiento predeterminado), cada réplica gestiona de forma independiente sus punteros a blobs en almacenamiento de objetos. Los cambios realizados en una réplica no son visibles para las demás. En ese caso, refresh_parts_interval no hace que las partes nuevas sean visibles entre réplicas, porque los metadatos que lee cada réplica son locales a esa réplica.
  • La actualización automática de partes requiere que los metadatos del filesystem se compartan (o que la tabla use metadatos de solo lectura propiedad de la propia tabla para que la actualización sea aplicable). Configurar table_disk = true junto con un disco local de la tabla (por ejemplo, SETTINGS disk = disk(type=object_storage, ...), table_disk = true) es una forma de obtener la semántica correcta: la tabla controla el ciclo de vida de los metadatos y el almacenamiento se trata como de solo lectura, por lo que refresh_parts_interval se ejecuta y pueden detectarse las partes añadidas externamente.
  • Con un disco definido globalmente (por ejemplo, disk = 's3' en storage_configuration) y los metadatos locales predeterminados, cada réplica tiene su propio estado de metadatos. Aunque los blobs puedan estar en S3, el almacenamiento no se considera compartido a efectos de refresh_parts_interval, y las partes nuevas creadas fuera de ClickHouse o en otra réplica no se detectarán.
Para la actualización automática de partes, asegúrese de que los metadatos se compartan o use un disco a nivel de tabla con table_disk = true, como se indicó anteriormente. Si se confía solo en refresh_parts_interval con metadatos locales de la réplica, las partes no se actualizarán como se espera.
refresh_parts_interval no se usa para tablas ReplicatedMergeTree. Las tablas replicadas ya sincronizan las partes mediante el mecanismo de replicación. Esta configuración solo se aplica a tablas MergeTree no replicadas en las que las partes se escriben externamente y se requiere actualizar los metadatos.

Configuración dinámica

También es posible especificar la configuración de almacenamiento sin definir previamente un disco en el archivo de configuración, ya que puede configurarse en los ajustes de la consulta CREATE/ATTACH. La siguiente consulta de ejemplo se basa en la configuración dinámica de disco anterior y muestra cómo usar un disco local para almacenar en caché datos de una tabla almacenada en una URL.
El siguiente ejemplo añade una caché al almacenamiento externo.
En la configuración resaltada a continuación, observe que el disco de type=web está anidado dentro del disco de type=cache.
El ejemplo usa type=web, pero cualquier tipo de disco puede configurarse como dinámico, incluido un disco local. Los discos locales requieren que el argumento path esté dentro del parámetro de configuración del servidor custom_local_disks_base_directory, que no tiene ningún valor predeterminado, así que establézcalo también cuando use un disco local.
También es posible combinar una configuración basada en archivos de configuración con una configuración definida en SQL:
donde web procede del archivo de configuración del servidor:

Uso del almacenamiento S3

Parámetros obligatorios

Parámetros opcionales

Google Cloud Storage (GCS) también es compatible mediante el tipo s3. Consulte GCS backed MergeTree.

Uso de Plain Storage

En 22.10 se introdujo un nuevo tipo de disco, s3_plain, que proporciona almacenamiento de escritura única. Sus parámetros de configuración son los mismos que los del tipo de disco s3. A diferencia del tipo de disco s3, almacena los datos tal cual. En otras palabras, en lugar de usar nombres de blob generados aleatoriamente, usa nombres de archivo normales (de la misma forma en que ClickHouse almacena archivos en el disco local) y no almacena metadatos localmente. Por ejemplo, estos se derivan de los datos en s3. Este tipo de disco permite mantener una versión estática de la tabla, ya que no permite ejecutar merges sobre los datos existentes ni insertar nuevos datos. Un caso de uso de este tipo de disco es crear backups en él, lo que puede hacerse mediante BACKUP TABLE data TO Disk('plain_disk_name', 'backup_name'). Después, puede hacer RESTORE TABLE data AS data_restored FROM Disk('plain_disk_name', 'backup_name') o usar ATTACH TABLE data (...) ENGINE = MergeTree() SETTINGS disk = 'plain_disk_name'. Configuración:
A partir de 24.1, es posible configurar cualquier disco de almacenamiento de objetos (s3, azure, hdfs (no compatible), local) usando el tipo de metadatos plain. Configuración:

Uso de almacenamiento S3 simple reescribible

Se introdujo un nuevo tipo de disco s3_plain_rewritable en 24.4. Al igual que el tipo de disco s3_plain, no requiere almacenamiento adicional para los archivos de metadatos. En su lugar, los metadatos se almacenan en S3. A diferencia del tipo de disco s3_plain, s3_plain_rewritable permite ejecutar merges y admite operaciones INSERT. No se admiten las mutaciones ni la replicación de tablas. Un caso de uso de este tipo de disco es en tablas MergeTree no replicadas. Aunque el tipo de disco s3 es adecuado para tablas MergeTree no replicadas, puede optar por el tipo de disco s3_plain_rewritable si no necesita metadatos locales para la tabla y está dispuesto a aceptar un conjunto limitado de operaciones. Esto puede resultar útil, por ejemplo, para las tablas del sistema. Configuración:
es igual a
A partir de la versión 24.5, es posible configurar cualquier disco de almacenamiento de objetos (s3, azure, local) con el tipo de metadatos plain_rewritable.

Uso de Azure Blob Storage

Los motores de tabla de la familia MergeTree pueden almacenar datos en Azure Blob Storage mediante un disco de tipo azure_blob_storage. Configuración:

Parámetros de conexión

Parámetros de autenticación (el disco intentará usar todos los métodos disponibles y Managed Identity Credential):

Parámetros de límite

Otros parámetros

Pueden encontrarse ejemplos de configuraciones funcionales en el directorio de pruebas de integración (consulte, por ejemplo, test_merge_tree_azure_blob_storage o test_azure_blob_storage_zero_copy_replication).
La replicación zero-copy no está lista para producciónLa replicación zero-copy está deshabilitada de forma predeterminada en ClickHouse versión 22.8 y posteriores. Esta funcionalidad no se recomienda para uso en producción.

Uso del almacenamiento HDFS (sin soporte)

En esta configuración de ejemplo:
  • el disco es de tipo hdfs (sin soporte)
  • los datos están alojados en hdfs://hdfs1:9000/clickhouse/
HDFS no tiene soporte y, por lo tanto, podrían surgir problemas al usarlo. No dudes en enviar una pull request con la corrección si aparece algún problema.
Ten en cuenta que HDFS puede no funcionar en casos límite.

Uso del cifrado de datos

Puede cifrar los datos almacenados en discos externos S3 o HDFS (no compatible), o en un disco local. Para activar el modo de cifrado, en el archivo de configuración debe definir un disco del tipo encrypted y elegir el disco en el que se guardarán los datos. Un disco encrypted cifra todos los archivos escritos en tiempo real y, al leer archivos desde un disco encrypted, los descifra automáticamente. Así, puede trabajar con un disco encrypted como si fuera uno normal. Ejemplo de configuración de disco:
Por ejemplo, cuando ClickHouse escribe datos de una tabla en un archivo store/all_1_1_0/data.bin en disk1, en realidad ese archivo se escribirá en el disco físico en la ruta /path1/store/all_1_1_0/data.bin. Al escribir el mismo archivo en disk2, en realidad se escribirá en el disco físico en la ruta /path1/path2/store/all_1_1_0/data.bin, en modo cifrado.

Parámetros requeridos

Parámetros opcionales

Ejemplo de configuración del disco:

Uso de la caché local

Es posible configurar una caché local sobre discos en la configuración de almacenamiento a partir de la versión 22.3. En las versiones 22.3 - 22.7, la caché solo es compatible con el tipo de disco s3. En las versiones >= 22.8, la caché es compatible con cualquier tipo de disco: S3, Azure, Local, Encrypted, etc. En las versiones >= 23.5, la caché solo es compatible con tipos de disco remotos: S3, Azure, HDFS (sin soporte). La caché usa la política LRU. Ejemplo de configuración para versiones posteriores o iguales a 22.8:
Ejemplo de configuración para versiones anteriores a la versión 22.8:
Ajustes de configuración del disco de caché del sistema de archivos: Estos ajustes deben definirse en la sección de configuración del disco.
Nota: Los valores de tamaño admiten unidades como ki, Mi, Gi, etc. (p. ej., 10Gi).

Configuración de consulta/perfil de la caché del sistema de archivos

La configuración de la caché y la configuración de consultas de la caché corresponden a la versión más reciente de ClickHouse; es posible que algunas opciones no estén disponibles en versiones anteriores.

Tablas del sistema de la caché del sistema de archivos

Comandos de la caché

SYSTEM CLEAR|DROP FILESYSTEM CACHE (<cache_name>) (ON CLUSTER)ON CLUSTER
Este comando solo se admite cuando no se proporciona <cache_name>
SHOW FILESYSTEM CACHES
Muestra una lista de las cachés del sistema de archivos configuradas en el servidor. (En las versiones anteriores o iguales a 22.8, el comando se llama SHOW CACHES)
Query
Response
DESCRIBE FILESYSTEM CACHE '<cache_name>'
Muestra la configuración de la caché y algunas estadísticas generales de una caché concreta. El nombre de la caché puede obtenerse con el comando SHOW FILESYSTEM CACHES. (En versiones anteriores o iguales a 22.8, el comando se llama DESCRIBE CACHE)
Query
Response

Uso de almacenamiento web estático (solo lectura)

Este es un disco de solo lectura. Sus datos solo se leen y nunca se modifican. Una tabla nueva se carga en este disco mediante la consulta ATTACH TABLE (consulte el ejemplo a continuación). En realidad, el disco local no se utiliza; cada consulta SELECT dará lugar a una solicitud http para obtener los datos necesarios. Cualquier modificación de los datos de la tabla producirá una excepción; es decir, no se permiten los siguientes tipos de consultas: CREATE TABLE, ALTER TABLE, RENAME TABLE, DETACH TABLE y TRUNCATE TABLE. El almacenamiento web puede utilizarse con fines de solo lectura. Un caso de uso es alojar datos de muestra o migrar datos. Existe una herramienta, clickhouse-static-files-uploader, que prepara un directorio de datos para una tabla determinada (SELECT data_paths FROM system.tables WHERE name = 'table_name'). Para cada tabla que necesite, se obtiene un directorio de archivos. Estos archivos se pueden cargar en, por ejemplo, un servidor web de archivos estáticos. Después de esta preparación, puede cargar esta tabla en cualquier servidor de ClickHouse mediante DiskWeb. En esta configuración de ejemplo:
  • el disco es de tipo web
  • los datos están alojados en http://nginx:80/test1/
  • se utiliza una caché en el almacenamiento local
El almacenamiento también puede configurarse temporalmente dentro de una consulta, si no se prevé usar un conjunto de datos web de forma rutinaria; consulte la configuración dinámica y omita editar el archivo de configuración.Hay un conjunto de datos de demostración alojado en GitHub. Para preparar sus propias tablas para el almacenamiento web, consulte la herramienta clickhouse-static-files-uploader
En esta consulta ATTACH TABLE, el UUID proporcionado coincide con el nombre del directorio de los datos, y el endpoint es la URL del contenido raw de GitHub.
Un caso de prueba ya preparado. Debes añadir esta configuración a config:
Y luego, ejecuta esta consulta:

Parámetros obligatorios

Parámetros opcionales

Si una consulta falla con la excepción DB:Exception Unreachable URL, puedes intentar ajustar esta configuración: http_connection_timeout, http_receive_timeout, keep_alive_timeout. Para obtener archivos para la carga, ejecuta: clickhouse static-files-disk-uploader --metadata-path <path> --output-dir <dir> (--metadata-path se puede encontrar en la consulta SELECT data_paths FROM system.tables WHERE name = 'table_name'). Al cargar archivos mediante endpoint, deben cargarse en la ruta <endpoint>/store/, pero la configuración solo debe contener endpoint. Si la URL no es accesible al cargar el disco mientras el servidor inicia las tablas, se capturan todos los errores. Si en este caso hubo errores, las tablas pueden volver a cargarse (hacerse visibles) mediante DETACH TABLE table_name -> ATTACH TABLE table_name. Si los metadatos se cargaron correctamente durante el inicio del servidor, las tablas están disponibles de inmediato. Usa la configuración http_max_single_read_retries para limitar el número máximo de reintentos durante una sola lectura HTTP.

Replicación zero-copy (no lista para producción)

La replicación zero-copy es posible, pero no se recomienda, con discos S3 y HDFS (no compatibles). La replicación zero-copy significa que, si los datos se almacenan de forma remota en varias máquinas y es necesario sincronizarlos, solo se replican los metadatos (las rutas a las partes de datos), pero no los datos en sí.
La replicación zero-copy no está lista para producciónLa replicación zero-copy está deshabilitada de forma predeterminada en ClickHouse 22.8 y versiones posteriores. Esta funcionalidad no se recomienda para uso en producción.
Última modificación el 12 de junio de 2026