数据分区

• S：在学习和实践“数据分区”时，需要建立统一的概念和问题边界。
• C：相关概念、实现机制和工程取舍容易混在一起，导致只记住结论而无法判断适用条件。
• Q：“数据分区”要解决什么问题？它的核心抽象、工作机制和边界分别是什么？
• A：本文围绕“数据分区”整理核心概念、关键机制和工程实践，并明确其适用边界。

S 数据量太大一台机器放不下，或单节点吞吐不够 C 按某种规则拆分到多台机器上后，查询、索引、节点增减都变复杂 Q 怎么拆？拆了之后怎么查、怎么扩？ A 选合适的分区策略，处理好热点、再平衡和二级索引

分区策略

• 按范围分区（range）：key 按范围划分，支持范围查询；但可能热点不均
• 按哈希分区（hash）：key 哈希后分配，分布均匀；但丢失了范围查询能力
• 组合：先哈希确定分区，分区内按范围排序

热点问题

某些 key 被大量访问（如热门用户），导致单个分区压力过大 解决：在 key 后加随机后缀分散写入，读取时合并多个分区结果

分区再平衡（Rebalancing）

节点增减时，数据需要重新分配：

• 固定数量分区：分区数远大于节点数，节点增减时只移动分区
• 动态分区：分区大了就拆，小了就合
• 一致性哈希：节点加入/离开时只影响相邻节点的数据

二级索引与分区

分区后，二级索引怎么办？

• 本地索引（document-based）：每个分区维护自己的索引；写入快，但查询需要 scatter-gather（等所有分区返回）
• 全局索引（term-based）：索引本身也分区；查询快，但写入需要跨分区更新

分区 vs 分片

Partitioning：分区是在同一个数据库逻辑表下面，把数据按规则拆成多个物理区域。 通常还在一个数据库系统内部，逻辑上是一张表。

Sharding： 把数据拆到多个数据库节点/实例上。

分区：一台数据库内部拆 分片：多台数据库之间拆

延伸阅读

分库分表偏数据库工程实践，重点是主从 vs 分库分表、分片键，以及事务、Join、分页、全局 ID 的代价