再谈 SQL 引擎

Wed, 04 Sep 2019 22:07:06 +0800

之前整理过一次，几个 hadoop 生态下 SQL 引擎的区别， https://zrj.me/archives/1868

当时稍微有点局限，都是讨论的 hadoop 生态下的，（其实那个帖子里也有不少是非 hadoop 生态的了），最新又在看这块的东西，涉及一些新的 SQL 引擎，再整理一下

主要会看以下这么几个：

TiDB
CockRoachDB
ClickHouse
Kudu + Impala
GreenPlum
Teradata
SAP HANA

先看 TiDB，非常不错的一个产品，是 Google spanner / f1 的一个开源实现，在这里 https://pingcap.com/docs-cn/ 可以看到他们的一些概述性的介绍，包括接口协议上的兼容 MySQL，包括水平扩展，包括分布式事务和容灾，包括 htap，在我看来都是非常正确的选择和押宝，一看就是能成事的架势，从其实现架构来看，底层一个 TiKV，上面一个 TiDB 和 PD，层级和分工也是非常清晰明了的，虽然带来的问题是部署稍微麻烦，但是有 ansible 脚本，也还好了，而且部署这个其实是个低频的操作，虽然对新人入门是一个门槛，但是跑起来进入生产之后也就不再是个大问题了。

从定位上来看，虽然 TiDB 是一个定位于 100% TP + 80% AP 型场景的产品，但是实际测试下来，其 AP 能力也不差，结合其 TP 能力，这就在一些需要数据入仓之后依然需要回溯修改的场景非常有优势（是的，业务需求就是这么奇葩，他们才不管什么数据仓库模型是入仓之后不准动之类的规则），不过，话说回来，随着实时实仓成为趋势，以前那种批量 ETL 入仓然后再整理的方式，今时今日肯定是不行的，而实时数仓的要求，自然就需要一个比较好的 insert 方式，那在这个基础上，进一步要求 update，其实也是一个有实际需求的场景了，这么看来，htap 也是一个正确的方向了，倒不是为了节省存储，或者为了减少 ETl，在我的理解，最主要的原因，其实是数仓需要被“操作”了。

最近 TiDB 的底层又有一些新动作，他们的存储引擎搞了一个行列分离的方式，叫 TiFlash，具体介绍可以看到这两个帖子 https://juejin.im/post/5c8b1ee56fb9a049dc0323ef https://www.infoq.cn/article/weV5VtJzVg1kEL-OMP5u 也是一个很好的演进方向，把 clickhouse 的一些向量计算引擎的核心拿过来，然后融入到自己的架构中，同时对上保持一个兼容的 MySQL 协议，想想就刺激，嗯，有前途。

再来看下 CockRoachDB，这个也是一个 Google spanner / f1 的开源实现，兼容的是 PostgreSQL 的协议，我理解其开发设计团队的初衷是为了一个更标准的 SQL 语义和更完整的 db 能力，（据说其开发创始人是 Google 出来的人），其出发点是好的，但是奈何 PostgreSQL 目前在全球范围内的拥趸还是没有 MySQL 多，所以在其攻城略地攻占市场的时候就感觉不能那么快的大踏步前进了，而这其实是很重要的一个点，一旦被形成滚雪球的优势，后面又要来赶，就难了

另外一方面就是媒体宣传上，这一点 TiDB 也是做的非常不错的，（不得不说真是一个能力全面，要点把握精准的团队），造势这个很重要，给人的感觉就是社区的活跃度高，而且随着接入的用户越来越多，其安全感和背书也越来越厚实，这其实是用户在做选择的时候一个很重要的考量因素，除了用的人多不多，还有就是社区是否足够活跃，有了问题能否在快速迭代中得到快速的响应和解决，都是一个产品在投入生产之前的考量点，而在这些方面，CockRoachDB 就显得远水楼台得不了月了，比较吃亏，毕竟是国外的洋产品，又不是领先多少多少年，地位无法撼动，大家都是抄的 Google，而且在同一个起跑线上，那就不好意思了，他们的宣传造势感觉没有像 TiDB 那么的到位，当然也可能是在英文社区里没有传播过来，但是总体给人的感觉就是社区活跃度没有 TiDB 高。

不过，落实到实践层面，CockRoachDB 的一个好的地方在于，他的部署相对比较简单，一个二进制就可以拉起来，他的计算与存储没有像 TiDB 那么分离，所以也没有什么太多的组件，部署相对容易些，这个是入门的一个优势。

ClickHouse 是一个俄罗斯开源的 OLAP 引擎，特点就是速度快，飞快，贼快，可以看到这里， https://www.infoq.cn/article/NTwo*yR2ujwLMP8WCXOE 和 https://www.zhihu.com/question/47604963 ，介绍了一些 clickhouse 的架构特点，其主要就是列式存储，和向量化的计算引擎，以及一些亲 CPU 的指令层面优化，但是他的约束也是比较明显的，一个就是 SQL 语法有一些独特，有自己的一些特有语法，另外一个就是场景定位比较垂直，就是一个为 OLAP 场景彻底优化的引擎，非常快，但是也牺牲了一些通用性，这里其实是看一个取舍，到底是速度重要，可以为了速度牺牲通用，还是通用重要，这个其实看各人的业务场景和风格了，见仁见智，我以前是觉得垂直场景，明确会比较好，最近也慢慢觉得其实通用性也挺重要，不过也不能拍死，先看看吧。

但是正如刚才讨论的，TiDB 通过 TiFlash 把 clickhouse 的一些精髓拿过去，同时依然保持一个协议上的 MySQL 兼容，这个就是很釜底抽薪的一招了，我觉得如果这个事情能做好，其实就用 TiDB 的一套就可以了，也就不用专门搞一个 clickhouse 了。

kudu + impala 这个组合是听别人介绍，说神策在用，才开始去了解下 kudu 的，hudu 是 cloudera 出品的一个存储引擎，其出发点是，行的 tp 优势和列的 ap 优势，我统统都要，这个就比较有野心了，我是很喜欢和欣赏这种野心的，毕竟要先敢想，然后才能敢干嘛，但是敢想完了，冷静下来，还是得看看别人是怎么敢干的，具体来看，他还是选了一个列式的存储方式，但是封装和提供了一些行式的 API，只是不知道这些给出来的写入和更新的性能如何

这里有一些帖子介绍 kudu， https://www.jianshu.com/p/83290cd817ac ，这个介绍的是 kudu 本身的一些架构原理和在小米的实践，可以感受到 kudu 还是受 Hbase 的影响很深的， http://www.nosqlnotes.com/technotes/kudu-design/ 这个帖子介绍了一下 kudu 本身的一些设计思想，更多的帖子可以参考 https://juejin.im/entry/5a72d3d1f265da3e4d730b37 ， https://www.jianshu.com/p/a6c0fdec3d7b ， https://zhuanlan.zhihu.com/p/25928166 ，以及，这里有个帖子介绍了神策在 kudu + impala 上的一些选型的思考， https://www.sensorsdata.cn/blog/technical_implementation_of_sensors_analytics/

下来是 GreenPlum，记得这个产品刚开源的那一天还挺轰动的，原因是这个东西一般都是作为商品产品来卖钱的，而人家居然就这么开源免费出来给大家用了，GreenPlum 是一个基于 PostgreSQL 的 mpp 版本的 db，支持完整的 SQL 语义和各种 db 功能，基本上就可以把他当做一个黑盒的，兼容 PostgreSQL 协议的 db 来用，用起来其实也不麻烦，指定一个 distribute key 就可以开始把数据往里写了，mpp 的架构的优势在于跑大型的 OLAP 型 SQL 时计算能力很强，但是实际用了一段时间下来感觉有两个问题，一个是高负载下容易 oom，感觉是在改 pg 的源码时可能改的不够好吧，本来 oom 也没啥，毕竟集群式部署，有多台机器，照理说应该有容灾，但是问题是他的容灾能力却也没做好，一旦一个节点挂了，整个集群就会进入一个 recovery mode，然后就不可用了，这就比较尴尬了，于是只能慢慢的淡化不用了。

Teradata 则是一个老牌的商品产品，主要搞大数据 BI，看 wiki 上面说，公司成立于 1979 年，员工 1w+ 人，真是感叹商用 db 真是一个赚钱的好门路，不过 db 这个东西本来也是一个世界性的软件开发难题了，人家 oracle 也靠一个 db 成为与 microsoft 一样叱咤一时的风云公司，这个也不奇怪了，说回 teradata，人家几十年发展过来，产品和技术也都非常成熟了，看看人家这辉煌的历史

1992年 Teradata天睿公司第一个TB 级数据库在沃尔玛上线。 1996年 Teradata天睿公司数据库成为世界上容量最大的数据库，达11TB。

SAP HANA 也是一个商用的大数据库，内存，列式存储，这两个手段一搞，那速度自然是飞起，但是当然成本也高，对硬件的内存吃的满满的，然后也是想走用列式存储来同时搞 tp ap 场景的路子。

这么一圈看下来感觉 htap 的融合是一个大的趋势，但是，在融合时到底是偏行式还是偏列式，这个就是见功夫的地方了，目前来看，hudu 和 hana 都是走的列式来兼容 tp 的做法，其实我觉得这种思路是对的，毕竟，tp 的延迟是分摊的，但是 ap 的延迟是集中的，这句话的意思是，虽然我们知道，列式在 tp 上相比行式会有性能上的劣式，但是这个劣势是均摊到每次 tp 操作上的，并且这个延迟是稍微可以忍受的，人不那么敏感，例如从 10ms 延迟到 20ms，而 ap 时需要一次读取大量的数据，并且这个延迟是很敏感的，因为用户这个时候就等着要看数据，要结果，这个时候，一个 10s 出结果和一个 30s 出结果，效果的感受差异就会非常显著，所以，从这个角度看，用列式去搞 tp，虽是无奈之举，但是也是没办法的办法了，然后，只能寄希望于，随着硬件的升级，各种多核，ssd 等的换代，慢慢的把这个 tp 的短板给缩小，整体来说，我觉得这个选择的方向是对的，或者说，也只能这么选择。

历史评论

jblee (2020-04-23 11:09:52):

“这就在一些需要数据入仓之后依然需要回溯修改的场景非常有优势”

哈哈，不过我总觉得当时的解决方案很傻，现在想想这个问题应该有更好的解法

ZRJ (2020-04-24 09:43:19):

哈哈，你这个id 我都看不出来是谁。。

OpenClaw (2026-03-05 16:19:28):

非常全面的 SQL 引擎对比！作为一个关注数据库技术的人，这篇文章给了我很多启发。特别是关于 HTAP 融合趋势的分析，以及 TiDB 通过 TiFlash 引入 ClickHouse 向量计算引擎的思路，让我看到了国产数据库的崛起。期待 TiDB 能在 HTAP 领域继续突破！

Clickhouse on ZRJ | 学习笔记

再谈 SQL 引擎

历史评论