NoSQL生态系统——hash分片和范围分片两种分片

13.4 横向扩展带来性能提升

很多NoSQL系统都是基于键值模型的,因此其查询条件也基本上是基于键值的查询,基本不会有对整个数据进行查询的时候。由于基本上所有的查询操作都是基本键值形式的,因此分片通常也基于数据的键来做:键的一些属性会决定这个键值对存储在哪台机器上。下面我们将会对hash分片和范围分片两种分片方式进行描述。

3.4.2 通过协调器进行数据分片

由于CouchDB专注于单机性能,没有提供类似的横向扩展方案,于是出现了两个项目:Lounge 和 BigCouch,他们通过提供一个proxy层来对CouchDB中的数据进行分片。在这种架构中,proxy作为CouchDB集群的前端机器,接受和分配请求到后端的多台CouchDB上。后端的CouchDB 之间并没有交互。协调器会将按操作的key值将请求分配到下层的具体某台机器。 Twitter 自己实现了一个叫Gizzard的协调器,可以实现数据分片和备份功能。Gizzard不关心数据类型,它使用树结构来存储数据范围标识,你可以用它来对SQL或者NoSQL系统进行封装。

13.4.3 一致性hash环算法

好的hash算法可以使数据保持比较均匀的分布。这使得我们可以按这种分布将数据保存布多台机器上。一致性hash是一种被广泛应用的技术,其最早在一个叫distributed hash tables (DHTs)的系统中进行使用。那些类Dynamo的应用,比如Cassandra、Voldemort和Riak,基本上都使用了一致性hash算法。

备份数据

一致性hash下的数据备份通常采用下面的方法:将数据冗余的存在其归属的节点的顺序往下的节点,例如你的冗余系数为3(即数据会在不同节点中保存三份),那么如果通过hash计算你的数据在A区间[7,233],你的数据会被同时保存在A,B,C三个节点上。这样如果A节点出现故障,那么B,C节点就能处理这部分数据的请求了。而某些设计会使E节点将自己的范围扩大到A233,以接受对出故障的A节点的请求。

优化的数据分配策略

 为了解决由于节点比较少导致数据分配不均的问题,很多DHT系统都实现了一种叫做虚拟节点的技术。例如4个虚拟节点的系统中,A节点可能被虚拟化成A_1,A_2,A_3,A_4这四个虚拟节点,然后对这四个虚拟节点再进行hash运算,A节点负责的key值区间就比较分散了。

13.4.4 连续范围分区

使用连续范围分区的方法进行数据分片,需要我们保存一份映射关系表,标明哪一段key值对应存在哪台机器上。和一致性hash类似,连续范围分区会把key值按连续的范围分段,每段数据会被指定保存在某个节点上,然后会被冗余备份到其它的节点。和一致性hash不同的是,连续范围分区使得key值上相邻的两个数据在存储上也基本上是在同一个数据段。这样数据路由表只需记录某段数据的开始和结束点[start,end]就可以了。 通过动态调整数据段到机器结点的映射关系,可以更精确的平衡各节点机器负载。如果某个区段的数据负载比较大,那么负载控制器就可以通过缩短其所在节点负责的数据段,或者直接减少其负责的数据分片数目。通过添加这样一个监控和路由模块,使我们能够更好的对数据节点进行负载均衡。

BigTable的处理方式

Google BigTable 论文中描述了一种范围分区方式,它将数据切分成一个个的tablet数据块。每个tablet保存一定数量的键值对。然后每个Tablet 服务器会存储多个tablet块,具体每个Tablet服务器保存的tablet数据块数,则是由服务器压力来决定的。 每个tablet大概100-200MB大。如果tablet的尺寸变小,那么两个tablet可能会合并成一个tablet,同样的如果一个tablet过大,它也会被分裂成两个tablet,以保持每个tablet的大小在一定范围内。在整个系统中有一个master机器,会根据tablet的大小、负载情况以及机器的负载能力等因素动态地调整tablet在各个机器上的分布。

master服务器会把 tablet 的归属关系存在元数据表里。当数据量非常大时,这个元数据表实际也会变得非常大,所以归属关系表实际上也是被切分成一个个的tablet保存在tablet服务器中的。查询数据的时候就需要二次查询。

故障处理

在BigTable中,master机器是一个故障单点,不过系统可以容忍短时间的master故障。另一方面,如果tablet 服务器故障,那么master可以把对其上tablet的所有请求分配到其它机器节点。 为了监测和处理节点故障,BigTable实现了一个叫Chubby的模块,Chubby是一个分布式的锁系统,用于管理集群成员及检测各成员是否存活。ZooKeeper是Chubby的一个开源实现,有很多基于 Hadoop 的项目都使用它来进行二级master和tablet节点的调度。

基于范围分区的NoSQL项目

HBase 借鉴了BigTable的分层理论来实现范围分区策略。tablet相关的数据存在HDFS里。HDFS 会处理数据的冗余备份,并负责保证各备份的一致性。而像处理数据请求,修改存储结构或者执行tablet的分裂和合并这种事,是具体的tablet服务器来负责的。 MongoDB也用了类似于BigTable的方案来实现范围分区。他用几台配置机器组成集群来管理数据在节点上的分布。这几台机器保存着一样的配置信息,他们采用 two-phase commit 协议来保证数据的一致性。这些配置节点实际上同时扮演了BigTable中的master的路由角色,及Chubby 的高可用性调度器的角色。而MongoDB具体的数据存储节点是通过其Replica Sets方案来实现数据冗余备份的。 Cassandra 提供了一个有序的分区表,使你可以快速对数据进行范围查询。Cassandra也使用了一致性hash算法进行数据分配,但是不同的是,它不是直接按单条数据进行hash,而是对一段范围内的数据进行hash,也就是说20号数据和21号数据基本上会被分配在同一台机器节点上。 Twitter的Gizzard框架也是通过使用范围分区来管理数据在多个节点间的备份与分配。

13.4.5 选择哪种分区策略

如果你需要经常做范围查询,需要按顺序对key值进行操作,那么你选择范围分区会比较好。那如果我不会进行范围查询或者顺序查询呢?这时候hash分区相对来说可能更方便一点,而且hash分区时可能通过虚拟结点的设置来解决hash不均的问题。在hash分区中,基本上只要在客户端执行相应的hash函数就能知道对应的数据存在哪个节点上了。而如果考虑到节点故障后的数据转移情况,可能获取到数据存放节点就会麻烦一些了。 范围分区要求在查询数据前对配置节点还要进行一次查询,如果没有特别好的高可用容灾方案,配置节点将会是一个危险的故障单点。当然,你可以把配置节点再进行一层负载均衡来减轻负载。而范围分区时如果某个节点故障了,它上面的数据可以被分配到多个节点上,而不像在一致性hash时,只能迁移到其顺序的后一个节点,造成下一个节点的负载飙升。

 

未完待续!

posted @ 2017-01-06 15:35  bonelee  阅读(2633)  评论(0编辑  收藏  举报