数据存储新势力：Doris如何挑战ClickHouse的霸主地位？
前些年人们说起日志存储，不自觉会拿ElasticSearch和ClickHouse进行对比，近几年人们不大说ES了，ClickHouse更多时候，成了Doris的对标对象，而ClickHouse也从昔日的屠龙者，成长为了他人眼中的巨龙。
作为深耕运维领域多年的擎创科技，见证了数据存储引擎的改朝换代，荣辱兴衰。本文就来聊一聊为什么ClickHouse注定会取代ES，而Doris又为何能在如日中天的CK的手中，夺得大数据城池的半壁江山。
基础属性
三者虽然都号称开源，但开源程度各有不同，Doris社区版和商业版功能基本对齐，ClickHouse的Cloud版本则增加了许多社区版本没有的新功能。从信创适配角度来说，Doris由于是国人开发，血脉上天生优人一等。但Doris比较ClickHouse的劣势在于，安全漏洞比较多，这几乎是Java系应用的通病，对于要求比较严格的金融客户，往往会因为安全漏洞扫描不过关，造成上线困难，而其社区开源的属性，如果依赖官方修复漏洞，则周期太长，从而造成成本巨大而不可控。
性能与资源查询能力
综合查询能力来说，Doris比较平均，上限不高，但下限也不低，ClickHouse在单表和聚合查询场景的极致性能堪称无敌，但在多并发查询、多表join和模糊查询的场景又弱得离谱（在最新版本已经有所增强）。ES最令人津津乐道的倒排索引能力纵横江湖多年，任他风吹浪打，依旧独孤求败。
ClickHouse真正的杀手锏是跨数据中心查询能力，Doris和ES虽然可以通过外部数据源的方式从一个集群查询到另一个集群的数据，但无法像CK那样，通过一条SQL举重若轻地将多个集群数据一把查询出来。
存储能力
无论是写入速度，还是压缩比，ES和前两者都不是一桌的玩家，我们虽然通过程序的极致优化，将Doris的写入性能提升到150万条数据每秒，但它是服务端攒批，异步写入，这意味着数据写入后可能需要隔一会儿才能看到，与clickhouse_sinker的所见即所得，在体验上还是有着本质的区别。而从压缩比来看，clickhouse比之Doris，几乎有着倍数级领先。
Doris和CK在存储策略的设计理念上有所不同。
Doris通过提出RESOURCE和POLICY的概念，仅靠SQL的轻量级操作，即可完成生命周期的创建和管理。但它的问题在于，生命周期的设置依赖存储时间(VisiableVersionTime)，而不是业务时间，而且表一旦关联上某个资源，再也无法删除。
ClickHouse的生命周期则通过Disk和Policy实现，它的理念是一切存储皆磁盘。这就意味着，数据可以随意在磁盘间移动，也就不存在磁盘一旦关联上就不能删除的问题。且可以自己指定时间字段进行生命周期的管理，比之Doris更加灵活。但它也有自己的不足，由于它的底层逻辑是磁盘，所以任何disk的变动，都需要修改配置，重启服务，且一旦某个磁盘挂掉了，很可能造成服务无法正常启动。
资源管理
在资源占用和资源隔离以及限额方面，ClickHouse和Doris的表现均可圈可点，Doris在某些方面做得更加精细一点，这一回合，姑且算作平手吧。
运维与扩展
Doris得益于本身的BE、FE的极简架构，部署简单，上手快，完全兼容MYSQL协议，对开发者非常友好。
总结
Doris和ClickHouse之争，有点像自动挡汽车和手动挡性能跑车之间的较量。Doris作为国人开发的数据库，秉承着中国人“中庸”的思想，什么都想做，什么都是中上等，既不冒尖，也没有特别明显的短板。而ClickHouse作为手动挡跑车，会调教的人觉得强得离谱，不会用的人甚至觉得不如MySQL。它是典型的偏科生，在擅长的领域一骑绝尘，而在某些短板场景，又令人无法直视。
而随着可观测领域的逐渐火热，CK已经成为了Metric、APM存储的标杆性代表， 被很多知名互联网公司推广并使用。人们聊起可观测时，与CK进行对比的，往往是VictoriaMetrics而不是Doris，由此可见，虽然Doris也开始在可观测场景上发力，但除了日志做得相对完善之外，其他的还有很长的路要走。
在擎创的产品体系中，我们并不是一家专注于数据库存储优化的公司，而是借数据库为载体，让数据发挥出其最大的价值。因此，我们并没有执着于某个数据库，进而排斥其他的存储引擎。而是通过统一查询层的入口，屏蔽所有存储层，完成对不同数据库的检索查询。这种解耦的设计的好处是，可以适配包括ES、CK、Doris在内的多种数据库选型，更好地接入客户已有的技术架构体系（比如客户更熟悉ES，或者已经有现成的ClickHouse集群，就可以无缝接入），更为未来可能出现的更强的数据存储引擎提供了灵活的可扩展空间。