TFS与其他分布式存储系统的对比分析

本文对比分析了TFS、GFS、BT、Dynamo和Cassandra这五种分布式存储系统。TFS起初为淘宝的小文件存储设计,支持大文件存储和自定义文件名。GFS和TFS采用星型架构,侧重大文件存储,GFS使用ChunkServer和Master节点。BT是星型NOSQL系统,适用于PB级别数据。Dynamo和Cassandra则采用P2P架构,强调水平扩展和数据一致性。文中探讨了数据一致性、负载均衡、复制和容错策略,以及系统设计需求和技术实现细节。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

TFS与其他分布式存储系统的对比分析

 

1 概述

TFS(Taobao File System),作为目前淘宝内部使用并开源的分布式文件系统,为淘宝提供海量小文件存储以及其他一些功能,被广泛地应用在淘宝各项应用中。其他分布式存储系统,这里主要指的是最近我通过读论文以及网络上的技术文档和分享所了解到的一些大公司所采用的存储系统,其中包括Google的GFS,BigTable(BT),Amazon的Dynamo以及Facebook的Cassandra。当然,市场上还存在着其他分布式存储系统以及相应的产品。而前面提到的这些产品,正是这些分布式存储系统的优秀代表。

在这五个分布式存储系统中,从数据是否结构化的角度划分,TFS、GFS和Dynamo均属于非结构化的存储系统,而剩下的BT和Cassandra则是典型的结构化Key-Value存储系统。由于它们和传统的关系数据库存储系统的差别,我们一般称之为NOSQL存储系统。另一方面,从系统的整体架构上来划分,TFS和GFS以及BT均属于星型(因为类似于网络中的星型拓扑设计)的架构设计,也就是采用中心服务节点控制数据服务节点的方式来对客户提供服务的。而剩下的Dynamo和Cassandra则是属于去中心化的P2P架构设计。正是由于它们在整体架构设计上的区别,很多分布式系统中所涉及的技术在实现上也存在着比较大的差异。

下面,我将从设计需求,具体架构,技术实现细节等这几方面对上述这些存储系统进行对比阐述。由于本人在分布式系统以及存储系统上刚刚起步,认识尚浅,水平有限,如有错误和认识不足的地方,请大家悉心指教,不胜感激。

2 设计需求

我们都知道,需求分析在软件工程中所处的地位是举足轻重的,如果需求没有分析到位,在软件的实施过程中往往会出现返工的现象,那样就会给软件的实施方造成巨大的损失,甚至是无法弥补的。对于分布式存储系统来说,我认为真正的需求包括两个方面,一个是功能上的需求,另一个则是性能上的需求。不管是功能上的需求还是性能上的需求,都有可能对系统的整个实施产生影响。

2.1 功能需求分析

从功能需求这一方面来看,TFS最初是为了满足淘宝内部对于小文件的存储需要而设计的。后面又加入了对大文件存储的支持,再到后来,又加入了对于各种特定应用的自定义文件名的支持,在读写方面,需要满足大规模的随机读写。这些功能上的需求,TFS在设计的最初应该是有所考虑的。至于其他几个存储系统,据我所知,GFS最初的设计是为了支持大文件的存储,并且在读方面需要满足大规模的流式读和小规模的随机读,在写方面需要满足大规模的追加写和小规模的随机写,BT则需要在Google的各项应用中均能灵活表现,Dynamo是为了支持Amazon的购物车而设计的,并且要求时刻不能停写服务,而Cassandra最初是为了解决收件箱搜索的存储需要而设计的。

2.2 性能需求分析

再从性能需求这一方面看,这几个分布式存储系统的一个最主要的共同点就是可扩展性(即伸缩性)比较好,这也是目前几乎所有的分布式存储系统所支持的特性。另一方面,可用性也是大部分分布式存储系统所支持的特性。如果一个分布式系统在读写性能上和单机的相差不大,那么这个分布式系统的设计无疑是失败的,或者说设计是有问题的。同时,很多分布式存储系统都是布置在普通的机器上的,某一台机器的不可用对于整个系统来说是很正常的事情,于是保证系统的可靠性也是几乎所有分布式存储系统所要考虑的问题。在可靠性的设计中,会涉及到包括复本(replication),负载均衡,数据一致性等很多复杂的问题,这些会在第四部分进行详细的分析。

另外,在分布式系统中存在一个有名的理论,即CAP理论。代表含义如下:

Consistency(一致性):任何一个读操作总是能读到之前完成的写操作结果。

Availability(可用性):每一个操作总是能够在确定的时间内返回。

Tolerance of network Partition(分区容忍性):在出现网络分区的情况下,仍然能够满足一致性和可用性。

并且这个理论认为,CAP三者无法同时满足。事实上,对于分布式系统来说,CAP理论其实是在给我们设计的时候提供了一个思路,那就是既然鱼与熊掌不可兼得,想要C和A,往往就需要牺牲P,那么如何在这三者之间做一个平衡考虑呢?针对不同的应用需求和功能需求,就需要设计不同的系统。

对于星型的系统,我们可以将CAP理论的定义做出适当的调整如下[1]

一致性:读操作总是能读取到之前完成的写操作结果,且不需要依赖于操作合并;

可用性:读写操作总是能够在很短的时间内返回,即使某台机器发生了故障,也能够通过其它副本正常执行,而不需要等到机器重启或者机器上的服务分配给其它机器以后才能成功;

分区可容忍性:能够处理机器宕机,机房停电或者出现机房之间网络故障等异常情况;

而对于P2P类型的系统,在一致性方面需要依赖于操作的合并,但它们在P方面是做的比较好的。因此,我们认为大部分星型的系统选择的是CA,而P2P的系统选择了AP。但并不是所有的系统都这么做的,关键还在于平衡把握这三者对应用的影响。

3 具体架构

无疑,在系统的架构和很多细节的设计上,TFS参考了GFS的设计思路。所以在描述TFS的具体架构之前,我们可以先来看看GFS的具体架构。

3.1  GFS架构

一个GFS集群[2]包括一个Master节点(这里一般是两台物理机器,外面来看仅仅是一个逻辑节点)和多个ChunkServer节点以及多个客户端访问。存储在GFS中的文件都被分割成固定大小(GFS中是64MB)的Chunk,并且给每一个Chunk分配一个不变的,全球唯一的64位的Chunk 标识。ChunkServer节点以Linux文件的形式将Chunk保存在本地磁盘中。所有的机器均是普通的Linux机器并运行着用户级别(user-level)的进程。下面我将从Master节点,ChunkServer节点,客户端以及缓存这四个方面描述下GFS的设计架构。

Master节点的主要功能是管理文件系统的所有元数据(为了找到真实数据所需要的数据,类似于Linux文件系统中的inode),并且这些元数据均是放在内存中进行管理的。这里的元数据包括Chunk和文件的名字空间,访问控制信息(是否可读写等权限),

TFS(Taobao FileSystem)是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统,其设计目标是支持海量的非结构化数据。 目前,国内自主研发的文件系统可谓凤毛麟角。淘宝在这一领域做了有效的探索和实践,Taobao File System(TFS)作为淘宝内部使用的分布式文件系统,针对海量小文件的随机读写访问性能做了特殊优化,承载着淘宝主站所有图片、商品描述等数据存储。 文章首先概括了TFS的特点:最近,淘宝核心系统团队工程师楚材(李震)在其官方博客上撰文(《TFS简介》,以下简称文章)简要介绍了TFS系统的基本情况,引起了社区的关注。 完全扁平化的数据组织结构,抛弃了传统文件系统的目录结构。 在块设备基础上建立自有的文件系统,减少EXT3等文件系统数据碎片带来的性能损耗。 单进程管理单块磁盘的方式,摒除RAID5机制。 带有HA机制的中央控制节点,在安全稳定和性能复杂度之间取得平衡。 尽量缩减元数据大小,将元数据全部加载入内存,提升访问速度。 跨机架和IDC的负载均衡和冗余安全策略。 完全平滑扩容。 当前,TFS淘宝的应用规模达到“数百台PCServer,PB级数据量,百亿数据级别”,对于其性能参数,楚材透漏: TFS淘宝的部署环境中前端有两层缓冲,到达TFS系统的请求非常离散,所以TFS内部是没有任何数据的内存缓冲的,包括传统文件系统的内存缓冲也不存在......基本上我们可以达到单块磁盘随机IOPS(即I/O per second)理论最大值的60%左右,整机的输出随盘数增加而线性增加。 TFS的逻辑架构图1如下所示: 图1. TFS逻辑架构图(来源:淘宝核心系统团队博客) 楚材结合架构图做了进一步说明: TFS尚未对最终用户提供传统文件系统API,需要通过TFSClient进行接口访问,现有JAVA、JNI、C、PHP的客户端 TFS的NameServer作为中心控制节点,监控所有数据节点的运行状况,负责读写调度的负载均衡,同时管理一级元数据用来帮助客户端定位需要访问的数据节点 TFS的DataServer作为数据节点,负责数据实际发生的负载均衡和数据冗余,同时管理二级元数据帮助客户端获取真实的业务数据。 标签:分布式  阿里巴巴
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值