一、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% 左右。