JuiceFS 在 Elasticsearch/ClickHouse 温冷数据存储中的实践( 四 ) _生活百科

ClickHouse 还支持基于时间的迁移策略，这是一个独立于存储策略的概念。数据写入后，ClickHouse 会按照每个表的 TTL 属性设置的时间来触发磁盘上数据的迁移。比如设置 TTL 为 7 天，ClickHouse 就会把表中超过 7 天的数据从当前的磁盘（如默认的 SSD）再写到另外一个更低优先级的磁盘上（如 JuiceFS）。
03- 温冷数据存储：为什么使用对象存储+ JuiceFS ？企业把温、冷数据存放到云上后，存储成本相较于传统的 SSD 架构大为下降。企业还享受到了云上的弹性伸缩空间；不用为数据存储去做任何运维操作，比如扩缩容，或者一些数据清理类的工作。温冷数据所需的存储容量比热数据大很多，尤其是随着时间推移，会产生大量需要长期保存的数据，如果这些数据都存储在本地，相应的运维工作将不堪重负。
但如果在对象存储上使用 Elasticsearch、ClickHouse 这类数据应用组件，会存在写入性能差、兼容性等问题。希望兼顾查询性能的企业，开始在云上寻找解决方案。在这样的背景之下，JuiceFS 被越来越多地应用于数据分层的架构之中。
通过下面 ClickHouse 写入性能测试可以直观了解到写入SSD、JuiceFS 以及对象存储的性能差异。

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

文章插图

文章插图
JuiceFS 与 SSD 盘的查询性能基本相当，平均差异在 6% 左右，但是对象存储相比 SSD 盘有 1.4 至 30 倍的性能下降。得益于 JuiceFS 高性能的元数据操作以及本地缓存特性，可以自动将查询请求需要的热数据缓存在 ClickHouse 节点本地，大幅提升了 ClickHouse 的查询性能。需要注意的是以上测试中对象存储是通过 ClickHouse 的 S3 磁盘类型进行访问，这种方式只有数据是存储在对象存储上，元数据还是在本地磁盘。如果通过类似 S3FS 的方式把对象存储挂载到本地，性能会有进一步的下降。
另外值得一提的是 JuiceFS 是一个完全兼容 POSIX 的文件系统，它能够与上层应用（如 Elasticsearch、ClickHouse）有很好的兼容。用户对底层存储是分布式文件系统或者是本地磁盘是没有感知的。如果直接使用对象存储，不能很好地实现与上层应用的兼容。
04- 实操：ES + JuiceFSStep 1：准备多种类型节点，分配不同角色。每一个 ES 节点可以分配不同的角色，比如存热数据、温数据、冷数据等，用户需要准备不同机型的节点来匹配不同角色的需求。
Step 2：挂载 JuiceFS 文件系统。一般用户将 JuiceFS 用于温、冷数据的存储，用户需要在 ES 温数据节点或冷数据的节点上把 JuiceFS 文件系统挂载到本地。用户可以通过符号链接或其它方式把挂载点配置到 ES 中去，让 ES 认为它的数据存储在本地目录里，但这个目录背后其实是一个 JuiceFS 文件系统。
Step 3：创建生命周期策略。这个需要每个用户自己去定制，用户既可以通过 ES API 去创建，也可以通过 Kibana 去创建，Kibana 提供了一些相对便捷的方式去创建和管理生命周期策略。