「阅读」数据密集型系统设计 第六章 分区

本文主要是介绍「阅读」数据密集型系统设计 第六章 分区，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

6.1 介绍

1. 什么是分区？
   分区是通过特定列的值将数据划分为逻辑独立的部分，每个分区是一个数据子集。
   常见的可以用于分区的维度：时间、地理位置、类别等
2. 分区的好处？
   1. 提高查询性能：只扫描某个表而不是整张表
   2. 提高管理和维护数据的能力：数据通过某个维度进行组织。
3. 为什么有分区技术？
   分区技术的初衷：针对海量数据场景，提高获取/更新数据的性能
   分区技术和可伸缩性契合。

6.2 如何实现分区？

6.2.1 键值数据分区

目标

将数据和查询负载均匀分布到各个节点中。

方案一：随机分配
随机分配可以保证负载均衡，但是当读取一个特定值时，无法知道该值在那个分区，只能遍历全表。

方案二：根据键的范围分区
定义：每个分区定义一个最小值和最大值。
优点：

1. 查询时可以找到迅速找到分区
   缺点：
2. 数据分布无法保证均匀，可能会导致某个（些）分区成为“热点”

方案三：散列（hash）分区–一致性哈希算法
优点：

1. 可以公平的分配键，负载比较均衡
   缺点：
2. 范围查询性能没有提升

6.2.2 分区和次级索引

次级索引的分区问题

当前数据库，例如 mysql、oracle 中，分区键中必须是主键的一部分，因此主键是可以快速定位到分区的。

但是次级索引列和分区键可能是两个不同的列，通过次级索引列的每次操作，就需要对所有数据进行操作。
参考资料：mysql 分区键为什么必须是主键的一部分

方案一：基于文档的分区-本地索引

这种索引优点：

• 每个分区完全独立，只需要处理当前分区中的信息

缺点

• 不会将某种特定的 key 放在一起（color 所有数据），导致搜索时必须全表扫描

应用的数据库如 MongoDB、Elasticsearch 等。

方案二：基于关键词的分区-全局索引

构建一个覆盖所有分区数据的全局索引。全局索引也不可以放在一个节点上，需要进行分区。

优点：

• 读取效率更高

缺点：

• 写入速度慢 && 复杂
• 需要跨分区的事务

6.2.3 分区再平衡问题 && 解决方案

问题介绍

随时间推移，数据库以下情况都需要数据 && 请求从一个节点转移到另一个节点种，将负载从一个节点转移到另一个节点的过程称为再平衡。

• 查询吞吐量增加
• 数据集大小增加
• 机器故障

再平衡目标：

• 负载应该公平
• 再平衡进行中，服务可用
• 节点间移动的数据应该尽量少

策略一：hash && Mod N（不推荐）

策略执行：先对 key 进行 hash，对结果通过 mod n 分区。

节点数量 n 增加时，大量原有数据必须迁移，成本过大。

策略二：固定数量分区

分区数量 > 节点数量，每个节点分配多个分区。

优点：

• 分区在节点种移动
• 分区总数不变
  缺点：
• 无法很好的评估分区数量

策略三：动态分区

采用关键字区间分区的数据库，如果边界设置有问题，可能导致数据倾斜到一个分区中。

• 按键的范围进行分区的数据库（如HBase和RethinkDB）会动态创建分区。
• 当分区增长到超过配置的大小时（在HBase上，默认值是10GB），会被分成两个分区，每个分区约占一半的数据。
• 与之相反，如果大量数据被删除并且分区缩小到某个阈值以下，则可以将其与相邻分区合并。此过程与B树顶层发生的过程类似。
  优点：
• 分区数量适应总数据量
  缺点：
• 空数据库从 1 个分区开始，导致所有写入必须单个节点处理，其他节点空闲。

策略四：按照节点比例分区

动态分区和固定数量的分区，分区数量都与节点数量无关。
Cassandra和Ketama使用的第三种方法是使分区数与节点数成正比：每个节点有固定数量的分区。

• 当节点数不变，分区大小与数据集大小成比例增长；
• 当节点数改变，分区大小将变小。

操作方式：

• 当一个新节点加入集群时，它随机选择固定数量的现有分区进行拆分，然后占有这些拆分分区中每个分区的一半，同时将每个分区的另一半留在原地。
• 随机化可能会产生不公平的分割，但是平均在更大数量的分区上时，新节点最终从现有节点获得公平的负载份额。
• 随机选择分区边界要求使用基于散列的分区（可以从散列函数产生的数字范围中挑选边界）。实际上，这种方法最符合一致性哈希的原始定义。

这篇关于「阅读」数据密集型系统设计 第六章 分区的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---