背景
Starrocks和clickhouse都是非常优秀的OLAP数据库，那么什么情况下使用clickhouse，什么场景下使用starrocks呢，本文就简单列举一下他们的优缺点
理由
首先两者都是列存储，并且都实现了列压缩，所以从存储中两者的压缩比是差不多的，所以对应的I/O消耗也是相差不大的
介绍一下Starrocks计算资源的底层实现：
- MPP并行查询，可以充分利用多台机器的资源
- 单机通过pineline并行执行，充分利用单机的多线程资源
- 单核CPU利用SIMD向量化进行查询
备注： Starrocks的MPP并行是设计之初就完善好的，他自身支持动态扩展
对应的clickhouse计算资源的底层实现: - 可以通过分布式表的方式利用多台机器的资源
- 单机利用多核的实现利用的不够充分
- 单核CPU利用SIMD向量化进行查询
备注：clickhouse严格来说是单机数据库，他的分布式的实现都需要手动完成
OK，回到最初的问题，对于Starrocks来说，分布式的实现从设计之初就已经完成，而clickhouse分布式完全是通过手动的方式应用方组装起来的，使用起来非常不方便，我们列举下使用Starrocks替换Clickhouse的几个理由
1.如果我们的表可以做成中等大小的宽表的，那么使用Starrocks和Clickhouse的实现都无所谓，两者的性能都很出色
2.starrocks具有主键表，这个是真正拥有去重能力的表，同一个主键的数据合并虽然也是延迟进行(磁盘还是占用)，但是查询的时候也会进行过滤获取最新版本的主键记录，所以这是一个真正意义的主键表，而clickhouse没有严格意义的主键表，最接近主键的实现是ReplacingMergeTree，但是他的主键数据合并是延迟进行的，而且在这期间，查询时会有返回新旧的主键记录，需要应用自身进行处理，非常麻烦
3.Starrocks对于多表join的支持非常完善，starrocks从设计之初就考虑到了多表join的分布式实现的问题，多表join时依然可以充分利用多机/多核/SIMD的并行化能力，所以几乎可以理解成使用starrocks的join和Mysql的join的性能相差不大，而Clickhouse对于join的实现可以用灾难来形容，特别是在分布式表的join的时候，容易出错并且性能大打折扣，当然这里并不是说starrocks的join性能有多好，只是说他可以非常好的支持join的实现
4.Starrocks的qps请求可以比clickhouse要高很多，原因在于它的FE可以扩展支持更多的QPS，但是底层的BE的瓶颈还是有限的，毕竟BE要进行数据IO和计算，此外，网络资源也是有限的，毕竟join等操作需要进行数据的移动，所以Starrocks可以支持比较高的qps，但是由于他们都是OLAP引擎，不可能支持类似OLTP数据库那样的QPS，充其量也就是使用了类似后台，定时任务等几百到几千左右的qps，不可能用于C端的应用
5.Starrocks的部分列更新功能，Starrocks可以更新部分列，这对于当一个表的数据是来源于多个业务方，每个业务方只更新自己对应的列的宽表来说非常有用，clickhouse是不支持部分列更新的功能的，这个功能真的很有用
6.Starrocks的物化视图在查询时是会进行自动改写的，也就是不需要类似clickhouse一样需要应用方根据不同的应用场景选择对应的物化视图
结论
Starrocks替换clickhouse的优点是很多的，几乎每个功能Starrocks都可以几乎无损的替换掉clickhouse，再加上Starrocks拥有clickhouse没有的一些功能，所以使用Starrocks替换clickhouse除了历史数据迁移问题外，几乎不需要犹豫