분할 정책

  • 아티클

분할 정책은 특정 테이블 또는 구체화된 뷰에 대해 익스텐트(데이터 분할)를 분할해야 하는지 여부와 방법을 정의합니다.

정책은 데이터 수집 후 익스텐트를 만든 후에 발생하는 추가 백그라운드 프로세스를 트리거합니다. 이 프로세스에는 원본 익스텐트에서 데이터를 다시 수집하고 파티션 키로 지정된 열의 모든 값이 단일 파티션 내에 있는 균일한 익스텐트를 생성하는 작업이 포함됩니다.

분할 정책의 주요 목표는 지원되는 특정 시나리오에서 쿼리 성능을 향상시키는 것입니다.

참고

기본적으로 데이터 분할 정책이 정의되지 않은 경우(은 null) 생성 시간(수집)에 따라 익스텐트를 분할합니다. 대부분의 경우 데이터 분할 정책을 설정할 필요가 없습니다.

지원되는 시나리오

다음은 데이터 분할 정책을 설정하는 것이 권장되는 유일한 시나리오입니다. 다른 모든 시나리오에서는 정책 설정이 권장되지 않습니다.

  • 중간 또는 높은 카디널리티 string 또는 guid 열에 대한 빈번한 필터:
    • 예를 들어 다중 테넌트 솔루션 또는 대부분의 또는 모든 쿼리가 또는 형식 string 의 열(예: 또는 guid)을 TenantId 필터링하는 MetricId메트릭 테이블입니다.
    • 중간 카디널리티는 10,000개 이상의 고유 값입니다.
    • 해시 파티션 키를 또는 guid 열로 string 설정하고 속성을 로 설정합니다PartitionAssigmentMode.uniform
  • 높은 카디널리티 string 또는 열에 대한 빈번한 집계 또는 guid 조인:
  • 순서가 지난 데이터 수집:
    • 테이블에 수집된 데이터는 데이터 생성 시간을 나타내며 일반적으로 데이터를 필터링하는 데 사용되는 특정 datetime 열에 따라 익스텐트(분할)로 정렬되고 분할되지 않을 수 있습니다. 이는 많은 시간 범위 동안 날짜/시간 값을 포함하는 다른 유형의 원본 파일의 백필 때문일 수 있습니다.
    • 이 경우 균일한 범위 datetime 파티션 키를 열로 datetime 설정합니다.
    • 수집 시간에 맞추는 대신 열의 datetime 값에 맞게 보존 및 캐싱 정책이 필요한 경우 속성을 true로 설정합니다OverrideCreationTime.

주의

  • 분할 정책이 정의된 테이블 수에는 하드 코딩된 제한이 설정되지 않습니다. 그러나 모든 추가 테이블은 클러스터의 노드에서 실행되는 백그라운드 데이터 분할 프로세스에 오버헤드를 추가합니다. 더 많은 테이블에 정책을 설정하면 더 많은 클러스터 리소스가 사용되고 기본 스토리지 트랜잭션으로 인해 비용이 높아집니다. 자세한 내용은 용량을 참조 하세요.
  • 파티션당 압축된 데이터 크기가 1GB 미만인 경우 분할 정책을 설정하지 않는 것이 좋습니다.
  • 분할 프로세스는 분할 프로세스 중 및 병합 프로세스 중에 대체된 모든 익스텐트에서 잔여 스토리지 아티팩트가 생성됩니다. 대부분의 잔여 스토리지 아티팩트가 자동 정리 프로세스 중에 삭제될 것으로 예상됩니다. 속성 값을 MaxPartitionCount 늘리면 잔여 스토리지 아티팩트 수가 증가하고 정리 성능이 저하됩니다.
  • 구체화된 뷰에 분할 정책을 적용하기 전에 구체화된 뷰 분할 정책에 대한 권장 사항을 검토합니다.

파티션 키

다음과 같은 종류의 파티션 키가 지원됩니다.

종류 열 유형 파티션 속성 파티션 값
해시 string 또는 guid Function, MaxPartitionCount, Seed, PartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
균일 범위 datetime RangeSize, Reference, OverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

해시 파티션 키

정책에 해시 파티션 키가 포함된 경우 동일한 파티션에 속하는 모든 동종 익스텐트는 클러스터의 동일한 데이터 노드에 할당됩니다.

참고

데이터 분할 작업은 상당한 처리 부하를 추가합니다. 다음 조건에서만 테이블에 해시 파티션 키를 적용하는 것이 좋습니다.

  • 대부분의 쿼리에서 같음 필터(==, in())를 사용하는 경우
  • 대부분의 쿼리는 형식 string 의 특정 열 또는 guid큰 차원(10M 이상의 카디널리티)(예: 또는 )에 대한 집계/조인device_IDuser_ID입니다.
  • 분할된 테이블의 사용 패턴은 모니터링 또는 대시보드 애플리케이션과 같이 동시성 쿼리 부하가 높습니다.
  • 해시 모듈로 함수는 데이터를 분할하는 데 사용됩니다.
  • 동일한(분할된) 익스텐트 내의 데이터는 해시 파티션 키로 정렬됩니다.
    • 테이블에 해시 파티션 키가 정의된 경우 행 순서 정책에 해시 파티션 키를 포함할 필요가 없습니다.
  • 순서 섞기 전략을shuffle key 사용하고 에서 joinsummarize 사용되거나 make-series 테이블의 해시 파티션 키인 쿼리는 클러스터 노드 간에 이동하는 데 필요한 데이터의 양이 줄어들기 때문에 더 나은 성능을 발휘할 것으로 예상됩니다.

파티션 속성

속성 Description 지원되는 값 권장되는 값
Function 사용할 해시 모듈로 함수의 이름입니다. XxHash64
MaxPartitionCount 생성할 최대 파티션 수(해시-모듈로 함수에 대한 모듈로 인수)입니다. 범위 (1,2048]에서 입니다. 값이 높을수록 클러스터 노드에서 데이터 분할 프로세스의 오버헤드가 증가하고 각 기간에 대한 익스텐트 수가 증가합니다. 권장 값은 128입니다. 값이 높을수록 수집 후 데이터를 분할하는 오버헤드와 메타데이터 크기가 크게 증가하므로 권장되지 않습니다.
Seed 해시 값을 임의로 지정하는 데 사용합니다. 양의 정수 1기본값이기도 한 입니다.
PartitionAssignmentMode 클러스터의 노드에 파티션을 할당하는 데 사용되는 모드입니다. ByPartition: 동일한 파티션에 속하는 모든 동종(분할된) 익스텐트도 동일한 노드에 할당됩니다.
Uniform: 익스텐트의 파티션 값은 무시됩니다. 익스텐트 는 클러스터의 노드에 균일하게 할당됩니다.		 쿼리가 해시 파티션 키에 조인하거나 집계되지 않는 경우 를 사용합니다 Uniform. 그렇지 않으면 ByPartition를 사용합니다.

해시 파티션 키 예제

라는 tenant_id형식의 열에 대한 string해시 파티션 키입니다. 해시 함수를 XxHash64 사용하며, 은 권장 값128으로 MaxPartitionCount 설정되고 기본값 Seed 은 입니다1.

{
  "ColumnName": "tenant_id",
  "Kind": "Hash",
  "Properties": {
    "Function": "XxHash64",
    "MaxPartitionCount": 128,
    "Seed": 1,
    "PartitionAssignmentMode": "Uniform"
  }
}

균일 범위 날짜/시간 파티션 키

참고

테이블에 수집된 데이터가 이 열에 datetime따라 정렬되지 않을 경우에만 테이블의 형식이 지정된 열에 균일한 범위 datetime 파티션 키를 적용합니다.

이러한 경우 익스텐트 간에 데이터를 다시 구성하여 각 익스텐트에서 제한된 시간 범위의 레코드를 포함할 수 있습니다. 이 프로세스를 통해 열에 대한 필터가 datetime 쿼리 시간에 더 효과적입니다.

사용되는 파티션 함수는 bin_at() 이며 사용자 지정할 수 없습니다.

파티션 속성

속성 Description 권장되는 값
RangeSize timespan 각 datetime 파티션의 크기를 나타내는 스칼라 상수입니다. 값 1.00:00:00 (1일)으로 시작합니다. 테이블에 병합할 수 없는 작은 범위가 많을 수 있으므로 더 짧은 값을 설정하지 마세요.
Reference datetime 날짜/시간 파티션이 정렬되는 고정 시점을 나타내는 스칼라 상수입니다. 1970-01-01 00:00:00를 시작합니다. datetime 파티션 키 null 에 값이 있는 레코드가 있는 경우 해당 파티션 값은 값 Reference으로 설정됩니다.
OverrideCreationTime bool 결과 익스텐트의 최소 및 최대 생성 시간을 파티션 키의 값 범위로 재정의해야 하는지 여부를 나타내는 입니다. 기본값은 false입니다. true 데이터가 도착 시간 순서대로 수집되지 않는 경우 로 설정합니다. 예를 들어 단일 원본 파일에는 먼 날짜/시간 값이 포함되거나 수집 시간이 아닌 datetime 값에 따라 보존 또는 캐싱을 적용할 수 있습니다.

가 로 true설정되면 OverrideCreationTime 병합 프로세스에서 익스텐트 누락이 발생할 수 있습니다. 생성 시간이 테이블의 익스텐트 병합 정책 기간보다 Lookback 오래된 경우 익스텐트 누락됩니다. 익스텐트 검색 가능하도록 하려면 속성을 HotCache로 설정합니다Lookback.

균일 범위 날짜/시간 파티션 예제

코드 조각은 라는 timestamp형식화된 열 위에 균일한 datetime 날짜/시간 범위 파티션 키를 표시합니다. 을 각 파티션의 7d 크기로 참조 지점으로 사용 datetime(2021-01-01) 하며 익스텐트의 생성 시간을 재정의하지 않습니다.

{
  "ColumnName": "timestamp",
  "Kind": "UniformRange",
  "Properties": {
    "Reference": "2021-01-01T00:00:00",
    "RangeSize": "7.00:00:00",
    "OverrideCreationTime": false
  }
}

정책 개체

기본적으로 테이블의 데이터 분할 정책은 입니다 null. 이 경우 테이블의 데이터는 수집된 후에 다시 분할되지 않습니다.

데이터 분할 정책에는 다음과 같은 기본 속성이 있습니다.

  • PartitionKeys:

  • EffectiveDateTime:

    • 정책이 적용되는 UTC 날짜/시간입니다.
    • 이 속성은 선택 사항입니다. 지정하지 않으면 정책이 적용된 후 수집된 데이터에 정책이 적용됩니다.

주의

  • 과거에 날짜/시간 값을 설정하고 이미 수집된 데이터를 파티션할 수 있습니다. 그러나 이 방법은 분할 프로세스에 사용되는 리소스를 크게 늘릴 수 있습니다.
  • 대부분의 경우 새로 수집된 데이터만 분할하고 대량의 기록 데이터가 분할되지 않도록 하는 것이 좋습니다.
  • 기록 데이터를 분할하도록 선택하는 경우 정책을 변경할 때마다 최대 며칠의 단계에서 EffectiveDateTime 을 이전 datetime 으로 설정하여 점진적으로 분할하는 것이 좋습니다.

데이터 분할 예제

두 개의 파티션 키가 있는 데이터 분할 정책 개체입니다.

  1. 라는 tenant_id형식화된 열에 대한 string해시 파티션 키입니다.
    • 해시 함수를 XxHash64 사용하며, 를 권장 값128으로 MaxPartitionCount 설정하고 기본값 Seed1을 으로 설정합니다.
  2. 라는 timestamp형식 열에 대한 균일한 datetime 날짜/시간 범위 파티션 키입니다.
    • 각 파티션의 크기 7d 가 인 을 참조 지점으로 사용합니다datetime(2021-01-01).
{
  "PartitionKeys": [
    {
      "ColumnName": "tenant_id",
      "Kind": "Hash",
      "Properties": {
        "Function": "XxHash64",
        "MaxPartitionCount": 128,
        "Seed": 1,
        "PartitionAssignmentMode": "Uniform"
      }
    },
    {
      "ColumnName": "timestamp",
      "Kind": "UniformRange",
      "Properties": {
        "Reference": "2021-01-01T00:00:00",
        "RangeSize": "7.00:00:00",
        "OverrideCreationTime": false
      }
    }
  ]
}

추가 속성

다음 속성은 정책의 일부로 정의할 수 있습니다. 이러한 속성은 선택 사항이며 변경하지 않는 것이 좋습니다.

속성 Description 권장되는 값 기본값
MinRowCountPerOperation 단일 데이터 분할 작업의 원본 익스텐트 행 수 합계에 대한 최소 대상입니다. 0
MaxRowCountPerOperation 단일 데이터 분할 작업의 원본 익스텐트 행 수 합계에 대한 최대 대상입니다. 분할 작업에서 작업당 많은 양의 메모리 또는 CPU를 사용하는 경우 5M보다 낮은 값을 설정합니다. 0기본 대상이 5,000,000개 레코드인 입니다.
MaxOriginalSizePerOperation 단일 데이터 분할 작업의 원본 익스텐트의 원래 크기(바이트)의 합계에 대한 최대 대상입니다. 분할 작업에서 작업당 많은 양의 메모리 또는 CPU를 사용하는 경우 5GB보다 낮은 값을 설정합니다. 0기본 대상은 5,368,709,120바이트(5GB)입니다.

데이터 분할 프로세스

  • 데이터 분할은 클러스터에서 수집 후 백그라운드 프로세스로 실행됩니다.
    • 지속적으로 수집되는 테이블에는 아직 분할되지 않은 데이터의 "비상"이 항상 있어야 합니다(비호종 익스텐트).
  • 데이터 분할은 정책의 EffectiveDateTime 속성 값에 관계없이 핫 익스텐트에서만 실행됩니다.
    • 콜드 익스텐트 분할이 필요한 경우 캐싱 정책을 일시적으로 조정해야 합니다.

.show database extents partitioning statistics 명령을 사용하여 데이터베이스에서 정의된 정책을 사용하여 테이블의 분할 상태 모니터링할 수 있습니다.

용량 분할

  • 데이터 분할 프로세스로 인해 더 많은 범위가 생성됩니다. 클러스터는 익스텐트 병합 용량을 점진적으로 늘려 익스텐트 병합 프로세스를 유지할 수 있습니다.
  • 수집 처리량이 많거나 분할 정책이 정의된 충분한 수의 테이블이 있는 경우 클러스터는 익스텐트 분할 프로세스를 유지할 수 있도록 익스텐트 파티션 용량을 점진적으로 늘릴 수 있습니다.
  • 너무 많은 리소스를 사용하지 않도록 하기 위해 이러한 동적 증가는 제한됩니다. 완전히 사용되는 경우 한도를 넘어 서서히 선형적으로 늘려야 할 수 있습니다.
    • 용량을 늘리면 클러스터의 리소스 사용이 크게 증가하는 경우 수동으로 또는 자동 크기 조정을 사용하도록 설정하여 클러스터를 스케일 아웃/할 수 있습니다.

제한 사항

  • 이미 5,000,000개 이상의 익스텐트가 있는 데이터베이스에서 데이터를 분할하려는 시도가 제한됩니다.
    • 이러한 경우 EffectiveDateTime 데이터베이스에 있는 테이블의 분할 정책 속성이 몇 시간 지연되므로 구성 및 정책을 다시 계산할 수 있습니다.

분할된 열의 이상값

  • 다음 상황은 클러스터의 노드에서 데이터를 불균형하게 분산하고 쿼리 성능을 저하시킬 수 있습니다.
    • 해시 파티션 키에 빈 문자열 또는 제네릭 값(예: 또는 N/A)과 같이 null 다른 값보다 훨씬 더 널리 사용되는 값이 포함되어 있는 경우
    • 값은 데이터 세트에서 더 널리 사용되는 엔터티(예: tenant_id)를 나타냅니다.
  • 균일한 범위 날짜/시간 파티션 키에 열의 대부분의 값과 "멀리" 있는 값의 비율이 충분히 크면 데이터 분할 프로세스의 오버헤드가 증가하고 클러스터가 추적해야 하는 작은 범위가 많을 수 있습니다. 이러한 상황의 예로 먼 과거 또는 미래의 날짜/시간 값이 있습니다.

두 경우 모두 데이터를 "수정"하거나 수집 전이나 수집 시 데이터의 관련 없는 레코드를 필터링하여 클러스터에서 데이터 분할의 오버헤드를 줄입니다. 예를 들어 업데이트 정책을 사용합니다.

관련 콘텐츠