gydtep

首先，在技术上需要维护两套不同技术体系的数据库系统，其次由于两套系统处理机制的差异，维护上下游的数据实时一致性也非常具有挑战。而且由于同步延迟的存在，下游AP系统存储的经常是过时的数据，导致无法满足实时分析的需求。

gydtep

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

gydtep

执行引擎只能串行执行，无法发挥现代多核CPU的并行话能力。官方从MySQL 8.0开始，在一些count(*)等基本查询上增加并行执行的能力，但是复杂SQL的并行执行能力构建依然任重道远。

gydtep

并行执行框架突破了CPU扩展能力的限制，带来了显著的性能提升。然而受限于行式存储及行式执行器的效率限制，单核执行性能存在天花板，其峰值性能依然与专用的OLAP系统存在差距。要更进一步的提升PolarDB MySQL的分析性能，

gydtep

在PolarDB的SQL执行器层，我们重写了一套面向列存的执行器引擎框架(Column-oriented), 该执行器框架充分利用列式存储的优势，如以4096行的一个Batch为单位访问存储层的数据，使用SIMD指令提升CPU单核心处理数据的吞吐，所有关键算子均支持并行执行。在列式存储上，新的执行器对比MySQL原有的行存执行器性有几个数量级的性能提升。

gydtep

在IMCI的执行引擎中，每个Operator也使用迭代器函数来访问数据，但不同的是每次调用迭代器会返回一批的数据，而不是一行，可以认为这是一个支持batch处理的火山模型。

gydtep

但这种抽象会同时带来性能上的损耗，因为在迭代器进行迭代的过程中，每一行数据的获取都会引发多层的函数调用，同时逐行地获取数据会带来过多的 I/O，对缓存也不友好。MySQL采用树形迭代器模型，是受到存储引擎访问方法的限制，这导致其很难对复杂的逻辑计算进行优化。

gydtep

因此设计一个一体化的存储引擎能同时服务OLTP型和OLAP型负载非常具有挑战性。目前市场上HTAP存储引擎做的比较好的只有几家有几十年研发积累的大厂，如Oracle (In-Memory Column Store）/Sql Server(In Memory Column index）/DB2（BLU)等。如TiDB等只能通过将多副本集群中的一个副本调整为列存来支持HTAP需求。

gydtep

列存的设计无需考虑事务并发对数据的修改, 数据的unique check等问题，这些问题在行存系统中已经被解决，而这些问题对ClickHouse等单独的列存引擎是非常难以处理的。

gydtep

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