ClickHouse对比StarRocks

网友投稿 2470 2022-10-10

ClickHouse对比StarRocks

ClickHouse对比StarRocks

一、ClickHouse的瓶颈

伴随业务运⾏了一段时间,但随着使⽤平台的⽤户⽇渐增多,业务⽅需要查询的数据量也越来越⼤,业务场景变得复杂后,很多特定场景 ClickHouse ⽆法满⾜,⾯对不同⼈员⾓⾊的需求时也遇到一些瓶颈。同时我们分别从业务⽤户的⾓度,以及平台运维的⾓度发现了以下问题:

从⽤户⾓度

一⻚分析看板上往往有 6-8 个图表,这些图表的查询请求都是同时发给 ClickHouse 的。但是在多并发的场景,ClickHouse 的查询性能下降的很快,平时一个 1-2s 左右的查询,在 8 个并发下就可能把 CPU 吃满,平均响应时间退化 4 倍左右,降到 8-10s,对看板的⾸⻚加载时间,以及交互分析的体验影响都⽐较⼤;

平台⽀持数据表的关联查询,但是 ClickHouse 的多表关联查询性能⽋佳,涉及 Join 的查询往往都需要 10s 以上,数据量⼤的查询甚⾄直接超时⽆法返回结果

从运维⾓度

ClickHouse 不⽀持事务性的 DDL 与 DML 操作,⽽且多副本模式的元数据管理强依赖于 ZooKeeper,表结构变更时常常出现不同副本之间元数据不一致的问题,往往定位到最后都是 ZooKeeper 的原因,排查、运维的成本都⽐较⾼;

随着数据量的增多,集群需要扩容时,ClickHouse 缺少⾃动的 Resharding 机制,横向扩容时需要借助第三⽅⼯具或者⼿动 Reshard,成本⽐较⾼。

针对前⾯提到的实时场景,我们在使⽤ ClickHouse 的 Replacing 引擎中也遇到一些痛点:

查询慢,Replacing 引擎使⽤的是 Merge-On-Read 的模式,数据写⼊时保存多个版本,在查询时需要指定 FINAL 关键字进⾏去重取出最新版本的数据。这导致对于 Replacing 引擎表的查询,SQL 中的谓词⽆法下推,同时在低版本的 ClickHouse 中,对于 FINAL 语义的查询也不⽀持多线程处理,⼏乎每次查询都需要单线程扫描全表数据,涉及 Replacing 引擎的查询响应时间往往在 10s 以上;Replacing 引擎只⽀持数据的更新,并不⽀持数据的删除。对于 Delete 操作,当前的做法是通过额外字段来标记当前数据是否已经被删除,同时借助 TTL 功能来定时清除已经被删除的数据。这样一⽅⾯需要额外的定制处理,另一⽅⾯新增的标记字段进一步拖慢了查询的性能;Replacing 引擎只能对同一分⽚上同一分区的数据去重,这意味着我们在设计表分区时,以及写⼊数据时,都需要做⼩⼼的处理,增加了开发的成本。

上⾯描述的问题中,有一些涉及 ClickHouse 底层的缺陷,有一些场景利⽤ ClickHouse 提供的其他引擎或者 MaterializedView 等特性可以做一些定制的优化,但是掣肘于平台分析查询场景的多样性,我们很难做一些通⽤性的优化。

二、StartRocks的优势

注:如下的优势刚好是clickhouse比较欠缺的部分

⽀持多并发查询,部分场景可以达到 1 万以上 QPS;⽀持 Shuffle Join,Colocate Join 等多种分布式 Join ⽅式,多表关联性能更优;⽀持事务性的 DDL 与 DML 操作,兼容 MySQL 协议;FE、BE 架构简单,不依赖外部组件,运维更加简单;数据⾃动均衡,集群随业务增⻓⽔平扩展⽅便。

三、ClickHouse与StarRocks的对比测试

单表⽆并发的场景,除个别 SQL 外,StarRocks 的查询速度与 ClickHouse 基本持平,但是 StarRocks 的 CPU 负载偏低,是 ClickHouse 的 25%~50%;单表多并发的场景,除个别 SQL 外,StarRocks 的平均查询速度⽐ ClickHouse 快 1.8 倍;多表关联⽆并发的场景,StarRocks 平均⽐ ClickHouse 快 1.8 倍;多表关联多并发的场景,StarRocks 平均⽐ ClickHouse 快 8 倍;数据实时写⼊实时查询的场景,不同的查询场景下,StarRocks 的 Primary Key 模型查询速度⽐ ClickHouse 的 Replacing 引擎快 3~10 倍,且查询性能较 ClickHouse 更加稳定(Replacing 引擎由于后台不断地 Merge 操作,查询的性能会随底表数据量的起伏对应地波动);数据批量导⼊的场景,我们⽐较了不同批次⼤⼩下的写⼊性能,StarRocks 的写⼊速率平均⽐ ClickHouse 要慢 20%~30% 左右。

1.作者:Syw

3.如果文中有什么错误,欢迎指出。以免更多的人被误导。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:微信小程序开发规范化插件 for mpvue(微信小程序前端开发工具)
下一篇:elasticsearch索引的创建过程index create逻辑分析
相关文章

 发表评论

暂时没有评论,来抢沙发吧~