关于数据库:ClickHouse集群方案测评

本文首发于： 行者 AI

回合对战数据指标计算，耗时过长，甚至因为单机内存不足无奈满足需要，故思考将本来单节点的单机 ClickHouse 改为集群 , 采纳分布式表来进行相干计算。

1. 环境搭建

1.1 单机计划

1.2 集群计划 3 分片 1 复本

2. 计划比照

2.1 写入速度比照

数据量 : 26910101 Rows

计划一 : 单机计划 (全量数据插入单机表)

计划二 : 集群计划 (数据写入物理表, 别离并行向 3 台机器物理表写入数据)

论断 : 写入数据速度和磁盘 IO 无关 , 集群计划数据写入相比单机计划有显著劣势。

2.2 查问比照 (次要针对分组查问和关联查问操作)

（1）分布式建表办法

-- 物理表

CREATE table rd_physical.rd_baseinfo_physical on cluster cluster_3shards_1replicas
(
`appId` String,
`pvpId` String,
`accountId` String,
`userName` String,
`round` Nullable(Int32),
`event` String,
`mode` Nullable(Int32),
`win` Int32,
`country` String,
`timeStamp` String,
`ts` DateTime,
`ds` Date
)
ENGINE = ReplicatedMergeTree('/clickhouse/rd_physical/tables/{shard}/rd_baseinfo_physical', '{replica}')
PARTITION BY (ds)
ORDER BY (appId, accountId, pvpId)
SETTINGS index_granularity = 8192

-- 逻辑表

CREATE table rd_data.rd_baseinfo on cluster cluster_3shards_1replicas
(
`appId` String,
`pvpId` String,
`accountId` String,
`userName` String,
`round` Nullable(Int32),
`event` String,
`mode` Nullable(Int32),
`win` Int32,
`country` String,
`timeStamp` String,
`ts` DateTime,
`ds` Date
)
ENGINE =Distributed(cluster_3shards_1replicas, rd_physical, rd_baseinfo_physical, cityHash64(accountId))

（2）分组查问

SQL 语句 : select count(*) , accountId,pvpId from rd.rd_baseinfo where ds>=’2019-12-01′ and ds<‘2020-01-01’ group by accountId ,pvpId ;

论断 : 集群计划对数据分类查问效率比单机高出 25% 左右。

（3）关联查问

论断 : 小数据量 join 操作 , 单机计划和集群计划差别很小 ; 大数据量单机计划不如集群计划 , 单机计划还可能会存在内存不足等问题。

3. 其余方面

ClickHouse 并发较小 , 官网查问倡议 100 Queries / second , 单机 ClickHouse 不适宜做业务型高并发查问。ClickHouse 集群能够通过 chproxy 将并发的查问代理到集群上各分片下来作查问 , 能够极大进步了并发量。

4. 性能测试总结

单机计划写数据的性能上远不如集群计划。

查问方面, 数据量小时的查问单机计划和集群计划相差不显著, 数据量大时集群计划不会存在内存,cup 有余等问题, 同时查问的效率也高于单机计划。

集群计划相较于单机计划 , 建表略有繁琐 , 分布式表写数据无奈实时写入各个分片物理表 , 而会先写入内存而后同步到各个分片, 故咱们须要向每个分片的物理表同时写入数据。

综上, 目前 round 和 roundData 数据量越来越大 , 搭建集群分布式存储数据计划是可行的。