Page 220 - 《软件学报》2021年第10期

3192 Journal of Software 软件学报 Vol.32, No.10, October 2021

另外,他们还提出了两种基于 COD 框架的缓存策略,即 Conform-COD 和 Scramble-COD.
2007 年,Christian [63] 指出:数据库引擎在对表进行扫描时,通常都是由存储引擎从第 1 个页面(first page)一直
读取到最后一个页面(last page),因而导致 buffer 的利用率低下.为此,Christian 提出了一种协作扫描的方案,该方
案将具有相同扫描算子的查询整合到一起,设为一个扫描组,扫描组的实例如图 12 所示.第 1 个扫描算子称为
leader,从起始 page 开始扫描;之后的扫描称为 trailer,从当前 buffer pool 中读取 page,并记录 page 的位置,当扫描
算子再次读到标记位置时,扫描即结束.Christian 等人在 DB2 上实现了该方案,buffer 的效率显著提升.随着计算
机内存带宽的提升,越来越多的数据页可以缓存在内存中,从而使得该方案的应用场景逐渐减少,除非连续的查
询相似性非常高,否则,该方案几乎没有优势.图 12 显示了一个工作组的实例.

Fig.12 An example of scan group
图 12 扫描组实例

2008 年,Qiao 等人 [64] 指出:内存带宽增长速度无法与 CPU 性能的增长相匹配,而渐渐取代了磁盘 I/O,成为
查询处理的瓶颈.他们提供了一个新颖的方案来提高查询的吞吐量,该方案允许所有并发查询在执行基表 I/O
时共享 CPU 内核缓存,即将查询计划分为多个批次,每个批次聚集表(用于聚集操作的 hash 表)的工作集被写入
CPU 缓存中,已达到共享该批次操作的目的.Qiao 通过实验提出数据的选择性、工作集大小是制约该方案的重
要因素.为了避免“快查询”和“慢查询”被分入同一批次而导致系统延迟,以及工作集较大使得 CPU 缓存溢出等
问题,该方案提供了一种有效估计选择性和工作集大小的采样技术.实验结果表明:在 8 核平台上,该方案在选择
性波动较小的工作负载中的吞吐量,相比同等条件下的主流商用数据库要高出 2~2.5 倍.

4.2 多查询执行模块之间的调度
2005 年,Stavros [20] 提出了协调 OMP 执行模式的策略,并实现了 OMP 协调器.一旦 OMP 协调器将一个或多
个卫星数据包附加到主机数据包上,参与的查询之间便会形成“1 个生产者,N 个消费者”的关系.QPipe 的中间缓
冲区可调节数据流.如果任何一个消费者的速度都比生产者慢,则所有查询最终都会将其消费速度调整为最慢
的消费者的速度.Stavros 等人在后续的工作中还研究了:(1) QPipe 如何应对频繁到达或离开的卫星扫描的负担
问题;(2) OMP 协调器如何利用顺序敏感的重叠扫描问题;(3) QPipe 如何防止死锁的问题;(4) QPipe 如何处理锁
定请求和更新语句等问题.
2009 年,Candea 等人设计了 CJoin 查询流水线模型 [22] ,每一个 filter 和 Aggr Operator 都类似于一个-engine.
他们在文献[22]中指出其面临以下优化问题:给定一个工作负载 Q 和一个 Q 的 CJOIN 管道,确定筛选器的排序,
以使每个事实元组的探测预期数量最小.一个复杂的因素是,每个过滤器的选择性取决于工作负载 Q,因为过滤
器会在特定的维表上对多个查询的连接谓词进行编码.因此,如果工作负载是不可预测的(如数据仓库中的临时
分析查询),则最佳顺序可能会随着查询组合的变化而变化.通过观察该结果,Candea 等人提出了一种在线方法,
用于优化 CJOIN 管道中的过滤器顺序.这个想法是在运行时监视每个过滤器的选择性,然后根据收集的统计信
息优化顺序.监视和重新优化的连续过程可以在 Pipeline Manager 线程内部异步执行.
2018 年,Jonathan 为流分析查询系统专门设计了作业调度模式 [40] ,一旦查询优化器生成了全局查询计划,作
业调度器将广域网络带宽作为重要属性并对该查询计划进行部署.调度程序将根据其上游顶点的部署,以拓扑