坊间传来消息，OceanBase又一次打榜TPC全球第一。自从有过两次TPC-C第一之后，这第三次打榜也有点不新鲜了。不过这次可不是TPC-C，而是TPC-H。OceanBase以1526万QphH的性能总分创造了新的世界纪录，成绩是现在榜单第二名的10倍多！
和TPC-C一样，TPC-H也是TPC家族里面有悠久历史的测试标准，历来为很多的数据库厂商去打榜。但是不一样的是，TPC-C主攻OLTP，而TPC-H则是主攻OLAP。
传统意义上，我们认为OceanBase是一个OLTP数据库。但是，这些年里，OceanBase在OLAP端不断发力。OceanBase的OLAP能力也同样不容小觑。
OceanBase的领导团队也多次对外表示过，在不牺牲TP性能的前提下，让AP的性能也做到极致，从而真正打造一个混合事务/分析处理（HTAP）的通用关系型数据库。这次TPC-H的打榜，无疑证明了OceanBase在OLAP能力上同样不容小觑。
在数据库领域，一直以来有两种论调，一种是OLTP和OLAP都有自己的专属数据库产品，后者通常被成为数据仓库。另外一种观点是数据库就是数据库，能够很好处理OLTP的负载的同时也应该能够很好的处理OLAP。
后者通常被称为HTAP。比如说我们熟知的Oracle数据库，其TP性能很好是广为人知的，但是其AP性能也同样不容小觑，是真正的一款HTAP产品。市面上号称自己是HTAP的产品很多，但是能够真正在TPC-C和TPC-H两个测试标准都拿下世界第一的，还只能当属OceanBase。
由于TP和AP的查询在很多方面表现不同。TP查询通常数量多，单个查询简单，只需要访问少量的数据。AP的查询通常来说数量并没有那么多，但是查询逻辑复杂，很多查询会涉及到若干张表中的全表或者相当一部分数据。这就导致了TP和AP在技术上有天然的不一致性。在一个擅长OLTP的数据库里面，做到极致的OLAP，也就有着一些技术挑战。为此，我特意采访了OceanBase研发中心资深总监陈萌萌，来帮助我们深度解读一下OceanBase是如何解决这些技术挑战的。
陈萌萌表示，能够拿到TPC-H的第一名，这归功于OceanBase是一个MPP架构的分布式数据库能力。如果用数据库里面更通用的语言来翻译，这是一个shared-nothing的架构，具有很好的扩展性。
拿Oracle数据库和OceanBase做个比较。OceanBase很容易的就可以调度几千台机器进行运算。而Oracle则要困难的多，基本上以10为数量级的单位就是Oracle的集群规模。由于Oracle的架构问题，上千台机器是不可能的。所以Oracle的发展走向了数据库一体机，堆积高端硬件，搞垂直扩展。OceanBase并没有限制其垂直扩展的能力，同时其水平扩展能力也非常的强。
当然，这样的架构对于解决TP问题的优势是显而易见的。因为TP查询通常来说只需要访问一个分区的数据，可以在少量节点上跑起来，并且能够在不同的节点上跑不同的查询，并发性也很好。
仅仅有这样的MPP架构，并不足以支撑AP查询。AP查询引擎需要在两个方面做出很好的优化：
第一，其数据处理引擎必须是一个真正的分布式引擎。用数据库的学术用语来说就是支持exchange operator，能够对数据进行shuffle。当然仅仅是一个分布式的引擎还是不够的，那仅仅是这个数据库具备了OLAP的处理能力。但是在今天的环境下，要想高效率的处理OLAP的查询，还离不开operator的向量化。
OceanBase从OLTP的数据库到HTAP数据库的发展起步于OceanBase2.0时期。在数据处理引擎层面，同时做到了分布式化和向量化。这两方面是一个高效率的OLAP数据处理引擎的基础，也是今天TPC-H登顶的重要因素。
第二，其查询优化需要做的相当的好，能够有效的针对复杂的查询生成高效的执行计划。说个不恰当的比喻，如果说OLTP对查询优化的要求是小平房的话，OLAP对查询优化的要求则是高楼大厦。
OceanBase在优化器方面也做了很多的工作。其中有一个检验OLAP优化器到底是处于什么样水平的标志是优化器是如何处理serial和paralle plan的，也就是如何在执行计划中引入exchange operator。
这里的套路一般有两个，简单的做法是先不管exchange operator，直接当成单机查询先生成一个最优的serial plan，然后再在上面添加exchange operator。比较高级的做法是优化器可以同时检索serial和parall plan，同时生成有exchange和没有exchange的执行计划，并从中根据代价选择合适的。
而代价是什么，本身也是一个很复杂的问题。举个例子来说，Bloom filter经常用在分布式Join里，来减少数据传输。在传统意义上来说，比如说对一个只有几十台机器的Oracle 数据库，bloom filter的生成，传输和使用的代价基本上可以忽略不计。而在一些大数据产品，和包括OceanBase这样水平扩展可以上几千个节点的分布式数据库来说，Bloom filter的生成，传输和使用的代价就不再是可以忽略的了。因此，针对一个水平可扩展的分布式数据库的优化器，其基于代价的优化的逻辑上也必然不一样。
简单总结来说，OceanBase从2.0开始发力OLAP的能力，首先是基于其一直以来良好的MPP架构。其次是OceanBase在查询优化，和执行引擎等多方面都对OLAP进行了全面的提升。两者相辅相成的情况下，才同时登顶了TPC-C和TPC-H的世界第一，这是非常不容易的。
我比较好奇的另外一个问题是，在OceanBase里OLTP和OLAP的负载会不会打架。毕竟，从TPC-C和TPC-H两个测试来看，在单独跑TP和单独跑AP的时候，OceanBase都有非常良好的表现。而这也只能证明OceanBase在单独跑TP或者单独跑AP的时候性能很优，并不能证明TP和AP混合跑的时候，会有什么样的表现。就这个问题我也请教了陈萌萌。
陈萌萌表示OceanBase目前实现了基于cgroup的AP和TP资源隔离，这对CPU和内存的隔离效果都不错，所以并不会因为TP而抢了AP的风头，反之亦然。这也是我知道的业界比较通行的做法。
和陈萌萌的对话和沟通，让我对OceanBase目前的架构有了更好的了解。OceanBase打榜第一次拿下TPC-C第一的时候，我是非常兴奋的，看到了国产数据库的进步。但是我多少还有点遗憾，毕竟和第二名的差距并不大，而前者是很多年前跑的记录。第二次刷新TPC-C记录的时候，我不仅仅是兴奋，更多的是吃惊，毕竟那个新记录实实在在的是一座不容易攀登的高峰。无论哪个数据库厂商想来攀登一下，都要费九牛二虎之力。
而当这次OceanBase又登顶，但却是带着TPC-H的第一来的时候，我只有一种目瞪口呆的感觉了。这年头里，OLTP的数据库跑到OLAP的场地来秀肌肉，还把人家的头名给摘走了。这只能说对手太强，不能说那些做OLAP的都废物吧。
当然，TPC-H毕竟是一个比较老的标准了，也有其明显的缺陷。比如说TPC-H里面的Primary Key值的分布，并不能真实的反映出现实数据中的Key的zipf分布的特点，也就是著名的八二法则:80%的数据只出在20%的Key上。而新标准TPC-DS则很好的解决了这个问题。
展望未来，我很期待OceanBase什么时候能够把TPC-DS的第一也给拿下来，那就真的是无敌了。
