6 分析处理 6.1 透明查询路由
在PolarDB-IMCI中，通过一种基于成本的路由协议，可以在不同的节点和不同的执行引擎上执行查询。路由过程对应用程序和用户完全透明，并且具有两级策略：节点间路由和节点内路由。节点间路由通过代理层实现读写流的分割（负载均衡），而节点内路由通过优化器提供对数据访问路径和执行引擎（基于行或基于列）的动态选择。
节点间路由。PolarDB-IMCI的代理为所有应用程序请求（包括OLTP和OLAP）提供统一的SQL接口。当请求进入时，代理通过一个简单的语法解析器将读写请求（如事务）指向RW节点，并将只读查询（如分析查询）指向RO节点。
如果有多个 RO 节点可用，则代理会根据负载平衡策略选择一个可用的 RO 节点。节点内路由。在 RO 节点内部执行的查询通过优化器进行节点内路由。优化器根据查询的特性、数据分布和可用索引等因素，动态选择数据访问路径（行级或列级访问）和执行引擎。这样可以根据查询的需求最大程度地提高查询性能。
总的来说，透明查询路由机制使得在PolarDB-IMCI中执行的查询可以根据成本和数据访问需求智能地路由到最适合的节点和执行引擎，从而提高整体查询性能。
节点内路由。如图8所示，PolarDB-IMCI在每个RO节点内实现了两个执行引擎。一种是面向点查询的基于行的执行引擎，另一种是面向分析查询的基于列的执行引擎。PolarDB-IMCI的优化器根据基于行的成本估算来选择合适的执行引擎。通过假设所有查询优先在基于行的执行引擎中运行（即成本较低），优化器首先生成一个面向行的执行计划。如
果面向行的计划的估算成本超过一个阈值（即成本较高），则生成并使用一个面向列的计划来使用基于列的引擎。我们将新的行-列混合成本模型和混合执行计划的发展作为未来的研究方向。
6.2 IMCI计划生成 PolarDB-IMCI不是从顶向下构建面向列的执行计划，而是通过从面向行的计划转换而来。PolarDB-IMCI使用DPhyp [39]作为连接排序算法，并通过随机采样[10, 11, 26]收集统计信息。转换的工作流程如图8所示。通过这样做，面向列的计划可以保留所有的行为特征。
例如，在PolarDB-IMCI中，面向列的计划的隐式类型转换始终与面向行的计划一致。在计划生成过程中，PolarDB-IMCI将原始表达式转换为矢量化执行格式，以利用SIMD指令。这种转换是在表达式对象（例如MySQL中的Item类）内部处理的，并且严格遵循原始的隐式类型转换。另一个例子是，面向列的计划重用了面向行的计划的错误代码和消息。在不同的执行引擎之间对齐错误是具有挑战性的。在PolarDB-IMCI中，面向列的计划可以直接从面向行的计划中保留静态错误检测，以避免这个问题。对于运行时错误，PolarDB-IMCI会将执行回退为面向行的方式。因此，PolarDB-IMCI与MySQL现有框架的兼容性非常强。
6.3 执行引擎 为了获得先进的OLAP性能，PolarDB-IMCI设计了一个新的高性能分析执行引擎（即基于列的引擎）。借鉴内存中列式数据库[4, 24, 35]的知识，分析引擎融入了许多最先进的技术，包括流水线执行模型、一组经过优化的并行操作符和矢量化表达式评估框架。
流水线执行。矢量化执行计划的执行树被分解成多个线性路径，称为流水线。在流水线中，非阻塞操作符（例如过滤器，连接探测）一次处理一个批次的数据而不是所有数据，然后将中间结果传递给下一个操作符。流水线执行带来了几个优点：(1). 流经多个操作符的一批数据总是被缓存；(2). 中间结果被减少以最小化内存占用。
并行操作符。为了并行化每个流水线，分析引擎中的所有操作符都支持并行执行。例如，TableScan可以以非交错的方式并发获取数据包，分析引擎实现了无锁分区连接[1]。此外，为了减少缓存失效，阻塞操作符尽可能使用精心设计的数据结构（例如友好缓存的哈希表[3]）和软件预取[13]。此外，所有阻塞操作符都有一个经过优化的溢出到磁盘版本，用于处理内存溢出危机，例如动态混合哈希连接[29]。
表达式评估。当一批数据被缓存时，性能瓶颈从内存访问转换为CPU计算。SIMD指令，有时也称为矢量化指令，如AVX-512，对于加速CPU计算非常强大。因此，一个表达式评估框架[37]从操作符中分离出来，以矢量化的方式（即使用SIMD指令）为计算密集型模块提供服务。
6.4 强一致性 由于PolarDB-IMCI使用异步复制机制，分析查询可能会观察到陈旧的数据。例如，分析查询可能无法读取已经在RW节点中提交的更新。但是，通过代理层，PolarDB-IMCI可以实现多种一致性级别，以满足应用程序的需求，包括强一致性。代理会跟踪RW节点的写入LSN和所有RO节点的应用LSN。写入LSN和应用LSN分别表示RW和RO的事务提交点。在写入LSN之前的事务已经在RW节点上提交。同样，应用LSN之前的任何日志条目都保证在RO节点上已经被重放。为了满足强一致性的需求，代理只会将查询路由到应用LSN不小于写入LSN的RO节点。
