经验总结

  1. 首页 > 生活 > >

JuiceFS 元数据引擎选型指南( 四 )

生活百科

  • 整体数量规模 Top3，都是使用的 TiKV 而且都超过了 10 亿文件数量 。现在最大的文件系统的文件数量是超了 70 亿文件，总容量超过了 15 PiB，这也从侧面证明了 TiKV 在作为元数据引擎时的扩展能力 。我们自己内部测过使用 TiKV 作为元数据引擎存储 100 亿文件，系统仍能稳定地运行 。所以如果你的整个集群预期的规模会非常大，那么TiKV 确实是一个很好的选择 。
    • 04- 元数引擎迁移文章的最后，为大家介绍元数据引擎迁移 。随着用户业务的发展，企业对元数据引擎的需求会发生变化，当用户发现现有的元数据引擎不合适了，可以考虑将元数据迁移到另一个引擎中 。我们为用户提供了完整的迁移方法，具体可以参考这个文档 。
    这个迁移方法有一定的限制，首先只能迁移到空数据库，暂时无法将两个文件系统直接合在一起；其次，需要停写，因为数据量会比较大的情况下，很难在线将元数据完整的迁移过来 。要做到这点需要加许多限制，从实测来看速度会非常慢 。因此，把整个文件系统停掉再去做迁移是最稳妥的 。如果说实在需要有一定的服务提供，可以保留只读挂载，用户读数据并不会影响整个元数据引擎迁移的动作 。
    虽然社区提供了全套的迁移方法，但是还是需要提醒用户，尽量提前对数据量的增长做好规划，尽量不做迁移或尽早迁移 。当要迁移的数据规模很大时，耗时也会变长，期间出问题的概率也会变大 。
    如有帮助的话欢迎关注我们项目 Juicedata/JuiceFS 哟！ (0?0?)
    【JuiceFS 元数据引擎选型指南】

    经验总结扩展阅读


    上一篇：动态编译库 Natasha 5.0 兼容版本发布

    下一篇：没有使用IaC的DevOps系统都是耍流氓