join|ClickHouse vs StarRocks选型对比( 三 )
在ClickHouse中 ， 我们一般不建议做高并发的业务查询 ， 对于三副本的集群 ， 通常会将QPS控制在100以下 。 ClickHouse对高并发的业务并不友好 ， 即使一个查询 ， 也会用服务器一半的CPU去查询 。 一般来说 ， 没有什么有效的手段可以直接提高ClickHouse的并发量 ， 只能考虑通过将结果集写入MySQL中增加查询的并发度 。
StarRocks对高并发的支撑
相较于ClickHouse ， StarRocks可以支撑数千用户同时进行分析查询 ， 在部分场景下 ， 高并发能力能够达到万级 。 StarRocks在数据存储层 ， 采用先分区再分桶的策略 ， 增加了数据的指向性 ， 利用前缀索引可以快读对数据进行过滤和查找 ， 减少磁盘的I/O操作 ， 提升查询性能 。
在建表的时候 ， 分区分桶应该尽可能的覆盖到所带的查询语句 ， 这样可以有效的利用分区分桶剪裁的功能 ， 尽可能的减少数据的扫描量 。 此外 ， StarRocks也提供了MOLAP库的预聚合能力 。 对于一些复杂的分析类查询 ， 可以通过创建物化视图进行预先聚合 ， 原有几十亿的基表 ， 可以通过预聚合RollUp操作变成几百或者几千行的表 ， 查询时延迟会有显著下降 ， 并发也会有显著提升 。
数据的高频变更
ClickHouse中的数据更新
在OLAP数据库中 ， 可变数据（Mutable data）通常是不受欢迎的 。 ClickHouse也是如此 。 早期的版本中并不支持UPDATE和DELETE操作 。 在1.15版本后 ， Clickhouse提供了MUTATION操作（通过ALTER TABLE语句）来实现数据的更新、删除 ， 但这是一种“较重”的操作 ， 它与标准SQL语法中的UPDATE、DELETE不同 ， 是异步执行的 ， 对于批量数据不频繁的更新或删除比较有用 。 除了MUTATION操作 ， Clickhouse还可以通过CollapsingMergeTree、VersionedCollapsingMergeTree、ReplacingMergeTree结合具体业务数据结构来实现数据的更新、删除 ， 这三种方式都通过INSERT语句插入最新的数据 ， 新数据会“抵消”或“替换”掉老数据 ， 但是“抵消”或“替换”都是发生在数据文件后台Merge时 ， 也就是说 ， 在Merge之前 ， 新数据和老数据会同时存在 。
针对与不同的业务场景 ， ClickHouse提供了不同的业务引擎来进行数据变更 。
对于离线业务 ， 可以考虑增量和全量两种方案：
增量同步方案中 ， 使用ReplacingMergeTree引擎 ， 先用Spark将上游数据同步到Hive ， 再由Spark消费Hive中的增量数据写入到ClickHouse中 。 由于只同步增量数据 ， 对下游的压力较小 。 需要确保维度数据基本不变 。
全量同步方案中 ， 使用MergeTree引擎 ， 通过Spark将上游数据定时同步到Hive中 ， truncate ClickHouse中的表 ， 随后使用Spark消费Hive近几天的数据一起写入到ClickHouse中 。 由于是全量数据导入 ， 对下游压力较大 ， 但无需考虑维度变化的问题 。
推荐阅读
- 产品|采用njoinic英集芯IP5303的移动电源IC，威麦科技麦克风开箱拆解报告
- Meetup|“初雪”与“向量化”| StarRocks Hacker Meetup小记
- 平台|StarRocks VS ClickHouse，携程大住宿智能数据平台的应用
- user_id|滴滴 x StarRocks：极速多维分析创造更大的业务价值
- joins|PostgreSQL 12.2 公开课及视频及PGCP认证(第9期)(CUUG)(2020年)
- 分析|唯品会翻牌ClickHouse后，实现百亿级数据自助分析