JuiceFS 元数据引擎选型指南

> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码， 原文地址 [mp.weixin.qq.com](https://mp.weixin.qq.com/s/asVk0-rUfzdP2Np78HkDkw)

文件系统 （File System）是常见的存储形式，主要由数据和元数据两部分组成。其中数据是文件的具体内容，通常会直接展现给用户；而元数据是描述数据的数据，用来记录文件属性、目录结构、数据存储位置等。一般来说，元数据有非常鲜明的特点，即占用空间较小，但访问非常频繁。

当今的分布式文件系统中，有的（如 S3FS）会将元数据和数据统一管理，以简化系统设计，不过这样的弊端是某些元数据操作会让用户感受到明显的卡顿，如 `ls` 大目录，重命名大文件等。更多的文件系统会选择将这两者分开管理，并根据元数据的特点进行针对性优化。JuiceFS 采用的就是这种设计，其架构图如下：

![](https://mmbiz.qpic.cn/mmbiz_png/F446RY3QsZns2FhUt2kE85vR6NV0S1QrbW4YIVBCLtmyuibuPbHstqIKfk74spA0LI7FB199o9bg1MrPSibThMwg/640?wx_fmt=png)

JuiceFS 架构图

其中，**元数据引擎需要是能够支持事务操作的数据库**，而数据引擎一般是用对象存储。目前为止，JuiceFS 已经支持 10 种以上元数据引擎和 30 种以上数据引擎。

用户在使用 JuiceFS 时可以自由地选择成熟组件来充当这两个引擎，以应对丰富多变的企业环境和数据存储需求。然而对于新用户来说，当面对更多选择时，也带来了一个问题：在我的场景中究竟选择哪一款数据库作为元数据引擎比较合适？这篇文章将从产品设计角度，为大家介绍 JuiceFS 可使用的元数据引擎类型，以及他们的优劣势。

01-JuiceFS 元数据引擎类型
------------------

JuiceFS 现在支持的元数据引擎总共有有三大类。

**第一个是** **Redis**。Redis 是 JuiceFS 开源后最早支持的元数据引擎。首先 Redis 速度够快，这是元数据引擎需要具备的重要能力之一；其次，Redis 受众面广，大部分用户对 Redis 都有实践经验。JuiceFS 对兼容 Redis 协议的数据库也都实现了支持，比如 KeyDB、Amazon MemoryDB 等。

然而，Redis 的可靠性和扩展性容易受限，在一些数据安全性要求较高或规模较大的场景中表现乏善可陈，因此我们又开发支持了另外两类引擎。

**第二个是** **SQL 类**。如 MySQL、MariaDB、PostgreSQL 等，它们的特点是流行度较高，且通常具有不错的可靠性与扩展性。另外，还支持了嵌入式数据库 SQLite。

**最后一个是 TKV（Transactional Key-Value Database）类。**它们的原生接口比较简单，因此在 JuiceFS 中的定制性更好，相较于 SQL 类一般也能有更高的性能。目前这一类支持的有 TiKV、etcd 和嵌入式的 BadgerDB 等，对 FoundationDB 的支持也在紧锣密鼓地开发中。

以上是根据 JuiceFS 在对接数据库时的协议接口进行的分类。每个大类里面有各种不同的数据库，每种数据库又有其自身的特点，以下根据这些特点对用户常用的几个选项进行比较。

### 元数据引擎比较

<table><thead><tr><td><br></td><td>Redis</td><td>MySQL/PostgreSQL</td><td>TiKV</td><td>etcd</td><td>SQLite/BadgerDB</td></tr></thead><tbody><tr><td>性能</td><td>高</td><td>低</td><td>中</td><td>低</td><td>中</td></tr><tr><td>扩展性</td><td>低</td><td>中</td><td>高</td><td>低</td><td>低</td></tr><tr><td>可靠性</td><td>低</td><td>高</td><td>高</td><td>高</td><td>中</td></tr><tr><td>可用性</td><td>中</td><td>高</td><td>高</td><td>高</td><td>低</td></tr><tr><td>流行度</td><td>高</td><td>高</td><td>中</td><td>高</td><td>中</td></tr></tbody></table>

如上文中提到的，Redis 的最大优势是性能高，因为它是全内存的数据库。其他几方面它就表现平平。

从扩展性上说，通常单机 Redis 可以支持 1 亿文件左右，超过 1 亿时，Redis 单进程的内存使用量会比较大，管理性能上也会有所下降。开源版 Redis 支持以集群模式来扩展其可管理的数据总量，但由于集群模式下 Redis 并不支持分布式事务，因此作为 JuiceFS 元数据引擎时，每个 JuiceFS volume 能用的 Redis 进程还是只有一个，单 volume 的扩展性相较于单机 Redis 并没有太大提升。

从可靠性来看，Redis 默认每秒将数据刷盘，在异常时可能导致小部分数据丢失。通过将配置 appendfsync 改为 always，可以让 Redis 在每个写请求后都刷盘，这样数据可靠性能提高，但是性能却会下降。

从可用性来说，部署 Redis 哨兵监控节点和备用节点，可以在主 Redis 节点挂掉后选择一个备份节点来重新提供服务，一定程度上提高可用性。然而，Redis 本身并不支持分布式的一致性协议，其备用节点采用的是异步备份，所以虽然新的节点起来了，但是中间可能会有数据差，导致新起来的数据并不是那么的完整。

MySQL 和 PostgreSQL 的整体表现比较类似。它们都是经过大量用户多年时间验证过的数据库产品，可靠性和可用性都不错，流行度也很高。只是相较于其余元数据引擎，它们的性能一般。

TiKV 原本是 PingCAP TiDB 的底层存储，现在已经分离出来，成为一个独立的 KV 数据库组件。从我们的测试结果来看，它用来作为 JuiceFS 的元数据引擎是一个非常出色的选择。其本身就有不弱于 MySQL 的数据可靠性和服务可用性，而且在性能与扩展性上表现更好。只是在流行度上，它和 MySQL 还有差距。从我们与用户交流来看，如果他们已经是 TiKV 或 TiDB 的用户，那最后通常都会偏向使用 TiKV 来做 JuiceFS 的元数据引擎。但如果他们之前对 TiKV 并不熟悉，那要再接受这样一个新的组件就会慎重许多。

etcd 是另一个 TKV 类的数据库。支持 etcd 的原因是因为它在容器化场景中流行度非常高，基本上 k8s 都是用 etcd 来管理它的配置。使用 etcd 作为 JuiceFS 的元数据引擎，并不是一个特别适配的场景。一方面是它的性能一般，另一方面是它有容量限制（默认 2G，最大 8G），之后就难以扩容。但是它的可靠性和可用性都非常高，而且容器化场景中也很容易部署，**因此如果用户只需要一个规模在百万文件级别的文件系统，etcd 依然是一个不错的选择。**

最后是 SQLite 和 BadgerDB，它们分别属于 SQL 类和 TKV 类，但使用起来体验却非常类似，因为它们都是单机版的嵌入式数据库。这类数据库的特点是性能中等，但扩展性和可用性都比较差，因为其数据其实就存放在本地系统中。它们的优势在于非常易用，只需要 JuiceFS 自己的二进制文件，不需要任何额外组件。用户在某些特定场景或者进行一些简单功能测试时，可以使用这两个数据库。

02- 典型引擎的性能测试结果
---------------

我们做过一些典型引擎的性能测试，并将其结果记录在这个文档 [1] 中。其中一份从源码接口处测试的最直接结果大致为：**Redis > TiKV（3 副本）> MySQL（本地）~= etcd（3 副本）**，具体如下：

<table><thead><tr><td><br></td><td>Redis-Always</td><td>Redis-Everysec</td><td>TiKV</td><td>MySQL</td><td>etcd</td></tr></thead><tbody><tr><td>mkdir</td><td>600</td><td>471 (0.8)</td><td>1614 (2.7)</td><td>2121 (3.5)</td><td>2203 (3.7)</td></tr><tr><td>mvdir</td><td>878</td><td>756 (0.9)</td><td>1854 (2.1)</td><td>3372 (3.8)</td><td>3000 (3.4)</td></tr><tr><td>rmdir</td><td>785</td><td>673 (0.9)</td><td>2097 (2.7)</td><td>3065 (3.9)</td><td>3634 (4.6)</td></tr><tr><td>readdir_10</td><td>302</td><td>303 (1.0)</td><td>1232 (4.1)</td><td>1011 (3.3)</td><td>2171 (7.2)</td></tr><tr><td>readdir_1k</td><td>1668</td><td>1838 (1.1)</td><td>6682 (4.0)</td><td>16824 (10.1)</td><td>17470 (10.5)</td></tr><tr><td>mknod</td><td>584</td><td>498 (0.9)</td><td>1561 (2.7)</td><td>2117 (3.6)</td><td>2232 (3.8)</td></tr><tr><td>create</td><td>591</td><td>468 (0.8)</td><td>1565 (2.6)</td><td>2120 (3.6)</td><td>2206 (3.7)</td></tr><tr><td>rename</td><td>860</td><td>736 (0.9)</td><td>1799 (2.1)</td><td>3391 (3.9)</td><td>2941 (3.4)</td></tr><tr><td>unlink</td><td>709</td><td>580 (0.8)</td><td>1881 (2.7)</td><td>3052 (4.3)</td><td>3080 (4.3)</td></tr><tr><td>lookup</td><td>99</td><td>97 (1.0)</td><td>731 (7.4)</td><td>423 (4.3)</td><td>1286 (13.0)</td></tr><tr><td>getattr</td><td>91</td><td>89 (1.0)</td><td>371 (4.1)</td><td>343 (3.8)</td><td>661 (7.3)</td></tr><tr><td>setattr</td><td>501</td><td>357 (0.7)</td><td>1358 (2.7)</td><td>1258 (2.5)</td><td>1480 (3.0)</td></tr><tr><td>access</td><td>90</td><td>89 (1.0)</td><td>370 (4.1)</td><td>348 (3.9)</td><td>646 (7.2)</td></tr><tr><td>setxattr</td><td>404</td><td>270 (0.7)</td><td>1116 (2.8)</td><td>1152 (2.9)</td><td>757 (1.9)</td></tr><tr><td>getxattr</td><td>91</td><td>89 (1.0)</td><td>365 (4.0)</td><td>298 (3.3)</td><td>655 (7.2)</td></tr><tr><td>removexattr</td><td>219</td><td>95 (0.4)</td><td>1554 (7.1)</td><td>882 (4.0)</td><td>1461 (6.7)</td></tr><tr><td>listxattr_1</td><td>88</td><td>88 (1.0)</td><td>374 (4.2)</td><td>312 (3.5)</td><td>658 (7.5)</td></tr><tr><td>listxattr_10</td><td>94</td><td>91 (1.0)</td><td>390 (4.1)</td><td>397 (4.2)</td><td>694 (7.4)</td></tr><tr><td>link</td><td>605</td><td>461 (0.8)</td><td>1627 (2.7)</td><td>2436 (4.0)</td><td>2237 (3.7)</td></tr><tr><td>symlink</td><td>602</td><td>465 (0.8)</td><td>1633 (2.7)</td><td>2394 (4.0)</td><td>2244 (3.7)</td></tr><tr><td>write</td><td>613</td><td>371 (0.6)</td><td>1905 (3.1)</td><td>2565 (4.2)</td><td>2350 (3.8)</td></tr><tr><td>read_1</td><td>0</td><td>0 (0.0)</td><td>0 (0.0)</td><td>0 (0.0)</td><td>0 (0.0)</td></tr><tr><td>read_10</td><td>0</td><td>0 (0.0)</td><td>0 (0.0)</td><td>0 (0.0)</td><td>0 (0.0)</td></tr></tbody></table>

*   • 上表中记录的是每一个操作的耗时，数值越小越好；括号内数字是该指标对比 Redis-always 的倍数，数值也是越小越好
    
*   • Always 和 Everysec 是 Redis 配置项 appendfsync 的可选值，分别表示每个请求都刷盘和每秒刷一次盘
    
*   • 可以看到，Redis 在使用 everysec 的时候，性能更好，但与 always 相差的并不大；这是因为测试用的 AWS 机器上的本地 SSD 盘本身 IOPS 性能就比较高
    
*   • TiKV 和 etcd 都使用了三副本，而 MySQL 是单机部署的。即使这样，TiKV 的性能表现还是高于 MySQL，而 etcd 与 MySQL 接近。

**值得一提的是，上文中的测试使用的都是默认配置，并没有对各个元数据引擎去做特定的调优。用户在使用时可以根据自己的需求和实践经验进行配置调整，可能会有不一样的结果。**

另一份测试是通过 JuiceFS 自带的 bench 工具跑的，其运行的是操作系统读写文件的接口，具体结果如下：

<table><thead><tr><td><br></td><td>Redis-Always</td><td>Redis-Everysec</td><td>TiKV</td><td>MySQL</td><td>etcd</td></tr></thead><tbody><tr><td>Write big file</td><td>565.07 MiB/s</td><td>556.92 MiB/s</td><td>553.58 MiB/s</td><td>557.93 MiB/s</td><td>542.93 MiB/s</td></tr><tr><td>Read big file</td><td>664.82 MiB/s</td><td>652.18 MiB/s</td><td>679.07 MiB/s</td><td>673.55 MiB/s</td><td>672.91 MiB/s</td></tr><tr><td>Write small file</td><td>102.30 files/s</td><td>105.80 files/s</td><td>95.00 files/s</td><td>87.20 files/s</td><td>95.75 files/s</td></tr><tr><td>Read small file</td><td>2200.30 files/s</td><td>1894.45 files/s</td><td>1394.90 files/s</td><td>1360.85 files/s</td><td>1017.30 files/s</td></tr><tr><td>Stat file</td><td>11607.40 files/s</td><td>15032.90 files/s</td><td>3283.20 files/s</td><td>5470.05 files/s</td><td>2827.80 files/s</td></tr><tr><td>FUSE operation</td><td>0.41 ms/op</td><td>0.42 ms/op</td><td>0.45 ms/op</td><td>0.46 ms/op</td><td>0.42 ms/op</td></tr><tr><td>Update meta</td><td>3.63 ms/op</td><td>3.19 ms/op</td><td>7.04 ms/op</td><td>8.91 ms/op</td><td>4.46 ms/op</td></tr></tbody></table>

从上表可以看到，**读写大文件时使用不同的元数据引擎最后性能是差不多的。**这是因为此时性能瓶颈主要在对象存储的数据读写上，元数据引擎之间虽然时延有点差异，但是放到整个业务读写的消耗上，这点差异几乎可以忽略不计。当然，如果对象存储变得非常快（比如都用本地全闪部署），那么元数据引擎的性能差异可能又会体现出来。另外，对于一些纯元数据操作（比如 ls，创建空文件等），不同元数据引擎的性能差别也会表现的比较明显。

03 - 引擎选型的考虑要素
--------------

根据上文介绍的各引擎特点，用户可以根据自己的情况去选择合适的引擎。以下简单分享下我们在做推荐时会建议用户考虑的几个要素。

**评估需求**：比如想使用 Redis，需要先评估能否接受少量的数据丢失，短期的服务中断等。如果是存储一些临时数据或者中间数据的场景，那么用 Redis 确实是不错的选择，因为它性能够好，即使有少量的数据丢失，也不会造成很大的影响。但如果是要存储一些关键数据， Redis 就不适用了。另外还得评估预期数据的规模，如果在 1 亿文件左右， Redis 可以承受；如果预期会有 10 亿文件，那么显然单机 Redis 是难以承载的。

**评估硬件**：比如能否连通外网，是使用托管的云服务，还是在自己机房内私有部署。如果是私有部署，需要评估是否有足够的硬件资源去部署一些相关的组件。无论是用哪一种元数据引擎，基本上都要求有高速的 SSD 盘去运行，不然会对其性能有比较大的影响。

**评估运维能力，这是很多人会忽视的，但是在我们来看这应该是最关键的因素之一。**对于存储系统来说，稳定性往往才是其上生产后的第一重点。用户在选择元数据引擎的时候，应该先想想自己对它是不是熟悉，在出现问题时，能否快速定位解决；团队内是否有足够的经验或精力去把控好这个组件。通常来说，我们会建议用户在开始时选择一个自己熟悉的数据库是比较合适的。如果运维人员不足，那么选择公有云服务也确实是个省心的选项。

这里分享下社区在使用元数据引擎方面的一些统计数据。

*   • **目前为止， Redis 的使用者依然占了一半以上**，其次是 TiKV 和 MySQL，这两类的使用者的数量占比在逐步增长。
    
*   • **在运行的 Redis 集群的最大文件数大概是在 1.5 亿，**而且运行情况是比较稳定的。上文提到的推荐的 1 亿文件是建议值，并不是说无法超过 1 亿。
    
*   • **整体数量规模 Top3，都是使用的 TiKV 而且都超过了 10 亿文件数量。**现在最大的文件系统的文件数量是超了 70 亿文件，总容量超过了 15 PiB，这也从侧面证明了 TiKV 在作为元数据引擎时的扩展能力。我们自己内部测过使用 TiKV 作为元数据引擎存储 100 亿文件，系统仍能稳定地运行。所以如果你的整个集群预期的规模会非常大，那么 TiKV 确实是一个很好的选择。

04- 元数引擎迁移
----------

文章的最后，为大家介绍元数据引擎迁移。随着用户业务的发展，企业对元数据引擎的需求会发生变化，当用户发现现有的元数据引擎不合适了，可以考虑将元数据迁移到另一个引擎中。我们为用户提供了完整的迁移方法，具体可以参考这个文档 [2]。

这个迁移方法有一定的限制，首先只能迁移到空数据库，暂时无法将两个文件系统直接合在一起；其次，需要停写，因为数据量比较大的情况下，很难在线将元数据完整的迁移过来。要做到这点需要加许多限制，从实测来看速度会非常慢。因此，把整个文件系统停掉再去做迁移是最稳妥的。如果说实在需要有一定的服务提供，可以保留只读挂载，用户读数据并不会影响整个元数据引擎迁移的动作。

虽然社区提供了全套的迁移方法，但是还是需要提醒用户，尽量提前对数据量的增长做好规划，尽量不做迁移或尽早迁移。当要迁移的数据规模很大时，耗时也会变长，期间出问题的概率也会变大。

**本文作者  
**

![图片](https://mmbiz.qpic.cn/mmbiz_png/F446RY3QsZnsdx9Fr7BR4T5Hz5QbvFF4Iy4Tme5dvDC6mcWG1jCk0pNpJeLhk9dMxVYgCibicl8XjnlTEbAUfD4g/640?wx_fmt=png)

**Sandy**

JuiceFS 核心系统工程师，十年分布式存储系统经验，主要负责 JuiceFS 社区版本的日常开发与维护。

引用链接

`[1]` 文档: _https://juicefs.com/docs/zh/community/metadata_engines_benchmark/_  
`[2]` 这个文档: _https://juicefs.com/docs/zh/community/metadata_dump_load#%E5%85%83%E6%95%B0%E6%8D%AE%E8%BF%81%E7%A7%BB_

**关于元数据更多讨论  
****欢迎加入用户群**

![](https://mmbiz.qpic.cn/mmbiz_png/F446RY3QsZnicUqZp3Z8kiaYTeutdibxV6AzEciaNND2C30ZXAicFAW9pXQYFkWJT0bhuJj1ia8qW37XDCAob2RCTdYA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)

社群助手兼合伙人苏锐全天在线

用户案例

[一面数据 Hadoop 上云](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247487472&idx=1&sn=fad1bd5f9c27ecf4db54fe2b0129abdc&chksm=c03d84bef74a0da8aca5b055b93b1c94fb305ac05b14c1939eb3be2f039ed1cd6c3f7647fd80&scene=21#wechat_redirect)  [AI - 云知声](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247486878&idx=1&sn=0f9db6a5828f2b57a8899444d265f90e&chksm=c03d86d0f74a0fc6a05f0b9c22ea656a7b66182038d824bd0904cb3584ed74855f8508e6c4e0&scene=21#wechat_redirect)

[AI for Science - 深势科技](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247486950&idx=1&sn=08ae30278c08eb17a4ceb5705a8ea8f7&chksm=c03d86a8f74a0fbe060e7addb3eaa56cd6a918bd2fbb61fce8346795d30dc3309867f2334b7e&scene=21#wechat_redirect)

[理想汽车：从 Hadoop 到云上](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247487472&idx=1&sn=fad1bd5f9c27ecf4db54fe2b0129abdc&chksm=c03d84bef74a0da8aca5b055b93b1c94fb305ac05b14c1939eb3be2f039ed1cd6c3f7647fd80&scene=21#wechat_redirect) [知乎](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247485993&idx=1&sn=99d8bab067233cac450c8c930e89bc4a&chksm=c03d8167f74a08718c282f483fd0fbc886bc515f7159b798fed9ee5270b9a5fc5cae333243b7&scene=21#wechat_redirect)

[在线设计平台：稿定科技](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247485840&idx=1&sn=2b60bb01450ac4f10dcb2915eb1e339a&chksm=c03d82def74a0bc88b35bfc8b3c249a672ea8b5d0b94d6391eaac15ba5c6eb3d5b7f39cff6a6&scene=21#wechat_redirect)

[大搜车](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247483788&idx=1&sn=58dd2ff44ee8461cf2fe9b142f4e5c3d&chksm=c03d8ac2f74a03d4c7226223272f48493c44a8af022ac9db036f85a0205ed0059f2891af3ad4&scene=21#wechat_redirect)  [环球易购](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247483785&idx=1&sn=058e055ad9883cc55981ef7985595505&chksm=c03d8ac7f74a03d1319780d881c6e02c5ac42883f65c89ebf729529feeb5371c886ff109e4b8&scene=21#wechat_redirect) [趣头条](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247485547&idx=1&sn=07c962144b549d0091e0ac0b39f419b8&chksm=c03d8325f74a0a33feb9012651172152f90a080d620e1478f23b1d7c0f283144db479dac4e67&scene=21#wechat_redirect) [Shopee](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247485830&idx=1&sn=fd0a48ac1f7cd192ebfb91ce98155976&chksm=c03d82c8f74a0bdee80401268107e2f74d68b3737b50a351eebd2c33b4fbee616489036f33c7&scene=21#wechat_redirect)

[携程冷数据场景](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247487518&idx=1&sn=4a5034411a8f2aa68537dfcaba9ee9a2&chksm=c03d9b50f74a1246de65cbb2b8166daafd7c10a20b4dd725c416edd424853cb3bbe766eac0b0&scene=21#wechat_redirect)

最佳实践

[元数据备份性能提升 40 倍](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247487047&idx=1&sn=117b4dee65baf0ae4c27a7c51376533a&chksm=c03d8509f74a0c1fc128b3b0868cca71a271282af311de2365b12b14d7d7d0af34eaa3a9922f&scene=21#wechat_redirect) [元数据 - Redis](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247487104&idx=1&sn=77fa0a3b58851bc5f95951c0c45b179d&chksm=c03d85cef74a0cd8db91b7d205acf7eb55d70272520b86cd68d1e41d22842dab7b973f646ff3&scene=21#wechat_redirect) [CSI Driver](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247485950&idx=1&sn=942e620176edee9f64bd42c81fd891b8&chksm=c03d82b0f74a0ba6f8afc0f021d44e8ee9d132905d6e6548c64600db50ed099e87acb61e3d20&scene=21#wechat_redirect)  [性能分析和调优](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247485753&idx=1&sn=ab2e615fbd564879ed7a93260a033723&chksm=c03d8277f74a0b61022a478ab1f5200248f283f2cc17868985623cede0a7d6546ac3e600c341&scene=21#wechat_redirect) [HDFS 数据迁移](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247484563&idx=1&sn=9e295996afae83e8031bb24ffdf107f7&chksm=c03d8fddf74a06cb2daf308bd5a44398da65e6298da9ad3408f939d0ba9520521361a56eb9ba&scene=21#wechat_redirect) [跨云数据搬迁](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247484530&idx=1&sn=d840512b948037bec45fd89cf8418677&chksm=c03d8f3cf74a062ab547f44a8a5bd26ccfebd91c5009098c0d6b9b50a5ae27442c3d8a17d55d&scene=21#wechat_redirect) [ClickHouse 架构探索](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247485465&idx=1&sn=f4fd7f8ef8ecfa56f9315e07ff0b855b&chksm=c03d8357f74a0a41981872a7496cc9ddb7720b8289e04f2cb15bfdfeb051c565f78a854e2a29&scene=21#wechat_redirect)  [MySQL 备份验证性提升 10 倍](http://mp.weixin.qq.com/s?__biz=Mzg5MjUyNjExMw==&mid=2247483786&idx=1&sn=03e93207369fdd66f426db9b6794f1fa&chksm=c03d8ac4f74a03d2d101af6980b7ef81894a5225476bebb255126d5ad2568bb1114daccd98e9&scene=21#wechat_redirect)

**关于 Juicedata**

Juicedata，杭州果汁数据科技有限公司是一家企业级存储服务供应商，开发了云原生分布式文件系统 JuiceFS，致力于在大数据时代下，为客户打造安全、高性能、自主可控的存储基础设施及服务。

2021 年，JuiceFS 正式在 GitHub 上开源，已经获得 6.8 K star，欢迎开发者加入我们。 （github.com/juicedata/juicefs）

JuiceFS 用起来还不错，

点个 “在看”  让更多人知道