gydtep

IBM在2013年发布的10.5版本(Kepler)中，增加了DB2 BLU Acceleration组件，通过列式数据存储配合内存计算以及DataSkipping技术，大幅提升分析场景的性能。

gydtep

支持行列混合执行的优化器框架，该优化器框架会根据下发的SQL是否能在列索引上执行覆盖查询，并且其所依赖的的函数及算子能被列式执行器所支持来决定是否启动列式执行。优化器会同时对行存执行计划和列存执行计划做代价估算，并选中代价交代的执行计划。

gydtep

在PolarDB中除了有原生MySQL的行存串行执行，还有能够发挥多核计算能力的基于行存的Paralle Query功能。因此实际优化器会在1)行存串行执行，2）行存Paralle Query 3)IMCI 三个选项之中选择。在目前的迭代阶段，优化器按如下的流程操作：

gydtep

由于消除了树形迭代器模型中的递归过程，计算效率更高。同时该方法对计算过程提供简洁的抽象，将数据和计算过程分离，天然适合并行计算。

gydtep

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

gydtep

在PolarDB中除了有原生MySQL的行存串行执行，还有能够发挥多核计算能力的基于行存的Paralle Query功能。因此实际优化器会在1)行存串行执行，2）行存Paralle Query 3)IMCI 三个选项之中选择。在目前的迭代阶段，优化器按如下的流程操作：

gydtep

采用这种数据组织方式一方面满足了分析型查询按列进行批量扫描过滤的要求。另一方面对于TP型事务操作影响非常小，写入操作只需要按列追加写到内存即可，删除操作只需要设置一个删除标记位。

gydtep

SIMD向量化计算加速

AP型场景，SQL中经常会包含很多涉及到一个或者多个值/运算符/函数组成的计算过程，这都是属于表达式计算的范畴。表达式的求值是一个计算密集型的任务，因此表达式的计算效率是影响整体性能的一个关键的因素。

gydtep

采用基于统计信息的粗糙索引方案对于一些需要精准定位部分数据的查询并不是很友好。但是在一个行列混合存储引擎中，列索引只需要辅助加速那些会涉及到大量数据扫描的查询，在这个场景下使用列会具有显著的优势。而对于那些只会访问到少量数据的SQL，优化器通常会基于代价模型计算得出基于行存会得到一个成本更低的方案。

gydtep

POI 是 Point of Interest 的缩写。在电子地图上，POI 代表餐厅、超市、政府机关、旅游景点、交通设施等等 。POI是电子地图的核心数据。对普通用户而言，POI 数据包含的名称和位置信息，能够满足其使用电子地图“查找目的地”，进而唤起导航服务的基本需求；