JuiceFS 在 Elasticsearch/ClickHouse 温冷数据存储中的实践( 三 )

在示例的右侧,以 Column 作为前缀的这些文件是实际的数据文件,相比元信息通常会比较大 。这个示例中只有 A、B 两列,实际的表里可能有很多列 。所有这些文件,包括元信息、索引信息,都会共同帮助用户快速地在不同文件之间去做跳转或者查找 。
ClickHouse 存储策略如果要在 ClickHouse 里做冷热数据分层,会用到类似于 ES 中提到的生命周期策略 , 在 ClickHouse 里称为存储策略(Storage Policy) 。
与 ES 稍有不同 , ClickHouse 官方并没有将数据划分不同的阶段 , 比如热数据、温数据、冷数据这些不同的阶段,ClickHouse 提供了一些规则和配置方法,需要用户自己来制定分层策略 。
每个 ClickHouse 节点支持同时配置多块磁盘,存储介质可以是多种多样的 。比如,一般用户为了性能会给 ClickHouse 节点配置 SSD 盘;对于一些温冷数据,用户可以把数据存储在成本更低的介质,如机械盘 。ClickHouse 的用户对底层存储介质是无感知的 。
与 ES 相似,ClickHouse 用户需要根据数据不同的维度特征去制定存储策略,比如每个 part 子目录的大小、整个磁盘的剩余空间比例等,当满足某个维度特征设定的条件时就会触发存储策略的执行 。这个策略会将某一个 part 从一块盘迁移到另外一块盘 。在 ClickHouse 中,一个节点配置的多块盘是有优先级的,默认情况下数据会优先落在最高优先级的盘上 。这样实现了 Part 从一个存储介质转移到另外一个存储介质上 。
通过 ClickHouse 的一些 SQL 命令 , 如 MOVE PARTITION/PART 命令可以手动触发数据迁移,用户也可以通过这些命令做一些功能性的验证 。其次有某些情况下,可能也希望能够通过手动的方式,而不是自动转移的方式来显式把 part 从当前的存储介质上转移到另外一个存储介质上 。
ClickHouse 还支持基于时间的迁移策略,这是一个独立于存储策略的概念 。数据写入后,ClickHouse 会按照每个表的 TTL 属性设置的时间来触发磁盘上数据的迁移 。比如设置 TTL 为 7 天 , ClickHouse 就会把表中超过 7 天的数据从当前的磁盘(如默认的 SSD)再写到另外一个更低优先级的磁盘上(如 JuiceFS) 。
03- 温冷数据存储:为什么使用对象存储+ JuiceFS ?企业把温、冷数据存放到云上后 , 存储成本相较于传统的 SSD 架构大为下降 。企业还享受到了云上的弹性伸缩空间;不用为数据存储去做任何运维操作,比如扩缩容 , 或者一些数据清理类的工作 。温冷数据所需的存储容量比热数据大很多,尤其是随着时间推移,会产生大量需要长期保存的数据,如果这些数据都存储在本地,相应的运维工作将不堪重负 。
但如果在对象存储上使用 Elasticsearch、ClickHouse 这类数据应用组件 , 会存在写入性能差、兼容性等问题 。希望兼顾查询性能的企业,开始在云上寻找解决方案 。在这样的背景之下,JuiceFS 被越来越多地应用于数据分层的架构之中 。
通过下面 ClickHouse 写入性能测试可以直观了解到写入SSD、JuiceFS 以及对象存储的性能差异 。

JuiceFS 在 Elasticsearch/ClickHouse 温冷数据存储中的实践

文章插图
JuiceFS 的写入吞吐量远大于直接对接对象存储,接近 SSD 。当用户把热数据转移到温暖数据这一层时,对于写入性能也有一定要求 。在迁移的过程中,如果底层存储介质的写入性能差,整个迁移的流程也会拖得很长,对于整个 pipeline 或数据管理也会带来一些挑战 。
下图的 ClickHouse 查询性能测试使用真实业务中的数据,并选取几个典型的查询场景进行测试 。其中 q1-q4 是扫描全表的查询,q5-q7 是命中主键索引的查询 。测试结果如下图:
JuiceFS 在 Elasticsearch/ClickHouse 温冷数据存储中的实践

文章插图

JuiceFS 在 Elasticsearch/ClickHouse 温冷数据存储中的实践

文章插图
JuiceFS 与 SSD 盘的查询性能基本相当,平均差异在 6% 左右 , 但是对象存储相比 SSD 盘有 1.4 至 30 倍的性能下降 。得益于 JuiceFS 高性能的元数据操作以及本地缓存特性,可以自动将查询请求需要的热数据缓存在 ClickHouse 节点本地,大幅提升了 ClickHouse 的查询性能 。需要注意的是以上测试中对象存储是通过 ClickHouse 的 S3 磁盘类型进行访问,这种方式只有数据是存储在对象存储上,元数据还是在本地磁盘 。如果通过类似 S3FS 的方式把对象存储挂载到本地,性能会有进一步的下降 。
另外值得一提的是 JuiceFS 是一个完全兼容 POSIX 的文件系统 , 它能够与上层应用(如 Elasticsearch、ClickHouse)有很好的兼容 。用户对底层存储是分布式文件系统或者是本地磁盘是没有感知的 。如果直接使用对象存储,不能很好地实现与上层应用的兼容 。

推荐阅读