本文首发于：行者AI

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

1. 环境搭建

1.1 单机计划

ClickHouse实例CPU内存磁盘
ClickHouse16C64G4T , 高IO

1.2 集群计划 3分片1复本

ClickHouse实例CPU内存磁盘
ClickHouse116C64G4T , 高IO
ClickHouse28C32G1T , 超高IO
ClickHouse38C32G1T , 超高IO

2. 计划比照

2.1 写入速度比照

数据量 : 26910101 Rows

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

ClickHouse实例写入速度
ClickHouse26.009 sec ;1.03 million rows/s , 504.78 MB/s

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

ClickHouse实例写入速度
ClickHouse113.640 sec; 1.97 million rows/s., 320.96 MB/s
ClickHouse29.166 sec ; 2.94 million rows/s, 982.03 MB/s
ClickHouse39.632 sec; 2.79 million rows/s., 931.00 MB/s

论断 : 写入数据速度和磁盘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 ;

单机计划集群计划
10.177 sec ; 78.81 million rows/s., 2.66 GB/s6.264 sec ;104.32 million rows/s., 3.46 GB/s

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

（3）关联查问

关联形式单机计划集群计划
500万 join 100万0.946 sec; 0.86 million rows/s., 53.29 MB/s0.920 sec; 1.09 million rows/s., 75.70 MB/s
1000万 join 100万0.880 sec; 0.94 million rows/s., 58.80 MB/s0.921 sec; 1.09 million rows/s., 75.59 MB/s
2000万 join 100万0.938 sec; 0.87 million rows/s., 53.96 MB/s0.923 sec; 1.08 million rows/s., 75.41 MB/s
5000万 join 100万0.940 sec; 0.86 million rows/s., 53.81 MB/s0.960 sec; 1.04 million rows/s., 72.53 MB/s
1亿 join 100万1.906 sec; 0.90 million rows/s., 56.56 MB/s1.135 sec; 880.95 thousand rows/s., 61.34 MB/s.
500万 join 500万5.141 sec; 1.01 million rows/s., 74.07 MB/s3.791 sec; 1.32 million rows/s., 91.46 MB/s
1000万 join 500万5.149 sec; 1.01 million rows/s., 73.92 MB/s4.127 sec; 1.21 million rows/s., 84.00 MB/s
2000万 join 500万5.172 sec; 1.00 million rows/s., 73.46 MB/s4.110 sec; 1.22 million rows/s., 84.36 MB/s
5000万 join 500万5.096 sec; 1.02 million rows/s., 75.00 MB/s4.342 sec; 1.15 million rows/s., 79.84 MB/s
1亿 join 500万6.108 sec; 1.02 million rows/s., 74.75 MB/s4.362 sec; 1.15 million rows/s., 79.49 MB/s
500万 join 1000万12.341 sec; 1.16 million rows/s., 85.39 MB/s7.885 sec; 1.27 million rows/s., 87.61 MB/s
1000万 join 1000万12.337 sec; 1.16 million rows/s., 85.44 MB/s7.916 sec; 1.26 million rows/s., 87.27 MB/s
2000万 join 1000万12.324 sec; 1.17 million rows/s., 85.61 MB/s7.777 sec; 1.29 million rows/s., 88.84 MB/s
5000万 join 1000万13.039 sec; 1.14 million rows/s., 87.10 MB/s8.083 sec; 1.24 million rows/s., 85.46 MB/s
1亿 join 1000万13.101 sec; 1.13 million rows/s., 86.43 MB/s8.578 sec; 1.17 million rows/s., 80.53 MB/s

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

3. 其余方面

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

4. 性能测试总结

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

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

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

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