Columnstore 인덱스 쿼리 성능
적용 대상: 
SQL Server Azure SQL 데이터베이스 Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System(PDW)
이 문서에는 columnstore 인덱스를 사용하여 빠른 쿼리 성능을 달성하기 위한 권장 사항이 포함되어 있습니다.
Columnstore 인덱스는 분석 및 데이터 웨어하우징 워크로드에서 성능이 최대 100배 향상되고 기존 rowstore 인덱스보다 최대 10배 더 나은 데이터 압축을 달성할 수 있습니다. 이러한 권장 사항은 쿼리가 columnstore 인덱스가 제공하도록 설계된 빠른 쿼리 성능을 달성하는 데 도움이 됩니다.
쿼리 성능 개선을 위한 권장 사항
다음은 columnstore 인덱스가 제공하도록 설계된 매우 빠른 쿼리 성능을 달성하기 위한 권장 사항입니다.
1. 전체 테이블 검색에서 더 많은 행 그룹을 제거할 수 있도록 데이터 구성
삽입 순서를 신중하게 선택합니다. 일반적인 데이터 웨어하우스에서 주로 데이터는 시간 순서에, 분석은 시간 차원에 삽입됩니다. 예를 들어 분기별 매출을 분석합니다. 이러한 종류의 워크로드의 경우 행 그룹 제거가 자동으로 수행됩니다. SQL Server 2016(13.x)에서는 쿼리 처리의 일부로 건너뛴 행 그룹 수를 확인할 수 있습니다.
rowstore 클러스터형 인덱스 사용 일반적인 쿼리 조건자가 삽입 순서와 관련이 없는 열(예
C1: 열)에 있는 경우 열C1에 rowstore 클러스터형 인덱스 만들기 그런 다음 rowstore 클러스터형 인덱스 삭제 및 클러스터형 columnstore 인덱스 만들기 명시적으로 사용하여MAXDOP = 1클러스터형 columnstore 인덱스 만들기의 결과 클러스터형 columnstore 인덱스는 열C1에서 완벽하게 정렬됩니다. 지정MAXDOP = 8하면 8개 행 그룹에 걸쳐 값이 겹치는 것을 볼 수 있습니다. NCCI(비클러스터형 columnstore 인덱스)의 경우 테이블에 rowstore 클러스터형 인덱스가 있는 경우 행은 이미 클러스터형 인덱스 키로 정렬됩니다. 이 경우 비클러스터형 columnstore 인덱스도 자동으로 정렬됩니다. columnstore 인덱스는 기본적으로 행 순서를 유지하지 않습니다. 새 행이 삽입되거나 이전 행이 업데이트되면 분석 쿼리 성능이 저하될 수 있으므로 프로세스를 반복해야 할 수 있습니다.테이블 분할을 구현합니다. columnstore 인덱스를 분할한 다음 파티션 제거를 사용하여 검사할 행 그룹 수를 줄일 수 있습니다. 예를 들어 팩트 테이블에는 고객이 구매한 내용이 저장됩니다. 일반적인 쿼리 패턴은 분기별 구매를 찾는 것입니다
customer. 이 경우 삽입 순서 열을 열의customer분할과 결합합니다. 각 파티션에는 삽입 시 정렬된 각customer파티션에 대한 행이 포함됩니다. 또한 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를 1로 줄여야 합니다.
SQL Server 2016(13.x) 이후 쿼리는 항상 일괄 처리 모드에서 작동합니다. 이전 릴리스에서는 DOP가 1보다 큰 경우에만 일괄 처리 실행이 사용됩니다.
Columnstore 성능 설명
Columnstore 인덱스는 고속 메모리 내 일괄 처리 모드 처리와 I/O 요구 사항을 크게 줄이는 기술을 결합하여 높은 쿼리 성능을 달성합니다. 분석 쿼리는 많은 수의 행을 검색하므로 일반적으로 I/O 바인딩되므로 쿼리 실행 중에 I/O를 줄이는 것이 columnstore 인덱스의 디자인에 중요합니다. 데이터를 메모리로 읽은 후에는 메모리 내 작업의 수를 줄이는 것이 중요합니다.
Columnstore 인덱스는 I/O는 줄이고, 높은 데이터 압축, columnstore 제거, 행 그룹 제거 및 일괄 처리를 통해 메모리 내 작업을 최적화합니다.
데이터 압축
Columnstore 인덱스는 rowstore 인덱스보다 최대 10배 더 큰 데이터 압축을 달성합니다. 이를 통해 분석 쿼리를 실행하는 데 필요한 I/O는 크게 줄이고 그에 따라 쿼리 성능이 향상됩니다.
Columnstore 인덱스는 디스크에서 압축된 데이터를 읽습니다. 즉, 메모리로 읽어야 하는 데이터의 바이트가 줄어듭니다.
Columnstore 인덱스는 데이터를 압축된 형식으로 메모리에 저장하여 동일한 데이터를 메모리로 읽지 않도록 하여 I/O를 줄입니다. 예를 들어 압축이 10배인 columnstore 인덱스는 압축되지 않은 형식으로 데이터를 저장하는 것에 비해 메모리에 10배 더 많은 데이터를 유지할 수 있습니다. 메모리에 더 많은 데이터가 있으면 columnstore 인덱스가 디스크에서 불필요한 읽기를 수행하지 않고 메모리에 필요한 데이터를 찾을 가능성이 높습니다.
Columnstore 인덱스는 행이 아닌 열별로 데이터를 압축하여 높은 압축률을 달성하고 디스크에 저장된 데이터의 크기를 줄입니다. 각 열은 독립적으로 압축 및 저장됩니다. 열 내의 데이터는 항상 동일한 데이터 형식을 가지며 값이 비슷한 경향이 있습니다. Columnstore 데이터 압축 기술은 값이 비슷한 경우 더 높은 압축 속도를 달성하는 데 유용합니다.
예를 들어 팩트 테이블은 고객 주소를 저장하고 열이 있습니다 country-region. 가능한 값의 총 수는 200개 미만입니다. 이러한 값 중 일부는 여러 번 반복됩니다. 팩트 테이블에 1억 개의 행이 있는 경우 열이 country-region 쉽게 압축되고 스토리지가 거의 필요하지 않습니다. 행 단위 압축은 이러한 방식으로 열 값의 유사성을 대문자로 사용할 수 없으며 더 많은 바이트를 사용하여 열의 country-region 값을 압축해야 합니다.
열 제거
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)부터 클러스터형 columnstore 인덱스에 하나 이상의 일반 비클러스터형 rowstore 또는 B-트리 인덱스를 만들 수 있습니다. 비클러스터형 B-트리 인덱스는 같음 조건자 또는 값 범위가 작은 조건자가 있는 쿼리의 속도를 높일 수 있습니다. 더 복잡한 조건자의 경우 쿼리 최적화 프로그램에서 전체 테이블 검색을 선택할 수도 있습니다. 행 그룹을 건너뛰는 기능이 없으면 전체 테이블 검색은 특히 큰 테이블의 경우 시간이 많이 걸릴 수 있습니다.
분석 쿼리는 전체 테이블 검색에 대한 행 그룹 제거의 이점을 언제 활용하나요?
예를 들어 소매업은 클러스터형 columnstore 인덱스가 있는 팩트 테이블을 사용하여 판매 데이터를 모델화합니다. 각 새 판매는 제품이 판매되는 날짜를 포함하여 트랜잭션의 다양한 특성을 저장합니다. 흥미롭게도 columnstore 인덱스가 정렬된 순서를 보장하지 않더라도 이 테이블의 행은 날짜 정렬 순서로 로드됩니다. 시간이 지남에 따라 이 테이블이 증가합니다. 소매업은 지난 10년 동안의 판매 데이터를 유지할 수 있지만 분석 쿼리는 지난 분기에 대한 집계만 계산하면 됩니다. Columnstore 인덱스는 날짜 열의 메타데이터만 확인하여 이전 39개 분기의 데이터에 액세스하지 않게 할 수 있습니다. 이는 메모리로 읽고 처리되는 데이터의 양을 97% 줄이는 것입니다.
전체 테이블 검색에서 건너뛰는 행 그룹은 무엇인가요?
제거할 행 그룹을 결정하기 위해 columnstore 인덱스는 메타데이터를 사용하여 각 행 그룹에 대한 각 열 세그먼트의 최소값과 최대값을 저장합니다. 쿼리 조건자 조건을 충족하는 열 세그먼트 범위가 없으면 실제 I/O를 수행하지 않고 전체 행 그룹을 건너뜁니다. 이는 데이터가 일반적으로 정렬된 순서로 로드되기 때문에 작동합니다. 행 정렬이 보장되지는 않지만 유사한 데이터 값은 동일한 행 그룹 또는 인접한 행 그룹 내에 있는 경우가 많습니다.
행 그룹 에 대한 자세한 내용은 Columnstore 인덱스 디자인 가이드를 참조하세요.
일괄 처리 모드 실행
일괄 처리 모드 실행이란 실행 효율성을 위해 일반적으로 최대 900개의 행을 함께 행 세트로 처리하는 것을 말합니다. 예를 들어 쿼리 SELECT SUM (Sales) FROM SalesData는 SalesData 테이블의 총 매출을 집계합니다. 일괄 처리 모드 실행에서 쿼리 실행 엔진은 900개 값의 그룹으로 집계를 계산합니다. 이렇게 하면 각 행에 대한 비용을 지불하는 대신 액세스 비용 및 다른 유형의 오버헤드가 일괄 처리의 모든 행에 분산되어 코드 경로가 상당히 줄어듭니다. 일괄 처리 모드 처리는 가능하면 압축된 데이터에서 작동하며 행 모드 처리에서 사용되는 일부 교환 연산자를 제거하여 분석 쿼리를 크기 단위로 가속화합니다.
모든 쿼리 실행 연산자를 일괄 처리 모드로 실행할 수 있는 것은 아닙니다. 예를 들어 삽입, 삭제 또는 업데이트와 같은 DML(데이터 조작 언어) 작업은 한 번에 한 행씩 실행됩니다. 검사, 조인, 집계, 정렬 등의 일괄 처리 모드 연산자는 쿼리 성능을 향상시킬 수 있습니다. 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 인덱스 스캔 | SCAN | 사용할 수 없음 | 예 | 예 | columnstore 인덱스의 경우 조건자를 SCAN 노드에 푸시할 수 있습니다. |
| columnstore 인덱스 스캔(비클러스터형) | SCAN | 예 | 예 | 예 | 예 |
| 인덱스 검색 | 사용할 수 없음 | 사용할 수 없음 | 아니요 | 행 모드에서 비클러스터형 B-트리 인덱스를 통해 검색 작업을 수행합니다. | |
| compute scalar | 스칼라 값으로 평가되는 식입니다. | 예 | 예 | 예 | 모든 일괄 처리 모드 연산자처럼 데이터 형식에 대한 몇 가지 제한 사항이 있습니다. |
| concatenation | UNION 및 UNION ALL | 아니요 | 예 | 예 | |
| 필터링 | 조건자 적용 | 예 | 예 | 예 | |
| Hash Match | 해시 기반 집계 함수, 외부 해시 조인, 오른쪽 해시 조인, 왼쪽 해시 조인, 오른쪽 내부 조인, 왼쪽 내부 조인 | 예 | 예 | 예 | 집계에 대한 제한 사항: 문자열에 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,SUM,COUNT,COUNT(*)입니다. - 집계 연산자는 SCAN 노드 또는
GROUP BY의 SCAN 노드 맨 위에 있어야 합니다. - 이 집계는 고유 집계가 아닙니다.
- 집계 열이 문자열 열이 아닙니다.
- 집계 열이 가상 열이 아닙니다.
- 입력 및 출력 데이터 형식은 다음 중 하나여야 하며 64비트 내에 있어야 합니다.
- tinyint, int, bigint, smallint, bit
- smallmoney, money, decimal 및 numeric with precision <= 18
- smalldate, date, datetime, datetime2, time
예를 들어 집계 푸시다운은 다음 두 쿼리에서 모두 수행됩니다.
SELECT productkey, SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI
GROUP BY productkey;
SELECT SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI;
필터링 조건자 푸시다운
데이터 웨어하우스 스키마를 디자인할 때 권장되는 스키마 모델링은 하나 이상의 팩트 테이블과 여러 차원 테이블로 구성된 별모양 스키마 또는 눈송이 스키마를 사용하는 것입니다.
팁
팩트 테이블은 비즈니스 측정값 또는 트랜잭션을 저장하고 차원 테이블은 팩트를 분석해야 하는 차원을 저장합니다. 차원 모델링에 대한 자세한 내용은 Microsoft Fabric의 차원 모델링을 참조 하세요.
예를 들어 팩트 차원은 지역, 제품 등의 집합을 나타내는 반면 팩트는 특정 지역에서 특정 제품의 판매를 나타내는 레코드가 될 수 있습니다. 팩트 테이블과 차원 테이블은 기본/외래 키 관계를 통해 연결됩니다. 가장 일반적으로 사용되는 분석 쿼리는 하나 이상의 차원 테이블을 팩트 테이블에 조인하는 것입니다.
차원 테이블 Products를 살펴보겠습니다. 일반적인 기본 키는 ProductCode일반적으로 문자열로 표현됩니다. 쿼리 성능의 경우 서로게이트 키(일반적으로 정 수 열)를 만들어 팩트 테이블에서 차원 테이블의 행을 참조하는 것이 좋습니다.
columnstore 인덱스는 숫자 또는 정수 기반 키와 관련된 조인 및 조건자를 사용하여 분석 쿼리를 효율적으로 실행합니다. SQL Server 2016(13.x)은 문자열 열이 있는 조건자를 SCAN 노드로 푸시하여 문자열 기반 열이 있는 분석 쿼리의 성능을 크게 향상시켰습니다.
문자열 조건자 푸시다운은 열에 대해 만든 기본/보조 사전을 활용하여 쿼리 성능을 향상시킵니다. 예를 들어 100개의 고유 문자열 값으로 구성된 행 그룹 내의 문자열 열 세그먼트를 고려합니다. 각 고유 문자열 값은 100만 개의 행을 가정하여 평균 10,000회 참조됩니다. 문자열 조건자 푸시다운을 사용하면 쿼리 실행에서 사전의 값에 대한 조건자를 계산합니다. 조건자가 한정되면 사전 값을 참조하는 모든 행이 자동으로 정규화됩니다. 이렇게 하면 두 가지 방식으로 성능이 향상됩니다.
- 정규화된 행만 반환되므로 검색 노드에서 벗어나야 하는 행의 수가 줄어듭니다.
- 문자열 비교 수가 줄어듭니다. 이 예제에서는 100만 개 비교와 비교하여 100개의 문자열 비교만 필요합니다. 몇 가지 제한 사항이 있습니다.
- 델타 행 그룹에 대한 문자열 조건자 푸시다운이 없습니다. 델타 행 그룹의 열에 대한 사전이 없습니다.
- 사전이 64KB 항목을 초과하는 경우 문자열 조건자 푸시다운이 없습니다.
- null을 계산하는 식은 지원되지 않습니다.
세그먼트 제거
데이터 형식 선택 항목은 columnstore 인덱스의 쿼리에 대한 일반적인 필터 조건자를 기반으로 쿼리 성능에 상당한 영향을 미칠 수 있습니다.
columnstore 데이터에서 행 그룹은 열 세그먼트로 구성됩니다. 세그먼트를 읽지 않고도 세그먼트를 빠르게 제거할 수 있도록 각 세그먼트에 메타데이터가 있습니다. 이 세그먼트 제거는 숫자, 날짜 및 시간 데이터 형식 및 크기가 2보다 작거나 같은 datetimeoffset 데이터 형식에 적용됩니다. SQL Server 2022(16.x)부터 세그먼트 제거 기능은 문자열, 이진, guid 데이터 형식 및 2보다 큰 배율에 대한 datetimeoffset 데이터 형식으로 확장됩니다.
문자열 최소/최대 세그먼트 제거(SQL Server 2022(16.x) 이상)를 지원하는 SQL Server 버전으로 업그레이드한 후에는 columnstore 인덱스가 a 또는 DROP/CREATE를 사용하여 REBUILD 다시 작성될 때까지 이 기능에 도움이 되지 않습니다.
세그먼트 제거는 (max) 데이터 형식 길이와 같은 LOB 데이터 형식에는 적용되지 않습니다.
현재 SQL Server 2022(16.x) 이상만 LIKE 조건자의 접두사(예: column LIKE 'string%')에 대한 클러스터형 columnstore 행 그룹 제거를 지원합니다. column LIKE '%string'과 같은 LIKE의 비접두사 사용에 대해서는 세그먼트 제거가 지원되지 않습니다.
정렬된 클러스터형 columnstore 인덱스는 특히 문자열 열의 경우 세그먼트 제거의 이점을 누릴 수 있습니다. 정렬된 클러스터형 columnstore 인덱스의 경우 인덱스 키의 첫 번째 열에서 세그먼트 제거가 정렬되므로 가장 효과적입니다. 테이블의 다른 열에서 세그먼트 제거로 인한 성능 향상은 예측하기 어렵습니다. 정렬된 클러스터형 columnstore 인덱스에 대한 자세한 내용은 큰 데이터 웨어하우스 테이블에 대해 정렬된 클러스터형 columnstore 인덱스 사용을 참조하세요. 순서가 지정된 columnstore 인덱스 가용성은 Ordered 열 인덱스 가용성을 참조 하세요.
쿼리 연결 옵션 SET STATISTICS IO를 사용하여 작동 중인 세그먼트 제거를 볼 수 있습니다. 세그먼트 제거가 발생했음을 나타내려면 다음과 같은 출력을 찾습니다. 행 그룹은 열 세그먼트로 구성되므로 세그먼트 제거를 나타낼 수 있습니다. 쿼리의 다음 SET STATISTICS IO 출력 예제에서는 쿼리에서 약 83%의 데이터를 건너뛰었다.
...
Table 'FactResellerSalesPartCategoryFull'. Segment reads 16, segment skipped 83.
...