clickhouse vs kudu
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了clickhouse vs kudu相关的知识,希望对你有一定的参考价值。
参考技术A 一、项目背景清洗的结果中有两张比较大的表:
1)ip域名关系首次发现统计表,日增约0.5亿;
2)ip域名关系历史变化轨迹统计表,日增约1.4亿;
前端查询方式包括以下两种方式:
1)查询某个ip的信息,例如:select * from xxx where ip='xxxx'
2)查询某个域名的信息,例如: select * from xxx where dn = 'xxx'
二、clickhouse
优势:
1)数据压缩率高、写入性能高;
2)主键最左侧列出现在查询条件中时查询耗时在1秒内。(实测数据44亿,公司wiki其他项目组测试数据在百亿级别)
存在问题:
1)只有主键中的第二列出现在查询条件中时,查询速度很差,实测数据量在十亿级别时耗时在几十秒甚至查不出。
官网中也提到过该问题,见下图:
2)不能保证数据全局唯一,clickhouse的主键并不能约束数据唯一性,即使使用ReplacedMergeTree,也只能保证分区内数据唯一。
3)跳数索引作用不大,实测过set、ngrambf_v1、tokenbf_v1。(后两者均为布隆过滤器)
三、impala+kudu
由于clickhouse存在类似主键“最左原则”问题,导致无法同时满足dns反查的应用场景,变通的解决方案是同时存储两份数据,一份使用ip作为主键,另一份使用域名作为主键,前端不同查询场景分别转换为对这两份数据的查询,但这种解决方案存在数据不一致的隐患,一旦出现两份数据不一致时对数据的比对、修复等都是件麻烦的事情,此外还增加了数据同步任务维护的负担。
思考是否存在一种存储方式能够同时满足两个主键的索引(或分区)。
kudu可以支持同时按hash和范围分区,例如:
PARTITION BY HASH (id) PARTITIONS 4,
RANGE (sku)
(
PARTITION VALUES < ‘g’,
PARTITION ‘g’ <= VALUES < ‘o’,
PARTITION ‘o’ <= VALUES < ‘u’,
PARTITION ‘u’ <= VALUES
)
这样在原理上是能够支持分别按单列作为查询条件的应用场景。
四、clickhouse与kudu对比
clickhouse impala+kudu
服务器情况 单机128G 24核 4台 128G 24核
集群支持情况 支持,但对zk的依赖过重 支持,不依赖zk,内部使用raft算法;可在CDH中管理impala和kudu
数据一致性支持情况 不能保证数据一致性,即使使用ReplacedMergeTree,也只能保证分区内数据唯一 支持upsert操作,能够保证唯一性
占用磁盘空间 44亿69g 31亿163G
写入速度 10万/s 23万/s
查询速度 10亿数据量时:只有主键中最左侧列作为查询条件时耗时在1秒内;当主键中最左侧列不在查询条件中时耗时在几十秒 29亿时分别将ip和域名作为条件查询耗时均在1秒内;63亿时ip作为条件(range分区)时,耗时大部分在1~2秒,部分查询时间在几十秒(原因待查)域名作为条(hash分区),耗时基本在1秒内
并发 不支持大并发查询 不支持大并发查询
kudu查询性能记录
1、集群描述
3个master 3个tabletserver
128G内存(设置kudu和impala可用内存上限均为80G) 24核
2、不同条件下的查询时间记录
3、数据量为28亿时的查询记录
总数:
将dn作为条件查询:
将ip作为条件查询:
4、数据量为63亿时的查询记录
总数:
将dn作为条件查询:
将ip作为条件查询:
在某些时候查询速度一般(第一次查询慢,再次查会快),
5、数据量为110亿时的查询记录
总数:
将dn作为条件查询:
将ip作为条件查询:
附录: 一些其他对比
以上是关于clickhouse vs kudu的主要内容,如果未能解决你的问题,请参考以下文章
ClickHouse vs Elasticsearch谁更胜一筹?
ClickHouse vs Elasticsearch谁更胜一筹?