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

对于实时业务，可以采用VersionedCollapsingMergeTree和ReplacingMergeTree两种引擎：
使用VersionedCollapsingMergeTree引擎，先通过Spark将上游数据一次性同步到ClickHouse中，在通过Kafka消费增量数据，实时同步到ClickHouse中。但因为引入了MQ ，需要保证exectly once语义，实时和离线数据连接点存在无法折叠现象。
使用ReplacingMergeTree引擎替换VersionedCollapsingMergeTree引擎，先通过Spark将上游存量数据一次性同步到ClickHouse中，在通过MQ将实时数据同步到ReplacingMergeTree引擎中，相比VersionedCollapsingMergeTree要更简单，且离线和实时数据连接点不存在异常。但此种方案无法保重没有重复数据。
StarRocks中的数据更新
相较于ClickHouse ， StarRocks对于数据更新的操作更加简单。
StarRocks中提供了多种模型适配了更新操作，明细召回操作，聚合操作等业务需求。更新模型可以按照主键进行UPDATE/DELETE操作，通过存储和索引的优化可以在并发更新的同时高效的查询。在某些电商场景中，订单的状态需要频繁的更新，每天更新的订单量可能上亿。通过更新模型，可以很好的适配实时更新的需求。
StarRocks 1.19版本之前，可以使用Unique模型进行按主键的更新操作， Unique模型使用的是Merge-on-Read策略，即在数据入库的时候会给每一个批次导入数据分配一个版本号，同一主键的数据可能有多个版本号，在查询的时候StarRocks会先做merge操作，返回一个版本号最新的数据。
自StarRocks 1.19版本之后发布了主键模型，能够通过主键进行更新和删除的操作，更友好的支持实时/频繁更新的需求。相较于Unique模型中Merge-on-Read的模式，主键模型中使用的是Delete-and-Insert的更新策略，性能会有三倍左右的提升。对于前端的TP库通过CDC实时同步到StarRocks的场景，建议使用主键模型。
集群的维护
相比于单实例的数据库，任何一款分布式数据库维护的成本都要成倍的增长。一方面是节点增多，发生故障的几率变高。对于这种情况，我们需要一套良好的自动failover机制。另一方便随着数据量的增长，要能做到在线弹性扩缩容，保证集群的稳定性与可用性。
ClickHouse中的节点扩容与重分布
与一般的分布式数据库或者Hadoop生态不同， HDFS可以根据集群节点的增减自动的通过balance来调节数据均衡。但是ClickHouse集群不能自动感知集群拓扑的变化，所以就不能自动balance数据。当集群数据较大时，新增集群节点可能会给数据负载均衡带来极大的运维成本。
一般来说，新增集群节点我们通常有三种方案：
·如果业务允许，可以给集群中的表设置TTL ，长时间保留的数据会逐渐被清理到，新增的数据会自动选择新节点，最后会达到负载均衡。

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

推荐阅读

如何找寻自我

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

强组词强字组词

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

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

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

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

暖气有流水声是什么原因

皮球是什么体

手机怎样开通QQ空间

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

手指盖凹陷怎么回事

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

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

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

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

如何评价猪场阉割猪？

最后一个字是豹的成语

泰山散酒怎么样

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