数据库迭代模型扩展

火山模型（Volcano Model）也称为迭代模型（Iterator Model），是最著名的查询执行模型，早在 1990 年就在论文 “Volcano, an Extensible and Parallel Query Evaluation System” 中被提出。主流的 OLTP 数据库 Oracle、MySQL 都采用了这种模型。引用地址

但是，在使用过程中感觉到该模型存在一些工程上的缺陷，需要扩展。

存在问题

火山模型定义的接口清晰、简单，使得各个算子只需要关注算子本身的算法，无需关心上游是谁产出的数据。例如，Sort 算子做排序，下游数据可能来自 TableScan，可能来自 GroupBy，也可能来自 Limit。

但是，在特定场景下，下游算子如果能知道上游算子的一些额外信息，有利于执行优化。例如：

WINDOW
  SORT
    TBALE SCAN

在火山模型里，WINDOW 算子并不知道它的 CHILD 算子是 SORT，即便知道也没有一个规范的办法从 SORT 里取得任何信息。WINDOW 算子如果能知道输入的数据总行数，可以做很多动态优化。而 SORT 是阻塞算子，它正好有条件计算出总行数。这两个算子相互配合，就能让 WINDOW 算子更好地优化。

解决方案

在火山模型里，算子只有一种输出：

• 行数据

而在工程实现里，算子可以有两种产物输出：

• 行数据
• 其它统计信息、执行辅助信息

借助通信领域的概念，我将其抽象为：

• 带内数据
• 带外数据

关于带外数据的应用场景，可以参考这篇文章，写得很好。

有了带外数据的概念，上下层算子之间就有可能实现信息的共享与传输了。

接口定义

为了描述方便，还是使用上面的计划作为例子。

WINDOW
  SORT
    TBALE SCAN

首先，在计划优化阶段，优化器可以明确告诉 WINDOW 算子，它的下面是 SORT。
然后，在计划生成阶段，Code Generator 模块告知 WINDOW 算子它可以调用 child.get_stat() 接口
最后，在计划执行阶段，WINDOW 算子在 get_next_row 之前调用 child.get_stat() 传入回调对象以获取统计信息。SORT 算子检测到回调对象存在时，就会在返回任何行之前向回调对象里传入统计信息。

从上面的描述可知，每个阻塞算子都可以和一个特定类型的回调对象绑定，通过改对象对外暴露自身状态。

存在问题

如果 WINDOW 想要获得 TABLE SCAN 的统计信息呢？应该如何处理？OceanBase 里的 Datahub 组件是一种方法，但这个方法依赖了网络。我们需要一个 Local Datahub 组件，用于 DFO/fragment 内部的快算子带外数据传输。

本文重点是引入“带外数据” 的概念，其具体实现细节不做过多讨论，故而本文打住至此。