用qq空间做网站,360网站地图怎么做,建设项目前期收费查询网站,wordpress论坛注册随着技术的进步和数据的不断爆炸#xff0c;传统的磁盘文件系统已经暴露出它们的局限性。为了满足不断增长的存储需求#xff0c;分布式文件系统作为动态且可扩展的解决方案应运而生。在本文中#xff0c;我们探讨了三种代表性分布式文件系统的设计原则、创新和解决的挑战传统的磁盘文件系统已经暴露出它们的局限性。为了满足不断增长的存储需求分布式文件系统作为动态且可扩展的解决方案应运而生。在本文中我们探讨了三种代表性分布式文件系统的设计原则、创新和解决的挑战Google 文件系统 (GFS)、Tectonic和JuiceFS。
GFS 开创了商品硬件的使用并影响了大数据领域的 Hadoop 分布式文件系统 (HDFS) 等系统。
Tectonic 引入了分层元数据和存储/计算分离提高了可扩展性和性能。
JuiceFS 专为云原生时代而设计使用对象存储和多功能元数据引擎在云中实现可扩展的文件存储。
通过探索这三个系统的架构您将获得设计分布式文件系统的宝贵见解。这种认识可以指导企业选择合适的文件系统。我们的目标是激励大数据、分布式系统设计和云原生技术领域的专业人士和研究人员了解优化数据存储、了解行业趋势并探索实际应用。
流行的分布式文件系统概述
下表显示了各种广泛使用的分布式文件系统包括开源的和专有的。
广泛使用的分布式文件系统 如表所示大量的分布式系统在2000年左右出现。在此之前共享存储、并行文件系统和分布式文件系统已经存在但它们往往依赖于专门且昂贵的硬件。
表中的“POSIX兼容”列表示分布式文件系统与可移植操作系统接口POSIX的兼容性POSIX是操作系统实现的一组标准包括文件系统相关的标准。兼容 POSIX 的文件系统必须满足标准中定义的所有功能而不仅仅是少数功能。
例如GFS 不是 POSIX 兼容的文件系统。Google 在设计 GFS 时做了一些权衡。它抛弃了很多磁盘文件系统的特性保留了当时谷歌搜索引擎所需的一些分布式存储需求。
在接下来的章节中我们将重点介绍 GFS、Tectonic 和 JuiceFS 的架构设计。让我们探讨每个系统的贡献以及它们如何改变我们处理数据的方式。
GFS架构
2003年Google发表了GFS论文。它证明了我们可以使用经济高效的商用计算机来构建功能强大、可扩展且可靠的完全基于软件的分布式存储系统而无需依赖专有或昂贵的硬件资源。
GFS 显着降低了分布式文件系统的进入门槛。它对许多后续系统都有不同程度的影响。HDFS是雅虎开发的开源分布式文件系统深受GFS论文中提出的设计原则和思想的影响。它已成为大数据领域最流行的存储系统之一。尽管 GFS 于 2003 年发布但其设计至今仍然具有相关性并被广泛使用。
GFS架构如下图所示 GFS 集群由以下部分组成 Master充当元数据节点。 为了维护文件系统的目录、权限和属性等元数据需要使用中央节点主节点。大师采用树状设计结构。 多个存储数据的块服务器。 chunkserver依赖本地操作系统的文件系统来存储数据。 多个客户
master和chunkserver之间的通信是通过网络进行的从而形成分布式文件系统。块服务器可以随着数据的增长而水平扩展。所有组件在 GFS 中互连。当客户端发起请求时首先从Master上获取文件元数据信息并与ChunkServer进行通信最终获取数据。GFS 将文件存储在固定大小的块中通常为 64 MB并具有多个副本以确保数据可靠性。因此读取同一个文件可能需要与不同的 chunkserver 进行通信。副本机制是分布式文件系统的经典设计当今许多开源分布式系统实现都受到GFS的影响。
虽然 GFS 本身具有开创性但它在可扩展性方面存在局限性。为了解决这些问题Google 开发了Colossus作为 GFS 的改进版本。Colossus 为各种 Google 产品提供存储并作为 Google Cloud 服务的底层存储平台使其公开可用。Colossus 具有增强的可扩展性和可用性旨在满足现代应用程序快速增长的数据需求。
构造结构
Tectonic 是 Meta以前的 Facebook使用的最大的分布式文件系统。这个项目最初被称为 Warm Storage于 2014 年开始但其完整架构直到 2021 年才公开发布。
在开发 Tectonic 之前Meta 主要使用 HDFS、Haystack 和 f4 进行数据存储 HDFS用于数据仓库场景受限于单个集群存储容量部署了几十个集群。 Haystack和f4用于非结构化数据存储场景。
Tectonic 旨在在单个集群中支持这三种存储场景。
下图展示了 Tectonic 架构 构造由三个部分组成 客户库 元数据存储 大块商店
构造层位设计
构造建筑设计的创新
创新一分层元数据
Tectonic 将分布式文件系统的元数据抽象为简单的键值KV模型。这样可以实现出色的水平扩展和负载平衡并有效防止数据访问中的热点。Tectonic 引入了元数据的分层方法使其有别于传统的分布式文件系统。Metadata Store分为三层对应底层KV存储中的数据结构 Name层存储与文件名或目录结构相关的元数据按目录ID进行分片。 文件层存储文件属性按文件ID进行分片。 块层存储有关数据块在块存储中的位置的元数据并按块 ID 进行分片。
下图总结了三层的键值映射
Tectonic 中的图层映射 这种分层设计解决了 Tectonic 的可扩展性和性能需求特别是在 Meta 需要处理 EB 级数据的场景中。
创新二元数据存储与计算分离
这三个元数据层是无状态的可以根据工作负载进行水平扩展。它们通过网络与键值存储元数据存储中的状态存储进行通信。
Key-Value Store 并非由 Tectonic 团队单独开发相反他们使用 ZippyDBMeta 中的分布式 KV 存储系统。ZippyDB 建立在 RocksDB 和 Paxos 共识算法之上。Tectonic 依靠 ZippyDB 的 KV 存储及其事务来确保文件系统元数据的一致性和原子性。
事务功能在实现大规模分布式文件系统中起着至关重要的作用。水平扩展元数据存储以满足此类系统的需求至关重要。然而水平扩展引入了数据分片的挑战。保持强一致性是文件系统设计中的关键要求尤其是在执行重命名具有多个子目录的目录等操作时。确保整个重命名过程的效率和一致性是分布式文件系统设计中一个重大且广泛认可的挑战。
为了应对这一挑战Tectonic 使用 ZippyDB 的事务功能。在处理单个分片内的元数据操作时Tectonic 保证了事务行为和强一致性。
但是ZippyDB 不支持跨分片事务。这限制了 Tectonic 在处理跨多个目录的元数据请求例如在目录之间移动文件时确保原子性的能力。
创新三块存储中的纠删码
如前所述GFS通过多副本保证数据的可靠性和安全性但这种方式的存储成本较高。例如仅存储 1 TB 数据通常需要三个副本从而产生至少 3 TB 的存储空间。对于像 Meta 这样以 EB 级别运行的大型系统这种成本会显着增加。
为了解决这个问题Meta 在 Chunk Store 中实现了纠删码EC通过减少冗余来实现数据的可靠性和安全性通常约为原始数据大小的 1.2 至 1.5 倍。与传统的三副本方法相比这种方法可以节省大量成本。Tectonic 的 EC 设计提供了灵活性允许按块进行配置。
虽然EC以最小的存储空间有效地保证了数据的可靠性但它也存在一些缺陷。具体来说重建丢失或损坏的数据会产生较高的计算和 I/O 资源要求。
根据 Tectonic研究论文Meta 中最大的 Tectonic 集群由大约 4,000 个存储节点组成总容量约为 1,590 PB相当于 100 亿个文件。这个规模对于分布式文件系统来说是相当大的通常可以满足目前大多数用例的要求。
JuiceFS 架构
JuiceFS诞生于2017年与GFS和Tectonic的出现相比外部格局发生了重大变化
硬件资源有了显着进步。相比之下当时谷歌数据中心的网络带宽仅为100Mbps。如今在 AWS 上机器网络带宽最高可达 100 Gbps提升了千倍。
云计算已成为主流企业通过公有云、私有云或混合云过渡到“云时代”。这种转变给基础设施架构带来了新的挑战。将针对 IDC 环境设计的传统基础设施迁移到云端常常会带来各种问题。最大限度地发挥云计算的优势成为将基础设施无缝集成到云环境中的关键要求。
此外GFS 和 Tectonic 是为特定公司运营服务的内部系统运营规模较大但关注范围较窄。相比之下JuiceFS 旨在满足广泛的面向公众的用户并满足不同的用例需求。因此JuiceFS 的架构与其他两种文件系统有很大不同。
考虑到这些变化和区别我们来看下图所示的 JuiceFS 架构 JuiceFS 由三个组件组成 元数据引擎 数据存储 客户端
虽然 JuiceFS 与上述系统共享相似的整体框架但它通过各种设计方面脱颖而出。
数据存储
与GFS和Tectonic依赖专有数据存储不同JuiceFS通过使用对象存储来顺应云原生时代的趋势。如前所述Meta 的 Tectonic 集群使用 4,000 多台服务器来处理 EB 级数据。这不可避免地会导致管理如此大规模的存储集群的巨大运营成本。
对于普通用户来说对象存储有几个优点 开箱即用的可用性 弹性容量 简化操作和维护 支持纠删码与复制相比存储成本更低。
然而对象存储也有局限性包括 对象不变性 元数据性能不佳 缺乏强一致性 随机读取性能有限
为了应对这些挑战JuiceFS在架构设计上采取了以下策略 独立的元数据引擎 由块、片和块组成的三层数据架构。 多级缓存
元数据引擎
JuiceFS 支持各种开源数据库作为元数据的底层存储。这与 Tectonic 类似但 JuiceFS 更进一步不仅支持分布式 KV 存储还支持 Redis、关系数据库和其他存储引擎。这种设计有以下优点 它允许用户为他们的特定用例选择最合适的解决方案这符合 JuiceFS 成为多功能文件系统的目标。 开源数据库通常在公共云中提供完全托管的服务从而使用户的运营成本几乎为零。
Tectonic 通过使用事务性 KV 存储 ZippyDB 实现了强大的元数据一致性。然而它的事务性仅限于单个分片内的元数据操作。相比之下JuiceFS 对事务性的要求更加严格要求跨分片的全局强一致性。因此所有集成为元数据引擎的受支持数据库都必须支持事务。借助TiKV等可水平扩展的元数据引擎JuiceFS 现在可以在单个文件系统中存储超过 200 亿个文件满足海量数据企业的存储需求。此功能使 JuiceFS 成为处理海量数据存储需求的企业的理想选择。
客户
JuiceFS客户端与其他两个系统的客户端主要区别如下 GFS 客户端采用非标准协议不支持 POSIX 标准。它只允许仅追加写入。这限制了其在特定场景中的可用性。 Tectonic 客户端也缺乏对 POSIX 的支持并且只允许仅附加写入但它采用了丰富的客户端设计在客户端整合了许多功能以实现最大的灵活性。 JuiceFS 客户端支持多种标准访问方式包括 POSIX、HDFS、S3、WebDAV、Kubernetes CSI。 JuiceFS客户端还提供缓存加速功能这对于云原生架构中的存储分离场景非常有价值。
结论
分布式文件系统已经改变了数据存储三个著名的系统在这个领域脱颖而出GFS、Tectonic 和 JuiceFS。 GFS 展示了经济高效的商用计算机在构建可靠的分布式存储系统方面的潜力。它为后续系统铺平了道路并在塑造该领域发挥了重要作用。 Tectonic 引入了创新的设计原则例如分层元数据以及存储和计算的分离。这些进步解决了可扩展性和性能挑战提供了元数据操作的效率、负载平衡和强一致性。 JuiceFS 专为云原生时代而设计使用对象存储和多功能元数据引擎来提供可扩展的文件存储解决方案。JuiceFS 支持各种开源数据库和标准访问方法可满足广泛的用例并与云环境无缝集成。
分布式文件系统克服了传统的磁盘限制为管理大数据量提供了灵活性、可靠性和效率。随着技术进步和数据呈指数级增长它们的持续发展反映了行业对高效数据管理的承诺。分布式文件系统凭借多样化的架构和创新功能推动了跨行业的创新。 作者Changjian Gao
更多技术干货请关注公号【云原生数据库】
squids.cn云数据库RDS迁移工具DBMotion云备份DBTwin等数据库生态工具。
irds.cn多数据库管理平台私有云。
