资深架构师技术分享：一文详解分布式系统的分区
|
固定数量分区不能很好的应对热点问题,当一个分区存储的数据量远多于其他节点时,这是不合理的。由于节点数量固定,这些数据无法迁移,因此引入类似B+树节点分裂与合并的概念,我们对分区也可以根据其数据量的多少进行分裂与合并,当某个分区负载高于一个指定的阈值时,我们就会对其进行分裂,变成两个分区,这样分区的数量就发生了变化,此种方案就不能使用分区数取模的方式进行数据的散列了,仅能根据关键字区间或者哈希进行分区。但这是值得的,他可以有效的平衡各个分区的数据负载。 按节点比例进行分区 动态分区同样拥有一个弊端,那就是其分区的数量与数据量成正比,数据量的增加会不断的增加新的分区,分区数量的变多将会成为新的性能瓶颈。 因此,引入一种新的方案,结合上述两种方案,当节点数固定不变时,分区数也是固定不变的,每个节点上的分区数永远是固定数量的,这样当节点数不变时,随着数据负载的增加,其分区的大小也会不断变大,当有新的节点加入或者剔除时,会随机(可以有某些复杂的策略)选择一些节点上的分区进行分裂,一分为二的分区,一半被移动到新的节点,另一半留在原地,这样做的好处是分区的数量被节点数所限定了,不会无限的增长成为瓶颈。 手动与自动的再平衡 是否应该有数据系统自动的完成分区再平衡?这样做无疑是方便的,也有很多数据库采用,但其复杂度确是非常之高的,例如,当发生节点分区平衡时,被系统检测到节点不可用时,那么就会造成级联崩溃的情况,触发剔除节点逻辑,又会触发新的分区平衡致使整个集群崩溃。 基于简单性的原则,有管理员手动的分区再平衡是一种折中的选择。 请求路由 引入复杂的分区方案后,客户端如何知道请求的数据在哪个分区上?一般有三种方式:
无论哪种方式,只不过是路由决策的逻辑交由谁来完成的问题。 对于客户端的请求路由,需要让客户端感知到分区与节点的映射关系的变化,通常基于分布式的一致性共识组件完成,例如zk,etcd等。当分区节点启动时向zk注册自己的元数据,然后zk会将信息传播到订阅了此变化的客户端上,客户端更新分区与节点的映射关系,当有请求时直接访问对应的分区即可。其优点在于这样网络调用次数最少最高效,但依赖第三方一致性共识组件。 另一种不同的做法是,让客户端请求任意节点,分区节点根据自身持有的元数据信息判断请求的数据是否在自己的分区,在则直接处理并返回,不在则将请求转发给拥有分区的请求进行处理并返回给客户端。这样做的优点在于不依赖共识组件,但最坏情况下网络的调用次数翻倍,影响性能。 并行查询处理 当需要对多个字段进行联合查询时,分区数据库应该怎么做,我们一直探讨如何通过单独的key进行查询,但是对于大量的针对数据仓库的查询,更多的是复杂的join等多表操作.分区数据库能表现的很好吗?这就涉及到分布式数据库的分区并行查询的问题,理论上当请求到达路由层后,由路由层中并行查询优化器等组件制定并行查询计划,并委派给对应的分区,并把结果做最后的合并。这个过程中的细节非常之多,我将在之后的文章中详细介绍。
（编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
