Columnstore 인덱스 디자인 지침Columnstore indexes - design guidance

이 항목은 다음에 적용됩니다. 예SQL Server(2016부터 시작)아니요Azure SQL 데이터베이스아니요Azure SQL 데이터 웨어하우스아니요병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL Server (starting with 2016)noAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

columnstore 인덱스 디자인을 위한 고급 권장 사항입니다.High-level recommendations for designing columnstore indexes. 적은 수의 올바른 의사 결정만으로 columnstore 인덱스에서 제공하고자 하는 높은 데이터 압축 및 쿼리 성능을 얻을 수 있습니다.A small number of good decision decisions helps you achieve the high data compression and query performance that columnstore indexes are designed to provide.

필수 구성 요소Prerequisites

이 문서에서는 columnstore 아키텍처 및 용어에 대해 잘 알고 있다고 가정합니다.This article assumes you are familiar with columnstore architecture and terminology. 자세한 내용은 Columnstore 인덱스 - 개요Columnstore 인덱스 - 아키텍처를 참조하세요.For more information, see Columnstore indexes - overview and Columnstore indexes - architecture.

데이터 요구 사항 파악Know your data requirements

columnstore 인덱스를 디자인하려면 먼저 데이터 요구 사항에 대해 최대한 많이 이해해야 합니다.Before designing a columnstore index, understand as much as possible about your data requirements. 예를 들어 다음 질문에 대한 답변을 생각해 보세요.For example, think through the answers to these questions:

  • 테이블이 얼마나 큰가요?How large is my table?
  • 쿼리는 대부분 큰 값 범위를 검색하는 분석을 수행하나요?Do my queries mostly perform analytics that scan large ranges of values? columnstore 인덱스는 특정 값 조회가 아닌 큰 범위 검색에 적합하도록 디자인되었습니다.Columnstore indexes are designed to work well for large range scans rather than looking up specific values.
  • 워크로드에서 많은 업데이트 및 삭제를 수행하나요?Does my workload perform lots of updates and deletes? columnstore 인덱스는 데이터가 안정적일 때 제대로 작동합니다.Columnstore indexes work well when the data is stable. 쿼리는 행의 10% 미만을 업데이트하고 삭제해야 합니다.Queries should be updating and deleting less than 10% of the rows.
  • 데이터 웨어하우스에 대한 팩트 및 차원 테이블이 있나요?Do I have fact and dimension tables for a data warehouse?
  • 트랜잭션 워크로드에 대해 분석을 수행해야 하나요?Do I need to perform analytics on a transactional workload? 이러한 경우 실시간 운영 분석에 대한 columnstore 디자인 지침을 참조하세요.If this is the case, see the columnstore design guidance for real-time operational analytics.

columnstore 인덱스가 필요하지 않을 수 있습니다.You might not need a columnstore index. 힙이나 클러스터형 인덱스가 있는 rowstore 테이블은 데이터를 찾는 쿼리, 특정 값을 검색하는 쿼리 또는 작은 범위의 값에 대한 쿼리에 가장 적합합니다.Rowstore tables with heaps or clustered indexes perform best on queries that seek into the data, searching for a particular value, or for queries on a small range of values. rowstore 인덱스는 큰 범위 테이블 검색 대신 주로 테이블 찾기가 필요한 경향이 있으므로 트랜잭션 워크로드에서 사용됩니다.Use rowstore indexes with transactional workloads since they tend to require mostly table seeks instead of large range table scans.

요구에 맞는 최상의 columnstore 인덱스 선택Choose the best columnstore index for your needs

columnstore 인덱스는 클러스터형이거나 비클러스터형입니다.A columnstore index is either clustered or nonclustered. 클러스터형 columnstore 인덱스에는 하나 이상의 비클러스터형 btree 인덱스가 있을 수 있습니다.A clustered columnstore index can have one or more nonclustered btree indexes. columnstore 인덱스는 쉽게 사용해 볼 수 있습니다.Columnstore indexes are easy to try. 테이블을 columnstore 인덱스로 만드는 경우 columnstore 인덱스를 삭제하여 테이블을 rowstore 테이블로 다시 쉽게 변환할 수 있습니다.If you create a table as a columnstore index, you can easily convert the table back to a rowstore table by dropping the columnstore index.

다음은 옵션 및 권장 사항에 대한 요약입니다.Here is a summary of the options and recommendations.

columnstore 옵션Columnstore option 사용하는 경우에 대한 권장 사항Recommendations for when to use 압축Compression
클러스터형 columnstore 인덱스Clustered columnstore index 다음과 같은 경우에 사용됩니다.Use for:
1) 별모양 또는 눈송이 스키마를 사용하는 기존 데이터 웨어하우스 워크로드1) Traditional data warehouse workload with a star or snowflake schema
2) 최소 업데이트 및 삭제로 많은 양의 데이터를 삽입하는 IOT(사물 인터넷) 워크로드2) Internet of Things (IOT) workloads that insert large volumes of data with minimal updates and deletes.
평균 10배Average of 10x
클러스터형 columnstore 인덱스의 비클러스터형 btree 인덱스Nonclustered btree indexes on a clustered columnstore index 다음을 수행하는 데 사용됩니다.Use to:
1) 클러스터형 columnstore 인덱스에 기본 키 및 외래 키 제약 조건을 적용합니다.1) Enforce primary key and foreign key constraints on a clustered columnstore index.
2) 특정 값이나 작은 범위의 값을 검색하는 쿼리의 속도를 향상시킵니다.2) Speedup queries that search for specific values or small ranges of values.
3) 특정 행의 업데이트 및 삭제 속도를 향상시킵니다.3) Speedup updates and deletes of specific rows.
평균 10배와 NCI에 대한 약간의 추가 저장소.10x on average plus some additional storage for the NCIs.
디스크 기반 힙 또는 btree 인덱스의 비클러스터형 columnstore 인덱스Nonclustered columnstore index on a disk-based heap or btree index 다음과 같은 경우에 사용됩니다.Use for:
1) 몇 가지 분석 쿼리가 있는 OLTP 워크로드.1) An OLTP workload that has some analytics queries. 분석을 위해 만든 btree 인덱스를 삭제하고 하나의 비클러스터형 columnstore 인덱스로 바꿀 수 있습니다.You can drop btree indexes created for analytics and replace them with one nonclustered columnstore index.
2) ETL(Extract Transform and Load) 작업을 수행하여 별도의 데이터 웨어하우스로 데이터를 이동하는 기존의 많은 OLTP 워크로드.2) Many traditional OLTP workloads that perform Extract Transform and Load (ETL) operations to move data to a separate data warehouse. 일부 OLTP 테이블에 비클러스터형 columnstore 인덱스를 만들어 ETL 및 별도의 데이터 웨어하우스를 제거할 수 있습니다.You can eliminate ETL and a separate data warehouse by creating a nonclustered columnstore index on some of the OLTP tables.
NCCI는 평균 10% 더 많은 저장소가 필요한 추가 인덱스입니다.NCCI is an additional index that requires 10% more storage on average.
메모리 내 테이블의 columnstore 인덱스Columnstore index on an in-memory table 기본 테이블이 메모리 내 테이블이라는 점을 제외하면 디스크 기반 테이블의 비클러스터형 columnstore 인덱스와 권장 사항이 동일합니다.Same recommendations as nonclustered columnstore index on a disk-based table, except the base table is an in-memory table. columnstore 인덱스는 추가 인덱스입니다.Columnstore index is an additional index.

큰 데이터 웨어하우스 테이블에 클러스터형 columnstore 인덱스 사용Use a clustered columnstore index for large data warehouse tables

클러스터형 columnstore 인덱스는 인덱스 이상의 의미가 있으며, 기본 테이블 저장소라고 할 수 있습니다.The clustered columnstore index is more than an index, it is the primary table storage. 큰 데이터 웨어하우징 팩트 및 차원 테이블에서 높은 데이터 압축을 제공하며 쿼리 성능을 현저하게 향상시킵니다.It achieves high data compression and a significant improvement in query performance on large data warehousing fact and dimension tables. 분석 쿼리는 특정 값을 조회하지 않고 큰 범위의 값에 대해 작업을 수행하는 경향이 있으므로 클러스터형 columnstore 인덱스는 트랜잭션 쿼리가 아닌 분석 쿼리에 가장 적합합니다.Clustered columnstore indexes are best suited for analytics queries rather than transactional queries, since analytics queries tend to perform operations on large ranges of values rather than looking up specific values.

다음과 같은 경우에 클러스터형 columnstore 인덱스를 사용하는 것이 좋습니다.Consider using a clustered columnstore index when:

  • 각 파티션에 백만 개 이상의 행이 있습니다.Each partition has at least a million rows. columnstore 인덱스는 각 파티션 내에 행 그룹을 갖습니다.Columnstore indexes have rowgroups within each partition. 테이블이 너무 작아서 각 파티션 내의 행 그룹을 채울 수 없는 경우 columnstore 압축 및 쿼리 성능의 이점을 얻을 수 없습니다.If the table is too small to fill a rowgroup within each partition, you won't get the benefits of columnstore compression and query performance.
  • 쿼리는 주로 값의 범위에 대해 분석을 수행합니다.Queries primarily perform analytics on ranges of values. 예를 들어 열의 평균 값을 찾으려면 쿼리에서 모든 열 값을 검색해야 합니다.For example, to find the average value of a column, the query needs to scan all the column values. 그런 다음 값을 더하여 집계하고 평균을 결정합니다.It then aggregates the values by summing them to determine the average.
  • 대부분의 삽입은 최소한의 업데이트 및 삭제로 많은 양의 데이터에서 수행됩니다.Most of the inserts are on large volumes of data with minimal updates and deletes. IOT(사물 인터넷) 같은 많은 워크로드에서 최소한의 업데이트 및 삭제로 많은 양의 데이터를 삽입합니다.Many workloads such as Internet of Things (IOT) insert large volumes of data with minimal updates and deletes. 이러한 워크로드는 클러스터형 columnstore 인덱스 사용으로 제공되는 압축 및 쿼리 성능 이점을 누릴 수 있습니다.These workloads can benefit from the compression and query performance gains that comes from using a clustered columnstore index.

다음과 같은 경우 클러스터형 columnstore 인덱스를 사용하지 마세요.Don't use a clustered columnstore index when:

  • 테이블에 varchar(max), nvarchar(max) 또는 varbinary(max) 데이터 형식이 필요합니다.The table requires varchar(max), nvarchar(max), or varbinary(max) data types. 또는 이러한 열이 포함되지 않도록 columnstore 인덱스를 디자인하세요.Or, design the columnstore index so that it doesn't include these columns.
  • 테이블 데이터가 영구적이지 않습니다.The table data is not permanent. 데이터를 신속하게 저장하고 삭제해야 하는 경우 힙이나 임시 테이블을 사용하는 것이 좋습니다.Consider using a heap or temporary table when you need to store and delete the data quickly.
  • 테이블에 파티션당 백만 개 미만의 행이 있습니다.The table has less than one million rows per partition.
  • 테이블에서 수행되는 작업의 10% 이상이 업데이트 및 삭제입니다.More than 10% of the operations on the table are updates and deletes. 많은 수의 업데이트 및 삭제를 수행하면 조각화가 발생합니다.Large numbers of updates and deletes cause fragmentation. 조각화는 모든 데이터를 columnstore에 적용하고 조각화를 제거하는 다시 구성이라는 작업을 실행할 때까지 압축률 및 쿼리 성능에 영향을 줍니다.The fragmentation affects compression rates and query performance until you run an operation called reorganize that forces all data into the columnstore and removes fragmentation. 자세한 내용은 columnstore 인덱스에서 인덱스 조각화 최소화를 참조하세요.For more information, see Minimizing index fragmentation in columnstore index.

자세한 내용은 Columnstore 인덱스-데이터 웨어하우징을 참조하세요.For more information, see Columnstore indexes - data warehousing.

효율적인 테이블 검색을 위해 btree 비클러스터형 인덱스 추가Add btree nonclustered indexes for efficient table seeks

SQL Server 2016부터는 클러스터형 columnstore 인덱스의 보조 인덱스로 비클러스터형 btree 인덱스를 만들 수 있습니다.Beginning with SQL Server 2016, you can create nonclustered btree indexes as secondary indexes on a clustered columnstore index. 비클러스터형 btree 인덱스는 columnstore 인덱스가 변경될 때 업데이트됩니다.The nonclustered btree index is updated as changes occur to the columnstore index. 이는 유용하게 사용할 수 있는 강력한 기능입니다.This is a powerful feature that you can use to your advantage.

보조 btree 인덱스를 사용하면 모든 행을 검색하지 않고도 특정 행을 효율적으로 검색할 수 있습니다.By using the secondary btree index, you can efficiently search for specific rows without scanning through all the rows. 다른 옵션도 사용할 수 있습니다.Other options become available too. 예를 들어 btree 인덱스에서 UNIQUE 제약 조건을 사용하여 기본 키 또는 외래 키 제약 조건을 적용할 수 있습니다.For example, you can enforce a primary or foreign key constraint by using a UNIQUE constraint on the btree index. 고유하지 않은 값은 btree 인덱스에 삽입되지 않으므로 SQL Server에서 columnstore에 값을 삽입할 수 없습니다.Since an non-unique value will fail to insert into the btree index, SQL Server cannot insert the value into the columnstore.

다음과 같은 경우 columnstore 인덱스에서 btree 인덱스를 사용하는 것이 좋습니다.Consider using a btree index on a columnstore index to:

  • 특정 값 또는 작은 범위의 값을 검색하는 쿼리를 실행합니다.Run queries that search for particular values or small ranges of values.
  • 기본 키 또는 외래 키 제약 조건과 같은 제약 조건을 적용합니다.Enforce a constraint such as a primary key or foreign key constraint.
  • 업데이트 및 삭제 작업을 효율적으로 수행합니다.Efficiently perform update and delete operations. btree 인덱스는 전체 테이블 또는 테이블의 파티션을 검색하지 않고도 특정 행에서 업데이트 및 삭제를 신속하게 찾을 수 있습니다.The btree index is able to quickly locate the specific rows for updates and deletes without scanning the full table or partition of a table.
  • btree 인덱스를 저장하는 데 사용할 수 있는 추가 저장소가 있습니다.You have additional storage available to store the btree index.

실시간 분석을 위해 비클러스터형 columnstore 인덱스 사용Use a nonclustered columnstore index for real-time analytics

SQL Server 2016SQL Server 2016부터는 rowstore 디스크 기반 테이블 또는 메모리 내 OLTP 테이블에 비클러스터형 columnstore 인덱스가 있을 수 있습니다.Beginning with SQL Server 2016SQL Server 2016, you can have a nonclustered columnstore index on a rowstore disk-based table or an in-memory OLTP table. 따라서 트랜잭션 테이블에서 실시간으로 분석을 실행할 수 있습니다.This makes it possible to run the analytics in real-time on a transactional table. 트랜잭션이 기본 테이블에서 발생하는 동안 columnstore 인덱스에 대해 분석을 실행할 수 있습니다.While transactions are occurring on the underlying table, you can run analytics on the columnstore index. 한 테이블에서 두 인덱스를 모두 관리하므로 rowstore 및 columnstore 인덱스 모두 실시간으로 변경할 수 있습니다.Since one table manages both indexes, changes are available in real-time to both the rowstore and the columnstore indexes.

columnstore 인덱스는 rowstore 인덱스보다 10배 더 뛰어난 데이터 압축을 제공하므로 약간의 추가 저장소만 있으면 됩니다.Since a columnstore index achieves 10x better data compression than a rowstore index, it only needs a small amount of extra storage. 예를 들어 압축된 rowstore 테이블이 20GB를 사용할 경우 columnstore 인덱스에는 추가 2GB가 필요할 수 있습니다.For example, if the compressed rowstore table takes 20 GB, the columnstore index might require an additional 2 GB. 또한 필요한 추가 공간은 비클러스터형 columnstore 인덱스에 있는 열의 수에 따라 달라집니다.The additional space required also depends on the number of columns in the nonclustered columnstore index.

다음과 같은 경우에 비클러스터형 columnstore 인덱스를 사용하는 것이 좋습니다.Consider using a nonclustered columnstore index to:

  • 트랜잭션 rowstore 테이블에 대해 실시간으로 분석을 실행합니다.Run analytics in real-time on a transactional rowstore table. 분석을 위해 설계된 기존 btree 인덱스를 비클러스터형 columnstore 인덱스로 바꿀 수 있습니다.You can replace existing btree indexes that are designed for analytics with a nonclustered columnstore index.

  • 별도 데이터 웨어하우스가 필요하지 않습니다.Eliminate the need for a separate data warehouse. 일반적으로 회사는 rowstore 테이블에서 트랜잭션을 실행하고 별도의 데이터 웨어하우스에 데이터를 로드하여 분석을 실행합니다.Traditionally, companies run transactions on a rowstore table and then load the data into a separate data warehouse to run analytics. 많은 워크로드에서 트랜잭션 테이블에 비클러스터형 columnstore 인덱스를 만들어 로드 프로세스 및 별도의 데이터 웨어하우스를 제거할 수 있습니다.For many workloads, you can eliminate the loading process and the separate data warehouse by creating a nonclustered columnstore index on transactional tables.

    SQL Server 2016은 이 시나리오의 성능을 향상시킬 수 있는 몇 가지 전략을 제공합니다.SQL Server 2016 offers several strategies to make this scenario performant. OLTP 응용 프로그램을 변경하지 않고도 비클러스터형 columnstore 인덱스를 사용할 수 있으므로 매우 쉽게 체험할 수 있습니다.It's very easy to try it since you can enable a nonclustered columnstore index with no changes to your OLTP application.

처리 리소스를 더 추가하려면 읽기 가능한 보조 복제본에서 분석을 실행할 수 있습니다.To add additional processing resources, you can run the analytics on a readable secondary. 읽기 가능한 보조 복제본 사용으로 트랜잭션 워크로드 및 분석 워크로드의 처리를 구분합니다.Using a readable secondary separates the processing of the transactional workload and the analytics workload.

자세한 내용은 실시간 운영 분석을 위한 Columnstore 시작을 참조하세요.For more information, see Get started with columnstore indexes for real-time operational analytics

최상의 columnstore 인덱스를 선택하는 방법에 대한 자세한 내용은 Sunil Agarwal의 블로그 Which columnstore index is right for my workload?(내 워크로드에 적합한 columnstore 인덱스는 무엇일까요?)를 참조하세요.For more information on choosing the best columnstore index, see Sunil Agarwal's blog Which columnstore index is right for my workload?.

데이터 관리 및 쿼리 성능을 위해 테이블 파티션 사용Use table partitions for data management and query performance

columnstore 인덱스는 데이터를 관리하고 보관하는 적합한 방법인 분할을 지원합니다.Columnstore indexes support partitioning which is a good way to manage and archive data. 또한 분할에서는 하나 이상의 파티션으로 작업을 제한하여 쿼리 성능이 향상됩니다.Partitioning also improves query performance by limiting operations to one or more partitions.

파티션을 사용하여 더 쉽게 데이터 관리Use partitions to make the data easier to manage

큰 테이블에서 실제로 많은 데이터를 관리할 수 있는 유일한 방법은 파티션 사용입니다.For large tables, the only practical way to manage ranges of data is by using partitions. rowstore 테이블에 파티션을 사용할 때의 장점이 columnstore 인덱스에도 적용됩니다.The advantages of partitions for rowstore tables also apply to columnstore indexes.

예를 들어 rowstore와 columnstore 테이블 모두 파티션을 사용하여 다음을 수행합니다.For example, both rowstore and columnstore tables use partitions to:

  • 증분 백업의 크기를 제어합니다.Control the size of incremental backups. 파티션을 별도의 파일 그룹에 백업한 다음 읽기 전용으로 표시할 수 있습니다.You can backup partitions to separate filegroups and then mark them as read-only. 이렇게 하면 이후 백업에서 읽기 전용 파일 그룹을 건너뜁니다.By doing this, future backups will skip the read-only filegroups.
  • 오래된 파티션을 저렴한 저장소로 이동하여 저장소 비용을 절감합니다.Save storage costs by moving an older partition to less expensive storage. 예를 들어 파티션 전환을 사용하여 저렴한 저장소 위치로 파티션을 이동할 수 있습니다.For example, you could use partition switching to move a partition to a less expensive storage location.
  • 작업을 파티션으로 제한하여 효율적으로 작업을 수행합니다.Perform operations efficiently by limiting the operations to a partition. 예를 들어 인덱스 유지 관리를 위해 조각화된 파티션만 대상으로 지정할 수 있습니다.For example, you can target only the fragmented partitions for index maintenance.

또한 columnstore 인덱스에서는 분할을 사용하여 다음을 수행합니다.Additionally, with a columnstore index, you use partitioning to:

  • 저장소 비용을 추가 30% 절감합니다.Save an additional 30% in storage costs. COLUMNSTORE_ARCHIVE 압축 옵션을 사용하여 오래된 파티션을 압축할 수 있습니다.You can compress older partitions with the COLUMNSTORE_ARCHIVE compression options. 쿼리 성능을 위해 데이터 속도가 느려지므로 파티션이 자주 쿼리되는 경우 적합합니다.The data will be slower for query performance, which is acceptable if the partition is queries infrequently.

파티션을 사용하여 쿼리 성능 향상Use partitions to improve query performance

파티션을 사용하면 검색할 행 수를 제한하는 특정 파티션만 검색하도록 쿼리를 제한할 수 있습니다.By using partitions, you can limit your queries to scan only specific partitions which limits the number of rows to scan. 예를 들어 인덱스가 연도별로 분할되고 쿼리가 작년의 데이터를 분석하는 경우 한 파티션의 데이터만 검색하면 됩니다.For example, if the index is partitioned by year and the query is analyzing data from last year, it only needs to scan the data in one partition.

columnstore 인덱스에 더 적은 수의 파티션 사용Use fewer partitions for a columnstore index

데이터 크기가 충분히 크지 않은 경우 columnstore 인덱스는 rowstore 인덱스에 사용할 수 있는 것보다 더 적은 파티션으로 최상의 성능을 얻을 수 있습니다.Unless you have a large enough data size, a columnstore index performs best with fewer partitions than you what you might use for a rowstore index. 파티션당 백만 개 이상의 행이 있지 않으면 대부분의 행이 columnstore 압축의 성능 혜택을 받지 못하는 deltastore로 이동할 수 있습니다.If you don't have at least one million rows per partition, most of your rows might go to the deltastore where they don't receive the performance benefit of columnstore compression. 예를 들어 10개의 파티션이 있는 테이블에 100만 개 행을 로드하고 각 파티션에서 100, 000개 행을 받으면 모든 행이 델타 행 그룹으로 이동합니다.For example, if you load one million rows into a table with 10 partitions and each partition receives 100,000 rows, all of the rows will go to delta rowgroups.

예:Example:

  • 1,000,000개 행을 하나의 파티션 또는 분할되지 않은 테이블에 로드합니다.Load 1,000,000 rows into one partition or a non-partitioned table. 1,000,000개 행이 있는 압축된 행 그룹 하나를 받습니다.You get one compressed rowgroup with 1,000,000 rows. 높은 데이터 압축 및 빠른 쿼리 성능에 적합합니다.This is great for high data compression and fast query performance.
  • 1,000,000개 행을 10개의 파티션에 균등하게 로드합니다.Load 1,000,000 rows evenly into 10 partitions. 각 파티션은 columnstore 압축의 최소 임계값보다 작은 100,000개 행을 받습니다.Each partition gets 100,000 rows which is less than the minimum threshold for columnstore compression. 결과적으로 columnstore 인덱스에는 각각 100,000개 행이 있는 10개의 델타 행 그룹이 생성됩니다.As a result the columnstore index could have 10 delta rowgroups with 100,000 rows in each. columnstore에 델타 행 그룹을 적용하는 방법이 있습니다.There are ways to force the delta rowgroups into the columnstore. 그러나 columnstore 인덱스에 행만 있는 경우 압축된 행 그룹이 너무 작아서 최상의 압축 및 쿼리 성능을 제공할 수 없습니다.However, if these are the only rows in the columnstore index, the comrpessed rowgroups will be too small for best compression and query performance.

분할에 대한 자세한 내용은 Sunil Agarwal의 블로그 게시물 Should I partition my columnstore index?(내 columnstore 인덱스를 분할해야 하나요?)를 참조하세요.For more information about partitioning, see Sunil Agarwal's blog post, Should I partition my columnstore index?.

적절한 데이터 압축 방법 선택Choose the appropriate data compression method

columnstore 인덱스에서는 columnstore 압축 및 보관 압축이라는 두 가지 데이터 압축 옵션을 제공합니다.The columnstore index offers two choices for data compression: columnstore compression and archive compression. 인덱스를 만들 때 압축 옵션을 선택하거나 나중에 ALTER INDEX ... REBUILD를 사용하여 변경할 수 있습니다.You can choose the compression option when you create the index, or change it later with ALTER INDEX ... REBUILD.

최적의 쿼리 성능을 위해 columnstore 압축 사용Use columnstore compression for best query performance

일반적으로 columnstore 압축은 rowstore 인덱스에 비해 10배 더 뛰어난 압축률을 제공합니다.Columnstore compression typically achieves 10x better compression rates over rowstore indexes. columnstore 인덱스에 대한 표준 압축 방법이며 빠른 쿼리 성능을 사용할 수 있도록 합니다.It is the standard compression method for columnstore indexes and enables fast query performance.

최상의 데이터 압축을 위해 보관 압축 사용Use archive compression for best data compression

보관 압축은 쿼리 성능이 중요하지 않은 경우 최대 압축을 위해 설계되었습니다.Archive compression is designed for maximum compression when query performance is not as important. 이 압축은 columnstore 압축보다 더 높은 데이터 압축률을 제공하지만 가격이 함께 제공됩니다.It achieves higher data compression rates than columnstore compression, but it comes with a price. 데이터를 압축하고 압축 해제하는 데 더 오래 걸리므로 빠른 쿼리 성능에는 적합하지 않습니다.It takes longer to compress and decompress the data, so it is not well-suited for fast query performance.

rowstore 테이블을 columnstore 인덱스로 변환할 때 최적화 사용Use optimizations when you convert a rowstore table to a columnstore index

데이터가 이미 rowstore 테이블에 있는 경우 CREATE COLUMNSTORE INDEX를 사용하여 테이블을 클러스터형 columnstore 인덱스로 변환할 수 있습니다.If your data is already in a rowstore table, you can use CREATE COLUMNSTORE INDEX to convert the table to a clustered columnstore index. 테이블을 변환한 후 쿼리 성능을 향상시키는 몇 가지 최적화 방법이 있습니다.There's a couple optimizations that will improve query performance after the table is converted.

MAXDOP를 사용하여 행 그룹 품질 향상Use MAXDOP to improve rowgroup quality

힙 또는 클러스터형 btree 인덱스를 columnstore 인덱스로 변환하기 위해 최대 수의 프로세서를 구성할 수 있습니다.You can configure the maximum number of processors for converting a heap or clustered btree index to a columnstore index. 프로세서를 구성하려면 최대 병렬 처리 수준 옵션(MAXDOP)을 사용합니다.To configure the processors, use the maximum degree of parallelism option (MAXDOP).

데이터가 많은 경우 MAXDOP 1은 너무 느릴 수 있습니다.If you have large amounts of data, MAXDOP 1 will likely be too slow. MAXDOP를 4로 높이면 제대로 작동합니다.Increasing MAXDOP to 4 works fine. 행 수가 최적이 아닌 몇 개의 행 그룹이 생성되면 ALTER INDEX REORG를 실행하여 백그라운드에서 병합할 수 있습니다.If this results in a few rowgroups that do not have the optimal number of rows you can run ALTER INDEX REORG to merge them together in the background.

btree 인덱스의 정렬된 순서 유지Keep the sorted order of a btree index

btree 인덱스는 정렬된 순서로 행을 저장하므로 행이 columnstore 인덱스로 압축될 때 해당 순서를 유지하면 쿼리 성능을 향상시킬 수 있습니다.Since the btree index already stores rows in a sorted order, preserving that order when the rows get compressed into the columnstore index can improve query performance.

columnstore 인덱스는 데이터를 정렬하지 않지만 메타데이터를 사용하여 각 행 그룹에서 각 열 세그먼트의 최소값과 최대값을 추적합니다.The columnstore index does not sort the data, but it does use metadata to track the minimum and maximum values of each column segment in each rowgroup. 값 범위를 검색할 때 행 그룹을 건너뛸 시기를 신속하게 계산할 수 있습니다.When scanning for a range of values, it can quickly compute when to skip the rowgroup. 데이터가 정렬되면 더 많은 행 그룹을 건너뛸 수 있습니다.When the data is ordered, more rowgroups can be skipped.

변환하는 동안 정렬된 순서를 유지하려면To preserve the sorted order during conversion:

  • DROP_EXISTING 절과 함께 CREATE COLUMNSTORE INDEX를 사용합니다.Use CREATE COLUMNSTORE INDEX with the DROP_EXISTING clause. 그러면 인덱스의 이름도 유지됩니다.This also preserves the name of the index. rowstore 인덱스의 이름을 이미 사용하는 스크립트가 있는 경우 해당 스크립트를 업데이트할 필요가 없습니다.If you have scripts that already use the name of the rowstore index you won't need to update them.

    다음 예제에서는 MyFactTable이라는 테이블의 클러스터형 rowstore 인덱스를 클러스터형 columnstore 인덱스로 변환합니다.This example converts a clustered rowstore index on a table named MyFactTable to a clustered columnstore index. 인덱스 이름 ClusteredIndex_d473567f7ea04d7aafcac5364c241e09가 동일하게 유지됩니다.The index name, ClusteredIndex_d473567f7ea04d7aafcac5364c241e09, stays the same.

    CREATE CLUSTERED COLUMNSTORE INDEX ClusteredIndex_d473567f7ea04d7aafcac5364c241e09  
    ON MyFactTable  
    WITH DROP_EXISTING = ON;  
    

다음은 columnstore 인덱스를 만들고 유지하기 위한 태스크입니다.These are tasks for creating and maintaining columnstore indexes.

태스크Task 참조 항목Reference Topics 참고Notes
테이블을 columnstore로 만듭니다.Create a table as a columnstore. CREATE TABLE(Transact-SQL)CREATE TABLE (Transact-SQL) SQL Server 2016SQL Server 2016부터 테이블을 클러스터형 columnstore 인덱스로 만들 수 있습니다.Beginning with SQL Server 2016SQL Server 2016, you can create the table as a clustered columnstore index. 먼저 rowstore 테이블을 만든 다음 이를 columnstore로 변환할 필요가 없습니다.You do not have to first create a rowstore table and then convert it to columnstore.
columnstore 인덱스가 포함된 메모리 테이블을 만듭니다.Create a memory table with a columnstore index. CREATE TABLE(Transact-SQL)CREATE TABLE (Transact-SQL) SQL Server 2016SQL Server 2016부터 columnstore 인덱스가 포함된 메모리 액세스에 최적화된 테이블을 만들 수 있습니다.Beginning with SQL Server 2016SQL Server 2016, you can create a memory-optimized table with a columnstore index. 테이블을 만든 후 ALTER TABLE ADD INDEX 구문을 사용하여 columnstore 인덱스를 추가할 수도 있습니다.The columnstore index can also be added after the table is created, using the ALTER TABLE ADD INDEX syntax.
rowstore 테이블을 columnstore로 변환합니다.Convert a rowstore table to a columnstore. CREATE COLUMNSTORE INDEX(Transact-SQL)CREATE COLUMNSTORE INDEX (Transact-SQL) 기존 힙 또는 이진 트리를 columnstore로 변환합니다.Convert an existing heap or binary tree to a columnstore. 예제에서는 이 변환을 수행할 때 기존 인덱스 및 인덱스 이름을 처리하는 방법을 보여 줍니다.Examples show how to handle existing indexes and also the name of the index when performing this conversion.
columnstore 테이블을 rowstore로 변환합니다.Convert a columnstore table to a rowstore. CREATE COLUMNSTORE INDEX(Transact-SQL)CREATE COLUMNSTORE INDEX (Transact-SQL) 일반적으로 이 작업은 필요하지 않지만 이 변환을 수행해야 하는 경우가 있을 수 있습니다.Usually this is not necessary, but there can be times when you need to perform this conversion. 예제에서는 columnstore를 힙 또는 클러스터형 인덱스로 변환하는 방법을 보여 줍니다.Examples show how to convert a columnstore to a heap or clustered index.
Rowstore 테이블에 columnstore 인덱스를 만듭니다.Create a columnstore index on a rowstore table. CREATE COLUMNSTORE INDEX(Transact-SQL)CREATE COLUMNSTORE INDEX (Transact-SQL) Rowstore 테이블에는 하나의 columnstore 인덱스가 있을 수 있습니다.A rowstore table can have one columnstore index. SQL Server 2016SQL Server 2016부터 columnstore 인덱스에 필터링된 조건이 있을 수 있습니다.Beginning with SQL Server 2016SQL Server 2016, the columnstore index can have a filtered condition. 예제에서는 기본 구문을 보여 줍니다.Examples show the basic syntax.
운영 분석에 대한 고성능 인덱스를 만듭니다.Create performant indexes for operational analytics. Get started with Columnstore for real time operational analytics(실시간 운영 분석을 위한 Columnstore 시작)Get started with Columnstore for real time operational analytics OLTP 쿼리에서는 btree 인덱스를 사용하고 분석 쿼리에서는 columnstore 인덱스를 사용하도록 상호 보완적인 columnstore 및 btree 인덱스를 만드는 방법을 설명합니다.Describes how to create complementary columnstore and btree indexes so that OLTP queries use btree indexes and analytics queries use columnstore indexes.
데이터 웨어하우징용 고성능 columnstore 인덱스를 만듭니다.Create performant columnstore indexes for data warehousing. Columnstore 인덱스 - 데이터 웨어하우징Columnstore indexes - data Warehousing Columnstore 테이블에서 btree 인덱스를 사용하여 고성능 데이터 웨어하우징 쿼리를 만드는 방법을 설명합니다.Describes how to use btree indexes on columnstore tables to create performant data warehousing queries.
btree 인덱스를 사용하여 columnstore 테이블에서 기본 키 제약 조건을 적용합니다.Use a btree index to enforce a primary key constraint on a columnstore index. Columnstore 인덱스 - 데이터 웨어하우징Columnstore indexes - data warehousing btree 및 columnstore 인덱스를 결합하여 columnstore 인덱스에서 기본 키 제약 조건을 적용하는 방법을 보여 줍니다.Shows how to combine btree and columnstore indexes to enforce primary key constraints on the columnstore index.
Columnstore 인덱스를 삭제합니다.Drop a columnstore index DROP INDEX(Transact-SQL)DROP INDEX (Transact-SQL) Columnstore 인덱스 삭제에서는 btree 인덱스에서 사용하는 표준 DROP INDEX 구문을 사용합니다.Dropping a columnstore index uses the standard DROP INDEX syntax that btree indexes use. 클러스터형 columnstore 인덱스를 삭제하면 columnstore 테이블이 힙으로 변환됩니다.Dropping a clustered columnstore index will convert the columnstore table to a heap.
Columnstore 인덱스에서 행을 삭제합니다.Delete a row from a columnstore index DELETE(Transact-SQL)DELETE (Transact-SQL) 행을 삭제하려면 DELETE(Transact-SQL) 를 사용합니다.Use DELETE (Transact-SQL) to delete a row.

columnstore 행: SQL ServerSQL Server 는 행을 논리적으로 삭제된 것으로 표시하지만, 인덱스가 다시 작성될 때까지는 행에 대한 물리적 저장소를 회수하지 않습니다.columnstore row: SQL ServerSQL Server marks the row as logically deleted but does not reclaim the physical storage for the row until the index is rebuilt.

deltastore 행: SQL ServerSQL Server 는 행을 논리적 및 물리적으로 삭제합니다.deltastore row: SQL ServerSQL Server logically and physically deletes the row.
Columnstore 인덱스의 행을 업데이트합니다.Update a row in the columnstore index UPDATE(Transact-SQL)UPDATE (Transact-SQL) 행을 삭제하려면 UPDATE(Transact-SQL) 를 사용합니다.Use UPDATE (Transact-SQL) to update a row.

columnstore 행: SQL ServerSQL Server 는 행을 논리적으로 삭제됨으로 표시한 다음 업데이트된 행을 deltastore에 삽입합니다.columnstore row: SQL ServerSQL Server marks the row as logically deleted, and then inserts the updated row into the deltastore.

deltastore 행: SQL ServerSQL Server 는 deltastore에 있는 행을 업데이트합니다.deltastore row: SQL ServerSQL Server updates the row in the deltastore.
deltastore의 모든 행을 강제로 columnstore로 이동합니다.Force all rows in the deltastore to go into the columnstore. ALTER INDEX(Transact-SQL) ... REBUILDALTER INDEX (Transact-SQL) ... REBUILD

Columnstore 인덱스 - 조각 모음Columnstore indexes - defragmentation
REBUILD 옵션과 함께 ALTER INDEX를 사용하면 모든 행이 강제로 columnstore로 이동합니다.ALTER INDEX with the REBUILD option forces all rows to go into the columnstore.
Columnstore 인덱스를 조각 모음합니다.Defragment a columnstore index ALTER INDEX(Transact-SQL)ALTER INDEX (Transact-SQL) ALTER INDEX …ALTER INDEX … REORGANIZE는 columnstore 인덱스를 온라인으로 조각 모음합니다.REORGANIZE defragments columnstore indexes online.
테이블을 columnstore 인덱스와 병합합니다.Merge tables with columnstore indexes. MERGE(Transact-SQL)MERGE (Transact-SQL)

다음 단계Next steps

빈 columnstore 인덱스를 만들려면To create an empty columnstore index for:

기존 rowstore 힙 또는 btree 인덱스를 클러스터형 columnstore 인덱스로 변환하거나 비클러스터형 columnstore 인덱스를 만들려면 다음을 사용합니다.To convert an existing rowstore heap or btree index to a clustered columnstore index, or to create a nonclustered columnstore index, use: