너무 많은 파트 문제

이 가이드는 커뮤니티 밋업에서 얻은 인사이트 모음의 일부입니다. 더 많은 실제 사례 기반의 해결책과 인사이트는 문제별로 살펴보기에서 확인할 수 있습니다. 추가 성능 최적화 팁은 커뮤니티 인사이트 가이드인 Performance Optimization에서 확인할 수 있습니다.

문제 이해하기

ClickHouse는 심각한 성능 저하를 방지하기 위해 "Too many parts" 오류를 발생시킵니다. 작은 파트는 여러 문제를 유발합니다. 쿼리 수행 시 더 많은 파일을 읽고 병합해야 하므로 쿼리 성능이 저하되고, 각 파트마다 메타데이터를 메모리에 유지해야 하므로 메모리 사용량이 증가합니다. 데이터 블록이 작을수록 압축 효율이 떨어지며, 더 많은 파일 핸들과 seek 연산으로 인해 I/O 오버헤드가 커집니다. 또한 백그라운드 병합이 느려져 병합 스케줄러의 작업량이 증가합니다.

관련 문서

• MergeTree 엔진
• Parts
• Parts 시스템 테이블

문제를 조기에 인지하기

이 쿼리는 모든 활성 테이블의 파트 개수와 크기를 분석하여 테이블 단편화를 모니터링합니다. 머지 최적화가 필요할 수 있는, 파트 수가 과도하게 많거나 지나치게 작은 파트를 가진 테이블을 식별합니다. 이 쿼리를 정기적으로 실행하여 단편화 문제가 쿼리 성능에 영향을 미치기 전에 발견되도록 하십시오.

-- Challenge: Replace with your actual database and table names for production use
-- Experiment: Adjust the part count thresholds (1000, 500, 100) based on your system
SELECT 
    database,
    table,
    count() as total_parts,
    sum(rows) as total_rows,
    round(avg(rows), 0) as avg_rows_per_part,
    min(rows) as min_rows_per_part,
    max(rows) as max_rows_per_part,
    round(sum(bytes_on_disk) / 1024 / 1024, 2) as total_size_mb,
    CASE 
        WHEN count() > 1000 THEN 'CRITICAL - Too many parts (>1000)'
        WHEN count() > 500 THEN 'WARNING - Many parts (>500)'
        WHEN count() > 100 THEN 'CAUTION - Getting many parts (>100)'
        ELSE 'OK - Reasonable part count'
    END as parts_assessment,
    CASE 
        WHEN avg(rows) < 1000 THEN 'POOR - Very small parts'
        WHEN avg(rows) < 10000 THEN 'FAIR - Small parts'
        WHEN avg(rows) < 100000 THEN 'GOOD - Medium parts'
        ELSE 'EXCELLENT - Large parts'
    END as part_size_assessment
FROM system.parts
WHERE active = 1
  AND database NOT IN ('system', 'information_schema')
GROUP BY database, table
ORDER BY total_parts DESC
LIMIT 20;

영상 자료

• Fast, Concurrent, and Consistent Asynchronous INSERTS in ClickHouse - ClickHouse 팀 구성원이 비동기 INSERT와 「too many parts」 문제를 설명합니다
• Production ClickHouse at Scale - 관측성 플랫폼에서 사용하는 실제 배치 전략을 소개합니다