数据分区设计(4)-负载偏斜与热点消除及基于文档的二级索引进行分区

负载偏斜

hash分区可减少热点，但也无法完全避免：极端的，所有读/写操作都针对同K，则所有请求都会被路由到同一分区。如社交网站的坐拥百万粉丝的大V，每次发布一些热点事件，就会引发一场访问风，导致某博宕机。导致同一K的大量写操作（K可能是大V的用户ID或人们正在评论的事件ID）。此时，hash策略失效，因为两个相同ID的hash值仍相同。

热点消除

大多数据系统无法自动消除这种高偏斜负载，只能通过应用层来减少倾斜。如若某K被确认为热点，简单方案就是在K的开始或结尾添加一个随机数。只要一个两位数的十进制随机数就能将主键再分散为100种不同的K，以存储在不同分区。

但之后的任何读取都需额外工作，须从所有100个K分布中读取数据，然后聚合。因此通常只对少量热点K附加随机数才有意义；对写吞吐量低的大多数K，这些都是不必要的开销。

还需额外的元数据来标记哪些K进行了特殊处理。

3 分区与二级索引

目前的分区方案都依赖KV数据模型。KV模型简单，都是通过K访问记录，自然可根据K确定分区，并将读写请求路由到负责该K的分区。

但若涉及二级索引，就很复杂。二级索引通常并不能唯一标识一条记录，而是一种加速特定值的查询，如查询用户JavaEdge的所有操作，查找包含词语 java 的所有博客等。

许多KV存储（如HBase）为了减少实现复杂度而放弃二级索引，但一些（如 Riak）已开始支持它们，二级索引也是 Solr 和 ES 等搜索服务器的根本。

二级索引的主要挑战是不能整齐地映射到分区。有两种方案支持对二级索引进行分区：

• 基于文档的分区（document-based）
• 基于关键词（term-based）的分区

3.1 基于文档的二级索引进行分区

二手车销售网（如图-4）。 每个列表都有个唯一的文档ID，以此对DB进行分区，如分区0 中的ID 0~499，分区1中的 ID 500~999。

用户搜车，可按颜色和厂商过滤，所以需要在颜色和厂商设置二级索引（在文档DB中这些是字段（field），关系DB中这些是列（column））。每当将一辆红色汽车添加到DB，DB分区都会自动将其添加到索引条目 color:red 的文档ID列表。

[ii]  若DB仅支持KV模型，则你可能尝试在应用程序代码中创建从值到文档ID的映射来实现二级索引。 若沿着这条路，请确保你的索引与原 DB 系统保持数据一致。 竞争条件和中间写入失败（其中一些更改已保存，但其他更改未保存）都很容易导致数据不同步。

这种索引方法中，每个分区完全独立，各自维护自己的二级索引，且只负责自己分区内的文档，而不关心其他分区的数据。每当需要写DB（添加，删除或更新文档），只需处理包含你正在编写的目标文档ID的分区。因此，文档分区索引也被称为本地索引，而非全局索引。

但读时注意：除非对文档ID特别处理，否则不太可能将所有特定颜色或品牌的汽车放在同一分区。图-4中，红车出现在分区0、1。因此，若搜索红车，就需将查询发送到所有分区，然后合并所有返回的结果。

这种查询分区DB的方法有时称为分散/聚集（scatter/gather），显然这种二级索引的查询代价高昂。即使并行查询分区，分散/聚集也容易导致尾部读延迟显著放大。但它依旧被广泛使用：MongoDB，Cassandra，ES都直至基于文档分区的二级索引。大多DB供应商建议用户自己构建合适的分区方案，尽量由单个分区满足二级索引查询，但这并不总是可行，尤其是当查询中使用多个二级索引时（例如同时需按颜色、制造商两个条件查询）。