这样的架构有其灵活之处，例如对于TP数据库和AP数据库都可以各自选择最好的方案，而且实现了TP/AP负载的完全隔离。但是其缺点也是显而易见的。
三家领先的商用数据库厂商，均同时采用了行列混合存储结合内存计算的技术路线，这是有其底层技术逻辑的：列式存储由于有更好的IO效率(压缩,DataSkipping,列裁剪)以及CPU计算效率(Cache Friendly), 因此要达到最极致的分析性能必须使用列式存储，
第二点，基于性能的的考量，我们完全重写了一套面向列存的SQL执行引擎，包括其中所有的物理执行算子和表达式计算，其所覆盖的场景相对MySQL原生行存能够支持的范围有欠缺。当下发的SQL中包含一些IMCI执行引擎不能支持的算子片段或者列类型时，需要能能够识别拦截并切换回行存执行。
事务型应用和分析型应用对存储引擎有着截然不同的要求，前者要求索引可以精确定位到每一行并支持高效的增删改，而后者则需要支持高效批量扫描处理，这两个场景对存储引擎的设计要求完全不同，有时甚至是矛盾的。
lan转换的目的是将MySQL的原生逻辑执行计划表示方式AST转换为IMCI的Logical Plan。在生成IMCI的Logical Plan之后，会经过一轮Optimize过程，生成Physical Plan。Plan转换的方法简单直接，只需要遍历这个执行计划树，
向量化执行解决了单核执行效率的问题，而并行执行突破了单核的计算瓶颈。二者结合使得IMCI执行速度相比传统MySQL行式执行有了数量级的速度提升。
第一种方式，RW上开启行列混合存储，此种模式部署可以支持轻量级的AP查询，在主要为TP负载，且AP型请求比较少时可以采用。或者使用PolarDB进行报表查询，但是数据来自批量数据导入的场景。
行列混合执行，即一个SQl的执行计划部分片段在行存执行，部分片段在列存执行。以获得最大化的执行加速效果。
值得注意的是，在对牌匾提取OCR结果时，为了减少单帧内识别结果不准的影响，我们利用了一趟资料内同一牌匾的多帧OCR结果，并且将所得到的OCR结果进行拼接，使用BERT对OCR结果特征编码时，对来自不同帧的OCR结果之间插入符号做区分。
此次开源的OpenXuantie系列RISC-V处理器，包括玄铁E902、E906、C906、C910等4款量产处理器IP，以及基于OpenXuantie的多操作系统（AliOS、FreeRTOS、RT-Thread、Linux、Android等）的全栈软件及工具。
