当前，号称HTAP的数据库不少，但是OLTP和OLAP（以下简称：TP和AP）任意一方面做好的其实并不多，更何况是两方面都做的不错的。

　　不过，OceanBase可以算是一个。

　　为什么这么说？因为，OceanBase又打榜了。

　　每家数据库厂商都试图向客户证明自己的系统性能最好、处理能力最强，但数据库厂商各自的性能测试数据，没有足够的说服力。

　　这时候，TPC的价值就体现出来了。TPC作为数据库领域benchmark世界最权威的测试基准（不是给钱就能过的，需要经过严苛测试流程、审计及公示，一次打榜长则半年，短则数月），因此，在业内被广泛接受。在国内，曾经金融，电信，政府等行业POC都以TPC为性能测试基准。

　　事实上，国内这几年也在搞类似的标准，但目前看，还差点火候，距离被广泛接受还需要一些时间。至于，其他厂商说跑分没意义，显然是有点酸。

　　继2次打榜TPC-C证明自身OLTP能力之后，OceanBase再次打榜，不过，这次打的是TPC-H，并以1526万QphH的性能总分创造了新的世界纪录，成绩是现在榜单（V3）上的第二名10倍多！

题图：来自TPC官网截图

　　本文重点不在此次打榜过程及故事，都第三次打榜了，大家看腻味了，老鱼也写腻味了，本文关键在于解析OceanBase此次打榜的目的？OceanBase为什么要做HTAP，又是如何支持HTAP的，这其中OceanBase有着怎样的思考。

　　在获知TPC结果的第一时间，老鱼采访了OceanBase创始人兼首席科学家阳振坤和OceanBase研发中心资深总监陈萌萌。

　　打榜TPC-H只为证明AP能力

　　TPC-H是一个偏OLAP场景的基准测试，反映了系统处理查询能力的多个方面。

　　陈萌萌告诉老鱼，OceanBase在TPC-C登顶之后再次打榜TPC-H，是希望用户能够对OceanBase在OLAP场景的一些能力有进一步了解，也是进一步贯彻OceanBase产品的HTAP定位。

　　OceanBase立志成为一个世界级的通用关系数据库。其产品定位在2.0后就很清晰，其存在就为解决企业客户三大难题，第一大难题是可扩展性，第二难题是高可用，第三大难题是混合事务/分析处理（HTAP）。而AP能力与TP能力一样，并不是突然出现，是一个渐进的过程，在2.0版本后，AP能力开始逐步发展。

　　目前，号称HTAP的数据库不少，但是TP和AP任意一方面做好的其实并不多，更何况是两方面都做的不错的。

　　因为，单一的AP分析系统，只需要关注AP，数据也是按业务需求生成的，所以通常产生报表速度更快，但缺点是，一旦业务需求发生较大的变化，需要重新拉取数据；HTAP系统，需要同时兼顾TP和AP，其AP分析也更加困难，这也是为什么两个都做的好很难的原因，但好处是，即使业务需求发生了很大的变化，也不需要重新拉取数据，因为数据已经在系统中了。

　　为什么OceanBase能做HTAP，阳振坤说，因为要能够产生报表（AP），那么，系统的容量必须足够大，这只能是分布式数据库，而这个系统还需要有真正的TP能力，即得是真正的分布式交易数据库，而市场上的AP系统， TP处理能力普遍非常弱，根本不足以作为一个交易处理数据库。

　　OceanBase是一个真正的分布式数据库，首先展示和被验证的，是其TP能力，最近几年，OceanBase的AP能力也在蚂蚁内部和外部得到了验证。因此OceanBase的HTAP产品和技术能力，其实是领先的。

　　为何要做HTAP如何实现

　　2014 年 1 月 28 日，Gartner 在《混合事务/分析处理促进重大商业创新》报告中，对HTAP数据库给出了明确的定义。HTAP数据库需要同时支持 OLTP 和OLAP 场景。HTAP迅速成为引起一些企业的关注，被很多人视为未来数据库领域发展趋势之一。

　　HTAP并不是要彻底取代传统TP或AP数据库，HTAP有自己的市场。

　　阳振坤告诉老鱼，客户对销售状况和业务收入等各种报表的实时性要求越来越高，通过ETL（数据抽取转换加载）从交易数据库(TP)系统同步数据到数据仓库或大数据系统，然后产生报表，不可避免地存在较大的延迟，从数小时到数天不等，进一步缩短这个延时的代价非常大。在交易数据库上直接生成报表，即HTAP，天然没有任何延迟，是最符合业务需求的。这也是OceanBase为什么要做HTAP的原因所在。

　　对于OceanBase是如何支持HTAP的，此前，OceanBase CTO、团队创始成员杨传辉在《OceanBase CTO 杨传辉：下一代企业级分布式数据库的一体化设计》一文中，有所提及。

　　HTAP 也是分布式数据库领域的一个热门概念。

　　有两种做法：

　　第一种是主备库物理隔离，主库做 OLTP，备库做 OLAP，主备之间通过 redo 日志做同步，备库与主库之间有一定的延迟。第二种是在同一套引擎实现 OLTP 和 OLAP 混合负载，区分 OLTP 和 OLAP 请求所在的资源组，对资源组进行逻辑隔离。

　　第一种方案实现相对简单，但由于产生了更多数据冗余，性价比较低；第二种方案实现相对复杂，但采用一体化设计，性价比更高。第二种方案来自经典数据库，例如 Oracle、SQL Server。

　　我认为，企业级分布式数据库应该学习 HTAP 技术，采用第二种方案。

　　很显然，OceanBase采用的第二种。也就是说，OceanBase自研了一套引擎同时支持了OLTP和OLAP，这是与其它HTAP数据库差异化的体现，比如当红炸子鸡TiDB，使用的就是两套引擎。OLAP引擎魔改自ClickHouse，OLTP引擎基于KV。

　　陈萌萌告诉老鱼，OceanBase当前的OLAP能力已经实现了很多复杂的决策支持的查询，报表的制作等。

　　那么，OceanBase到底能兼顾怎样程度的OLAP？陈萌萌说，OceanBase当前的OLAP能力以结构化数据为主（暂时还不支持JSON、图、全文索引等大数据分析），覆盖了一些比较常见的SQL功能，包括CTE（with语句）、窗口函数、多表连接（小于15张表）、聚合、子查询、层次查询等等。

　　写在最后

　　从决心做一个通用关系数据库开始，OceanBase团队就很清楚，不可避免的需要直面市场传统关系数据库的竞争，作为后来者，假如OceanBase硬件性价比没有高出市场上主流商业关系数据库一个数量级，假如OceanBase不能做到传统商业数据库做不到的事情，比如主库故障时备库数据不完整、水平扩展能力缺失等等。那么，OceanBase很难会有明显竞争优势。

　　三次刷榜TPC，并三次打破世界纪录，倔强的OceanBase无疑是在用成绩向世界证明，中国数据库也能行，OceanBase不仅能做到传统关系数据库能做到的事，也能做到传统关系数据库做不到的事，而且是世界级的。

　　毕竟，数据库竞争光靠情怀、政策是不行的，关键还要看技术能力。

　　篇外话

　　不少人觉得OceanBase不接地气，过于强调世界第一、金融级，整的太高大上，这让中小规模的企业都不敢去尝试，怕杀鸡用牛刀。其实，这是一种误解，与传播策略有关，但与产品本身与技术无关。

　　确实，OceanBase诞生于蚂蚁这种超大规模和超高压力的应用场景，在最初设计时确实有很多对极限场景的考虑和优化，但从开始商业化之后，OceanBase其实已经开始强调更贴近外部真实客户场景，特别是降低中小客户的使用门槛。

　　比如在这次TPC-H测试中，OceanBase除了水平扩展能力（多机），也非常强调单机的垂直扩展能力，通过向量化引擎、单机并行执行等技术，充分挖掘硬件潜力。

　　据陈萌萌介绍，在内部非官方的测试中，在几T甚至更小的数据规模下，OceanBase也能取得不错的成绩。另外，这几年OceanBase对硬件的要求也一直在降低过程中，从之前的动辄几十G上百G的最小内存规格，降低到现在的十几G甚至几G就可以运行，都是为了更好的服务中小客户，降低使用门槛。

　　对于一般的中小规模客户，OceanBase的HTAP能力能够在一套系统中承载更多的客户需求，避免独立TP、AP系统带来的各种开销，整体来看用户的成本是明显降低的。

　　阳振坤说，未来，OceanBase希望能够帮助客户完全摆脱ETL+数据仓库/大数据，而首先是中小企业客户。