共计 4214 个字符，预计需要花费 11 分钟才能阅读完成。
概述
分布式数据库系统是物理上散布而逻辑上集中的数据库系统，为了进步性能并最大限度地缩小资源争用，其被宽泛用于海量数据处理的场景中。在这种状况下，数据库查问速度是零碎性能体现的决定性指标。而因为数据分布在不同节点上并通过网络通信在不同节点间传输，分布式查问的解决流程比单机集中式查问更加简单。与传统的集中式数据库系统相比，对分布式查问的构建和优化须要同时思考 CPU、I/ O 老本以及网络通信老本。
本文旨在从分布式集群视角，对 Transwarp Scope 查问相干原理和优化技术进行较为全面的解读。
整体流程
对于分布式搜索引擎来说，个别状况下，一次查问波及到多台机器的多个分片，正确的后果须要汇总多个分片的各自后果之后能力取得。因而，无论是 Transwarp Scope 还是 es，其查问过程都包含一个 Merger 的角色存在，这个 Merger 在 es 中是 Coordinating node, 而在 NS 中是 Client。而整个流程以 Phase 划分，能够分为 DFS, QUERY, FETCH 三类 Phase。
专用词与明确
分片个别也被成为 shard/tablet
Phase 简介
DFS Phase: 统计数据收集阶段，对于文本信息来说，其在单个 text 中的 freq 等信息是精确的。然而相似与 idf 这样的全局统计信息而言，每个分片只能明确该文本在分片外部的 idf，也就是一个部分的 idf。如果不进行全局 idf 综合统计，仅以 local idf 计算 score，得进去的分数是不精确的。所以，在很多对打分后果准确性要求较高的场景下，都会有 dfs 这个阶段进行全局统计信息汇总。当然，也因为多了这个阶段，相应地响应速度也会受到影响。
Query Phase: 查问阶段，依据 client 输出的信息在各个分片上找到匹配的文档汇合。这一阶段基本上会做 3 件事件：match（匹配），score(打分），local_sort(本地排序）。各个分片会将匹配的 doc_id 汇合，返回给 Merger 节点。Merger 节点会对各个分片汇报上来的 doc_set 进行 merge + global_sort。而后依据 client 设定的 from,size, 从 global_result_set 中 cut 出[from, from + size]，再进行下一阶段。
Fetch 阶段：获取 doc 原始内容的 phase。该 Phase 会依据 Query Phase 完结后的 global_result_set 向各个分片索要指标的 doc_set, 包含文档的原始内容以及可能的某些再加工内容，比方 Highlight。因为要真正地加载文档内容，所以 Fetch 阶段会产生比拟大的 io 负载（page cache 缺失的状况下）。因而，如果是一些大宽表（500 列 +）的场景，其行数据 size 比拟大的状况下，更可行的形式其实是把 ES/NS 作为一张纯正的 Index Table，即只对指标列设置索引 + 对表面主键列存储 source。如此，当 query 阶段阶段执行完之后，进行 fetch phase 的时候只须要加载 rowkey 这一列的值，再 global_result_set 中的表面 rowkey 值去内部行数据库中拿到原始内容，这样做能显著加重 es/ns 集群的存储和读写压力。
从整体上来看，查问局部根本的架构准则就是用各种不同的 Phase 拼接执行不同的查问动作，即 Compose Phases into Action. 如上图示意。
查问操作类型简介
查问操作自身能够依照如上图这样进行细分，各自含意如下表：
点查问图解
点查，或者说排序查问是外围性能，举例如下。
对于一张成绩表 schema=(姓名、数学问题、语文问题、英语问题），整张表格有 3 个 tablet, 当初要获取全副问题的前 3 名，则整体流程如下图所示。
如上图所示，即为单次点查问的原理示意图。在 Query 阶段，所有 Tablet 都将本人的数学问题的前 3 名汇总给 Merger, Merger 进行全局排序之后，发现真正的前三名是 tablet1 的 11,4 号, tablet3 的 4 号。而后在 Fetch 阶段，将这些对应 doc 标识发送给 tablet1, tablet3, 再拿到对应的文档原始内容，这里有 2 处细节值得提及。
二维全局 rowKey。在上图所示数据分布体系中，用以示意全局惟一 row 或者 doc 的标识是一个（tablet, docId)的二元组，及 tablet1 和 tablet3 都有 doc4, 但 2 者没有关系。
上图所示是在全局数据自身无序散布的状况下进行排序查问的流程，如果对数据自身就是有序散布的，那么流程会大大简化，这一点会在后续内容中探讨。
分页查问
所谓分页查问，或者扫描，就是当后果集比拟大的时候，分成屡次 rpc 返回后果。
1. 并发分页查问
所谓并发分页，如下图所示，就是 client 同时向所有的 tablet 发送 request。这种状况下，每一页的具体流程以排序 / 不排序分能够对应上文点查 / 轻量点查。
2. 程序分页查
所谓程序分页查，如上右图所示，指的是每一页并不是将 rpc 同时发送给所有 tablet, 而是对所有 tablet 进行一一扫描，tablet1，tablet2，tablet3。这种扫描形式的显著益处就是大幅度缩小了 rpc 的数量，升高了集群整体负载。又因为每个 rpc 只有 1 个 tablet 的后果，所以也不须要进行多个 tablet 后果的合并，升高了 client 的解决负载。
3. 动静超分页查问
对于查问操作来说，缓存是很有成果的优化措施。尤其是对一些单线程扫描全表的利用，其客户端内存可能大量闲置。这种场景下，正当地应用客户端内存作为缓存来优化查问速度，就是动静超分页查问的思维，其基本原理仍以是否排序分 2 种状况探讨。
对于不排序场景，缓存的策略很简略，如上图所示，就是一次 rpc 取 n 个整页，放在客户端内存中备用，从第二次之后，间接从本地内存中取用。而为了在保障稳定性的根底上尽可能地放慢 scan，对于 N 这个值采纳二进制试探 + 回退的形式进行管制。即最开始只取一页，而后是 2,4,8,16。在这个过程中，保留 Page 的均匀大小和曾经应用的内存量，综合 jvm 内存大小，从而计算出下一次 scan 最大能拿多少页。从而让 N 回退，升高 client 内存压力，保障客户端程序的稳固。在理论应用中，个别会限定客户端 jvm_heap 的 8% 作为 scan_cache 的下限。
此外，为了防止 N 过大导致提早过长问题，当单次工夫超过肯定阈值的时候，N 也会相应回退，防止让客户端感觉到太显著的卡顿。
对于排序场景，缓存不能像 no sort 场景下这么莽撞。因为排序自身存在一个回收率（1/s)的问题，即前文所提及的，3 个 shard，取前 3 名，则实际上须要拿到 3×3= 9 行数据，最终无效返回却是只有 3 行，所以回收率 =1/3。在超大集群场景下，一张大表可能有 500+ 个 shard，此时如果贸然地扩充 N 倍，一次性从 server 端取回 4000-5000 个 page，很有可能造成 client 激烈的 gc, 影响程序稳固。因而，排序场景下客户端缓存，Transwarp Scope 采纳了客户端复用的形式来进行。
如上图所示，续前文所述排序场景下 QueryThenFetch 的流程，当第一轮 Fetch 完结之后，真正的全局前三被 fetch 之后，残余的(图中标红的）T1-doc5, T2-doc11-doc22-doc15 和 T3-doc32-doc5，肯定是下一轮全局排序的备选项，所以下一轮 query 阶段并不需要再从每个 tablet 拿 3 个了，对于 tablet1，只须要再拿 2 个，tablet3 再拿 3 个，而 tablet2 则不须要在 round2 进行 query 阶段。在超大表的场景下，以 500shard, page_size=1000 为例，那么 98% 的 row 都能够在客户端进行复用，从而大大减少了 rpc 次数和 server 端查问排序的开销。当然，理论生产环境中也要思考到 rpc_size 的问题，配合整页缓存一起应用。
查问优化的根底：分区
分区是最间接无效的查问减速伎俩，尤其是对于超大规模的集群的大表（1000+ shard，单表 50T)这样的场景，如果能在查问真正开始之前将搜寻范畴放大到全量数据汇合的 1 -2%，即 10-20shard，500G-1000G 这个规模。那么理论体现进去的性能就是百毫秒到秒级级别。
最常见的两种分区机制，是 Range 分区和 Hash 分区。
1.Range 分区
如上图所示，即为 Range 分区的基本原理示意图，所有的 row, 依照 age 这一列进行划分 partition。当 select (14,19)之间的 row 时，就能够通过 partition prune 将查问限度在一个 tablet1 上，从而防止了全表搜寻，大幅度缩小了集群负载。
另外，在排序场景下，如果要获取全局 age 最大的 5 个 row，那么在已有范畴分区的状况下，只须要对 tablet1 和 tablet2 的数据进行排序，填满后果集即可，防止了对 Tablet1 的有效查问和排序。
又如上图所示，在 Range 分区的根底上，配合分片外部的预排序，就能够保障整张表格数据的全局有序。此时的升序扫表动作，就转换成了程序顺次扫描每个 shard，从而完全避免了分片级别 / 表级别的排序动作，极大晋升速度。
2.Hash 分区
hash 分区的即是依据指定列的 hash 值进行分区，如上图所示，当搜寻 age=13 的所有 row 时，因为 13 的 hash 值是 1，所以搜寻能够被剪枝到 tablet1 上，从而防止了 tablet0, tablet2 的有效搜寻。
3. 混合分区
分区的实际意义在于，通过对数据进行物理散布上的隔离，从而查问时进行大片的剪枝。在理论应用中，实在数据可能有很多的细化查问需要，须要对数据进行不止一层或一种分区，这就对应了混合分区的概念。
如上图所示，数据选集采纳 2 层分区进行物理隔离，在 shard 级别，依照 age 进行范畴分区。在每个 shard 外部，再依照 rid 进行 hash 分区。那么对于如上图 sql, 查问操作能立即通过 partiton prune 将范畴放大到 shard1 的 P0 Parition 上，查问范畴大大放大。
留神，在同一个物理隔离级别上，只能有一个 Range 分区规范，否则会有歧义导致无奈排序。而 Hash 分区能够组合多个。
总结
本文别离从客户端和集群的视角，介绍了 Transwarp Scope 的查问的根本流程、基本原理、实现形式以及不同类型分区对查问速度带来的优化。