discuz建站教程,设计好用的网站,网站设计时间,义乌 外贸网站 开发第六章 数据分区
数据分区与数据复制
分区通常与复制结合使用#xff0c;即每个分区在多个节点都存在副本#xff0c;这就意味着某条记录属于特定的分区#xff0c;而同样的内容会保存在不同的节点上以提高系统的容错性。
每个节点同时充当某些分区的主副本和其他分区的从…第六章 数据分区
数据分区与数据复制
分区通常与复制结合使用即每个分区在多个节点都存在副本这就意味着某条记录属于特定的分区而同样的内容会保存在不同的节点上以提高系统的容错性。
每个节点同时充当某些分区的主副本和其他分区的从副本 如何进行分区
如何决定哪些记录放在哪些节点上分区的主要目的是将数据和查询负载均匀的分布在所有节点上。如果分区不均匀则会出现某些分区节点比其他分区承担更多的数据量和查询负载称之为倾斜。更为严重的情况是所有的负载都集中在一个分区节点上这种负载严重不成比例的分区称为系统热点。避免系统热点最简单的方式就是将记录随机分配给所有节点但这有带来了另一个问题如何读取数据简单的键-值数据模型可以通过关键字来访问记录
键-值数据的分区
基于关键字区间分区
为每个分区分配一段连续的关键字或者关键值区间范围。为了更均匀的分布数据分区边界理应适配数据本身的分布特征。 但是基于关键字的区间分区的缺点是某些访问模式可能会导致热点例如采用时间戳作为关键字则分区对应于一个时间范围如果将每天作为一个分区同一天内所有写入都集中在同一个分区而其他的分区始终处于空闲状态。
基于关键字哈希值分区
一个好的哈希函数可以处理数据倾斜并使其均匀分布。一旦找到了合适的关键字哈希函数就可以为每个分区分配一个哈希范围关键字根据其哈希值的范围划分到不同的分区中。
这种方式看似非常完美但是在做范围查询时往往会变的非常麻烦即使关键字相邻但经过哈希函数之后可能会被分散到不同的分区中。在MongoDB中如果启用了基于哈希的分片模式则区间查询会发送到所有分区上。
综上基于哈希的分区方法可以减轻热点但无法做到完全避免。
分区与二级索引
二级索引带来的主要挑战是它们不能规整的映射到分区中。有两种主要的方法来支持对二级索引进行分区
基于文档分区的二级索引
如图每条记录都有唯一的ID首先用此ID对数据库进行分区例如0 ID 500属于分区0500 ID 1000属于分区1。现在用户需要搜索汽车可以支持按汽车颜色和厂商进行过滤所以需要在颜色和制造商上设定二级索引。声明这些索引之后数据库会自动创建索引。 在这种索引方法中每个分区完全独立各自维护自己的二级索引因此文档分区索引也被称为本地索引。
读取时需要注意如果是要查询所有红色汽车假设没有对ID做特殊处理则查询请求需要发送到所有的分区然后再合并结果。所以导致了查询代价高昂、读延迟加大。
基于词条的二级索引分区
另一种方法我们可以对所有的数据构建全局索引同时为了避免瓶颈不能将全局索引存储在一个节点上否则就破坏了设计分区均衡的目标。所以全局索引也必须分区且可以与数据关键字采用不同的分区策略。
如图所有颜色为红色的汽车的ID收录在索引color:red中而索引本身也是分区的例如从ar开始的颜色索引放在分区0中。我们将这种索引方案称为词条分区。和前面讨论的方法一样可以直接通过关键字来全局划分索引或者对其取哈希值各自的优点在前面也都提到了。 这种全局的词条索引相比于文档分区索引的主要优点是它的读取更为高效即不需要向所有分区都查询一遍。但是缺点也非常明显由于需要维护索引导致它的写入速度非常慢。理想情况下索引应该时刻保持最新但是对于词条分区来说这需要一个跨多个相关分区的分布式事务支持这也是现有数据库不支持同步更新二级索引的原因。
分区再平衡
随着时间的推移数据库可能总会出现某些变化
查询压力增加因此需要更多的CPU来处理负载数据规模增加因此需要更多的磁盘和内存来存储数据节点可能出现故障因此需要其他节点代替失效节点
所有这些变化都要求数据和请求能从一个节点转移到另一个节点这样一个过程就称为再平衡动态平衡。无论对于哪种分区方案分区再平衡通常只少要满足
平衡之后负载、数据存储、读写请求等应该在集群范围更均匀的分布再平衡执行过程中数据库应该可以继续正常提供读写服务避免不必要的负载迁移并尽量减少网络和磁盘I/O影响
动态再平衡策略
为什么不采用模运算
如果节点数发生变化将会导致大量的关键字需要从现有节点迁移到另一个节点频繁的迁移大大增加再平衡的成本。
固定数量的分区
如图如果集群中添加了一个新节点该新节点可以从每个现有的节点上匀走几个分区直到分区再次达到全局平衡当然如果增加的节点性能更加强大则可以给它分配更过的分区从而分担更多的负载。删除的话就是一个逆向的操作。这种方式不会改变关键字到分区的映射关系唯一要调整的是分区与节点的对应关系。 在这种方式中为了使得相关操作变得非常简单分区的数量往往中数据库创建时就已经确定好原则上可以拆分和合并但是为了简单许多数据库决定不支持分区拆分和合并所以在初始化时就会设置一个足够大的分区数每个分区都会有额外的管理开销。如果数据集的规模不确定此时如何选择合适的分区数以及分区大小就会有些困难。
动态分区
简单的理解就是当分区的数据增长超过一个参数阈值HBase默认值为10GB时它就拆分为两个分区可以将其中一部分转移到其他节点每个分区承担一半的数据量。相反如果数据被大量删除并且缩小到某个阈值以下则将其与相邻分区进行合并。
动态分区的一个优点是分区数量可以自动适配数据总量。
但对于一个空的数据库初始时可能会从一个分区开始这样在达到第一个分裂点之前所有写入请求都由单个节点来处理而其他节点处于空闲状态。为了缓解这种问题HBase和MongoDB允许采用预分裂配置一组初始分区同时预分裂要求知道一些关键字的分布情况。
按节点比例分区
动态分区中分区的数量与数据集的大小成正比固定数量分区中分区大小也与数据集反大小成正比这两种方式都与节点数无关。
一些数据库系统Cassandra、Ketama采用了第三种方式使分区数与集群节点数成正比。也就是说每个节点具有固定数量的分区。当一个新节点加入集群时它随机选择固定数量的现有分区进行分裂然后拿走这些分区的一半数据。
自动与手动再平衡操作
再平衡总体上讲是一个昂贵的操作它需要重新路由请求并将大量数据从一个节点迁移到另一个节点。
全自动再平衡虽然方便但有可能在再平衡过程中出现难以预测的情况。例如假设某个节点负载过重对请求对响应暂时受到影响其他的节点可能会得到结论该节点失效接着触发自动平衡来转移负载这无疑会加重该节点、其他节点以及网络的负载。
所以你怎么选择自动 or 手动
请求路由
客户端如何知道要连接哪个节点
这个问题有以下几种处理策略
允许客户端链接任意节点。如果某节点恰好拥有所请求的分区则直接处理该请求否则将请求转发给下一个节点接收答复并将答复返回给客户端所有客户端的请求发给路由层由路由层将请求转发给对应的分区节点客户端自己感知分区和节点的分配关系 所以这里的核心问题就变成了作出路由决策的组件某个节点、路由层、客户端是如何知道分区与节点的对应关系以及变化情况的呢很多分布式数据系统依靠独立的协调服务如ZooKeeper跟踪集群范围内的元数据。类似的还有MongoDB依赖于自己的配置服务器和mongos守护进程来充当路由层等。 每个节点都向Zookeeper中注册自己ZooKeeper维护了分区到节点的最终映射关系。其他参与者可以向ZooKeeper订阅此信息。一旦分区发生了改变或者删除、添加节点ZooKeeper都会通知参与者。 并行查询执行
大规模并行计算massively parallel processingMPP中查询类型方面要复杂的多典型的操作会包含多个联合、过滤、分组、聚合等操作。MPP查询优化器会将复杂的查询分解成许多执行阶段和分区以便在不同节点上并行执行。
