예외의 의미
MergeTree 테이블의 활성 데이터 파트 수가 설정된 한도를 INSERT로 초과하게 되면 Too many parts 예외를 발생시킵니다. 이 예외에는 흔히 Merges are processing significantly slower than inserts라는 메시지가 포함됩니다.
동기식 INSERT는 실행될 때마다 최소 1개의 데이터 파트를 생성합니다. 하나의 삽입에 여러 파티션 값에 해당하는 행이 포함되어 있으면 ClickHouse는 영향을 받는 각 파티션마다 하나의 파트를 생성할 수 있습니다. 백그라운드 머지는 작은 파트들을 더 큰 파트로 합치지만, 새 파트가 ClickHouse의 머지 처리 속도보다 더 빠르게 생성되면 활성 파트 수는 계속 증가합니다.
이 예외는 다음 설정 중 하나에 의해 트리거될 수 있습니다.
parts_to_throw_insert: 단일 파티션의 활성 파트 수를 제한합니다.max_parts_in_total: 테이블 전체의 활성 파트 총수를 제한합니다.
원인 파악
max_parts_in_total에 의해 테이블 전체에 적용되는 제한을 확인하려면, 테이블의 모든 활성 파트 수를 셉니다:
- 빈번한 소규모 동기 삽입.
- high-cardinality 파티셔닝 키.
- 여러 파티션 값에 해당하는 행이 포함된 삽입.
- 스토리지 처리량이 제한적이거나, 사용 가능한 디스크 공간이 부족하거나, 기타 리소스 경합이 발생해 백그라운드 머지가 이를 따라가지 못하는 경우.
system.merges에서 확인하고, 머지 실패와 관련된 서버 로그를 검토할 수 있습니다.
예외 해결하기
동기 삽입 배치 처리
INSERT를 목표로 하십시오. 횟수는 줄이고 한 번에 더 큰 규모로 삽입하면 생성되는 파트 수가 줄어들고 백그라운드 머지에 필요한 작업도 감소합니다.
비동기 삽입 사용
wait_for_async_insert = 1로 유지하여 데이터가 성공적으로 기록된 후에만 ClickHouse가 삽입을 확인하도록 하십시오.
파티셔닝 키 검토
머지 병목 현상 조사
주된 해결책으로 파트 제한을 늘리지는 마십시오
parts_to_throw_insert 또는 max_parts_in_total을 늘려도 과도한 파트 생성의 근본 원인은 해결되지 않습니다. 제한을 높이면 예외 발생을 늦출 수는 있지만, 파일 시스템과 메타데이터 오버헤드를 늘리고 쿼리 성능을 저하시킬 수도 있습니다. 이러한 설정은 원인을 파악하고 시스템에 충분한 용량이 있는지 확인한 후에만 변경하십시오.
복구 상태 확인
system.merges를 계속 모니터링하십시오.