执行并行查询及总结

5.1 执行并行查询

至此，只关注了读/写入单K的简单查询（对文档分区的二级索引，要求分散/聚集查询）。这也是大多数NoSQL分布式数据存储所支持的访问类型。

但对大规模并行处理（MPP, Massively parallel processing）这类主要用于数据分析的关系型数据库，在查询类型方面要复杂多了。典型的数仓查询包含多个连接，过滤，分组和聚合操作。 MPP查询优化器将复杂的查询分解成许多执行阶段和分区，以便在DB集群的不同节点上并行执行。尤其是涉及全表扫描的查询，很受益于这种并行执行。

数仓查询的快速并行执行查询是个专门话题，分析业务日渐重要，可以带来很多利益。后文再详解。

总结

本文探讨了将大规模数据集划分成更小子集的各种方案。数据量太大，单台机器存储和处理就会成为瓶颈，因此需要引入数据分区机制。

分区的目标：通过多台机器均匀分布数据和查询负载，避免出现热点。这需要选择合适的数据分区方案，在节点添加或删除时，重新动态平衡分区。

主要的分区方案：

• K范围分区

  先对K排序，每个分区只负责一段包含min到max K 范围的的一段K。排序的优势在于能支持高效的范围查询，但若应用程序经常访问某段K，就存在热点风险。这种方案，当分区太大时，通常将分区分成两个子分区，从而动态地再平衡分区。

• hash分区

  将hash函数应用于每个K，每个分区负责一定范围的hash值。这种方案破坏了K的顺序，范围查询效率低下，但能更均匀分配负载。

  采用该方案分区时，一般预创建好足够且固定数量的分区，让每个节点承载多个分区，当添加或删除节点时，将某些分区从一个节点迁移到另一个节点。也可支持动态分区。

两种方案混用也可行，如使用联合K：

• K的一部分来标识分区

• 另一部分记录排序后的顺序

分区和二级索引之间的相互作用。二级索引也需要分区，有如下方案：

• 基于文档分区二级索引（本地索引）。二级索引存储在与K相同的分区中，即写时只需要更新一个分区，但缺点是读二级索引时，需要在所有分区之间执行分散/收集

• 基于词条分区二级索引（全局索引）。基于索引的值而进行的独立分区。二级索引中的条目可能包含来自K的多个分区里的记录。写入时，不得不更新二级索引的多个分区；但读时，可以从单个分区直接快速提取数据

最后，讨论如何将查询请求路由到正确的分区，包括简单的分区负载平衡到复杂的并行查询执行引擎。

理论上，每个分区基本独立运行，这也是为何试图将分区数据库可伸缩到多台机器的原因。但若需跨多个分区，就很复杂了，如若写一个分区成功，但另一个失败，后续会咋样？静等下文~