Columnstore 인덱스에 대해서 팀 내 소개를 드렸는데, 몇가지 질문을 받아서 관련하여 테스트해 본 내용을 정리해보았습니다.
아래에 진행된 테스트는 Part 1에서 만든 임시테이블을 기준으로 진행된 점 참고 부탁드립니다.
1. 일반 인덱스와 컬럼스토어 인덱스의 크기 비교
1-1. 인덱스 크기 비교 스크립트 (쿼리가 길어서 첨부파일로 올림)
columnstore_CompareIndexSize.sql1-2. 인덱스 크기 비교 결과
1-3. 의견
- 일반 인덱스의 경우 약 1500MB인데, 동일한 name 컬럼에 대해서 columnstore 인덱스로 구성한 경우 약 270M로 5.5배이상 축소되어짐.
- Columnstore 인덱스의 경우 압축등의 기술을 통하여 대량의 데이터 집계 및 분석에 최적화되어짐.
- 여기서 추가적인 의문이 생김. Columnstore 인덱스는 equal 검색에도 사용할 수 있을까?/적합할까?
2. equal 비교에서의 성능 비교
2-1. 일반 인덱스에서 equal 비교
-- 쿼리
select top 10 *
from ColumnstoreTable with (readuncommitted, index(idx_ColumnstoreTable_name_normal))
where name = 'ColumnstoreTable'
-- 실행계획
-- 쿼리 실행 비용
2-2. 컬럼스토어 인덱스에서 equal 비교
-- 쿼리
select top 10 *
from ColumnstoreTable with (readuncommitted, index(idx_ColumnstoreTable_name))
where name = 'ColumnstoreTable'
-- 실행계획
-- 쿼리 실행 비용
2-3. 의견
- 논리 읽기수를 비교하면 약 160배 이상 일반 인덱스가 빠른 것을 볼 수 있음. (일반인덱스 : 14 pages, 컬럼스토어인덱스 : 2255 pages)
- 컬럼스토어 인덱스의 경우 실행계획을 보면 Index scan으로 풀리는 것을 볼 수 있음.
- 컬럼스토어인덱스의 경우 대량 집계에 최적화된 구조로 index seek가 불가함.
3. 컬럼스토어 인덱스가 있는 테이블의 경우 DML이 안된다고 하는데 진짜 안될까?
3-1. Insert
-- 쿼리
insert into ColumnstoreTable
(name ,id ,xtype ,uid ,info ,status ,base_schema_ver ,replinfo ,parent_obj ,crdate ,ftcatid ,schema_ver ,stats_schema_ver ,type
,userstat ,sysstat ,indexdel ,refdate ,version ,deltrig ,instrig ,updtrig ,seltrig ,category ,cache )
select top 1
name ,id ,xtype ,uid ,info ,status ,base_schema_ver ,replinfo ,parent_obj ,crdate ,ftcatid ,schema_ver ,stats_schema_ver ,type
,userstat ,sysstat ,indexdel ,refdate ,version ,deltrig ,instrig ,updtrig ,seltrig ,category ,cache
from ColumnstoreTable
-- 결과
-- 쿼리
delete from ColumnstoreTable
-- 결과
3-3. Update
update ColumnstoreTable set name = 'hyunsoolim'
-- 결과
4. 결론/의견
- Columnstore index를 잘 활용하면 좋을 것 같습니다. 하지만 그만큼 주의를 요하는 부분도 있으니 실제 서비스에 적용하기 전에는 주의가 필요할 것 같습니다.
- 파티션테이블과 접목시키면 DML이 안되는 단점은 극복이 가능할 것 같습니다. (나중에 테스트해볼 예정임)
참고. Part 1 문서 하단 참고