做一次标题党，其实我们做软件的当然没办法改变芯片的性能，也不可能真地让国产芯片超越 Intel。

这个话题从去年做过的一次性能测试说起，先看测试结果：

这些题目原本是某大用户在选型数据库时用于评测性能的。给定了数据（结构和规模）和 SQL，在同样的硬件环境下让各家数据库都跑一下，看谁的速度最快。

我们从中选择了几个耗时最长的 SQL，再做了少量补充。然后准备了两组集群，一组用 Intel 芯片，另一组用国产飞腾芯片，安装好分布式数据库和集算器，并在数据库中生成测试数据。

1. 用 SQL 在数据库中执行，记录时长；

2. 将 SQL 改写成 SPL（这有些工作量，涉及到算法更改），但仍读取数据库中数据计算，记录时长；

3. 将数据导出到文件，使用集算器特有的组表格式存储，再改写 SPL（更换数据源，使用组表数据源会比使用数据库源更简单）计算，记录时长；

然后就得到了上面那个测试结果表。

还有几点说明：

1. 我们刻意选择了一些在原评测中耗时最长的 SQL（几乎都 >1 小时），所以这里看到的数据库上跑 SQL 的性能都较差；原测试中也有几条能跑得很快的 SQL，但这里没有选用。

2. 原评测中要求只要返回第一批数据即可，不需要返回全部结果集，这里延用了此规则，但我们补充了一些题目，在其中确保必须把涉及数据全部遍历到才可能计算出结果（比如增加 GROUP BY 和 ORDER BY），这样可以更有效地测试遍历性能。

3. 飞腾上数据库的运算性能和 Intel 上差不多，也不是关注重点，没有再列出了。

4. 前两题用 SPL 读数据库的性能已经非常好，所以没再做读文件的测试了。

从测试结果可以看出：

1. 在 Intel 机上，用 SPL 读文件的计算性能远远超过数据库用 SQL 的计算性能，即使用 SPL 读数据库运算也常常能获得比在数据库中用 SQL 好得多的性能，这还是在付出了数据库 IO 成本的代价之后的结果。

2. 在飞腾上的 SPL 读文件的计算性能也远远超过在 Intel 上数据库的计算性能，在飞腾上用 SPL 读数据库也比 Intel 上的纯数据库计算有优势。

那么，SPL 是怎么做到高性能的？

就是我们常说的办法，SPL 可以采用更高性能的算法，而 SQL 不可以。

这些题目都不是非常简单的两三行 SQL，基本都带有子查询或较多表的 JOIN。在充分理解数据特征之后，我们可以设计出更低成本的算法，把运算复杂度降低一个到几个数量级。在这里主要是对有序的利用，SPL 的理论体系是基于有序集合的，可以充分利用数据有序的特征来提高性能，而 SQL 就很难利用这一点，即使知道有好办法优化也无法实施。

这篇文章里不合适解释每个问题的算法了，我们以后会写文章再披露详细的测试过程与算法说明。这里有一篇对前两题的算法解析《 利用有序高效实施交并差集合运算 》。（其中有个 SPL 跑得也不快的场景就没有写到测试结果表里了:)）

现在可以解释标题中说的怎样让国产芯片性能超越 Intel 了，芯片本身的性能并没有超越，超越的是算法。具体来说，就是用 SPL 在低性能芯片上跑高性能算法，能超越 SQL 在高性能芯片上跑低性能算法。而用 SPL 在 Intel 芯片上跑高性能算法，当然还能获得比飞腾更好的性能。

就我们的工作经验来看，绝大多数的数据仓库运算都可以获得这种优化。只要写出的 SQL 够长够复杂，基本都有不少可优化的环节。如果我们用 SPL 来重构数据仓库，就可能把现有运算性能再提高一个数量级。

这个测试结果表上还可以看出两个结论：

1. 读数据库显然比读文件的性能要差很多。这是因为数据库 IO 成本很高，而且很难做高效的压缩。要想获得最高性能，尽量不要把数据存到数据库中。象我们在另一篇文章《数据库的封闭性》中说的，未来的数据仓库不必要有“库”这么个形式。

2. 飞腾上 SPL 的性能并没有比 Intel 差出数量级（传说飞腾落后 5 年，按摩尔定律，差不多有一个数量级）。数据密集型的计算性能，起决定性作用的常常是硬盘和内存，而不是 CPU。我不知道这组设备的飞腾芯片到底和 Intel 差多少，但即使有差距，也不会造成整体性能上数量级的下降，做好存储方面的优化要比 CPU 重要。