- Amazon S3 对象存储。
- Azure Blob 存储。
- 不支持:Hadoop Distributed File System (HDFS)
ClickHouse 还支持外部表引擎,它们与本页介绍的外部存储选项不同,因为前者允许读取以通用文件格式 (如 Parquet) 存储的数据。本页介绍的是 ClickHouse
MergeTree 家族或 Log 家族表的存储配置。- 如需处理存储在
Amazon S3磁盘上的数据,请使用 S3 表引擎。 - 如需处理存储在 Azure Blob 存储中的数据,请使用 AzureBlobStorage 表引擎。
- 如需处理 Hadoop Distributed File System (不支持) 中的数据,请使用 HDFS 表引擎。
配置外部存储
MergeTree 和 Log
家族的表引擎可分别通过类型为 s3、azure_blob_storage、hdfs (不支持) 的磁盘,将数据存储到 S3、AzureBlobStorage、HDFS (不支持) 中。
磁盘配置需要:
- 一个
type配置项,其值必须是s3、azure_blob_storage、hdfs(不支持) 、local_blob_storage、web之一。 - 针对具体外部存储类型的配置。
- 值为
object_storage的type object_storage_type,其值必须是s3、azure_blob_storage(或从24.3起简写为azure) 、hdfs(不支持) 、local_blob_storage(或从24.3起简写为local) 、web之一。
此外,还可以指定
metadata_type (默认值为 local) ,也可将其设置为 plain、web,以及从 24.4 开始支持的 plain_rewritable。
plain 元数据类型的用法见plain storage 部分;web 元数据类型只能与 web 对象存储类型一起使用;local 元数据类型会将元数据文件存储在本地 (每个元数据文件都包含对象存储中文件的映射,以及与这些文件相关的一些附加元信息) 。
例如:
24.1 开始) :
MergeTree 表的默认选项,
请在配置文件中添加以下部分:
disk 替代 storage_policy。在这种情况下,
配置文件中无需包含 storage_policy 部分,只需有一个 disk
部分即可。
refresh_parts_interval 和 table_disk
refresh_parts_interval 可定期从底层存储刷新数据分区片段列表 (例如发现外部写入的 parts) 。这里的关键区别在于跨副本共享元数据与副本本地元数据 (例如每个副本各自维护本地元数据的 S3) :只有在元数据共享时,新的 parts 才会对所有副本可见。仅使用对象存储本身并不意味着元数据是共享的。
-
对象存储 (例如
disk = 's3') 并不意味着元数据是共享的。 当元数据默认按副本存储在本地时,每个副本都会独立管理自己指向对象存储中 blob 的指针。在一个副本上所做的更改,对其他副本不可见。在这种情况下,refresh_parts_interval不会让新的 parts 在副本之间变得可见,因为每个副本读取的都是各自的本地元数据。 -
自动刷新 parts 要求 filesystem 元数据是共享的 (或者表使用表自有的只读元数据,从而能够进行刷新) 。将
table_disk = true与表本地磁盘一起使用 (例如SETTINGS disk = disk(type=object_storage, ...), table_disk = true) 是获得正确语义的一种方式:表负责元数据的生命周期管理,存储会被视为只读,因此会执行refresh_parts_interval,并且能够发现外部新增的 parts。 -
使用全局定义的磁盘时 (例如在
storage_configuration中设置disk = 's3') ,如果采用默认的本地元数据,则每个副本都有自己的元数据状态。即使 blob 可能位于 S3 中,就refresh_parts_interval而言,该存储也不被视为共享存储,因此在 ClickHouse 外部或在另一个副本上创建的新的 parts 都不会被检测到。
table_disk = true 的表级磁盘。如果在元数据为副本本地的情况下仅依赖 refresh_parts_interval,则 parts 不会按预期刷新。
refresh_parts_interval 不用于 ReplicatedMergeTree 表。
复制表已经通过复制机制同步 parts。
此设置仅适用于 parts 由外部写入且需要刷新元数据的非复制表 MergeTree 表。动态配置
CREATE/ATTACH 查询设置中进行配置。
以下示例查询基于上述动态磁盘配置,展示了如何使用本地磁盘缓存存储在 URL 上的表数据。
type=web 的磁盘嵌套在
type=cache 的磁盘内。
此示例使用了
type=web,但任何磁盘类型都可以配置为动态磁盘,
包括本地磁盘。本地磁盘要求其 path 参数位于
server 配置参数 custom_local_disks_base_directory 中。该参数没有
默认值,因此使用本地磁盘时也需要设置它。web 来自服务端配置文件:
使用 S3 存储
必需参数
可选参数
也支持通过
s3 类型使用 Google Cloud Storage (GCS)。请参阅基于 GCS 的 MergeTree。使用 Plain Storage
22.10 版本中,引入了一种新的磁盘类型 s3_plain,可提供一次写入型存储。
它的配置参数与 s3 磁盘类型相同。
与 s3 磁盘类型不同,它会原样存储数据。换句话说,
它不会使用随机生成的 blob 名称,而是使用普通文件名
(与 ClickHouse 在本地磁盘上存储文件的方式相同) ,并且不会在本地存储任何
元数据。例如,这些元数据可根据 s3 上的数据推导出来。
这种磁盘类型可用于保留表的静态版本,因为它不允许
对现有数据执行 merge,也不允许插入新
数据。该磁盘类型的一个典型用法是基于它创建 backups,这可以通过
BACKUP TABLE data TO Disk('plain_disk_name', 'backup_name') 来完成。之后,
你可以执行 RESTORE TABLE data AS data_restored FROM Disk('plain_disk_name', 'backup_name')
或使用 ATTACH TABLE data (...) ENGINE = MergeTree() SETTINGS disk = 'plain_disk_name'。
配置:
24.1 起,可以使用
plain 元数据类型配置任何对象存储磁盘 (s3、azure、hdfs (不支持) 、local) 。
配置:
使用 S3 Plain Rewritable 存储
24.4 中引入了一种新的磁盘类型 s3_plain_rewritable。
与 s3_plain 磁盘类型类似,它不需要额外的存储空间来保存
元数据文件,而是将元数据存储在 S3 中。
不同于 s3_plain 磁盘类型,s3_plain_rewritable 允许执行合并,
并支持 INSERT 操作。
不支持变更和表的复制。
这种磁盘类型的一个适用场景是非复制的 MergeTree 表。虽然
s3 磁盘类型也适用于非复制的 MergeTree 表,但如果你不需要该表的本地元数据,
并且可以接受受限的操作集,则可以选择
s3_plain_rewritable 磁盘类型。例如,它对
系统表就可能很有用。
配置:
24.5 起,可以使用 plain_rewritable 元数据类型来配置任何对象存储磁盘
(s3、azure、local) 。
使用 Azure Blob 存储
MergeTree 家族表引擎可使用类型为 azure_blob_storage 的磁盘将数据存储到 Azure Blob 存储 中。
配置示例:
连接参数
身份验证参数 (磁盘会尝试所有可用方法以及 Managed Identity Credential) :
限制参数
其他参数
可在集成测试目录中找到可用的配置示例 (例如,test_merge_tree_azure_blob_storage 或 test_azure_blob_storage_zero_copy_replication) 。
零拷贝复制尚不能用于生产环境在 ClickHouse 22.8 及更高版本中,零拷贝复制默认处于禁用状态。不建议在生产环境中使用此功能。
使用 HDFS 存储 (不支持)
- 磁盘类型为
hdfs(不支持) - 数据存储在
hdfs://hdfs1:9000/clickhouse/
使用数据加密
encrypted 的磁盘,并选择一个用于保存数据的底层磁盘。encrypted 磁盘会在写入时即时加密所有文件,而从 encrypted 磁盘读取文件时则会自动解密。因此,你可以像使用普通磁盘一样使用 encrypted 磁盘。
磁盘配置示例:
disk1 上的文件 store/all_1_1_0/data.bin 时,实际上该文件会写入物理磁盘上的 /path1/store/all_1_1_0/data.bin 路径。
将同一文件写入 disk2 时,实际上它会以加密方式写入物理磁盘上的 /path1/path2/store/all_1_1_0/data.bin 路径。
必需参数
可选参数
磁盘配置示例:
使用本地缓存
s3 磁盘类型支持缓存。对于 >= 22.8 版本,所有磁盘类型都支持缓存:S3、Azure、Local、Encrypted 等。
对于 >= 23.5 版本,仅远程磁盘类型支持缓存:S3、Azure、HDFS (不支持) 。
缓存使用 LRU 缓存策略。
22.8 及以上版本的配置示例:
注意:Size 值支持ki、Mi、Gi等单位 (例如10Gi) 。
File Cache 查询/profile 设置
缓存相关系统表
缓存命令
SYSTEM CLEAR|DROP FILESYSTEM CACHE (<cache_name>) (ON CLUSTER) — ON CLUSTER
<cache_name> 时,才支持此命令
SHOW FILESYSTEM CACHES
22.8 的版本,该命令名为 SHOW CACHES)
Query
Response
DESCRIBE FILESYSTEM CACHE '<cache_name>'
SHOW FILESYSTEM CACHES 命令获取。 (在小于或等于 22.8 的版本中,
该命令名为 DESCRIBE CACHE)
Query
Response
使用静态 Web 存储 (只读)
ATTACH TABLE 查询加载到该磁盘 (见下方示例) 。本地磁盘
实际上不会被使用,每个 SELECT 查询都会触发一次 http 请求,以
拉取所需数据。对表数据进行任何修改都会导致
异常,也就是说,不允许执行以下类型的查询:CREATE TABLE、
ALTER TABLE、RENAME TABLE、
DETACH TABLE 和 TRUNCATE TABLE。
Web 存储可用于只读场景。一个示例用途是托管
示例数据,或用于迁移数据。有一个工具 clickhouse-static-files-uploader,
它会为指定表准备一个数据目录 (SELECT data_paths FROM system.tables WHERE name = 'table_name') 。
对于所需的每个表,都会生成一个文件目录。这些文件可以上传
到例如提供静态文件的 Web 服务器。完成这些准备后,
你可以通过 DiskWeb 将该表加载到任何 ClickHouse server 中。
在此示例配置中:
- 磁盘类型为
web - 数据托管在
http://nginx:80/test1/ - 使用了本地存储上的缓存
ATTACH TABLE 查询中,提供的 UUID 与数据目录名称一致,而端点是 GitHub 原始内容的 URL。
必需参数
可选参数
如果查询因异常
DB:Exception Unreachable URL 失败,你可以尝试调整以下设置:http_connection_timeout、http_receive_timeout、keep_alive_timeout。
要获取用于上传的文件,请运行:
clickhouse static-files-disk-uploader --metadata-path <path> --output-dir <dir> (可通过查询 SELECT data_paths FROM system.tables WHERE name = 'table_name' 找到 --metadata-path) 。
通过 endpoint 加载文件时,文件必须加载到 <endpoint>/store/ 路径下,但配置中只能填写 endpoint。
如果服务器在启动表时,磁盘加载过程中 URL 无法访问,系统会捕获所有错误。在这种情况下如果出现错误,可以通过 DETACH TABLE table_name -> ATTACH TABLE table_name 重新加载表 (使其重新可见) 。如果元数据在服务器启动时已成功加载,则表会立即可用。
使用 http_max_single_read_retries 设置来限制单次 HTTP 读取期间的最大重试次数。
零拷贝复制 (尚不适用于生产环境)
S3 和 HDFS (不受支持) 磁盘上使用零拷贝复制,但不建议这样做。零拷贝复制是指:如果数据远程存储在多台机器上并且需要同步,则只复制元数据 (数据分区片段的路径) ,而不复制数据本身。
零拷贝复制尚不适用于生产环境在 ClickHouse 22.8 及更高版本中,零拷贝复制默认被禁用。不建议在生产环境中使用此功能。