另外一部分用户，一直使用的是像Oracle这样的传统的数据库，对于TP和AP的边界认知比较模糊，尤其是Oracle的处理能力很强，很多复杂查询扔到Oracle里面也能跑。在一次某大型客户的业务上线过程中，压测的最后阶段，我们发现了非常多的复杂查询。当我们询问客户为什么他们的TP系统中会有如此多AP请求时，客户的一句话把我们问懵了——“啥叫TP、AP请求？”我们在内部也有过讨论，发现即使是团队内部大家的看法也是不一样的。只能说有一些场景偏TP类型或者偏AP类型，但很难给出绝对答案。
越来越多的客户案例让我意识到，过去一直坚持的HTAP技术方向也是很多客户需要的。但今天在很多客户眼中，OceanBase就是只支持TP处理的数据库，完全没想到我们还有很强的AP处理能力。“酒香也怕巷子深”，我们觉得这个时候打榜TPC-H，既能让产品的能力进一步提高，大家也能更了解OceanBase的价值。
三 TPC-H新世界纪录背后的“三座大山”如果让2014年的我说OceanBase什么时候能够在TPC-C、TPC-H这样的榜单上露个脸，我还真不知道。
做数据库就像盖房子，今天OceanBase这座房子已经到了交付阶段，要给客户的体验是“拎包入住”，因此水、电、装修风格都要做好。而2014 年就像在“打地基”的阶段，你说我将来要做某某内饰风格，至少当时没有想到那么具体的事情，但是我知道分布式一定是这个房子的“地基”，我们要盖的是一个摩天大楼，而不是一个独门小院。这个是打破传统数据库设计限制的前提，想通了这个事儿，后面的技术落地就比较自然了。
为什么分布式数据库是HTAP技术的未来？这个和HTAP的几大技术挑战有关。
首先，也是最重要的事情，这个系统的容量一定要足够大，扩展性足够强。
从数据容量上看，因为AP本身的分析要有价值，就需要聚集相当量的数据才有价值，这是以前的单机数据库做不到的。一台机器的容量，或者是几台机器的容量永远是受限的。十年前，世界上最大的Oracle RAC实际系统只有20来个节点。当时我在Oracle经历的一个重要项目是，将RAC的集群规模扩展到128台。而今天像OceanBase这样一个分布式数据库，做到几百台机器的集群规模是非常轻松的，这种规模上的区别带来技术上的想象空间是完全不同的。
而且在这次测试面向AP的场景中，又引入了一个OceanBase家族的新成员叫OceanBase File System（简称OFS）。这是一个分布式的共享存储系统，基于OFS的方案在存储容量上几乎是可以无限扩展，永远不用担心数据没地方存。这就解决了整个系统容量的扩展的问题。
另外，既然要将TP和AP放到同一个集群中处理，那么集群的处理能力也要有非常强的可扩展性。这里如果再讲多一些，处理能力的扩展性还能分为“水平”扩展和“垂直”扩展两个维度。
大家看过我们TPC-C的测试结果可能还有印象。当时，用了1554台机器，把整个TP系统跑这么高的分数。这个体现的是OceanBase的水平扩展能力。
什么叫垂直扩展性呢？就是在一台机器内部通过硬件扩展（更多CPU核数、更大内存）而提升性能。为什么这个在HTAP下仍然有挑战？因为在TPC-C的扩展里面，更强调的是水平扩展，换句话说，数据库集群规模越大，性能分数就越高。但在AP场景下，用户同时也会关心能不能实现垂直扩展，比如说能不能让一个系统的几千个CPU核，几十台机器同时为一个查询服务。万事万物，只要涉及到“协同“，就有成本。把协同的成本降低到最低，考验的是系统整体的设计。
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的这个性能。