估计很多做数据库选型的同学们，都纠结过这个问题。

那些 Doris 阵营的同学，一定会告诉你：选 Doris，我们是多么多么牛逼，吧啦吧啦之类。

而那些偏爱 Clickhouse(下称CK) 的同学，也一定会告诉你：选 CK 吧，我们快，吧啦吧啦之类。

如果这两个声音同时出现，你会听谁的？是不是就懵逼了。

0. 关于技术选型

其实这种技术选型的问题，明白人都知道，任何人都没有办法替你做选择，你能做的，就是基于你当前真实的数据现状，搞清楚自己想实现的业务目的。

然后倒推技术实现的过程，再看这个过程中，会涉及到哪些步骤，数据怎么接入？怎么计算？离线还是实时，或者两者兼具，然后数据怎么存储等等。

基础流程大致确定了，再看对应的流程需要用到哪些技术，而功能类似的技术如果拿不定主意，最靠谱的办法，就是基于你当前的业务要求，去亲自做选型测试，既正规又专业。

不要去听信那些营销爽文，为了打广告，就没有他们吹不出来的牛逼，而那些跟复读机一样的跟风水文，如果你没有基础的判断力，还是少看为妙。

1. 关于 Doris 跟 CK

拉回到正片，关注我这个号的同学应该知道，对于 Doris 跟 CK 的使用体验，到目前为止我应该有一年时间了。

在使用这两款数据库的过程中，针对任何一个功能点，我都会有意无意地拿这两款数据库做对比，顺道也写了很多篇关于 Doris 跟 CK 对比的文章，有兴趣的同学可以去翻翻。

随着对比的越深入，就越发现一个真相，没有谁是全方位的好，也没有谁是全方位的孬，有的只是「各有千秋」。

如果分别用一句话来形容这两款数据库的特点，那就是：

CK：从数据库核心功能这个维度来说，它表现得更加成熟一些，毕竟它出现的时间更早；

Doris：从数据库生态的丰富性这个角度来说，Doris 则更胜一筹。

下面，就根据我这一年来，对这两款数据库的实测体验，谈谈我的个人看法。

2. 两者的相同点

既然同为数据库，那么就必然存在一些相同的地方。

1，都是当下比较流行的，可以用来存储大数据量的，且同时能满足高效查询需求的 SQL 数据库；

2，都提供了多种表引擎，或者表模型，来满足不同需求下的数据存储需求，以及类似的索引原理和压缩方式，来解决数据的查询效率和存储效率问题；

3，社区都很活跃，关注度都很高，项目都没有烂尾。

3. 两者的不同点

3.1 Doris 比 CK 强的地方

1. 软件架构上：Doris 是典型的 master/slaver 集群架构，天生的 cluster 模式，而 CK 是原生的单节点模式，想要实现cluster，需要通过创建分布式表，同时还要借助 ZK (或者自带的 keeper 服务)这种手动方式，将多个单节点 CK 实例连接起来实现，对比之下，Doris 的架构更智能一些；

2. 建表方式的不同：正是因为第1点的架构不一样，就直接导致了这两款数据库在建表时玩法的差异，对于 Doris 来说，你创建的表，除非刻意通用参数指定，否则这张表默认就是分布式的，且带数据带冗余的。

而 CK 的情况则恰恰相反，默认情况下你建的表，是单机的本地表，数据没有分片，也没有冗余，除非你用特定参数来指定。而且，如果要创建数据分布在多台机器上的分片表，要涉及到多个建表、以及设置 zk 参数的必要步骤，创建过程要比 Doris 繁琐；

3. 从对接上下游组件和数据源的生态上：Doris提供了更丰富好用的工具和接口(对接 Spark 跟 Flink 更友好一点)，相比之下 CK 就要弱一些，比如前几天对比的，对同一个数据源的入库方案，Doris 提供的方式既多又快，而 CK 提供的方案少不说，还慢；

4. 从对集群的管理角度来看：Doris 有专门的 Doris Manager 这款可以管理集群的工具，虽然有同学觉得这个工具没什么卵用，但我用过它来升级 Doris 集群，虽然这款工具本身，我认为在设计上有瑕疵，但确实能够让集群升级这件事情变得更简单方便，而反观 CK，好像就没有这个便利。

3.2 CK 比 Doris 强的地方

1. 从查询的极致效率上来看：相同的业务数据，相同的索引方式以及数据量，绝大部分情况下，无论是本地表，还是分片表，CK 的查询效率都要比 Doris 高；

2. 在识别 SQL 的智能程度上：同样的一个SQL，对同一张表进行查询时，CK 明显要聪明得多，只要 SQL 不出现明显的语法错误，它基本上都能领会我的意思，让人欣喜。

而 Doris，如果这个 SQL 稍微复杂一点点，要么它会误解我的意思，得出错误的查询结果，要么就干脆抛一个解析异常的错误，表现得很木讷，非常讨厌；

3. 从数据库的查询交互方式来看：我个人非常喜欢 CK 那种既能显示查询进度，又能在查询过程中显示耗费的硬件资源这种设计，而反观 Doris 的交换界面，就很寡淡，索然无味。

4. 核心功能的成熟度上：所有这两款数据库都具备的功能，比如字段类型、函数、物化视图等等，从体验上来看，CK 像一位相对稳重的中年人，而 Doris，则更像一个迈出大学校门不久的学生，虽然意气风发，但也一身稚嫩。

4. 两个有争议的地方

对于这两款数据库，我听到最多的，有这两个说法：一个是 Doris 更好运维，使用更简单；另一个说法是 CK 的join 支持的不好。

先说 Doris 更好运维这件事：

如果你把运维只是单纯的理解为对数据库的上手难度，以及如果不能对一款数据有比较深入的理解，就不能用好它基础功能的话，那这句话没毛病。

而如果你的思路再打开一点，对于一款数据库来说，能提供高效、稳定、少 bug 的运行状态，让你在使用过程中，少碰到些糟心的破事，也算是对运维的贡献的话，那这句话就未必正确。

再说 CK 的 join 支持不如 Doris：

对于这个问题，我专门实测对比过，基于我当时的场景跟测试结论来看，这个说法就不成立。

当时我 join 的方式相对比较简单，可能说服力不够强，但是，至少能说明一点，CK 的 join 能力没有 Doris 强这个结论，并不总是对的，不要人云亦云。 

最后

从上面列出的优缺点对比来看，貌似 Doris 跟 CK 打平了(4:4)，但如果你因此得出结论，说 Doris 跟 CK 一样，那就未免过于肤浅了。

要知道，在面对一款数据库的选择时，你要关注你更在意什么，哪些是你的必选项，哪些又是你可以忽略的。

如果你对生态的兼容性更加看重(比如项目数据源众多，数据需要各种导来导去)，但对于查询体验的极致性(效率+功能)没有过多要求，可以考虑 Doris。

而如果你对查询体验很苛刻(效率+功能)，且没有那么多乱八七糟的数据源接入需要，可以考虑 CK。

另外，还有一个真相就是，对于很多数据项目来说(甚至是大部分)，不管是 Doris 还是 CK ，其实都能满足你的业务需求，关键在于，你能不能玩得转。

关于 Doris 跟 CK，其实还有很多内容可以聊，但限于篇幅所限，先这样吧。