Columnstore 인덱스 쿼리 성능

적용 대상:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics AnalyticsPlatform System(PDW)

columnstore 인덱스가 제공하도록 설계된 매우 빠른 쿼리 성능을 달성하기 위한 권장 사항입니다.

Columnstore 인덱스는 분석 및 데이터 웨어하우징 워크로드에서 최대 100배 더 나은 성능을 달성하고 기존 rowstore 인덱스보다 최대 10배 더 나은 데이터 압축을 달성할 수 있습니다. 이러한 권장 사항은 쿼리가 columnstore 인덱스가 제공하도록 설계된 매우 빠른 쿼리 성능을 달성하는 데 도움이 됩니다. columnstore 성능에 대한 추가 설명은 마지막에 있습니다.

쿼리 성능 향상을 위한 권장 사항

고성능 columnstore 인덱스를 구현하기 위한 몇 가지 권장 사항은 다음과 같습니다.

1. 전체 테이블 검색에서 더 많은 행 그룹을 제거할 수 있도록 데이터 구성

  • 삽입 순서를 활용합니다. 일반적인 데이터 웨어하우스에서 주로 데이터는 시간 순서에, 분석은 시간 차원에 삽입됩니다. 예를 들어 분기별 매출을 분석합니다. 이러한 종류의 워크로드의 경우 행 그룹 제거가 자동으로 수행됩니다. SQL Server 2016(13.x)에서는 쿼리 처리의 일부로 건너뛴 행 그룹 수를 확인할 수 있습니다.

  • rowstore 클러스터형 인덱스 활용 일반 쿼리 조건자가 행의 삽입 순서와 관련되지 않은 열(예: C1)에 있는 경우 열 C1에서 클러스터형 rowstore 인덱스를 만든 다음 클러스터형 rowstore 인덱스를 삭제하여 클러스터형 columnstore 인덱스를 만듭니다. 명시적으로 사용하여 MAXDOP = 1클러스터형 columnstore 인덱스가 만들어지면 결과 클러스터형 columnstore 인덱스는 C1 열에서 완벽하게 정렬됩니다. 지정 MAXDOP = 8하면 8개 행 그룹에 걸쳐 값이 겹치는 것을 볼 수 있습니다. 이 전략의 일반적인 경우는 큰 데이터 집합을 사용하여 columnstore 인덱스(columnstore 인덱스)를 처음 만들 때입니다. NCCI(비클러스터형 columnstore 인덱스)의 경우 기본 rowstore 테이블에 클러스터형 인덱스가 있으면 행이 이미 정렬됩니다. 이 경우 결과 비클러스터형 columnstore 인덱스는 자동으로 정렬됩니다. 한 가지 중요한 점으로 columnstore 인덱스는 기본적으로 행 순서를 유지 관리하지 않음을 참고하세요. 새 행이 삽입되거나 이전 행이 업데이트되면 분석 쿼리 성능이 저하될 수 있으므로 프로세스를 반복해야 할 수 있습니다.

  • 테이블 분할을 활용합니다. columnstore 인덱스를 분할한 다음 파티션 제거를 사용하여 검사할 행 그룹 수를 줄일 수 있습니다. 예를 들어 팩트 테이블에는 고객이 구매한 내용이 저장됩니다. 일반적인 쿼리 패턴은 특정 고객이 수행한 분기별 구매를 찾는 것입니다. 삽입 순서를 고객 열의 분할과 결합할 수 있습니다. 각 파티션에는 특정 고객에 대한 행이 시간 순서로 포함됩니다. 또한 columnstore에서 데이터를 제거해야 하는 경우 테이블 분할을 사용하는 것이 좋습니다. 더 이상 필요하지 않은 파티션을 전환하고 자르는 것은 더 작은 행 그룹을 사용하여 도입된 조각화를 생성하지 않고 데이터를 삭제하는 효율적인 전략입니다.

  • 많은 양의 데이터를 삭제하지 않습니다. 행 그룹에서 압축된 행을 제거하는 것은 동기 작업이 아닙니다. 행 그룹을 압축 해제하고 행을 삭제한 다음 다시 압축하는 데 비용이 많이 듭니다. 따라서 압축된 행 그룹에서 데이터를 삭제하는 경우 행을 더 적게 반환하더라도 이러한 행 그룹은 계속 검색됩니다. 여러 행 그룹에 대해 삭제된 행 수가 더 적은 행 그룹으로 병합될 만큼 충분히 큰 경우 columnstore를 다시 구성하면 인덱스의 품질이 향상되고 쿼리 성능이 향상됩니다. 데이터 삭제 프로세스에서 일반적으로 전체 행 그룹을 비우는 경우 테이블 분할을 사용하고, 더 이상 필요하지 않은 파티션을 전환하고, 행을 삭제하는 대신 잘라낼 수 있습니다.

    참고 항목

    SQL Server 2019(15.x)부터 튜플 이동기는 내부 임계값에 따라 일정 시간 동안 존재했던 더 작은 OPEN 델타 행 그룹을 자동으로 압축하거나 많은 수의 행이 삭제된 곳에서 COMPRESSED 행 그룹을 병합하는 백그라운드 병합 작업의 도움을 받습니다. 그러면 시간이 지남에 따라 columnstore 인덱스 품질이 향상됩니다.
    columnstore 인덱스에서 많은 양의 데이터를 삭제해야 하는 경우 이 작업을 지속적으로 더 작은 삭제 배치로 분할하는 것이 좋습니다. 이렇게 하면 백그라운드 병합 태스크가 더 작은 행 그룹을 병합하고 인덱스 품질을 개선하는 태스크를 처리할 수 있어 데이터 삭제 후의 인덱스 재구성 유지 관리 기간을 예약하지 않아도 됩니다.
    columnstore 용어 및 개념에 대한 자세한 내용은 Columnstore 인덱스: 개요를 참조하세요.

2. columnstore 인덱스를 병렬로 만들기에 충분한 메모리 계획

인덱스 만들기는 메모리가 제한되지 않는 한 기본적으로 병렬 작업입니다. 병렬로 인덱스를 만들려면 직렬로 인덱스를 만들 때보다 많은 메모리가 필요합니다. 메모리가 충분하면 동일한 열에 B-트리를 작성할 때보다 1.5배 많은 메모리가 columnstore 인덱스를 만드는 데 사용됩니다.

columnstore 인덱스를 만드는 데 필요한 메모리는 열 수, 문자열 열 수, DOP(병렬 처리 수준) 및 데이터의 특성에 따라 달라집니다. 예를 들어 테이블에 100만 개 미만의 행이 있는 경우 SQL Server는 하나의 스레드만 사용하여 columnstore 인덱스를 만듭니다.

테이블에 100만 개 이상의 행이 있지만 SQL Server가 MAXDOP를 사용하여 인덱스를 만들 만큼 충분한 메모리 부여를 얻을 수 없는 경우 SQL Server는 사용 가능한 메모리 부여에 맞게 필요에 따라 자동으로 감소 MAXDOP 합니다. 일부 경우 제한된 메모리로 인덱스를 작성하도록 DOP를 줄여야 합니다.

SQL Server 2016(13.x)부터 쿼리는 항상 일괄 처리 모드에서 작동합니다. 이전 릴리스에서는 DOP가 1보다 큰 경우에만 일괄 처리 실행이 사용됩니다.

Columnstore 성능 설명

Columnstore 인덱스는 고속 메모리 내 일괄 처리 모드 처리와 I/O 요구 사항을 크게 줄이는 기술을 결합하여 높은 쿼리 성능을 달성합니다. 분석 쿼리는 많은 수의 행을 검색하므로 일반적으로 IO 바인딩되므로 쿼리 실행 중에 I/O를 줄이는 것이 columnstore 인덱스의 디자인에 중요합니다. 데이터를 메모리로 읽은 후에는 메모리 내 작업 수를 줄이는 것이 중요합니다.

Columnstore 인덱스는 I/O는 줄이고, 높은 데이터 압축, columnstore 제거, 행 그룹 제거 및 일괄 처리를 통해 메모리 내 작업을 최적화합니다.

데이터 압축

Columnstore 인덱스는 rowstore 인덱스보다 최대 10배 더 큰 데이터 압축을 달성합니다. 이렇게 하면 분석 쿼리를 실행하는 데 필요한 I/O가 크게 감소하므로 쿼리 성능이 향상됩니다.

  • Columnstore 인덱스는 디스크에서 압축된 데이터를 읽습니다. 즉, 메모리로 읽어야 하는 데이터의 바이트가 줄어듭니다.

  • Columnstore 인덱스는 데이터를 압축된 형식으로 메모리에 저장하므로 동일한 데이터를 메모리로 읽는 횟수를 줄여 I/O를 줄입니다. 예를 들어 압축률이 10배인 columnstore 인덱스에서는 데이터를 압축되지 않은 형태로 저장하는 작업과 비교해 볼 때 메모리에 10배 이상의 데이터를 보관할 수 있습니다. 메모리에 더 많은 데이터가 있으면 columnstore 인덱스가 디스크에서 추가 읽기를 수행하지 않고 메모리에 필요한 데이터를 찾을 가능성이 높습니다.

  • Columnstore 인덱스는 행이 아닌 열별로 데이터를 압축하여 높은 압축 속도를 달성하고 디스크에 저장된 데이터의 크기를 줄입니다. 각 열은 독립적으로 압축 및 저장됩니다. 열 내의 데이터는 항상 동일한 데이터 형식을 가지며 값이 비슷한 경향이 있습니다. 데이터 압축 기술은 값이 비슷할 경우 더 높은 압축률을 달성할 수 있습니다.

  • 예를 들어 팩트 테이블에 고객 주소가 저장되고 국가/지역에 대한 열이 있는 경우 가능한 총 값 수는 200개 미만입니다. 이러한 값 중 일부는 여러 번 반복됩니다. 팩트 테이블에 1억 개의 행이 있는 경우 국가/지역 열은 쉽게 압축되며 스토리지가 거의 필요하지 않습니다. 행 단위 압축은 이러한 방식으로 열 값의 유사성을 활용할 수 없으며 더 많은 바이트를 사용하여 국가/지역 열의 값을 압축합니다.

열 제거

Columnstore 인덱스는 쿼리 결과에 필요하지 않은 열에서 읽기를 건너뜁니다. 열 제거라고 하는 이 기능은 또한 쿼리 실행에 필요한 I/O를 줄이므로 쿼리 성능이 향상됩니다.

  • 데이터가 열별로 구성되고 압축되므로 열 제거가 가능합니다. 반면 데이터가 행 단위로 저장되면 각 행의 열 값이 물리적으로 함께 저장되므로 쉽게 구분할 수 없습니다. 쿼리 프로세서는 특정 열 값을 검색하려면 전체 행에서 읽어야 하며, 이로 인해 추가 데이터가 메모리로 불필요하게 읽혀지므로 I/O가 증가합니다.

  • 예를 들어 테이블에 50개의 열이 있고 쿼리에서 해당 열 중 5개만 사용하는 경우 columnstore 인덱스는 디스크에서 5개의 열만 가져옵니다. 나머지 45개 열은 읽기를 건너뜁니다. 이렇게 하면 모든 열의 크기가 비슷하면 I/O가 90% 감소합니다. 동일한 데이터가 rowstore에 저장되면 쿼리 프로세서는 추가로 45개 열을 모두 읽어야 합니다.

행 그룹 제거

전체 테이블 검색의 경우 데이터의 많은 비율이 일반적으로 쿼리 조건자 조건과 일치하지 않습니다. 메타데이터를 사용하면 columnstore 인덱스는 실제 I/O 없이 쿼리 결과에 필요한 데이터가 포함되지 않은 행 그룹에서 읽기를 건너뛸 수 있습니다. 행 그룹 제거라고 하는 이 기능은 전체 테이블 검색에 대한 I/O를 줄여 쿼리 성능을 향상시킵니다.

columnstore 인덱스가 전체 테이블 검색을 수행해야 하는 경우는 언제인가요?

SQL Server 2016(13.x)부터 rowstore 힙에서처럼 클러스터형 columnstore 인덱스에 하나 이상의 일반 비클러스터형 B-트리 인덱스를 만들 수 있습니다. 비클러스터형 B-트리 인덱스는 같음 조건자 또는 값 범위가 작은 조건자가 있는 쿼리의 속도를 높일 수 있습니다. 더 복잡한 조건자의 경우 쿼리 최적화 프로그램에서 전체 테이블 검색을 선택할 수도 있습니다. 행 그룹을 건너뛰는 기능이 없으면 전체 테이블 검색은 특히 큰 테이블의 경우 매우 시간이 많이 소요됩니다.

분석 쿼리는 전체 테이블 검색에 대한 행 그룹 제거의 이점을 언제 활용하나요?

예를 들어 소매업은 클러스터형 columnstore 인덱스가 있는 팩트 테이블을 사용하여 판매 데이터를 모델링했습니다. 각 새 판매는 제품이 판매된 날짜를 포함하여 트랜잭션의 다양한 특성을 저장합니다. 흥미롭게도 columnstore 인덱스가 정렬된 순서를 보장하지 않더라도 이 테이블의 행은 날짜 정렬 순서로 로드됩니다. 시간이 지남에 따라 이 테이블은 증가합니다. 소매업은 지난 10년 동안 판매 데이터를 유지할 수 있지만 분석 쿼리는 지난 분기에 대한 집계만 계산하면 됩니다. Columnstore 인덱스는 날짜 열의 메타데이터만 확인하여 이전 39분기의 데이터에 액세스하지 않도록 할 수 있습니다. 이는 메모리로 읽고 처리되는 데이터의 양을 추가로 97% 줄이는 것입니다.

전체 테이블 검색에서 건너뛰는 행 그룹은 무엇입니까?

제거할 행 그룹을 결정하기 위해 columnstore 인덱스는 메타데이터를 사용하여 각 행 그룹에 대한 각 열 세그먼트의 최소값과 최대값을 저장합니다. 열 세그먼트 범위 중 어떤 것도 쿼리 조건자의 조건에 맞지 않을 경우 실제 IO를 수행하지 않고 행 그룹 전체를 건너뜁니다. 이는 일반적으로 데이터가 정렬된 순서로 로드되고 행이 정렬되도록 보장되지는 않지만 유사한 데이터 값이 동일한 행 그룹 또는 인접한 행 그룹 내에 있는 경우가 많기 때문에 작동합니다.

행 그룹에 대한 자세한 내용은 Columnstore 인덱스 디자인 지침을 참조 하세요.

일괄 처리 모드 실행

일괄 처리 모드 실행이란 실행 효율성을 위해 일반적으로 최대 900개의 행을 함께 행 세트로 처리하는 것을 말합니다. 예를 들어 쿼리 SELECT SUM (Sales) FROM SalesData 는 SalesData 테이블의 총 매출을 집계합니다. 일괄 처리 모드 실행에서 쿼리 실행 엔진은 900개 값 그룹으로 집계를 계산합니다. 이렇게 하면 각 행에 대한 비용을 지불하는 대신 액세스 비용 및 다른 유형의 오버헤드가 일괄 처리의 모든 행에 분산되어 코드 경로가 크게 줄어듭니다. 일괄 처리 모드 처리는 가능하면 압축된 데이터에서 작동하며 행 모드 처리에서 사용되는 일부 교환 연산자를 제거합니다. 이렇게 하면 크기가 큰 순서로 분석 쿼리의 실행 속도가 빨라질 수 있습니다.

모든 쿼리 실행 연산자를 일괄 처리 모드로 실행할 수 있는 것은 아닙니다. 예를 들어 삽입, 삭제 또는 업데이트와 같은 DML 작업은 한 번에 행을 실행합니다. 일괄 처리 모드 연산자는 쿼리 성능 속도 향상을 위해 Scan, Join, Aggregate, Sort 등과 같은 연산자를 대상으로 합니다. columnstore 인덱스는 SQL Server 2012(11.x)에서 도입되었으므로 일괄 처리 모드에서 실행할 수 있는 연산자를 확장하기 위한 지속적인 노력이 있습니다. 다음 표에서 제품 버전에 따라 일괄 처리 모드로 실행되는 연산자를 보여 줍니다.

일괄 처리 모드 연산자 언제 사용되나요? SQL Server 2012(11.x) SQL Server 2014(12.x) SQL Server 2016(13.x) 및 SQL Database1 주석
DML 작업(삽입, 삭제, 업데이트, 병합) 아니요 아니요 아니요 DML은 병렬이 아니므로 일괄 처리 모드 작업이 아닙니다. 직렬 모드 일괄 처리를 사용하도록 설정하더라도 DML을 일괄 처리 모드로 처리할 수 있도록 허용하면 큰 이득이 표시되지 않습니다.
columnstore 인덱스 검사 스캔 사용할 수 없음 columnstore 인덱스의 경우 조건자를 SCAN 노드에 푸시할 수 있습니다.
columnstore 인덱스 검사(비클러스터형) 스캔
인덱스 검색 사용할 수 없음 사용할 수 없음 아니요 행 모드에서 비클러스터형 B-트리 인덱스로 검색 작업을 수행합니다.
compute scalar 스칼라 값으로 계산되는 식입니다. 데이터 형식에는 몇 가지 제한 사항이 있습니다. 모든 일괄 처리 모드 연산자에서도 마찬가지입니다.
연결 UNION 및 UNION ALL 아니요
filter 조건자 적용
해시 일치 해시 기반 집계 함수, 외부 해시 조인, 오른쪽 해시 조인, 왼쪽 해시 조인, 오른쪽 내부 조인, 왼쪽 내부 조인 집계에 대한 제한 사항: 문자열에 min/max가 없습니다. 사용할 수 있는 집계 함수는 sum/count/avg/min/max입니다.
조인 제한 사항: 정수가 아닌 형식에서 일치하지 않는 형식 조인 없음
병합 조인 아니요 아니요 아니요
다중 스레드 쿼리
중첩 루프 아니요 아니요 아니요
MAXDOP 1에서 실행되는 단일 스레드 쿼리 아니요 아니요
직렬 쿼리 계획을 사용하는 단일 스레드 쿼리 아니요 아니요
sort columnstore 인덱스가 있는 SCAN의 Order by 절입니다. 아니요 아니요
최상위 정렬 아니요 아니요
창 집계 사용할 수 없음 사용할 수 없음 SQL Server 2016(13.x)의 새 연산자입니다.

1 SQL Server 2016(13.x), SQL Database 프리미엄 계층, 표준 계층 - S3 이상 및 모든 vCore 계층 및 분석 플랫폼 시스템(PDW)에 적용됩니다.

자세한 내용은 쿼리 처리 아키텍처 가이드를 참조하세요.

집계 푸시다운

SCAN 노드에서 정규화된 행을 가져오고 일괄 처리 모드에서 값을 집계하기 위한 집계 계산의 일반 실행 경로입니다. 이렇게 하면 성능이 양호하지만 SQL Server 2016(13.x)에서는 집계 작업을 SCAN 노드로 푸시하여 다음 조건이 충족되는 경우 일괄 처리 모드 실행 위에 있는 크기의 순서로 집계 계산 성능을 향상시킬 수 있습니다.

  • 집계는 MIN, MAX, SUMCOUNTCOUNT(*).
  • 집계 연산자는 SCAN 노드 또는 SCAN GROUP BY노드 위에 있어야 합니다.
  • 이 집계는 고유 집계가 아닙니다.
  • 집계 열이 문자열 열이 아닙니다.
  • 집계 열은 가상 열이 아닙니다.
  • 입력 및 출력 데이터 형식은 다음 중 하나여야 하며 64비트 내에 있어야 합니다.
    • tinyint, int, bigint, smallint, bit
    • smallmoney, moneydecimalnumeric 전체 자릿수 <= 18
    • smalldate, date, datetime, datetime2, time

예를 들어 집계 푸시다운은 아래 쿼리에서 모두 수행됩니다.

SELECT  productkey, SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI
GROUP BY productkey;
    
SELECT  SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI;

문자열 조건자 푸시다운

데이터 웨어하우스 스키마를 디자인할 때 권장되는 스키마 모델링은 하나 이상의 팩트 테이블과 여러 차원 테이블로 구성된 별모양 스키마 또는 눈송이 스키마를 사용하는 것입니다. 팩트 테이블비즈니스 측정값 또는 트랜잭션을 저장하고 차원 테이블은 팩트를 분석해야 하는 차원을 저장합니다.

예를 들어 팩트 차원은 지역, 제품 등의 집합을 나타내는 동안 특정 지역에서 특정 제품의 판매를 나타내는 레코드가 될 수 있습니다. 팩트 테이블과 차원 테이블은 기본/외래 키 관계를 통해 연결됩니다. 가장 일반적으로 사용되는 분석 쿼리는 하나 이상의 차원 테이블을 팩트 테이블에 조인하는 것입니다.

차원 테이블을 Products살펴보겠습니다. 일반적인 기본 키 ProductCode 는 일반적으로 문자열 데이터 형식으로 표현됩니다. 쿼리 성능을 위해 일반적으로 정수 열인 대리 키를 만들어 팩트 테이블에서 차원 테이블의 행을 참조하는 것이 가장 좋습니다.

columnstore 인덱스는 숫자 또는 정수 기반 키를 매우 효율적으로 포함하는 조인/조건자를 사용하여 분석 쿼리를 실행합니다. 그러나 많은 고객 워크로드에서 팩트/차원 테이블을 연결하는 문자열 기반 열을 사용하고 그 결과 columnstore 인덱스를 사용한 쿼리 성능이 수행되지 않았습니다. SQL Server 2016(13.x)은 문자열 열이 있는 조건자를 SCAN 노드로 푸시하여 문자열 기반 열이 있는 분석 쿼리의 성능을 크게 향상시킵니다.

문자열 조건자 푸시다운은 열에 대해 만든 기본/보조 사전을 활용하여 쿼리 성능을 향상시킵니다. 예를 들어 100개의 고유 문자열 값으로 구성된 행 그룹 내에서 문자열 열 세그먼트를 살펴보겠습니다. 즉, 1백만 개의 행이라고 가정하면 각 개별 문자열 값은 평균 10,000번 참조됩니다.

문자열 조건자 푸시다운을 사용하면 쿼리 실행이 사전의 값에 대해 조건자를 계산하고, 자격이 있으면 사전 값을 참조하는 모든 행이 자동으로 정규화됩니다. 이렇게 하면 다음과 같은 두 가지 방법으로 성능이 향상됩니다.

  1. 정규화된 행만 반환되므로 SCAN 노드에서 벗어나야 하는 행의 수가 줄어듭니다.

  2. 문자열 비교 수가 크게 줄어듭니다. 이 예제에서는 100만 개 비교와 비교하여 100개의 문자열 비교만 필요합니다. 아래에 설명된 대로 몇 가지 제한 사항이 있습니다.

    • 델타 행 그룹에 대한 문자열 조건자 푸시다운이 없습니다. 델타 행 그룹의 열에 대한 사전이 없습니다.
    • 사전이 64KB 항목을 초과하는 경우 문자열 조건자 푸시다운이 없습니다.
    • NULL을 평가하는 식은 지원되지 않습니다.

세그먼트 제거

데이터 형식 선택 항목은 columnstore 인덱스의 쿼리에 대한 일반적인 필터 조건자를 기반으로 쿼리 성능에 상당한 영향을 미칠 수 있습니다.

columnstore 데이터에서 행 그룹은 열 세그먼트로 구성됩니다. 각 세그먼트에는 세그먼트를 읽지 않고 빠르게 제거하도록 허용하는 메타데이터가 있습니다. 이 세그먼트 제거는 숫자, 날짜 및 시간 데이터 형식 및 크기가 2보다 작거나 같은 datetimeoffset 데이터 형식에 적용됩니다. SQL Server 2022(16.x)부터 세그먼트 제거 기능은 문자열, 이진, guid 데이터 형식 및 2보다 큰 배율에 대한 datetimeoffset 데이터 형식으로 확장됩니다.

문자열 최소/최대 세그먼트 제거(SQL Server 2022(16.x) 이상)를 지원하는 SQL Server 버전으로 업그레이드한 후에는 REBUILD 또는 DROP/CREATE를 사용하여 다시 작성될 때까지 columnstore 인덱스가 이 기능에 도움이 되지 않습니다.

세그먼트 제거는 (max) 데이터 형식 길이와 같은 LOB 데이터 형식에는 적용되지 않습니다.

현재는 SQL Server 2022(16.x) 이상에서만 조건자의 접두 LIKE 사에 대해 클러스터형 columnstore 행 그룹 제거를 지원합니다 column LIKE 'string%'. 세그먼트 제거는 접두사 이외의 용도(예: column LIKE '%string'.)에 LIKE대해 지원되지 않습니다.

Azure Synapse Analytics에서 SQL Server 2022(16.x)부터 정렬된 클러스터형 columnstore 인덱스를 만들 수 있습니다. 따라서 특히 문자열 열의 경우 세그먼트 제거를 지원하기 위해 열별로 정렬할 수 있습니다. 정렬된 클러스터형 columnstore 인덱스의 경우 인덱스 키의 첫 번째 열에서 세그먼트 제거가 정렬되므로 가장 효과적입니다. 테이블의 다른 열에서 세그먼트 제거로 인한 성능 향상은 예측하기 어렵습니다. 정렬된 클러스터형 columnstore 인덱스에 대한 자세한 내용은 큰 데이터 웨어하우스 테이블에 대해 정렬된 클러스터형 columnstore 인덱스 사용을 참조 하세요.

쿼리 연결 옵션 SET STATISTICS IO를 사용하여 작동 중인 세그먼트 제거를 볼 수 있습니다. 세그먼트 제거가 발생했음을 나타내려면 다음과 같은 출력을 찾습니다. 행 그룹은 열 세그먼트로 구성되므로 세그먼트 제거를 나타낼 수 있습니다. 쿼리의 아래 SET STATISTICS IO 출력 예제는 쿼리에서 약 83%의 데이터를 건너뛰었다.

...
Table 'FactResellerSalesPartCategoryFull'. Segment reads 16, segment skipped 83.
...

다음 단계