정렬 키 작업 - Amazon Redshift
복합 정렬 키인터리브 정렬 키

정렬 키 작업

참고

SORTKEY AUTO로 테이블을 생성하는 것이 좋습니다. 그러면 Amazon Redshift가 자동 테이블 최적화를 사용하여 정렬 키를 선택합니다. 자세한 내용은 자동 테이블 최적화 작업 섹션을 참조하세요. 이 섹션의 나머지 부분에서는 정렬 순서에 대한 세부 정보를 제공합니다.

테이블을 생성하면서 1개 이상의 열을 정렬 키로 정의할 수도 있습니다. 그러면 처음에 데이터를 빈 테이블에 로드할 때 열이 정렬 순서대로 디스크에 저장됩니다. 정렬 키 열에 대한 정보가 쿼리 플래너로 전달되고, 플래너는 이 정보를 사용해 데이터 정렬 방식의 활용 계획을 작성합니다. 자세한 내용은 CREATE TABLE 섹션을 참조하세요. 정렬 키 생성 모범 사례에 대한 자세한 내용은 최상의 정렬 키 선택 섹션을 참조하세요.

정렬은 범위 제한 조건자를 효율적으로 처리할 수 있는 방법입니다. Amazon Redshift는 열 기반 데이터를 1MB 디스크 블록에 저장합니다. 각 블록의 최소 값과 최대 값은 메타데이터로 저장됩니다. 쿼리가 범위 제한 조건자를 사용하는 경우에는 쿼리 프로세서가 테이블 스캔 도중 최소/최대 값을 사용하여 상당수의 블록을 빠르게 건너뛸 수 있습니다. 예를 들어 테이블에 날짜별로 정렬된 5년 치의 데이터를 저장되고 쿼리가 날짜 범위를 한 달로 지정한다고 가정합니다. 이 경우 스캔에서 디스크 블록의 최대 98%를 제거할 수 있습니다. 하지만 데이터가 정렬되어 있지 않다면 스캔해야 하는 디스크 블록의 수가 늘어납니다(모든 블록도 가능).

복합 또는 인터리브 정렬 키를 지정할 수 있습니다. 쿼리 조건자가 순서상 정렬 키 열의 하위 집합인 접두사를 사용할 때는 복합 정렬 키가 더욱 효율적입니다. 인터리브 정렬 키는 정렬 키에서 각 열마다 똑같은 가중치를 부여하기 때문에 쿼리 조건자가 정렬 키를 구성하는 열의 모든 하위 집합을 순서에 상관없이 사용할 수 있습니다.

선택한 정렬 키가 쿼리 성능에 미치는 영향을 알고 싶다면 EXPLAIN 명령을 사용하십시오. 자세한 내용은 쿼리 계획 및 실행 워크플로우 섹션을 참조하세요.

정렬 유형의 정의하려면 CREATE TABLE 또는 CREATE TABLE AS 문에서 INTERLEAVED 또는 COMPOUND 키워드를 사용하십시오. 기본 키워드는 COMPOUND입니다. 테이블이 INSERT, UPDATE 또는 DELETE로 정기적으로 업데이트되지 않는 한 기본 COMPOUND가 권장됩니다. 인터리브 정렬 키는 최대 8개까지 열을 사용할 수 있습니다. 데이터와 클러스터 크기에 따라 VACUUM REINDEX는 인터리브된 정렬 키를 분석하기 위한 추가적인 패스를 만들기 때문에 VACUUM FULL보다 상당히 더 많은 시간이 소요됩니다. 인터리브된 정렬은 복합 정렬보다 많은 행을 다시 배열해야 하므로 인터리브된 테이블에서는 정렬 및 병합 작업이 더 오래 걸릴 수 있습니다.

테이블 정렬 키를 확인하려면 SVV_TABLE_INFO 시스템 뷰에 대한 쿼리를 실행하십시오.

복합 정렬 키

복합 키는 정렬 키를 정의할 때 나열되는 모든 열로 구성되며, 나열 순서를 따릅니다. 이 정렬 키는 쿼리의 필터가 필터나 조인 같이 정렬 키의 접두사를 사용하는 조건을 적용할 때 가장 유용합니다. 쿼리가 기본 열을 참조하지 않고 보조 정렬 열에만 의존할 경우에는 복합 정렬의 성능 이점이 줄어듭니다. 이때는 COMPOUND기 기본 정렬 유형입니다.

복합 정렬 키는 조인 작업과 GROUP BY 및 ORDER BY 작업, 그리고 PARTITION BY와 ORDER BY를 사용하는 창 함수의 속도를 높이는 효과가 있습니다. 예를 들어 해시 조인보다 빠를 때가 많은 병합 조인은 데이터가 조인 열을 기준으로 분산 및 사전 정렬되어야 가능합니다. 그 밖에 압축 성능을 높이는 데도 복합 정렬 키가 효과적입니다.

이미 데이터가 로드되어 정렬까지 마친 테이블에 행을 추가하면 미정렬 영역이 증가하여 성능에 커다란 영향을 미칩니다. 이러한 영향은 테이블이 인터리브 정렬을 사용할 때, 특히 정렬 열에 날짜나 타임스탬프 열 같이 점차 증가하는 데이터가 포함되어 있으면 더욱 커집니다. 따라서 정기적으로, 특히 대용량 데이터를 로드한 후에는 VACUUM 작업을 실행하여 데이터를 다시 정렬 및 분석해야 합니다. 자세한 내용은 정렬되지 않은 리전 크기 관리 섹션을 참조하세요. 정리(VACUUM)를 통한 데이터 재정렬을 마친 후에는 ANALYZE 명령을 실행하여 쿼리 플래너의 통계 메타데이터를 업데이트하는 것이 좋습니다. 자세한 내용은 테이블 분석 섹션을 참조하세요.

인터리브 정렬 키

인터리브 정렬 키는 정렬 키에서 각 열, 즉 열의 하위 집합에 똑같은 가중치를 부여합니다. 다수의 쿼리가 다른 열을 필터로 사용하는 경우에는 인터리브 정렬 키를 통해 쿼리의 성능을 높일 수 있는 경우가 종종 있습니다. 그 밖에 쿼리가 보조 정렬 열에서 제한적인 조건자를 사용할 때도 인터리브 정렬이 복합 정렬과 비교하여 쿼리 성능을 크게 높여주는 효과가 있습니다.

중요

자격 증명 열, 날짜, 타임스탬프와 같이 단순하게 증가하는 속성이 있는 열에서는 인터리브 정렬 키를 사용하지 마십시오.

단, 인터리브 정렬 키를 사용하여 향상되는 성능 이점과 로드 및 정리 시간이 늘어나는 문제를 서로 비교하여 검토해야 합니다.

인터리브 정렬은 WHERE 절에서 1개 이상의 정렬 키를 기준으로 필터링하여 선택의 폭이 매우 제한적인 쿼리를 실행할 때 가장 효과적입니다(예: select c_name from customer where c_region = 'ASIA'). 이때는 제한적으로 정렬되는 열의 수와 함께 인터리브 정렬의 이점도 커집니다.

인터리브 정렬은 대용량 테이블에서 더욱 효과적입니다. 각 슬라이스에 정렬이 적용됩니다. 따라서 인터리브 정렬은 테이블이 슬라이스당 여러 개의 1MB 블록을 요구할 만큼 충분히 클 때 가장 효과적입니다. 여기서 쿼리 프로세서는 제한적 조건자를 사용하여 블록을 상당 부분을 건너뛸 수 있습니다. 테이블이 사용하는 블록 수를 확인하려면 STV_BLOCKLIST 시스템 뷰에 대한 쿼리를 실행하십시오.

인터리브 정렬은 단일 열을 기준으로 정렬할 때 열 값에 긴 공통 접두사가 포함되어 있다면 복합 정렬보다 뛰어난 성능을 발휘할 수 있습니다. 예를 들어 URL은 공통적으로 "http://www"로 시작하기 마련입니다. 이때 복합 정렬 키는 접두사에서 사용할 수 있는 문자 수가 제한되어 있기 때문에 키가 중복되는 일이 다수 발생합니다. 하지만 인터리브 정렬은 영역 지도(zone map) 값에 내부 압축 방식을 사용하기 때문에 공통 접두사가 긴 열 값 사이에서도 쉽게 구분할 수 있습니다.

Amazon Redshift 프로비저닝된 클러스터를 Amazon Redshift Serverless로 마이그레이션할 때 Redshift 는 인터리브된 정렬 키와 DISTSTYLE KEY가 있는 테이블을 복합 정렬 키로 변환합니다. DISTSTYLE은 변경되지 않습니다. 배포 스타일에 대한 자세한 내용은 데이터 배포 스타일 사용을 참조하십시오.

VACUUM REINDEX

이미 데이터가 로드되어 정렬까지 마친 테이블에 행을 추가하면 시간이 지나면서 성능이 저하될 수 있습니다. 이러한 성능 저하는 복합 정렬과 인터리브 정렬에 모두 발생하지만 인터리브 테이블에 미치는 영향이 더욱 큽니다. VACUUM이 정렬 순서를 복원하기는 하지만 새로운 인터리브 데이터를 병합하려면 모든 데이터 블록을 수정해야 하는 경우도 있기 때문에 인터리브 테이블일 때 작업 시간이 더욱 오래 걸릴 수 있습니다.

Amazon Redshift는 테이블에 데이터를 처음 로드할 때 정렬 키 열의 값 분산을 분석한 후 해당 정보를 사용하여 정렬 키 열에서 최적의 인터리브를 구합니다. 이후 테이블 크기가 커지면 정렬 키 열의 값 분산도 특히 날짜 또는 타임스탬프 열에서 변동, 즉 스큐가 일어날 수 있습니다. 스큐가 너무 커지면 성능까지 영향을 받게 됩니다. 이때 정렬 키를 다시 분석하여 성능을 복원하려면 REINDEX 키워드와 함께 VACUUM 명령을 실행하십시오. 단, VACUUM REINDEX는 데이터에 대한 추가 분석이 필요하기 때문에 인터리브 테이블에 대한 표준 VACUUM보다 시간이 오래 걸릴 수 있습니다. KEY 분산 스큐와 마지막 REINDEX 시간에 대한 자세한 내용은 SVV_INTERLEAVED_COLUMNS 시스템 뷰에 대한 쿼리를 실행하여 확인할 수 있습니다.

VACUUM 실행 주기와 VACUUM REINDEX 실행 시점에 대한 자세한 내용은 reindex 실행 여부 결정 섹션을 참조하세요.