再往下是 policies 配置项，这里定义了一个叫做 hot_and_cold 的存储策略 ， 用户需要定义一些具体的规则，如 volumes 中按照先热后冷的优先级排列，数据首先会落到 volumes 里的第一个 hot 盘上，及默认的 ClickHouse 磁盘，一般是本地的 SSD 。
volumes 中的 max_data_part_size_bytes 配置表示当某一个 part 的大小超过设定的大小之后，就会触发存储策略的执行，对应的 part 会下沉到下一个 volume ， 也就是 cold volume 。在上面的示例中，cold volume 就是 JuiceFS 。
最下面的 move_factor 配置代表 ClickHouse 会根据当前磁盘的剩余空间比例来触发存储策略的执行 。
CREATE TABLE test ( d DateTime, ...) ENGINE = MergeTree...TTL d + INTERVAL 1 DAY TO DISK 'jfs'SETTINGS storage_policy = 'hot_and_cold'；如上面的代码所示 ， 有了存储策略之后，在创建表或者修改这个表的 schema 时，可以在 SETTINGS 中设置 storage_policy 为前面定义的 hot_and_cold 存储策略 。上述代码中倒数第二行的 TTL 即为上文提过的基于时间的分层规则 。在这个示例中，我们指定的表中某一个叫做 d 的列，它的类型是 DateTime，结合 INTERVAL 1 DAY 就表示当新的数据写进来超过一天之后，这些数据就会转移到 JuiceFS 上 。
06- 展望第一，副本共享 。无论是 ES 还是 ClickHouse，他们都是由多副本来保证数据的可用性和可靠性 。JuiceFS 本质上是一个共享文件系统，任何一份数据写入到 JuiceFS 之后 ， 不再需要维护多个副本 。比如，用户有两个 ClickHouse 节点 ， 都有某一个表的或者某一个 part 的副本，这两个节点都下沉到了 JuiceFS，它可能会写两次一样的数据 。未来，我们是否可以做到让上层引擎能够感知到下层使用的是一个共享存储，当数据下沉的时候去降低副本数，这样在不同节点之间是可以做副本共享的 。从应用层来说，用户查看这个表 ， part 数还是多副本，但实际在底层的存储上只保了一个副本，因为本质上数据是可以共享的 。
第二点，故障恢复 。当数据已经下沉到一个远端的共享存储之后，如果 ES 或 ClickHousle 节点宕机故障之后，怎么快速地做故障恢复？除了热数据以外的大部分数据其实都已经转移到了一个远端的共享存储上，这个时候如果要去恢复或创建一个新的节点时 ， 成本会比传统的基于本地盘的故障恢复方式轻量很多，这在 ES 或者 ClickHouse 场景上是值得探索的 。
第三点，存算分离 。不管 ES 也好，还是 ClickHouse ， 整个社区也都在尝试或者探索在云原生的大环境下，怎么去让传统的这些基于本地盘的存储系统变成一个真正的存算分离系统 。但存算分离不是仅仅简单地把数据和计算分离就好了 ， 同时要满足上层各种复杂的需求，比如对于查询性能的需求、对于写入性能的需求、对各种维度调优的需求，在存量分离整个大的方向上还是有许多值得探索的技术难点 。
第四点，其他上层应用组件数据分层探索 。除了ES 和 ClickHouse 这两个场景，我们最近也有在做一些尝试，把 Apache Pulsar 中的温冷数据下沉到 JuiceFS 中，用到的一些策略和方案与本文中提到的是类似的，只不过在 Apache Pulsar 中，它需要下沉的数据类型或者数据格式不太一样 。有了进一步成功实践后，会分享出来 。
相关阅读：
- JuiceFS 在携程海量冷数据场景下的实践
- Shopee x JuiceFS: ClickHouse 冷热数据分离存储架构与实践
推荐阅读
- 苹果手机如何在家里自己刷机（苹果刷机工具哪个好用)
- Makfile总结
- iphone12怎么调出3g_iphone12怎么手动设置3g
- 工厂里懂得mes和erp有发展吗?
- MES与工业互联网的关联边界在哪里？
- influxDB2.2
- 华硕灵耀Pro16评测_华硕灵耀Pro16评测表现
- 荣耀50有耳机孔吗_荣耀50耳机接口在哪
- 我的 Kafka 旅程 - broker
- 七彩虹3060测评_七彩虹3060开箱测评