数据密集型应用设计--数据分区

数据分区与数据复制

每个分区在多个节点上有多个副本，一个节点上可能存储多个分区。

分区方式

基于关键字区间分区

比如某个单词的首字母、记录的时间等作为分区的条件。

**缺点：**会有可能出现不均匀的现象

基于关键字哈希分区

一致性哈希。

缺点：无法实现分区查询

分区与二级索引

基于文档分区的二级索引

每个分区完全独立，各自维护自己的二级索引，所以又称为本地索引。

写操作：只需要处理包含目标文档ID的那个分区

读操作：如果需要按某个查询条件来查记录，需要遍历所有的分区。

基于词条分区的二级索引

对所有数据构建全局索引，并把索引按自己的分区策略分到不同的分区上。

读操作：只需要找到对应词条上的分区，就可以知道所有记录的id

写操作：因为新增一条记录可能涉及多个词条，而不同的词条可能分布在不同分区，所以每次新增或者删除都需要维护不同分区上的词条，速度很慢。

分区再均衡

分区数量变化之后需要决定数据各由哪些分区负责。

注意：不能直接使用hash取模确定哪个分区，因为如果分区数量变了的话数据的位置就是错的了。

固定数量的分区

在系统建立之前，创建远超实际节点数的分区数，然后为每个节点分配多个分区。比如10个节点负责1000个分区，那一个节点平均负责100个分区。如果有新增节点的话，就把现有节点中的分区匀一些到新节点，删除节点就反向操作。类似Redis的slot。

• 优点：实现简单，适合数据量比较好估算而且不会有太多变化的系统
• 缺点：如果数据规模不确定，且变动很大，那么建立多少个固定的分区是不好确定的

动态分区

根据数据量自动适应分区数量。当数据量达到某个阈值，则一个分区分成两个分区，并且各自负责一半的数据量。当数据量小到某个阈值，则合并两个分区为一个分区。

• 优点：分区数量可以根据数据量自行调整
• 缺点：数据量和分区数量成正比，和节点数没关系

按节点比例分区

每个节点设置一个固定的分区数。当没有新节点加入的时候，数据量和分区大小成正比。当有新节点加入的时候，从老节点的分区中随机获取一定数量的数据转移到新节点的新分区中存储。

请求路由

如何知道某个数据在哪个节点上？

三种处理策略：

1. 允许客户端连接任易节点，查询遍历所有节点
2. 将客户端的请求通过路由层转发
3. 客户端感知节点和分区的分配关系

一般使用zookeeper