前几天听说 OceanBase 打榜了 TPCH 的第一名，之后又看到这样一个测试报告《OceanBase 开源版与 TiDB 对比测试报告》。

先点评一下这个测试报告：

1. 坦白地说，这个测试还不太专业，并不能比出分布式大数据计算的关键能力。TPCH10G 的数据量相对于这些机器内存实在太小了（单机内存都超过数据量 18 倍以上）。这种情况下，再加上预热，数据已经全部缓存到内存了，列存基本不起作用，也就谈不上对比列存引擎的能力了。而且，数据量太小，会被作为小表复制到集群中的每个节点，分布式计算中重要的 Shuffle 能力也无法被考查到，网络负担仅仅是些汇总结果的传输，而 TPCH 的结果集都很小，这个时间可以忽略不计。

2. 目前这个数据量对比的是纯 CPU 计算能力，本质上是在对比 SQL 优化引擎的能力。如果直接按 SQL 书写的逻辑去计算，那计算量通常会很大，也就会很慢了。但数据库都会有优化，不会严格按 SQL 的逻辑来计算，会在不改变运算目标时尽量采用更低复杂的算法，就可能跑得更快了。从这个测试结果上看，TiDB 的 SQL 优化引擎要明显强过 OceanBase。

以往的经验，Oracle 的 SQL 优化引擎做得很好。如果不能在列存和集群上占便宜的话，很多专业 OLAP 数据库都跑不过 Oracle。而当前这个场景就是这样，数据量太小可以全部缓存进单机的内存，列存失去意义，集群也沦为简单地用多机分摊运算。所以我们猜测 Oracle 会比这两个都快，单机的 Oracle 甚至有可能跑过集群的 OceanBase。

之前我们还用 SPL 重写过 TPCH 并和 Oracle 对比《全国产计算数据库性能测试报告》。SPL 可以直接实现高性能算法而不必寄希望于数据库的优化引擎，相当于已经人为实现了优化。实测的结果表明，在大数据量（超过内存）时 SPL 能比 Oracle 有数倍的优势，这主要是因为列存以及好算法能减少外部缓存而造成的。但对于小数据量，这些环节的时间占比会少很多，估计就不会有明显优势了。

于是，造了一套 10G 的 TPCH 数据，并安装了 Oracle 和 SPL 在单机上分别跑，测试服务器 CPU 是 12 核 1.7G 的 Intel3014。结果如下：

（前两列测试结果来自上述的测试报告）

Oracle 有三个查询可能执行路径被搞晕了，有点奇怪地慢，但也懒得给它再调优了。因为，即使这样，它的单机速度也基本上和 OceanBase 的集群相当了，如果再考虑到 CPU 核数和频率，可以认为还更快一些。

Oracle 单机速度赶不上 TiDB 集群了，但换算后核数和频率后，单位 CPU 的速度还是比 TiDB 要稍快一点。不过两者已经比较接近，看起来 TiDB 在 SQL 优化方面做得确实不错（Oracle 在这方面真地是一座高山），HTAP 中的 A 是很实在的。

之前猜测的结论基本都成立。

SPL 在小数据量上的复杂计算上仍然能占到便宜，但 Java 产生对象和计算上又吃点亏，总体结果和 Oracle 相比仍有优势但很小，可以算基本持平。这也和之前预计的一样。

OceanBase 在这个测试中表现的性能相对较弱，原因有可能如上述测试报告所言，开源版和用于打榜的企业版有差距，开源版中没有提供较好的 SQL 优化引擎，当然也有可能 OceanBase 的优化确实还不够好，因为 OceanBase 之前并没有作为 OLAP 数据库发展，在这方面下的功夫不够也算正常。而 TiDB 从事 HTAP 数据库已经有一段时间了，SQL 优化方面的积累相对丰富也不奇怪。至于 SPL，则是用不同的代码直接实现高性能算法（代码量其实比 SQL 更小），不会出现数据库优化引擎找不到合理执行路径的现象，所以虽然低层用 Java 实现却仍然能获得较好的运算性能，不过对程序员的要求会稍高一些。