TPCH10G 测试：OceanBase TiDB Oracle SPL
前几天听说 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。结果如下：
| 单位：秒 | TiDB | OceanBase | Oracle | SPL |
| 96*2.4G | 96*2.4G | 12*1.7G | 12*1.7G | |
| Q1 | 0.82 | 2.82 | 2.93 | 3.74 |
| Q2 | 0.42 | 1.17 | 0.63 | 0.62 |
| Q3 | 0.43 | 1.90 | 2.14 | 1.87 |
| Q4 | 0.37 | 2.63 | 1.62 | 1.37 |
| Q5 | 0.61 | 3.37 | 3.34 | 2.15 |
| Q6 | 0.12 | 1.64 | 0.88 | 0.97 |
| Q7 | 0.32 | 2.86 | 15.90* | 2.32 |
| Q8 | 0.66 | 3.04 | 1.88 | 2.22 |
| Q9 | 1.39 | 6.56 | 5.62 | 6.78 |
| Q10 | 0.72 | 1.90 | 4.35* | 1.72 |
| Q11 | 0.29 | 0.63 | 0.30 | 0.70 |
| Q12 | 0.27 | 1.41 | 1.63 | 1.98 |
| Q13 | 0.46 | 1.29 | 2.35 | 6.49 |
| Q14 | 0.26 | 0.43 | 1.09 | 1.31 |
| Q15 | 0.31 | 1.27 | 1.28 | 1.36 |
| Q16 | 0.29 | 0.75 | 1.06 | 1.33 |
| Q17 | 0.78 | 6.51 | 1.26 | 1.79 |
| Q18 | 0.94 | 1.55 | 8.65* | 1.64 |
| Q19 | 0.35 | 1.98 | 2.30 | 1.99 |
| Q20 | 0.47 | 5.94 | 2.83 | 1.70 |
| Q21 | 0.90 | 3.21 | 3.56 | 3.12 |
| Q22 | 0.23 | 0.86 | 0.63 | 1.50 |
| SUM | 11.41 | 53.72 | 66.23 | 48.64 |
（前两列测试结果来自上述的测试报告）
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 实现却仍然能获得较好的运算性能，不过对程序员的要求会稍高一些。
