事务型应用和分析型应用对存储引擎有着截然不同的要求，前者要求索引可以精确定位到每一行并支持高效的增删改操作，而后者则需要支持高效批量扫描处理。这两个场景对存储引擎的设计要求完全不同，有时甚至互相矛盾。因此，设计一个一体化的存储引擎能同时服务OLTP型和OLAP型负载非常具有挑战性。目前市场上HTAP存储引擎做的比较好的只有几家有几十年研发积累的大型企业，如Oracle (In-Memory Column Store）、Sql Server(In Memory Column index）、DB2（BLU)等。TiDB只能通过将多副本集群中的一个副本调整为列存来支持HTAP需求。
一体化的HTAP存储引擎一般使用行列混合的存储方案，即引擎中同时存在行存和列存，行存服务于TP，列存服务于AP。相比于部署独立一套OLTP数据库加一套OLAP数据库来满足业务需求，单一的HTAP引擎具有如下的优势：
-
行存数据和列存数据具有实时一致性，能满足很多苛刻的业务需求，所有数据写入即可见于分析型查询。
-
低成本。用户可以非常方便的指定哪些列甚至一张表的哪个范围的存储为列存格式。全量数据继续以行存存储。
-
管理运维方便，用户无需关注数据在两套系统之间同步及数据一致性问题。
PolarDB采用了和Oracle、Sql Server等商用数据库类似的行列混合存储技术，即In-Memory Column Index： -
建表时可以指定部分表或者列为列存格式，或者对已有的表可以使用ALTER TABLE语句为其增加列存属性，分析型查询会自动使用列存格式来进行查询加速。
-
列存数据默认以压缩格式存储在磁盘上，并可以使用In-Memory Columbia Store Area来做缓存并加速查询，传统的行格式依然保存在Buffer Pool中供OLTP型负载使用。
-
所有事务的增删改操作都会实时反馈到列存存储，保证了事务级别的数据一致性。
实现一个行列混合的存储引擎非常困难，但是在InnoDB这样一个成熟的面向OLTP负载优化的存储引擎中增加列存，又面临不同的情况： -
满足OLTP业务的需求是第一优先级。因此，增加列存不能对TP性能有太大影响。这要求维护列存必须足够轻量，必要时需要牺牲AP性能来维持TP性能。
-
列存的设计无需考虑事务并发场景下对数据的影响，以及数据的unique check等问题，这些问题在行存系统中已经被解决，而这些问题对ClickHouse等单独的列存引擎来说，非常难以处理。
-
由于有一个久经考验的行存系统的存在，列存系统出现任何问题，都可以切换回行存系统响应查询请求。
上述条件可谓有利有弊，这也影响了对整个行列混合存储的方案设计。
