ImageVerifierCode 换一换
格式:DOCX , 页数:11 ,大小:1.20MB ,
资源ID:20533405      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/20533405.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(分布式存储系统地一些理解和实践Word文档下载推荐.docx)为本站会员(b****6)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

分布式存储系统地一些理解和实践Word文档下载推荐.docx

1、key/value或者半结构化数据高吞吐高性能高扩展2)不适用Sql查询复杂查询,如联表查询复杂事务二、分布式存储系统设计要点1.数据分布分布式存储,可以由成千甚至上万台机器组成,以实现海量数据存储和高并发。那它最先要解决的就是数据分布问题,即哪些数据存储在哪些机器节点上。常用的有hash类算法和用meta表映射两种方式。一般完全分布式的设计无master节点,会用hash类算法;而集中式的设计有master节点用meta表映射的方式。两者各有优缺点,后面讲到具体问题时再做比拟。1)一致性hash将存储节点和操作的keykey唯一标识存储的object,有时也叫object name都hash

2、到02的32次方区间。映射到如下环中的某个位置。沿操作key的位置顺时针找到的第一个节点即为此key的primary存储节点。如如下图所示:图1 一致性hashCassandra借鉴了dynamo的实现,用了一致性hash的方式。节点的hash值也叫token,可以手动分配或者自动生成。Key的hash值即md5(key)。每个表可以在建表时指定副本数,当副本数为3时,找primary存储节点后,顺时针方向的下2个存储节点即为replica存储节点。Hash类算法,优点是无需master节点,一个缺点是,不支持key的顺序扫描。2)Crush算法也是一种类hash算法,随着ceph诞生,也是c

3、eph的一大亮点。Crush算法比拟复杂,这里简化介绍下。Ceph的每个Object最终都会映射到一组OSD中,由这组OSD保存这个Object,映射流程如下:Object PG OSD setOSD先理解为机器节点吧PG即Placement Groups,可以理解为存储在同一组OSD上的object的集合Object先映射到PG(Placement Group),再由PG映射到OSD set。每个表空间有固定数量的pg,在建表时指定。每个Object通过计算hash值并对pg数量取模得到它所对应的PG。PG再映射到一组OSDOSD的个数由表的副本数决定,也是建表时指定,第一个OSD是Prim

4、ary,剩下的都是Replicas。PG OSD set 的映射由几个因素决定:CRUSH hash算法:一种伪随机算法。OSD MAP:包含当前所有OSD的状态、OSD的机器机架信息等。CRUSH Rules:数据映射的策略。这些策略可以灵活的设置object存放的区域。比如可以指定table1中所有objects放置在机架1上,所有objects的第1个副本放置在机架1上的服务器A上,第2个副本分布在机架1上的服务器B上。 table2中所有的object分布在机架2、3、4上,所有Object的第1个副本分布在机架2的服务器上,第2个副本分布在机架3的服器上,第3个副本分布在机架4的服务

5、器上。具体实现不再展开。图2 ceph crush算法伪代码如下所示:locator = object_nameobj_hash = hash(locator)pg = obj_hash % num_pgosds_for_pg = crush(pg) # returns a list of osdsprimary = osds_for_pg0replicas = osds_for_pg1:Crush相比一致性hash更加灵活。3)按range查表由master节点记录和管理每个表range的粒度,以与每个range的数据存储在哪些节点上。range是根据key的字节序确定。Client在执行k

6、ey存取操作是,先到master,根据其所在range,查询其存储在哪些节点;再直接跟存储节点交互,实现存取。Hbase是用这种方式实现,支持key的顺序扫描。如如下图所示,region即一段range的数据存储在mater server上,region sever即实际存储节点。图3 hbase region映射2.数据可靠性数据可靠性,即数据不丢失,是存储系统的第一职责。图4 数据中心分布式一般采用普通服务器,要假设服务器和硬盘都是不可靠的。如何保证在有硬件损坏时数据不丢失,是任何分布式存储系统都必须考虑的。已有做法有以下几种。1)多副本即数据保存N+1份一般是3份,每一份都存储在不同的节

7、点上。在数据损坏N份时,仍能修复数据。缺点是,需N倍的冗余存储空间。hbase、cassandra、ceph都很好的支持。2)纠删码即将一条数据切分成n等份,通过对这n份数据编码,得到m份相等大小的校验数据块儿。这n+m份数据,各自存储在不同的节点上,拿到n+m中的任意n份数据,均可计算得到原始的数据。一般n取10,m取3。优点是,只需m/n倍的冗余空间,缺点是读写效率较低,且消耗cpu。图5 纠删码Hbase:hdfs层为hbase提供支持。Cassandra:社区版本不支持,社区还无添加此功能的路线图,之前社区有讨论过此功能,后来不了了之。应该是主要考虑到纠删码方式对现有系统的存储结构、一

8、致性语义都有较大影响,且性能较低。Ceph:支持。但在功能上有些缺失,比如不支持partial read,适合读远多于写的场景,应用较少。3)跨级群自动备份一般为了更高的可靠性,数据会通过准实时备份机制,备份到另外一个IDC的存储集群。社区版本已经支持。cassandra和ceph:都不支持,短期没有路线图,长远来讲,是需要添加的。4)接入修复客户端写数据到存储集群,一般先按一定规如此找到一个接入节点,再由次接入节点做proxy将数据写到实际存储的节点。假设需要写入3副本,如果接入节点发现,有的副本对应的存储节点此时不可用,或者写超时,那么会将写失败的节点与未写成功的数据存储下来。之后,定时或

9、者收到通知不可用节点变为可用时,尝试写入之前未写成功的数据。hdfs层会保证写入足够的副本,因为hdfs的namenode记录了每个block的meta数据block存储在哪些datanode,一个datanode写失败,换一个写,直至写成功。可以看到,记录meta这种方式很灵活有hinthandoff机制,原理如上有pglog机制,原理如上5)全局扫描修复用以修复磁盘损坏、误删文件等原因引起的数据丢失。由master节点发起全局数据,或者primary节点发起自己负责的range的数据,的多个副本间的数据扫描。如果发现某个副本缺失,如此进展修复。Hbase、cassandra、ceph都有类

10、似机制,原理类似,机制不同,这里不一一展开讲了。hdfs层的data node在发现盘损坏后,会收集剩下的所有block信息,并通知name node比照修复基于Merkle tree的anti-entropy机制scrub和deep-scrub机制3.可用性分布式存储系统,相比传统关系数据库,有更好的可用性。在个别机器硬件或软件故障,甚至整个机房断电断网等极端情况下,仍不影响在线读写。对于个别机器硬件或者软件故障,一般数据保存多份副本或者纠删码方式就能解决。对于整个机房断电,只能是多副本的跨idc存储,一般分布式存储系统都支持这种方式,只是目前实际应用的很少。保证可用性,另外一个影响因素是,

11、整个系统是否有单点故障。完全分布式的设计是没有单点的。集中式的设计,有meta信息,需要meta server的角色,一般也会将meta server做成集群式,以防止单点问题。下面结合例子讲下。1)分布式or集中式meta server是集群方式,通过zk的选举算法选出一个主节点来提供服务,主节点挂掉后,会重新选一个。所以hbase的meta server也不算是单点的。但其region server是单点的,即一个region server挂掉,在master没有为其负责的region进展重分配前,这个region所负责的range,是无法提供在线读写的。之所以存在此单点问题,猜想因为hb

12、ase设计之初,是为网页库这类离线存储设计的,而非在线服务。另外,region server的这种设计能较方便是实现强一致性和简单事务,后面会提到。现在貌似已有region server的stand by机制,即一台region server挂掉,另一台准备就绪的能马上接替并提供服务。Hbase架构如下:图6 hbase架构是完全分布式的ceph虽有monitor server,但仍可理解为完全分布式的,这里不展开了,无单点问题。4.可扩展性存储系统的可扩展性,即扩容的难易程度。可扩展性是分布式系统相比传统关系数据库,最大的优势。各分布式存储系统都能很好的支持横向扩展。由于实现方式的不同,扩容

13、的难易程度还是有差异的。一般集中式的系统扩容更加容易,完全分布式的系统会更加麻烦些。1)扩容比拟容易,扩容的大致过程为:增加一些region server,由master server做一下balance,即重新确定region server与region的对应关系每个region负责一定X围的key,对应于hdfs上的一组文件,完全不需要拖数据。而hdfs本身扩容也较容易,因为有name node存在相当于master server,对写入hdfs的每个块儿都记录其存储节点,可以将新写入的文件写入到新扩容的server,这样不需要拖数据;如果要考虑写压力均衡即不把写压力集中在新参加的机器上,

14、仍然写所有机器,仍需要做数据迁移。Cassandra和ceph:因为key定位是通过hash类算法,所以拖数据不可防止。拖的数据量即新加的node所负责的数据量。一致性hash和crush算法不同,导致拖数据的源节点不一样,但总的来说某某小异。5.数据一致性一致性分强一致性和最终一致性,解释如下:强一致性:写完一条数据key1,马上读key1,能读到最新数据。最终一致性:写完一条数据key1,马上读key1,可能读到老数据,但一段时间后,能够读到新数据。最终一致性相比强一致性,有更高的性能。一致性跟primary和replica在读写时的地位相关,不同系统在实现上会有不同的取舍,下面具体说明。

15、1)单主、多主、主从region server是单点,可以理解问题单主方式,天然的强一致性。最终一致性,通过客户端一致性级别的设置也可实现强一致性。Cassandra多个副本节点的地位一样,可以理解为多主方式,并列提供读写,这种方式读写性能很高,除了牺牲了强一致性,还有造成写冲突问题,cassandra通过column级别的时间戳解决此问题,但不彻底,时间戳一样时就没有方法了。的多个副本间有主从关系,一主多从,客户端写主节点,主节点负责写从节点。客户端只能读主节点。以此实现强一致性。Ceph也支持配置为本地化就近,不一定是主节点读方式,这种方式也牺牲了强一致性。Ceph的块儿存储和分布式文件系

16、统功能,要求它必须支持强一致性。6.性能前面已经提到,不同的一致性会对性能有影响。另外,还有两点对对性能影响较大:1)完全分布式or集中式集中式架构需要有meta server。读操作先查meta server,再向data node查询真正的数据;写操作除更新data node也可能要更新meta server。完全分布式读写如此少了与meta server交互的过程。所以延时更低。且集中式,在数据量巨大或者压力很大时,meta server有可能成为性能瓶颈,目前有meta server分层、静态子树等解决方案。是集中式的,但客户端维护meta server的缓存,一般读写时无需网络查询m

17、eta server,所以从hbase这层看,集中式并不影响其性能。但hdfs层读写必须要name node参与,所以性能低些。Hbase+hdfs这种分层架构,有很多好处,但显然性能会逊一筹。是完全分布式的,客户端可以连接任一台node读写,这台接入node通过一致性hash定位真正负责此次读写的node,再进展读写。效率要比hbase高些。是完全分布式的,客户端通过monitor server得到节点信息,缓存在本地,再通过crush算法,直接定位到主节点实现读写。这个角度看,ceph的效果比cassandra更高些。2)单机存储引擎分布式存储一般采用LSMT引擎,将随机写转化为顺序写lo

18、g和memtable内存方式,能极大提高写性能。读操作,还是通过索引来提高性能。分布式存储的数据模型一般是schema-less的,即不需要预先定义每行包括哪些列以与每个列的类型,多行之间允许包括不同的列;一般只有主key索引;不需考虑数据完整性约束比如外键约束、列类型约束、NOT NULL约束等;所以较适合用LSMT引擎实现,关系数据库如此不太适合。Schema-less是分布式存储一般性能较高的原因之一。图7 LSMTHbase、cassandra、ceph都是wal的方式。顺序写完journal log后,写实际数据。写数据时,hbase和cassandra是写memtable源自big

19、table吧,更多的减少随机写硬盘。Ceph不是memtable的方式,直接写文件系统,并定时sync。Memtable的方式对小value更加友好,但需要引入的paction,paction带来了更多的运维工作。Ceph由于其块儿存储功能,经常会修改一个对象的某一小段,如果用memtable的方式,即使修改一小段,也要重写整个对象,效率比拟低。7.易运维性主要是扩容、顶替一台机器损坏,用另外一台机器代替之,可能涉与到迁移数据、升级、盘故障数据修复等操作的快速性和简单性。存储机器一般是12*2T盘,现在极端一些有24*4T盘。单机存储数据量是很大的。扩容或者顶替一台机器,一般也要几个小时甚至1

20、天的时间。在这段时间内存储系统是处于副本缺失状态的,万一这段时间好的副本又出问题,后果可能很严重;所以,要尽量防止数据迁移或者缩短迁移时间。1)扩容、顶替、升级不考虑hdfs的话,其扩容、顶替更容易,因为不涉与迁移数据。Hbase因单点问题,升级必然影响在线服务,这一点是一直在努力优化的,例如之前提到的region server standby机制,hdfs的name node的热备机制。由于其gossip广播的限制,较难做的很大,所以360有多达几十个cassandra集群,给运维带来不少工作量。扩容和顶替因涉与到迁移数据,比拟麻烦,一般会绕过它,刚开始集群建设一步到位,后续不扩容,如果有机

21、器损坏,直接修,而不是顶替。Cassandra的升级比拟有优势,3副本的情况下,可以最多一次升级1/3的机器,而不影响在线读写。还没搞过大集群,crush机制理论上可以将集群建的比拟大也许几千台,但扩容、顶替拖数据不可防止。因为不能确定数据的几个副本在那几个节点上,或者说不能确定几台机器上是否有同一批数据的副本,所以,升级为了不影响在线服务,最好一台台升级。2)磁盘故障盘故障引起的数据修复,衡量其好坏的标准,就是是否够快、是否足够自动化。磁盘写性能是修复速度的瓶颈。全局修复机制都能够做到自动化。所以,三种系统在这一点上差异不大。8.复杂查询与事务分布式存储系统相对于关系数据库之所以能做到高性能、高扩展,主要的原因之一就是选择不支持复杂的联表查询与事务操作。联表查询,分布式存储系统一般都不支持,而是通过冗余存储的方式实现类似的功能需求。复杂的事务,也不支持。但简单的事务,如单行事务、CASpareand-set还是可以支持的。1)事务支持单行事务可以是多个操作,由于region sever单点,可以在单机上较容易的实现。这是region server单点的一个优势。支持单次操作行级锁;单个column的cas操作依赖paxos多机协商,较为复杂,效率低。Ceph如此没有此类需求,自然不支持。以上有些是实践总结,有些如此加了自己的理解,有不对之处,还请指出,多谢。

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1