主流分布式存储技术平台分析.docx

上传人:lao****ou 文档编号:411338 上传时间:2023-10-27 格式:DOCX 页数:9 大小:23.34KB
下载 相关 举报
主流分布式存储技术平台分析.docx_第1页
第1页 / 共9页
主流分布式存储技术平台分析.docx_第2页
第2页 / 共9页
主流分布式存储技术平台分析.docx_第3页
第3页 / 共9页
主流分布式存储技术平台分析.docx_第4页
第4页 / 共9页
主流分布式存储技术平台分析.docx_第5页
第5页 / 共9页
亲,该文档总共9页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《主流分布式存储技术平台分析.docx》由会员分享,可在线阅读,更多相关《主流分布式存储技术平台分析.docx(9页珍藏版)》请在第一文库网上搜索。

1、主流分布式存储技术平台分析应公【摘要】本文对分布式存储技术架构体系进行综述分析,区分了不同技术体系应用场景,对不同体系的分布式存储技术典型产品特性进行分析,明确不同技术产品的数据模型、数据访问、数据性能、数据量级等不同层面的优劣势。希望大家能够通过这些典型特性的了解以及对具体业务场景的数据需求挖掘,能将比较优秀的数据存储技术匹配到最合适的业务场景中。1 .为什么会引入分布式存储技术从70年代到2000年左右,数据存储基本上是伴随着IBME.F.Code提出的关系模型理论,以关系型数据库(Orac1e、DB2.MySQD为数据管理平台,以集中式存储产品为数据最终载体形成的坚实的数据存储架构体系。

2、2000年后,但是随着数据量的增加,单机的数据库瓶颈已经不能满足大数据量的需求,从数据管理层面开始诞生分库分表的方案。自2006年谷歌发了三篇论文(GFS、BigTab1e.Map-Reduce)之后,在数据管理层面以及数据载体层面不断涌现各类分布式产品,例如GFS、GPFS.HFS.DFS等各类分布式文件系统,例如HadoOp、HbaSe、Redis、MongoDB、RoCkDB等系列分布式数据管理平台。总而言之,数据量的爆发式增长催生了数据应用领域的各种新需求,数据应用领域的各种新需求驱动了数据管理层面以及数据载体层面的分布式变革。2 .主流分布式文件系统技术分析主流分布式文件系统技术主要

3、有GPFS、GFS、HDFS、DFS、CIUSterFS等很多,下面我们以同类或类似技术体系的典型产品为代表进行阐述。2.1 GFSGFS是基于文件系统实现的分布式存储系统,是属于有中心的分布式架构;通过对中心节点元数据的索引查询得到数据地址空间,然后再去数据节点上查询数据本身的机制来完成数据的读写;是基于文件数据存储场景设计的架构。接下来,我们来看GFS有哪些具体特性,选型的时候应该如何考虑?(1) GFS是一种适合大文件,尤其是GB级别的大文件存储场景的分布式存储系统。(2) GFS非常适合对数据访问延迟不敏感的搜索引擎服务。(3) GFS是一种有中心节点的分布式架构,MaSter节点是单

4、一的集中管理节点,即是高可用的瓶颈,也是可能出现性能问题的瓶颈。(4) GFS可以通过缓存一份部分Metadata到CIient节点,减少C1ient与Master的交互。(5) GFS的MaSter节点上的OPerationIog和CheCkPc)int文件需要通过复制方式保留多个副本,来保障元数据以及中心管理功能的高可用性。2. 2HDFSHDFS的架构原理与GFS基本类似,但是是基于GFS做了一些改进之后形成的一套技术体系。同样,它基于文件系统实现的分布式存储系统,是属于有中心的分布式架构;通过对中心节点元数据的索引查询得到数据地址空间,然后再去数据节点上查询数据本身的机制来完成数据的读

5、写;是基于文件数据存储场景设计的架构。接下来,我们来看HDFS有哪些具体特性,选型的时候应该如何考虑?(1) IIDFS的默认最小存储单元为128M,比GFS的64M更大。(2) HDFS不支持文件并发写,对于单个文件它仅允许有一个写或者追加请求。(3) HDFS从2.0版本之后支持两个管理节点(NameNode),主备切换可以做到分钟级别。(4) HDFS更适合单次写多次读的大文件流式读取的场景。(5) HDFS不支持对已写文件的更新操作,仅支持对它的追加操作。2. 3G1usterFSG1usterFS虽然是基于文件系统的分布式存储技术,但是它与GFS架构有本质的区别,它是去中心化的无中心

6、分布式架构;它是通过对文件全目录的DHT算法计算得到相应的Brike地址,从而实现对数据的读写,这与GFS以及HDFS等通过元数据检索实现数据寻址的方式有极大的不同。接下来,我们来看GIUSterFS都有哪些具体特性,选型的时候应该如何考虑?*(1) G1USterFS是采用无中心对称式架构,没有专用的元数据服务器,也就不存在元数据服务器瓶颈。元数据存在于文件的属性和扩展属性中。(2) G1USterFS可以提供Raid0、RaidhRaid1+0等多种类型存储卷类型。(3) G1USterFS采用数据最终一致性算法,只要有一个副本写完就可以Commito(4) GIUSterFS默认会将文件

7、切分为128KB的切片,然后分布于卷对应的所有Brike当中。所以从其设计初衷来看,更适合大文件并发的场景。(5) G1usterFS采用的DHT算法不具备良好的稳定性,一旦存储节点发生增减变化,势必影响卷下面所有Brike的数据进行再平衡操作,开销比较大。(6) G1usterFS文件目录利用扩展属性记录子卷的中brick的hash分布范围,每个brick的范围均不重叠。遍历目录时,需要获取每个文件的属性和扩展属性进行聚合,当目录文件较多时,遍历效率很差。3.主流分布式对象存储技术分析目前应用比较广发的分布式对象存储技术基本都是基于Swift或者Ceph体系衍生出来的产品。3.1 CephC

8、eph首先是一种对象存储技术,也就是说它存储数据的机制与我们之前接触的文件系统机制是完全不一样的,它是将数据抽象为对象和对象标识来进行管理。从架构上来讲,CePh相对类似于G1USterFS的无中心化架构;它是通过对对象的哈希算法得到相应的BUCket&Node地址,从而实现对数据的读写。接下来,我们来看CePh都有哪些具体特性,选型的时候应该如何考虑?(1) CePh是一种统一了三种接口的统一存储平台,上层应用支持ObjeCt、B1ock.Fi1eo(2) CePh采用CrUSh算法完成数据分布计算,通过Tree的逻辑对象数据结构自然实现故障隔离副本位置计算,通过将BUCket内节点的组织结

9、构,集群结构变化导致的数据迁移量最小。(3) CePh保持数据强一致性算法,数据的所有副本都写入并返回才算写事务的完成,写的效率会差一些,所以更适合写少读多的场景。(4) CePh对象保存的最小单元为4M,相比GFS&HDFS而言,适合一些小的非结构化数据存储。3. 2SwiftSWifty也是是一种对象存储技术,它与CePh的架构有类似的地方,也是无中心化架构;它是通过对对象的哈希算法得到相应的BucketfcNode地址,从而实现对数据的读写。但是SWift是需要通过PrOXy节点完成与数据节点的交互,虽然PrOXy节点可以负载均衡,但是毕竟经历了中间层,在并发量较大而且小文件操作量比较的

10、场景下,Ceph的性能表现会优秀一些。接下来,我们来看SWift都有哪些具体特性,选型的时候应该如何考虑?(1) SWift只保障数据的最终一致性,写完2个副本后即可COnImit,这就导致读操作需要进行副本的对比校验,读的效率相对较低。(2) SWift采用一致性哈希算法完成数据分布计算,通过首次计算对象针对逻辑对象(Zone)的映射实现数据副本的故障隔离分布,然后通过哈希一致性算法完成对象在Bucket当中的分布计算,采用Ring环结构组织Bucket节点组织,数据分布不如CePh均匀。(3) Swift需要借助PrOXy节点完成对数据的访问,不同通过客户端直接访问数据节点,相对数据的访问

11、效率来讲,比CePh要差一些(可以参照ICC1AB&SP1AB的性能测试报告)。(4) 流分布式数据库技术分析目前在分布式数据库技术的应用场景下,各行各业采用的产品比较多,尤其是NOSQ1&NewSQ1领域。记下来我们以文档、健值、内存、列式等几个典型分类来进行阐述。4.1 MongoDBMongoDB是以二进制JSON或叫BSON格式存储文档数据为数据模型,专门为文档存储设计。当查询MOngoDB并返回结果时,这些数据就会转换为易于阅读的数据格式。它的所谓分布式主要是指它的切片集群机制。通过基于范围的分区机制来实现水平扩展,称为分片机制,它可以自动化管理每个分布式节点存储的数据。接下来,我们

12、来看MOngoDB都有哪些具体特性,选型的时候应该如何考虑。(I)Monge)DB面向集合存储,模式自由,易存储对象类型的数据,文件存储格式为JSON,从这个角度来讲,我们需要从数据业务场景角度去剖析其与MongoDB数据模型的契合性。(2) MongODB使用高效的二进制数据存储,包括大型对象,因此比较适合媒体、视频之类的大对象的存取场景。(3) MOngoDB支持支持动态查询,支持完全索引,支持RUBY,PYTHON,JAVA,C,PHP,C#等多种语言,因此它与前端应用匹配的灵活性很强,适用于很多场景。(4) MOngODB水平扩展能力较强,可以通过分布式集群架构将数据分布到多台机器,并

13、且有完善的支持复制和故障恢复机制,支持海量数据的处理场景。4.2RedisRedis是一个开源的使用ANSIC语言编写、遵守BSD协议、支持网络、可基于内存、分布式、可选持久性的键值对(KeyTaIUe)存储数据库,并提供多种语言的API。Redis通常被称为数据结构服务器,因为值(va1ue)可以是字符串(StriIig)、哈希(HaSh)、列表(IiSt)、集合(SetS)和有序集合(SOrtedsets)等类型。接下来,我们来看RediS都有哪些具体特性,选型的时候应该如何考虑?(1) RediS所有数据是存放在内存中的,源代码采用C语言编写,距离底层操作系统更近,并且使用单线程架构,避

14、免了多线程可能产生的竞争开销。以上决定了它是执行速度非常快的数据库。(2) RediS不仅仅支持简单的key-va1ue类型的数据,同时还提供1ist,set,zset,hash等数据结构的存储。结合这个相对比较灵活的数据模型,ReCIiS通常被用来作为高速缓存使用。(3) RediS提供两种持久化方案AOF和RDB,因此它不仅仅适合高速缓存场景,而且适合基于此需求的衍生性业务场景。(4) RediS从3.0版本后开始支持集群模式,很好的实现了处理能力的水平扩展,结合它的速度快的特性,这就为互联网电子商务的高并发场景提供了解决方案。4.3HbaseHbase是Goog1eBigtab1e的开源

15、实现,与Bigtab1e利用GFS作为其文件存储系统类似,HBase利用HadoopHDFS作为其文件存储系统;运行MapReduce来处理Bigtab1e中的海量数据。因此从源头来看,HbaSe是为大数据处理提供的数据存取解决方案,可称为列式数据库。接下来,我们来看HbaSe都有哪些具体特性,选型的时候应该如何考虑。(1) Hbase与很多面向行存储的关系型数据库不同,HBase是面向列的存储和权限控制的,它里面的每个列是单独存储的,且支持基于列的独立检索。因此它天然适合分析类应用(O1AP)o(2) HBase中的数据都是以字符串形式存储的,为空的列并不占用存储空间,因此HBase的列存储

16、解决了数据稀疏性的问题,通常可以设计成稀疏矩阵,在很大程度上节省了存储开销。(3) HBase的单表容量非常大,可以有百亿行、百万列,可以在横向和纵向两个维度插入数据,具有很强的弹性。IIBase采用1SM树作为内部数据存储结构,这种结构会周期性地将较小文件合并成大文件,以减少对磁盘的访问。这些特性尤其适合单表数据量巨大的数据存取场景。5.总结与展望通过对分布式存储技术架构体系的综述分析,我们首先区分了不同技术体系究竟是应该用在数据管理场景还是数据载体场景。随后我们通过对不同体系的分布式存储技术典型产品特性的分析,明确了不同技术产品的数据模型、数据访问、数据性能、数据量级等不同层面的优劣势,最终希望通过这些典型特性的了解以及对具体业务场景的数据需求挖掘,能将比较优秀的数据存储技术匹配

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 应用文档 > 汇报材料

copyright@ 2008-2022 001doc.com网站版权所有   

经营许可证编号:宁ICP备2022001085号

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有,必要时第一文库网拥有上传用户文档的转载和下载权。第一文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知第一文库网,我们立即给予删除!



客服