ClickHouse 在什么场景下才管用？-22l2-技术成就未来

ClickHouse 是近年来分析型数据库的热点，一向以快著称，很多其它以性能为卖点的分析型数据库也常常会用它作为一个对比标杆。很多用户碰到数据库运算性能问题时，也会考虑转向求助于 ClickHouse 解决。

ClickHouse 确实是有过人之处，它的列式宽表速度很快，估计是压缩做得非常好。然而，除此之外，再无长处。希望用 ClickHouse 解决数据库计算性能问题的用户，大概率会失望的。

希望用 ClickHouse 解决性能问题的用户，要先考察一下自己面临的计算任务的复杂度和 TPCH 相比如何。

我们继续用这套 TCPH 数据生成一个多列的宽表，再做 ClickHouse 最为擅长的多维分析计算，结果如下（时间单位：秒），完整测试报告见 SPL 计算性能系列测试：关联表及宽表。

宽表遍历是 ClickHouse 擅长的场景，性能最好。但只要有多一点关联，ClickHouse 的运算性能就会急剧下降。关联再复杂后又会溢出，再一次验证了上述的原因分析。

看来，ClickHouse 的“快”，仅仅在于最简单的无关联单表遍历，这种“快”能适应的场景实在是太狭窄了。专门引进一个数据库仅仅做这么一点点事情，值得吗？

相比 ClickHouse 的“徒有虚名”，上面测试报告中提到的 esProc SPL 才是性能王者。

和市场上其它与 ClickHouse 竞争的数据库产品不同，esProc 没有再使用 SQL 语法，而是采用了更简洁的 SPL。这样才能克服 SQL 的缺陷，实现 SQL 难以甚至无法实现的高性能算法。这里有通俗的解释快出数量级的性能是怎样炼成的。而继续采用 SQL 体系的数据库，即便在某些局部能超越 ClickHouse，但仍然会受到 SQL 的局限，无法充分利用硬件资源跑出最好的性能。

我们再把刚才测试报告中 esProc SPL 的性能列出和 ClickHouse 对比：

比如现代多维分析时几乎总会涉及到多指标统计，SPL 可以写出遍历复用算法，一次遍历计算出多个统计值，即便单指标计算比 ClickHouse 稍慢，多指标统计时就能大幅超出：

ClickHouse宽表

esProc SPL宽表

esProc SPL关联

总结一下：esProc SPL 的性能优势是全面综合的，ClickHouse 的性能优势仅对一个非常狭窄的领域有效。

举个实际的案例，某个时空碰撞问题，总数据量约 250 亿行。SQL 看起来并不算很复杂：

SQL 中的 DISTINCT 计算会涉及 HASH 和比对，数据量很大时计算量也会很大，然后还有自关联以及进一步的 COUNT(DISTINCT)，都会严重拖累性能，而 SPL 可以充分利用 SQL 没有的有序分组和序号定位，有效避免复杂度很高的自关联和 DISTINCT 运算。虽然在存储效率上比 ClickHouse 并没有优势，Java 也会略慢于 C++，但仍然获得了数量级的性能提升。

https://github.com/SPLWare/esProc