ClickHouse集羣方案測評

本文首發於：行者AI

回合對戰數據指標計算，耗時過長，甚至由於單機內存不足沒法知足需求，故考慮將本來單節點的單機ClickHouse改成集羣 , 採用分佈式表來進行相關計算。

1. 環境搭建

1.1 單機方案

ClickHouse實例	CPU	內存	磁盤
ClickHouse	16C	64G	4T , 高IO

1.2 集羣方案 3分片1複本

ClickHouse實例	CPU	內存	磁盤
ClickHouse1	16C	64G	4T , 高IO
ClickHouse2	8C	32G	1T , 超高IO
ClickHouse3	8C	32G	1T , 超高IO

2. 方案對比

2.1 寫入速度對比

數據量 : 26910101 Rows

方案一 : 單機方案( 全量數據插入單機表 )

ClickHouse實例	寫入速度
ClickHouse	26.009 sec ;1.03 million rows/s , 504.78 MB/s

方案二 : 集羣方案( 數據寫入物理表,分別並行向3臺機器物理表寫入數據 )

ClickHouse實例	寫入速度
ClickHouse1	13.640 sec; 1.97 million rows/s., 320.96 MB/s
ClickHouse2	9.166 sec ; 2.94 million rows/s, 982.03 MB/s
ClickHouse3	9.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/s	6.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/s	0.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/s	0.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/s	0.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/s	0.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/s	1.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/s	3.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/s	4.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/s	4.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/s	4.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/s	4.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/s	7.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/s	7.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/s	7.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/s	8.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/s	8.578 sec; 1.17 million rows/s., 80.53 MB/s

結論 : 小數據量join操做 , 單機方案和集羣方案差別很小 ; 大數據量單機方案不如集羣方案 , 單機方案還可能會存在內存不足等問題。

3. 其餘方面

ClickHouse併發較小 , 官網查詢建議100 Queries / second , 單機ClickHouse不適合作業務型高併發查詢。ClickHouse集羣能夠經過chproxy 將併發的查詢代理到集羣上各分片上去做查詢 , 能夠極大提升了併發量。

4. 性能測試總結

單機方案寫數據的性能上遠不如集羣方案。

查詢方面, 數據量小時的查詢單機方案和集羣方案相差不明顯, 數據量大時集羣方案不會存在內存,cup不足等問題,同時查詢的效率也高於單機方案。

集羣方案相較於單機方案 , 建表略有繁瑣 , 分佈式表寫數據沒法實時寫入各個分片物理表 , 而會先寫入內存而後同步到各個分片,故咱們須要向每一個分片的物理表同時寫入數據。

綜上, 目前round和roundData數據量愈來愈大 ,搭建集羣分佈式存儲數據方案是可行的。

---

PS：更多技術乾貨，快關注【公衆號 | xingzhe_ai】，與行者一塊兒討論吧！