分布式执行引擎
当前 AntDB 的分布式执行引擎采用经典的迭代模型（Iterator Model）又称火山模型（Volcano Model）。执行计划中的每个算子都需要实现 next 函数， 上游算子每一次递归调用，内部都会调用其输入的 next 函数，再层层返回结果。PostgreSQL、MySQL、SQL Server、DB2、Oracle 等传统关系型数据库基本都采用这种计算模型。如图 7-10、图 7-11 所示是迭代模型实现两表 join 操作的处理流程。
迭代模型简单灵活，且不用占用过多的内存。在当时内存是非常昂贵的， 迭代模型将更多的内存资源用于 I/O 的缓存设计，而没有用于优化 CPU 的执行效率，这在当时的硬件基础上是自然的权衡。但是在 CPU 的硬件环境与大数据场景下，性能表现却不尽如人意。究其原因，主要有如下几点：
● 每次next都是一次虚函数调用过程，是被动拉数据，编译器无法对虚函数进行inline优化，同时也带来分支预测的开销，且很容易预测失败， 导致CPU流水线执行混乱。
● Volcano Style的代码对数据的局部性并不友好，往往造成cache miss。CPU cache存储着连续数据空间，每次可以对连续数据进行集中处理， 将收益最大化。而迭代模型每次调用只处理一行。
鉴于迭代模型每次只处理一行数据，而 next 调用代价又比较高，选用块存取和块计算对列存储而言能发挥更大优势。所以向量化模型（Vectorized Model）在业界应运而生。
向量化模型和迭代模型类似，每个算子都需要实现一个 next 函数，但是每次调用 next 函数会返回一批元组（tuples）而不是一个元组。在算子内部，每次循环都会处理多个元组。批次的大小可以根据硬件或者查询数据进行配置。向量化模型实现两表 join 操作的处理流程如图 7-12 所示。
向量化模型更适合与列式存储搭配使用，以提高 OLAP 查询性能。因为算子每次执行的时候都会在内部攒一批数据，大大提高了 CPU 缓存和高速缓存的命中率，且减少了虚函数调用的次数。此外，还可以基于 SIMD 向量化指令操作的思想去重构整个表达式计算，充分发挥 SIMD 指令并行计算的优势。
