워크시트 2: 정렬 키 설계 (ORDER BY)

예상 소요 시간: 20–25분 참고 자료: MergeTree 엔진 — ORDER BY Design 섹션

개념

ClickHouse의 ORDER BY 절은 장식이 아니다. 이 절은 primary index를 정의한다 — WHERE 절을 평가할 때 관련 없는 데이터 블록을 건너뛸 수 있게 해 주는 희소 블록 단위 인덱스다. 또한 파트 내부의 물리적 정렬 순서를 결정하므로 압축률에도 영향을 준다.

잘못된 ORDER BY = 느린 쿼리 + 낭비되는 스토리지. UUID를 앞에 둔 ORDER BY는 어떤 분석 쿼리에서도 블록 스킵이 일어나지 않는다는 뜻이다(UUID는 무작위라 정렬 가능한 접두부가 없다). 날짜를 앞에 둔 ORDER BY는 날짜로 필터하는 쿼리가 테이블의 대부분을 건너뛴다는 뜻이다.

ORDER BY 설계의 세 가지 규칙

규칙 1: 소스 스키마가 아니라 쿼리 필터에서 도출하라. 가장 자주 실행되는 쿼리들의 WHERE, GROUP BY, JOIN 컬럼을 보라. 가장 많이 필터되는 컬럼은 (카디널리티가 지나치게 높지 않다면) ORDER BY에 포함되어야 할 가능성이 높다. 소스 테이블의 primary key는(있다 하더라도) 보통 무관하다.

규칙 2: 낮은 카디널리티를 앞에, 높은 카디널리티를 뒤에. ClickHouse의 primary index는 약 8192행(그래뉼)마다 항목 하나를 갖는다. 낮은 카디널리티 컬럼(예: toStartOfMonth(date) = 4년 동안 약 48개의 서로 다른 값)은 많은 행을 함께 묶어 준다 — 인덱스가 그래뉼 전체를 건너뛸 수 있다. 높은 카디널리티 컬럼(예: trip_id = 5천만 개의 서로 다른 값)은 행마다 고유하므로, 앞에 두면 인덱스가 아무것도 건너뛸 수 없다. 이 순서는 기본값이며 규칙 1을 뒤집는 것이 아니다. 범위 필터로 대부분의 행을 제거하는 컬럼은, 언제나 동등 비교로만 필터되는 더 낮은 카디널리티 컬럼보다 여전히 앞자리를 차지할 수 있다.

규칙 3: ReplacingMergeTree에서는 고유 행 식별자로 끝내라. 중복 제거 키는 ORDER BY 튜플 전체다. ORDER BY에 trip_id가 없으면, pickup_at이 같고 그 뒤에 컬럼이 더 없는 서로 다른 두 트립이 중복으로 처리된다. 인덱스 성능을 해치지 않으면서 고유성을 보장하도록 trip_id를 마지막에 두어라.

연습: 쿼리 워크로드 분석

정렬 키를 설계하기 전에, 쿼리가 실제로 어떤 컬럼으로 필터하는지 파악하라. NYC Taxi 랩에는 대표 쿼리 7개가 있다. 각 쿼리에서 행을 가장 많이 제거하는 필터 컬럼을 선택하라.

연습: 카디널리티 추정

각 ORDER BY 후보 컬럼에 대해 4년, 5천만 행 데이터셋에서의 카디널리티를 추정하라. 아래 표의 대부분은 참고 데이터이며, 비어 있는 두 칸은 pickup_at의 추정 고유값 수와 카디널리티 등급이다. 4년은 약 1억 2600만 초(그리고 약 210만 분에 불과)이고, 프로듀서는 모든 트립에 월클록 기준 타임스탬프를 찍으며, PICKUP_AT은 DateTime64(3, 'UTC')로 저장된다 — 5천만 건의 트립이 그 슬롯 중 몇 개를 채울 수 있는지 계산한 뒤 구간을 선택하라.

연습: 정렬 키 설계

쿼리 워크로드 분석과 카디널리티 추정을 사용해 trips_raw, fact_trips, agg_hourly_zone_trips의 ORDER BY를 제안하라. 유념할 점은 다음과 같다.

• 낮은 카디널리티를 앞에 → 블록 스킵 최대화.
• 여러 쿼리의 WHERE/GROUP BY에 등장하는 컬럼 → 포함하라.
• ReplacingMergeTree 테이블 → 고유 행 식별자로 끝내라.
• 한 번도 필터되지 않는 컬럼은 넣지 마라.

모든 표를 채운 뒤 추론 문제와 회고 문제를 풀어라.

Loading worksheet...

migration-plan.md로 옮기기

이 워크시트를 채웠으면 ORDER BY 결정을 migration-plan.md의 Section 4에 복사하고 다음을 체크하라.

- [ ] Sort key design: completed