数据的复制是冗余的过程,冗余会增加可用性,并且可以有效均衡读取负载。而数据的分区是一个整体转换为局部的过程,这种拆解就像你拥有大量图书,但你的书架放不下,所以需要再加几个书架存储是一个道理。
将整体拆分,局部存储在多个较小空间内。这种思想映射到计算机上也是一样的,当数据量过大,单个存储节点不足与存储这些数据(更大容量的磁盘没有或者太贵)时,人们想要继续存储就需要将数据集拆解并规整。这就是数据分区的意义,它是用来提高数据系统的可扩展性而引入的技术方法。
如何分区?
分区的关键在于采用一种统一的规则,这种规则可以计算出将数据放在哪个节点,并且在读取时也能计算出去哪个节点读取数据。
要做到这几点目前有三种分区方式:
- 按key的范围进行分区 当要存储数据时,我们取数据中的某一个字段作为分区key,按这个字段的范围进行分区例如自增的id值,0-10000存储在A节点上,10001-20000存储在B节点上,那么基于这样的规则我们可以高效的存取分区中的数据,并且自然的支持按区间查找(key的存储是有序的),只要区间的范围仅在一个分区时,那么区间查找就只会访问一个分区,除非查找范围跨越多个分区。但是问题在于当数据的写入在某段时间内存在热点时,例如0-100000的key被大量的写入,而10001-20000的key很少的时候,就会造成 数据倾斜 (数据分区大小不均衡)
- 按key的散列进行分区 对于数据倾斜,很自然的方式想到一个高效的散列函数来将数据存放在不同的分区,只要散列函数一致,相同的key一定会被映射到同一个分区。所以也是能够解决分区的关键问题,但是由于散列的问题,自然的进行区间范围查找会非常的困难,有些数据库会将区间查找的请求发送给所有分区,并行处理后,再全部聚合返回结果,但无疑会频繁的产生大量的请求,虽然可以有效的解决数据倾斜问题,但是这种热点数据是没有办法完全避免的,比如一个大V用户总有非常多的粉丝,每天要产生非常多的数据,通过key散列这些数据还是会存储在相同的分区内,造成数据倾斜的同时,还会导致热点数据的频繁访问,读与写负载都会分布不均匀。
- range+hash 模式 上述两种分区的优缺点恰好是互补的,那么可以考虑将二者结合例如用数据记录的两个关键字段作为key,比如是id与时间戳,先用id 散列存储在不同的分区上,然后在使用时间戳按范围进行分区,这样做在一定程度上弥补了二者的优缺点。 但依旧没有完全解决热点数据问题,这时热点数据问题可以考虑其他方面来解决,比如建立热点数据的缓存架构。
分区方法看似完美的对数据的存储进行了扩展,但也引入了另外的复杂度,那就是在查询数据的时候,如果数据恰巧不在同一个分区内,就需要访问多次不同的分区这样就会加大请求的延迟,或者当我们需要对关系模型中的数据进行join操作时,由于数据在不同的分区中的不同表内,进行join的难度就会非常大,增加了多表查询的复杂程度,一种折中的解决方案是,从业务上来看,将会被join或者同时读取的数据尽量放在同一个分区上,来减少跨分区调用的性能损耗,这就相当于降低磁盘寻址寻道的次数是一样的道理,都是在降低最耗时操作的发生次数。
二级索引的分区如何设计?
上述的三种分区方案,仅仅是对主键的分区,也就是一条记录的唯一标识进行分区,但从数据库功能的角度来看,我们还需要可以根据一条记录的任意字段建立索引,以便灵活高效的查询.这样的索引,就称之为二级索引。那么二级索引在分区数据库的设计上应该如何实现呢?通常有两种设计,本地索引与全局索引。
本地索引
当写入与读取二级索引时都在本分区上进行时,我们就说这样的二级索引为本地索引,也就是说每个分区上的二级索引文件仅存储本分区上的索引数据。这样做的好处是,在写入数据时更新一条记录的二级索引会很方便,因为关于本记录的所有二级索引都在这个节点上.但是以二级索引读取某条记录时,我们没办法知道记录在哪个分区,因此我们需要进行并行查询然后将查询结果进行合并,这样做无疑放大了读取的延迟。
全局索引
与之相对的是全局索引,即对于某个二级索引,其全部的字段都在同一个分区之中(不同的全局索引在不同的分区上),当我们查询某个二级索引时,我们可以只去唯一的一个节点上进行读取数据即可,不需要并行查询,这样读取的效率会很高,但是在写入数据的时候,由于一条记录涉及的二级索引可能在多个分区上,所以需要操作多个分区这就涉及到分布式的事务一致性等问题,复杂度大大增加并影响性能。全局索引在读取数据时,如何找到索引所在分区呢?答案是,对于全局的二级索引我们可以对其采用相同的分区策略,范围分区,散列分区或者散列范围分区等. 不同的分区策略同样会影响其对区间查询的效率。
分区再平衡
多个节点上拥有多个分区,当随着数据负载的增加,每个分区的大小就会不断的增加,这样就造成了隐患,一旦一个节点失效,其上分区都将失效,占比很大的一部分数据都将失效,再比如现在向集群中加入或剔除一个新的节点,那么数据需要可以被均匀的转移到新的节点上(新节点不转移数据,而是接受新的写请求是否可行?这样做会使在一段时间内,写入请求不能均衡的请求不同的节点,大量的请求新节点会使其负载不平衡),上述问题都概括起来就是引入分区再平衡特性的原因,即为了可用性与扩展性,分区再平衡都是必不可少的特性。
固定数量的分区
分区数与节点数应当不同,这样做是为了方便其扩展。理由是:假设分区数与节点数相同,那么通过对节点数取模来决定数据被分配到哪个分区上,这种取模会造成隐患.当我们添加或者删除一个节点时,取模的数发生变化,之前的数据不能被路由到正确的分区,所以必须进行再平衡对,所有数据重新分区(类似,hashmap 的再哈希),这会导致所有数据都处于迁移的状态,整个集群将不可用。
因此,我们必须将节点数与分区数进行解耦合,在一个节点上分配固定数量的分区数,例如在集群初始化时指定一个有1024个分区,现在有三个节点,那么每个节点应该拥有341个分区,最后一个节点可能拥有342个分区,这时添加一个节点,集群拥有4个节点后,我们需要对其进行分区再平衡,仅需要将原来的三个节点上的分区各取一半即可,这样就仅仅有一半的数据在迁移的过程中(比例经过复杂的算法可以动态调整),就可以降低分区再平衡过程中的复杂度了。节点删除也是同样的道理,将该节点上的分区平均的分散在其他节点上即可,固定数量的分区方案解决了节点数与分区数的耦合,我们对分区数进行取模即可很快的确定数据所在分区,并且在迁移前后相对分区保持不变,redis的集群模式就是采用这种方式进行的分区再平衡。
动态数量分区
固定数量分区不能很好的应对热点问题,当一个分区存储的数据量远多于其他节点时,这是不合理的。由于节点数量固定,这些数据无法迁移,因此引入类似B+树节点分裂与合并的概念,我们对分区也可以根据其数据量的多少进行分裂与合并,当某个分区负载高于一个指定的阈值时,我们就会对其进行分裂,变成两个分区,这样分区的数量就发生了变化,此种方案就不能使用分区数取模的方式进行数据的散列了,仅能根据关键字区间或者哈希进行分区。但这是值得的,他可以有效的平衡各个分区的数据负载。
按节点比例进行分区
动态分区同样拥有一个弊端,那就是其分区的数量与数据量成正比,数据量的增加会不断的增加新的分区,分区数量的变多将会成为新的性能瓶颈。
因此,引入一种新的方案,结合上述两种方案,当节点数固定不变时,分区数也是固定不变的,每个节点上的分区数永远是固定数量的,这样当节点数不变时,随着数据负载的增加,其分区的大小也会不断变大,当有新的节点加入或者剔除时,会随机(可以有某些复杂的策略)选择一些节点上的分区进行分裂,一分为二的分区,一半被移动到新的节点,另一半留在原地,这样做的好处是分区的数量被节点数所限定了,不会无限的增长成为瓶颈。
手动与自动的再平衡
是否应该有数据系统自动的完成分区再平衡?这样做无疑是方便的,也有很多数据库采用,但其复杂度确是非常之高的,例如,当发生节点分区平衡时,被系统检测到节点不可用时,那么就会造成级联崩溃的情况,触发剔除节点逻辑,又会触发新的分区平衡致使整个集群崩溃。
基于简单性的原则,有管理员手动的分区再平衡是一种折中的选择。
请求路由
引入复杂的分区方案后,客户端如何知道请求的数据在哪个分区上?一般有三种方式:
- 随机的请求一个节点,该分区会判断数据是否在自身上,是则直接返回结果,不是则转发请求到拥有数据的节点,并返回结果。
- 所有的请求都访问一个路由层,路由层拥有足够的元数据进行决策,将请求转发到合适的节点上。
- 客户端本身可以感知到分区节点的分配关系,直接请求相应分区。
无论哪种方式,只不过是路由决策的逻辑交由谁来完成的问题。
对于客户端的请求路由,需要让客户端感知到分区与节点的映射关系的变化,通常基于分布式的一致性共识组件完成,例如zk,etcd等。当分区节点启动时向zk注册自己的元数据,然后zk会将信息传播到订阅了此变化的客户端上,客户端更新分区与节点的映射关系,当有请求时直接访问对应的分区即可。其优点在于这样网络调用次数最少最高效,但依赖第三方一致性共识组件。
另一种不同的做法是,让客户端请求任意节点,分区节点根据自身持有的元数据信息判断请求的数据是否在自己的分区,在则直接处理并返回,不在则将请求转发给拥有分区的请求进行处理并返回给客户端。这样做的优点在于不依赖共识组件,但最坏情况下网络的调用次数翻倍,影响性能。
并行查询处理
当需要对多个字段进行联合查询时,分区数据库应该怎么做,我们一直探讨如何通过单独的key进行查询,但是对于大量的针对数据仓库的查询,更多的是复杂的join等多表操作.分区数据库能表现的很好吗?这就涉及到分布式数据库的分区并行查询的问题,理论上当请求到达路由层后,由路由层中并行查询优化器等组件制定并行查询计划,并委派给对应的分区,并把结果做最后的合并。这个过程中的细节非常之多,我将在之后的文章中详细介绍。
