Alibaba 蚂蚁自研数据库OceanBase登顶TPC-H榜单，核心成员撰文讲述背后思考( 四 ) 蚂蚁自研数据库OceanBase登顶T

TPC-H测试场景中，要求我们用64台机器的5120个CPU超线程，同时去服务每一个用户请求，把本来需要几十分钟才能完成的请求，在几秒内处理掉，这里涉及的CPU核数和整体性能数值都是整个TPC-H结果中最高的。
第二个方面是一个真正的HTAP系统需要在TP场景和AP场景都有很强的处理能力。
OceanBase的TP处理能力在TPC-C打榜过程中已经得到了验证，背后的技术也有相关文章详细解读，这里不再赘述。那AP场景到底要求的是什么能力？
首先来说是查询优化的能力。AP场景天然有很多复杂的用户查询，具体到SQL语句上就是大量的多表连接、复杂的表达式计算、多层嵌套的子查询、聚合函数等等，这些对引擎的查询优化能力要求门槛极高。
记得曾经一个同行半开玩笑的说，很多专注TP的数据库系统不是不想做HTAP，只是“没有时间好好写一个查询优化器” 。OceanBase的1.0版本，重点重构了整个优化器的架构，引入了几十种逻辑改写和基于代价的计划选择，没有这个基础，我们不可能跑出今天TPC-H的这个性能。
其次，执行引擎的设计要求与TP天然不同，AP系统要访问大量的数据，迭代数据的效率极为关键。这个领域也是近十年来数据库研究的重点，从“火山”模型到“数据流”模型、从“拉”数据到“推”数据、cache-aware、即时编译（Just-in-time compilation），各种技术令人眼花缭乱。
OceanBase的最新3.0版本引擎与之前的最大不同在于引入了新的cache-aware向量化处理，在大数据量场景下有数倍的性能提升。当然，我们还要清醒的看到，OceanBase的引擎性能距离很多优秀产品还有明显的差距，这个方向的工作才刚起步。
第三个挑战，在于HTAP里面的H，Hybrid，混合。AP和TP是技术要求上天然不同的两类请求，典型的TP的场景是简单请求、小数据量、高并发，关注重点在系统的吞吐量。
而AP场景则是复杂查询居多，运行时间长，更多关注响应延迟。这就像是田径项目中的短跑和长跑，对运动员肌肉类型、反应速度、耐力都有不一样的要求。一个好的HTAP系统，能在一个系统里把很多TP、AP的请求同时解决掉，就相当于在培养一个运动员，既能跑一百米的短跑，又能跑一万米或者是马拉松。好比博尔特，100米短跑的王者，但今天还要博尔特跑进一万米的世界决赛，难度可想而知。
【Alibaba|蚂蚁自研数据库OceanBase登顶TPC-H榜单，核心成员撰文讲述背后思考】因此，考验一个HTAP系统，往往不是一个单一的维度，而是看如何在去做技术的妥协，这个是考验我们整个技术的能力。OceanBase今天已经应用在很多TP为主的核心场景，我希望做到的是AP能力的尽量能的延伸，我们今天在TPC-H测试中做了很多优化，但我们在TP场景的性能并没有出现回退。
另外，一旦将TP和AP的请求放在了同一个系统，意味着系统对于不同请求的资源使用要非常“合理”并且尽量互不影响。困扰数据库开发人员的一个难题是，当TP和AP请求混布时，两者之间的互相影响很难被“隔离”，今天“隔离”问题仍然是影响用户选择HTAP系统的一个重要挑战，我们将不同的资源在内部进行了虚拟化，并通过资源组的概念将TP、AP请求进行隔离，一定程度上解决了这个问题，但HTAP如何彻底的解决这些问题，还有很多有待探索的空间。
类似的问题还有很多，限于篇幅，只能先说这么多。但我认为任何一个真正的HTAP数据库，至少要能够比较好的解决上面提到的三个方面的挑战。
四、HTAP的边界在哪里？未来OceanBase的方向在哪里？
过去大家提到OceanBase，第一反应就是一个典型的TP处理系统，具有很强的高可用和线性扩展的能力。TPC-H打榜成绩以后，身边的很多朋友都问过我这样一些问题：

作为一款HTAP数据库产品，OceanBase未来有哪些是无法支持的？
OceanBase会不会主张One size fits all？
OceanBase会不会走自己的路，让别人无路可走？

换句话说，HTAP的产品边界到底在哪里？说实话，我对这个问题没有直接的答案。
但有几点想法想和同行、客户分享。
首先，一个既能处理TP又能处理AP的数据库系统，可以大大简化系统的复杂性，是有不可否认的客户价值的，这点是HTAP产品的立足之本，也是我们做产品的初心。
因此，一个HTAP系统如果本身的处理能力不足或者使用起来很复杂，也是不能满足用户期待的，OB过去两年一直在尝试降低用户的使用成本，就是希望不管是大型客户还是中小型客户，是金融客户还是非金融客户，都能用的起，用的简单，甚至用的爽，这个方向很关键，未来也会继续坚持下去。