一文详解分布式系统的分区

关键在于采用一种统一的规则,这种规则可以计算出将数据放在哪个节点,并且在读取时也能计算出去哪个节点读取数据。

要做到这几点目前有三种分区方式:

1. 按key的范围进行分区 当要存储数据时,我们取数据中的某一个字段作为分区key,按这个字段的范围进行分区例如自增的id值,0-10000存储在A节点上,10001-20000存储在B节点上,那么基于这样的规则我们可以高效的存取分区中的数据,并且自然的支持按区间查找(key的存储是有序的),只要区间的范围仅在一个分区时,那么区间查找就只会访问一个分区,除非查找范围跨越多个分区。但是问题在于当数据的写入在某段时间内存在热点时,例如0-100000的key被大量的写入,而10001-20000的key很少的时候,就会造成 数据倾斜 (数据分区大小不均衡)
2. 按key的散列进行分区 对于数据倾斜,很自然的方式想到一个高效的散列函数来将数据存放在不同的分区,只要散列函数一致,相同的key一定会被映射到同一个分区。所以也是能够解决分区的关键问题,但是由于散列的问题,自然的进行区间范围查找会非常的困难,有些数据库会将区间查找的请求发送给所有分区,并行处理后,再全部聚合返回结果,但无疑会频繁的产生大量的请求,虽然可以有效的解决数据倾斜问题,但是这种热点数据是没有办法完全避免的,比如一个大V用户总有非常多的粉丝,每天要产生非常多的数据,通过key散列这些数据还是会存储在相同的分区内,造成数据倾斜的同时,还会导致热点数据的频繁访问,读与写负载都会分布不均匀。
3. range+hash 模式 上述两种分区的优缺点恰好是互补的,那么可以考虑将二者结合例如用数据记录的两个关键字段作为key,比如是id与时间戳,先用id 散列存储在不同的分区上,然后在使用时间戳按范围进行分区,这样做在一定程度上弥补了二者的优缺点。 但依旧没有完全解决热点数据问题,这时热点数据问题可以考虑其他方面来解决,比如建立热点数据的缓存架构。

分区方法看似完美的对数据的存储进行了扩展,但也引入了另外的复杂度,那就是在查询数据的时候,如果数据恰巧不在同一个分区内,就需要访问多次不同的分区这样就会加大请求的延迟,或者当我们需要对关系模型中的数据进行join操作时,由于数据在不同的分区中的不同表内,进行join的难度就会非常大,增加了多表查询的复杂程度,一种折中的解决方案是,从业务上来看,将会被join或者同时读取的数据尽量放在同一个分区上,来减少跨分区调用的性能损耗,这就相当于降低磁盘寻址寻道的次数是一样的道理,都是在降低最耗时操作的发生次数。

二级索引的分区如何设计?

上述的三种分区方案,仅仅是对主键的分区,也就是一条记录的唯一标识进行分区,但从数据库功能的角度来看,我们还需要可以根据一条记录的任意字段建立索引,以便灵活高效的查询.这样的索引,就称之为二级索引。那么二级索引在分区数据库的设计上应该如何实现呢?通常有两种设计,本地索引与全局索引。

本地索引

当写入与读取二级索引时都在本分区上进行时,我们就说这样的二级索引为本地索引,也就是说每个分区上的二级索引文件仅存储本分区上的索引数据。这样做的好处是,在写入数据时更新一条记录的二级索引会很方便,因为关于本记录的所有二级索引都在这个节点上.但是以二级索引读取某条记录时,我们没办法知道记录在哪个分区,因此我们需要进行并行查询然后将查询结果进行合并,这样做无疑放大了读取的延迟。

（编辑：宣城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!