join|ClickHouse vs StarRocks选型对比( 二 )_数据库|vs|业务|支持|场景|交易

不同于以点查为主的TP业务，在AP业务中，事实表和维度表的关联操作不可避免。 ClickHouse与StarRocks最大的区别就在于对于join的处理上。 ClickHouse虽然提供了join的语义，但使用上对大表关联的能力支撑较弱，复杂的关联查询经常会引起OOM 。一般我们可以考虑在ETL的过程中就将事实表与维度表打平成宽表，避免在ClickHouse中进行复杂的查询。
目前有很多业务使用宽表来解决多远分析的问题，说明了宽表确有其独到之处：
·在ETL的过程中处理好宽表的字段，分析师无需关心底层的逻辑就可以实现数据的分析
·宽表能够包含更多的业务数据，看起来更直观一些
·宽表相当于单表查询，避免了多表之间的数据关联，性能更好
但同时，宽表在灵活性上也带来了一些困扰：
·宽表中的数据可能会因为join的过程中存在一对多的情况造成错误数据冗余
·宽表的结构维护麻烦，遇到维度数据变更的情况需要重跑宽表
·宽表需要根据业务预先定义，宽表可能无法满足临时新增的查询业务
StarRocks：通过星型模型适应维度变更
可以说，拼宽表的形式是以牺牲灵活性为代价，将join的操作前置，来加速业务的查询。但在一些灵活度要求较高的场景，比如订单的状态需要频繁改变，或者说业务人员的自助BI分析，宽表往往无法满足我们的需求。此时我们还需要使用更为灵活的星型或者雪花模型进行建模。对于星型/雪花模型的兼容度上， StarRocks的支撑要比ClickHouse好很多。
在StarRocks中提供了三种不同类型的join：
·当小表与大表关联时，可以使用boardcast join ，小表会以广播的形式加载到不同节点的内存中
·当大表与大表关联式，可以使用shuffle join ，两张表值相同的数据会shuffle到相同的机器上
·为了避免shuffle带来的网络与I/O的开销，也可以在创建表示就将需要关联的数据存储在同一个colocation group中，使用colocation join

文章图片

【join|ClickHouse vs StarRocks选型对比】目前大部分的MPP架构计算引擎，都采用基于规则的优化器（RBO）。为了更好的选择join的类型， StarRocks提供了基于代价的优化器（CBO）。用户在开发业务SQL的时候，不需要考虑驱动表与被驱动表的顺序，也不需要考虑应该使用哪一种join的类型， CBO会基于采集到的表的metric ，自动的进行查询重写，优化join的顺序与类型。
高并发支撑
ClickHouse对高并发的支撑
为了更深维度的挖掘数据的价值，就需要引入更多的分析师从不同的维度进行数据勘察。更多的使用者同时也带来了更高的QPS要求。对于互联网，金融等行业，几万员工，几十万员工很常见，高峰时期并发量在几千也并不少见。随着互联网化和场景化的趋势，业务逐渐向以用户为中心转型，分析的重点也从原有的宏观分析变成了用户维度的细粒度分析。传统的MPP数据库由于所有的节点都要参与运算，所以一个集群的并发能力与一个节点的并发能力相差无几。如果一定要提高并发量，可以考虑增加副本数的方式，但同时也增加了RPC的交互，对性能和物理成本的影响巨大。

join|ClickHouse vs StarRocks选型对比( 二 )

推荐阅读

如何找寻自我

缝纫机调线器怎么安装平车方法如何

强组词强字组词

火笋鸡翅的做法（增肥食谱）

闺女生日快乐祝福语朋友圈

LV请来潮牌设计师做艺术总监，看中的是啥

老虎豆怎么做好吃老虎豆图片怎样弄来吃

暖气有流水声是什么原因

皮球是什么体

手机怎样开通QQ空间

男生发mua说明 mua是什么意思

手指盖凹陷怎么回事

对自己的生活失去掌控咋调整

小米10s怎么没有月亮模式

我想找个偏僻的地方搞养殖！有没有推荐的地方？

南京养老金认证上门服务怎么申请南京市养老金认证

如何评价猪场阉割猪？

最后一个字是豹的成语

泰山散酒怎么样

猫发情的声音(猫发情的叫声)