파티셔닝
파티셔닝 (Partitioning)
Druid datasource 안에서 세그먼트 파티셔닝과 정렬을 사용하면 데이터 크기를 줄이고 성능을 높일 수 있어요.
파티셔닝하는 한 가지 방법은 데이터를 별도의 datasource들에 나눠 담는 거예요. 이는 완전히 타당한 접근이고, datasource 수가 과도한 per-datasource 오버헤드를 만들지 않는다면 아주 잘 동작합니다.
이 주제는 단일 datasource 안에서 파티션을 구성하는 방법을 다뤄요. 여러 datasource를 사용하는 방법은 다루지 않는데, 데이터를 별도 datasource로 나누는 방법과 잠재적 운영 고려사항은 Multitenancy considerations를 참고하세요.
출처: 문서
본문
시간 청크 파티셔닝 (Time chunk partitioning)
Druid는 datasource를 항상 시간으로 나눠 시간 청크(time chunk)로 파티셔닝합니다. 각 시간 청크에는 하나 이상의 세그먼트가 들어 있어요. 이 파티셔닝은 모든 수집 방법에 걸쳐, 수집 스펙 dataSchema 객체 안의 segmentGranularity 파라미터에 따라 이루어집니다.
시간별 파티셔닝은 두 가지 이유로 중요해요.
__time(SQL) 또는intervals(native)로 필터링하는 쿼리는 시간 파티셔닝을 이용해 고려할 세그먼트 집합을 잘라낼 수 있어요.- 기존 데이터 덮어쓰기·컴팩션 같은 특정 데이터 관리 작업은 시간 파티션에 대해 배타적 쓰기 잠금(exclusive write lock)을 획득합니다.
- 각 세그먼트 파일은 시간 파티션 안에 완전히 포함돼요. 너무 잘게 파티셔닝하면 작은 세그먼트가 많아져 성능이 떨어질 수 있습니다.
이런 고려사항을 균형 있게 조정하는 가장 흔한 선택은 hour와 day예요. 스트리밍 수집에서는 특히 hour가 흔한데, 컴팩션이 수집을 따라잡는 데 걸리는 시간 지연이 줄어들기 때문입니다.
시간 청크 파티셔닝 구성 방법은 다음 표와 같아요.
| Method | Configuration |
| SQL | PARTITIONED BY |
| Kafka 또는 Kinesis | granularitySpec 안의 segmentGranularity |
| Native batch | granularitySpec 안의 segmentGranularity |
보조 파티셔닝 (Secondary partitioning)
Druid는 각 시간 청크를 다시 불변(immutable) 세그먼트로 파티셔닝해요. 특정 dimension에 대한 보조 파티셔닝은 locality를 높여 줍니다. 즉 그 dimension에 대해 같은 값을 가진 행들이 함께 저장돼서 접근 시간이 줄어드는 것이죠.
최상의 성능과 가장 작은 전체 공간(footprint)을 얻으려면, 필터로 자주 사용하는 "자연스러운(natural)" dimension, 혹은 데이터 안에서 어떤 정렬을 이루는 dimension으로 데이터를 파티셔닝하세요. 이런 파티셔닝은 압축률과 쿼리 성능을 몇 배씩 향상시킬 수 있어요.
보조 파티셔닝 구성 방법은 다음 표와 같아요.
| Method | Configuration |
| SQL | CLUSTERED BY |
| Kafka 또는 Kinesis | 업스트림 파티셔닝이 Druid가 datasource를 파티셔닝하는 방식을 결정해요. 초기 수집 후 REPLACE(+CLUSTERED BY)나 컴팩션으로 클러스터링을 바꿀 수도 있습니다. |
| Native batch | tuningConfig 안의 partitionsSpec |
정렬 (Sorting)
각 세그먼트는 압축률과 locality를 높이기 위해 내부적으로 정렬됩니다.
파티셔닝과 정렬은 서로 잘 맞아요. "자연스러운" 파티셔닝 dimension이 있다면, 그 컬럼을 정렬 순서의 맨 앞에도 배치하는 걸 고려해 보세요. 그러면 Druid가 각 세그먼트 안의 행을 그 컬럼으로 정렬합니다. 이런 정렬 구성은 파티셔닝만 사용할 때보다 압축률과 성능을 훨씬 더 향상시키는 경우가 많아요.
정렬 구성 방법은 다음 표와 같아요.
| Method | Configuration |
| SQL | CLUSTERED BY 안의 필드 순서 또는 쿼리 컨텍스트의 segmentSortOrder 사용 |
| Kafka 또는 Kinesis | dimensionsSpec 안의 필드 순서 사용 |
| Native batch | dimensionsSpec 안의 필드 순서 사용 |
정보
Druid는 쿼리 컨텍스트(SQL)나 dimensionsSpec(다른 수집 형식)에서 forceSegmentSortByTime를 false로 설정하지 않는 한, 세그먼트 안의 행을 어떤 dimensions나 CLUSTERED BY 필드보다 먼저 __time으로 암묵적으로 정렬해요.
forceSegmentSortByTime를 false로 설정하는 것은 실험적 기능입니다. __time으로 시작하지 않는 정렬 순서로 만든 세그먼트는 Druid 31 이상에서만 읽을 수 있어요. 또 현재로서는 다음과 같은 일부 쿼리가 이런 세그먼트에서 지원되지 않습니다.
granularity가all이 아닌 native 쿼리- 오름차순·내림차순 시간 정렬을 쓰는 native
scan쿼리 - 지원되지 않는 native 쿼리로 계획(plan)되는 SQL 쿼리
더 알아보기 (Learn more)
관련 주제는 다음을 참고하세요.
- Native Batch 수집에서 파티셔닝을 더 자세히 보려면
partitionsSpec - Druid에서 기존 데이터를 다시 파티셔닝하는 방법은 Reindexing and Compaction