gydtep

比多副本Divergent Design方法更进一步的，是在同一个数据库实例中采用行列混合存储的方案，同时响应TP型和AP型负载。这是传统商用数据库Oracle/SQL Server/DB2等不约而同采用的方案。

gydtep

PolarDB团队开发的并行查询框架（Parallel Query), 可以在当查询数据量到达一定阈值时，自动启动并行执行，在存储层将数据分片到不同的线程上，多个线程并行计算，将结果流水线汇总到总线程，最后总线程做些简单归并返回给用户，提高查询效率。

gydtep

行列混合的优化器
PolarDB原生有一套面向行存的优化器组件，在引擎层增加对列存功能支持之后，此部分需要进行功能增强，优化器需要能够判断一个查询应该被调度到行存执行还是列存执行。我们通过一套白名单机制和执行代价计算框架来完成此项任务。系统保证对支持的SQL进行性加速，同时兼容运行不支持的SQL.

gydtep

在列存格式下，由于每一列的数据都单独顺序存储，涉及到某一个特定列上的表达式计算过程都可以批量进行。对每一个计算表达式，其输入和输出都以Batch为单位，在Batch的处理模式下，计算过程可以使用SIMD指令进行加速。新表达式系统有两项关键优化：

gydtep

将 mysql 优化后的 AST 转换成IMCI 以 relation operator 位节点的树状结构即可，是一个比较直接的翻译过程。不过在这个过程中，也会做一部分额外的事情，如进行类型的隐式转换，以兼容MySQL灵活的类型系统。

gydtep

更新操作采用标记删除的方式来支持，对于更新操作，首先根据RowID计算出其原始位置并设置删除标记，然后在ActiveRowGroup中写入新的数据版本。

gydtep

实现一个行列混合的存储引擎技术上非常困难，但是在InnoDB这样一个成熟的面向OLTP负载优化的存储引擎中增加列存支持，又面临不同的情况：

gydtep

PolarDB IMCI VS ClickHouse
而在对比当前社区最火热的分析型数据库ClickHouse时, IMCI在TPC-H场景下的性能也与其基本在同一水平。部分SQL的处理延时各有优劣。用户完全可以使用IMCI替代ClickHouse使用，同时其数据管理也更加方便。

gydtep

异源数据

行人重识别任务也存在异源数据问题，但是该任务的异源更多是不同相机拍摄以及不同场景的区别。而在POI牌匾检索场景中，存在更严重的异源数据问题，如下图所示：

gydtep

我们借鉴了传统特征点匹配算法思想，利用Sift特征点匹配算法对两趟资料中的所有牌匾进行两两匹配，并通过内点数量对匹配结果进行筛选，即内点数量大于阈值的匹配牌匾视作同一牌匾。