ClickHouse 클러스터 시나리오 평가

이 문서는 다음과 같이 시작되었습니다.
수행자 AI
라운드 대전 데이터 지표 계산은 시간이 너무 오래 걸리고 심지어 단기 메모리 부족으로 수요를 충족시키지 못하기 때문에 원래 단일 노드였던 단기 클릭하우스를 집단으로 바꾸고 분포식 표로 관련 계산을 하는 것을 고려한다.
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, 초고속 입출력
ClickHouse3
8C
32G
1T, 초고속 입출력
2. 시나리오 비교
2.1 쓰기 속도 비교
데이터: 26910101 Rows
시나리오 1: 독립 실행형 시나리오(전량 데이터 독립 실행형 테이블 삽입)
ClickHouse 인스턴스
쓰기 속도
ClickHouse
26.009 sec ;1.03 million rows/s , 504.78 MB/s
시나리오 2: 클러스터 시나리오(물리적 테이블에 데이터를 쓰고 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.rdbaseinfo where ds>='2019-12-01' and ds
독립 실행형 시나리오
클러스터 시나리오
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만, 준아 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만, 준아 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만, 준아 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만 준, 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만 준, 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만 준, 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만, 준아 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만 준, 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만 준, 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의 합병은 비교적 작고 홈페이지 조회는 100Queries/second를 권장합니다. 단기 ClickHouse는 업무형이 높은 합병 조회를 하기에 적합하지 않습니다.ClickHouse 집단은chproxy를 통해 병발된 조회 에이전트를 집단의 각 섹션에 나누어 조회할 수 있어 병발량을 크게 높일 수 있다.
4. 성능 테스트 요약
단기 방안으로 데이터를 쓰는 성능은 집단 방안보다 훨씬 못하다.
조회에 있어 데이터 양의 시간에 대한 조회 단기 방안과 집단 방안의 차이가 현저하지 않고 데이터 양이 많을 때 집단 방안에는 메모리,cup 부족 등 문제가 존재하지 않으며 조회의 효율도 단기 방안보다 높다.
집단 방안은 단기 방안에 비해 표를 작성하는 것이 약간 번거롭다. 분포식 표 작성 데이터는 각 블록의 물리 표를 실시간으로 쓸 수 없고 메모리를 먼저 쓴 다음에 각 블록에 동기화되기 때문에 우리는 각 블록의 물리 표에 데이터를 동시에 써야 한다.
종합적으로 보면 현재round와roundData의 데이터 양이 갈수록 커지기 때문에 집단 분포식 저장 데이터 방안을 구축하는 것이 가능하다.