怎么同时处理TP和AP请求？1988年提出的“数仓”概念，背后隐藏的假设是TP和AP请求会放在不同的系统中处理。这样假设有业务发展和应用架构的必然性，但技术层面的限制也是不可回避的问题。毕竟在那个时代，作为分布式数据库系统的Teradata，最大只能支持1000个核和5TB存储。而且，真正能够使用这样高端系统的用户寥寥无几。
当用户开始被迫地把TP或者是AP的请求分成不同系统时，专门处理TP和AP场景的数据库随之出现。针对不同场景，采用不同引擎技术，比如按行存储或是按列存储，确实能够大幅度提高特定场景下的数据库性能。
但不可否认，一个能同时处理TP和AP请求的数据库，对于用户来说是非常有价值的，除了能大幅度降低用户成本外，还能明显降低用户系统的复杂性和运维成本。
因此，很多成熟的商业数据库，如Oracle、IBM DB2等，在保持极强的TP处理能力之外，从来没有停止过对AP场景的支持和优化。如果大家看一下这些数据库巨头在顶级学术会议上发表的论文列表就会发现，面向AP场景的论文，数量甚至比事务处理方向的还多，而且每年都有更新。
2010年前后，随着硬件能力越来越强，尤其是SSD固态盘、大容量内存和多核CPU等技术的普及，大大增加了数据库的设计可能，促使不少数据库研究人员重新思考在同一个数据库中处理TP和AP请求的可能，甚至包括当初缔造“数仓”概念的Barry Devlin都提出，应该“重新考虑将TP和AP分开这一设计理念”。今天，不少新的数据库也开始宣称支持HTAP，我想也是顺应了整个技术的大趋势。
二 OceanBase把HTAP写入基因OceanBase是2010年开始在阿里集团内部自主研发的分布式数据库。最开始基本就是在阿里、蚂蚁内部用，真正长得像一个数据库的样子，应该是从2014年启动OceanBase 1.0版本开始的。我也是在那个时候加入OceanBase，跟着团队一步步走到了今天。
回想当初，数据库的很多技术都在悄悄发生着变化。一方面，以Oracle为首的传统数据库在TP场景似乎已经“独孤求败“，TPC-C世界纪录已经多年未被打破，而像OceanBase这样的分布式数据库还没有看到挑战Oracle霸主地位的可能。
另外一方面，传统数据库的AP能力越来越跟不上数据规模和硬件的发展。SSD、大容量内存、超高核数的CPU，这些理论上能带来巨大性能提升的硬件无一不在挑战传统的数据库软件设计。TPC-H榜单上，Oracle、SQL Server这种传统数据库被神秘的数据库厂商Exasol虐的找不着北。Exasol具体怎么实现的我不是特别清楚，但向量化引擎、cache-aware、列存、及时编译（Just-in-Time compilation）,大致总离不开这几个方向。但传统数据库不是这么设计的，内存能大到几百GB甚至上TB？最初的数据库设计者想都不敢想，更别提充分利用了，“守着金山要饭吃”，当时的传统数据库看到硬件的发展就是这么一种感觉吧。
当时的我也在思考这个问题：一个能同时处理好TP和AP请求、并且能充分挖掘硬件能力的数据库到底应该是什么样的？“缝缝补补带不来真正的技术革新”。在一个现成的开源组件上去打补丁，或者简单重构很难做出一个划时代的产品，因为我自己曾在一个面向AP的开源引擎上尝试过这件事儿，干到后面觉得比重写一个引擎难多了。2014年OceanBase 1.0版本正在酝酿中，对我来说，做一个真正HTAP引擎的机会来了。
从时间上看，AP场景的几项关键技术是随着产品丰富逐步完善起来的。2014年做了基于代价的查询优化器。2016年做了分布式运行一体化执行。2019年和2020年分别做了向量化执行引擎和TP、AP的资源隔离。事实上，这些年，OceanBase的AP能力一直在不断增强，只不过大家很少有机会了解。
如果知道这些来龙去脉，大家对OceanBase冲击TPC-H这件事儿，也许就没那么奇怪了。今天我们的用户场景和产品定位也都需要产品具备这样的能力，从这个角度上讲，OceanBase正式进入到HTAP产品时代，也是市场的选择。
从2017年开始，我每年都会投入相当比例的时间拜访外部客户。在这个过程中，深刻感受到，对于HTAP，不同客户有不一样的认知。
其中一部分用户使用的是典型的TP、AP独立架构。这类用户以互联网公司居多，受目前流行的解决方案影响。系统设计之初就将TP和AP系统分开，通过中间链路同步数据。这类用户一般有两个痛点，一个是实时性要求高的分析逻辑无法在TP数据库中原地完成，只能等数据同步到AP数据库中再做。另外就是系统难以运维，尤其是中小型的客户，运维人员得熟悉两套系统，还要时刻关注中间数据链路的稳定性，技术门槛很高。