새 기능으로 더욱 강력해진 SQL Server 2012 BI

쿼드디멘션스

전략기획팀 BI파트

박희용

경력

– ㈜ Quaddimensions • 전략기획팀-BI파트

– 한이음 IT 멘토

– SQL Server 2008 R2 MDS, StreamInsight 강의

– 관심분야 • BI, DQ

– 카페 http://cafe.naver.com/microsoftbi

강사소개

선두그룹

• Integration Service

– Expression Task(식 태스크)

– Redo, Undo

– Grouping(그룹)

– CDC 작업

– DQS Cleansing(DQS 정리)

– 피벗

– Parameters(매개변수)

– Deploy(배포)

• Columnstore 인덱스

목차

• Expression Task(식 태스크)

– 변수 제어가 용이

– 제어흐름작업 -> SSIS도구상자 -> 식 태스크 • 변수 = 표현식

• 예) @[User::from_date] = DATEADD(“Day”, -1, GETDATE())

SSIS 새 기능[1]

• Redo, Undo

– 실행 취소 및 재실행 기능

SSIS 새 기능[2]

• Grouping(그룹)

– 작업 환경 정리 기능

– 제어흐름, 데이터흐름, 이벤트 처리 등에서 사용 가능 • 하나 또는 다수의 객체 지정 선택 후 우 클릭 -> 그룹

SSIS 새 기능[3]

• CDC 작업

– CDC(변경 데이터 캡쳐) • CDC가 적용된 테이블의 갱신 작업

내용 기록

– Insert, Delete, Update

– 데이터 변경 내역 추적 가능

– 변경 데이터 저장

» <스키마>_<테이블>_CT

• 주의사항

– <스키마>_<테이블>_CT 테이블 관리가 필요

– 잦은 갱신이 발생할 경우 성능 고려

• CDC 활성화 옵션

– @supports_net_changes = 1

SSIS 새 기능[4]

CDC 데이터의 흐름

• CDC 관련 작업

– 제어흐름 • CDC 제어 작업

– CDC 데이터 life cycle 관리

» 데이터 로딩을 위한 LSN 설정

– 데이터 흐름 • CDC 데이터 원본

– 변경된 데이터를 로딩할 원본 테이블

• CDC 분할

– CDC 데이터를 Insert, Delete, Update로 구분

– 연결정보 • ADO.NET 연결 정보를 사용

• CDC ETL 구현

– 작업 순서 • 초기 데이터 작업

• 변경 데이터 작업

• ETL 이 후 데이터 관리 작업(_CT 테이블 관리 등)

초기 데이터로딩

변경 데이터 로딩 변경 데이터 로딩

Mark Initial load end

Mark Initial load start

Get processing range

Mark processed range

Get processing range

Mark processed range

– 초기 데이터 작업 • CDC 제어 작업 -> 초기 로드 시작 표시

• 데이터 흐름 작업 -> 모든 데이터 로딩

• CDC 제어 작업 -> 초기 로드 종료 표시

– 변경 데이터 작업 • CDC 제어 작업 -> 처리 범위 가져오기

• 데이터 흐름 작업

– CDC 원본 (cdc.<스키마>_<테이블>_CT)

» All(모두)

» All with old value(이전 값 포함 모두)

» Net(순 변경)

» Net with update mask(업데이트 마스크 포함 순 변경)

» Net with merge(병합 포함 순 변경)

– CDC 분할자

» 삽입, 업데이트, 삭제를 구분

– 데이터 대상

• CDC 제어 작업 -> 처리된 범위 표시

• DQS Cleansing(DQS 정리)

– Data Quality Server 설치 후 사용 가능

SSIS 새 기능[5]

• Data Quality Service

– 지식 기반 데이터 품질 서비스 • 데이터 품질 강화 및 표준화 기능

– 도메인으로 데이터를 관리 • 예) 권역 도메인

– Data Cleansing(정리) • 서울, 서울시 -> 서울특별시

• 수원시, 구리시 -> 경기도

서울특별시 경기도

서울 수원시

서울시 구리시

• 도메인 관리 화면

– DQS Cleansing(정리)

• 피벗

SSIS 새 기능[6]

1

2

3

• 이전 버전 피벗

• Parameters(매개변수)

– 프로젝트 매개변수 • 프로젝트 모든 Package에서 공용하는 변수

– 프로젝트 배포 모델에서 사용 가능

– 사용 방법

» 솔루션탐색기 -> Project.params 더블 클릭 -> 매개변수 추가

» 변수 명, 데이터타입, 값, 중요, 필수, 설명 입력

– Package 매개변수 • 해당 Package 에서만 사용

– 입력 값 • 중요 항목 -> True 변경 시 Value 암호화

• 필수 항목 -> 배포 후 Package 실행 시 Value 입력

– 패키지 구성보다 사용이 용이 • 패키지 구성은 속성으로 이동

SSIS 새 기능[7]

• Deploy(배포)

– Legacy Deployment • 이전 버전의 배포와 동일

• 하나의 Package가 배포 단위

– Project Deployment • Integration Services Catalogs에 배포

• 유효성 검사 리포팅 지원

• 버전 기능

– 총 10개 버전 지원

• 매개변수, Environment 지원

• 하나의 프로젝트가 배포 단위

SSIS 새 기능[8]

• 프로젝트 배포 과정 – SSISDB Catalog 설치

• CLR 통합 기능 체크, 암호 입력

– 솔루션 탐색기의 프로젝트 우 클릭 후 배포

• 유효성 검사 – 프로젝트, Package 단위

– 리포트 및 대시보드 형태로 열람 가능

• 버전 관리 – 이전 버전으로 롤백 가능

• 배포된 프로젝트만 해당

• 프로젝트 삭제 – exec [catalog].[delete_project]＇프로젝트',＇폴더'

– exec [catalog].[delete_folder] ＇폴더'

• SQL Server Columnstore의 특징 – Enterprise Edition 지원 – 열 기반 데이터 구조 – 집계 쿼리 성능 향상

• 필요한 열 데이터만 사용 • 높은 압축률

– 다음 데이터까지의 바이트 수 감소

• 집계 작업 감소 – Olap Cube 감소 – 집계 테이블 작업의 감소

– 인덱스 열 개수 제한 • 최대 1024개(일반 테이블의 최대 열 개수) • 행 기반의 인덱스는 16개 제한

– 클러스터형 제공 X – 파티션 된 테이블 지원 – 데이터 직접 갱신 불가(삽입, 삭제, 업데이트)

• 이후 버전에서 변경될 가능성이 있음

Columnstore Index

• Column-Store

– 열 단위로 데이터를 페이지에 저장

Columnstore Index

Column1 Column2 Column3 ...

.

.

.

.

.

.

Column1 Column2 Column3 ...

.

.

.

.

.

.

• Row-Store – 행 단위로 데이터를 페이

지에 저장

Columnstore Index

• Row-Store Storage

8KB

#Rows A1 B1 C1 … A2 B2 C2

… …

Am Bm Cm … Page Info

Table Page0 Page1 … eof

8KB

B1 B2

…

…

Bn Page Info

#val

8KB

A1 A2

…

…

An Page Info

#val

Table PageA0 PageA1… eof PageB0 PageB1… eof

• Column-Store Storage

• 장단점

– Row-Store • 데이터 업데이트가 보다 용이함

• 일반적으로 불필요한 열 데이터 읽기 발생

• 압축 효율이 상대적으로 낮음

• Random Access에 유리함

– Column-Store • 대용량 데이터 읽기 성능이 비교적 뛰어남

• 데이터 업데이트가 까다로움

• 압축 효율이 상대적으로 높음

Columnstore Index

• SQL Server 2012

Columnstore Index

EmployeeID Name City State

1 Ross San Francisco CA

2 Sherry New York NY

3 Gus Seattle WA

4 Stan San Jose CA

5 Lijon Sacramento CA

Row Store

3 Gus Seattle WA

4 Stan San Jose CA

5 Lijon Sacramento CA

1 Ross San Francisco CA

2 Sherry New York NY

Columnstore

San Francisco New York Seattle San Jose Sacramento

CA NY WA CA CA

1 2 3 4 5

Ross Sherry Gus Stan Lijon

• xVelocity

– In-memory column store engine • 이전 버전에서 PowerPivot에 사용됨(Vertipaq)

– 높은 데이터 압축률 • 20,000,000 건 데이터 -> 엑셀 50MB (PASS 2009 PowerPivot)

• 데이터 값의 분포에 따라 압축률 변동

– 향상된 I/O 성능 제공 • 적은 수의 페이지 접근

– 모든 데이터의 distinct value를 dictionary에 저장

– 비트맵 인덱스인 pointer로 dictionary 참조

Columnstore Index

키 열 비트맵

1 100

2 010

3 100

4 001

5 100

6 010

7 010

Columnstore Index

Dictionary

A

B

C

데이터

A

B

A

C

A

B

B

• 성능

– 읽기 성능 • 단순 집계(SalesOrderDetail)

– 약 200만 건

– Index Scan vs. Columnstore Index Scan

Columnstore Index

78

1404

423

860

5576

742

cpu 사용 시간 논리적 읽기 수 경과 시간

ColumnStore 인덱스

IndexScan

– 압축 성능 • Columnstore 인덱스의 크기

– sys.column_store_segments와 sys.column_store_dictionaries의on_disk_size 열로 확인

• 테이블(206만 건) 사이즈 비교

Columnstore Index

180.79

8.48

216.67

44.28

reserved(MB) Index_size(MB)

ColumnStore 인덱스

NonClustered 인덱스

• Columnstore Index 생성 • create nonclustered columnstore index 인덱스명 on 테이블명 (컬럼명)

– 제한 사항 • 특정 데이터 형식 지원 안됨

– Binary, text, image, varchar(max), uniqueidentifier, timestamp, 18자리 이상의 decimal과 numeric, xml

• 기본 키 또는 외래 키로 사용 불가

• 고유 인덱스로 생성 불가

• 뷰 또는 인덱싱 된 뷰에 생성 불가

– 메모리 요구 사항 • 인덱스 생성 시

– MSDN : 8MB * 인덱스 열 수 * DOP(병렬 처리 수준)

– Technet : [(4.2 *인덱스 열 수) + 68]*DOP + (문자열 열 수 * 34)

Columnstore Index

Columnstore Index

• 데이터 업데이트 – 인덱스 삭제 후 재생성

• Columnstore 인덱스 삭제 -> 데이터 업데이트 -> Columnstore 인덱스 생성

• 데이터 업데이트 빈도가 적은 경우

• 처리 시간이 충분한 경우

– 파티션 된 테이블 1. 스테이지 테이블 2개 생성

– 업데이트 될 파티션과 같은 위치

2. 스테이지 테이블 중 1개에 데이터 삽입 이후 업데이트

3. 원본과 같은 Columnstore 인덱스 생성

4. 원본 테이블 데이터 삭제(빈 스테이지 테이블과 스위치)

5. 파티션 스위치

6. 스테이지 테이블 삭제

– Union All

• 주의사항

– 성능 저하 가능성 • 전체적인 작업 성능 저하

– 쿼리 힌트로 Columnstore 인덱스 피하기

» IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX

» 안될 경우 Columnstore 인덱스 삭제

• 큰 테이블 조인 시

– 메모리를 초과하는 해시 테이블 생성 -> 성능 저하

• 조인 조건이 두 개 이상인 경우

• 쿼리 결과로 여러 개의 열이 반환 되는 경우

– Columnstore 인덱스를 검색해야 하는 경우

– SQL Server 메모리 관리(32bit 주의) • 에러코드 701 관련 오류

http://technet.microsoft.com/ko-kr/library/aa337311.aspx

Columnstore Index

• 고려 사항

– 어느 테이블의 어떤 열에 Columnstore 인덱스를 생성 할 것인가? • 제한된 결과를 반환할 때 불필요

– 조인 테이블의 결과가 적을 때

– 특정 조건으로 결과 집합이 작을 때

• 큰 범위의 집계 쿼리에 적합

• 빈번한 갱신이 일어나는 테이블?

– 유지보수 비용 고려

– OLTP에서 사용이 가능할까? • 읽기 전용 DB 에 가능

– Columnstore 인덱스를 읽기 전용 메커니즘으로 사용하지 말 것

– 비용 측면 • Cube 생성 vs. columnstore 인덱스

Columnstore Index

• [1]SQL_Server_2012_xVelocityBenchmark_DatasheetMar2012[1].pdf

• [2]Microsoft_Press_ebook_Introducing_SQL_Server_2012_Preview_II.pdf

• [3]Column-Oriented Database Systems. [VLDB 2009 Tutorial]

• [4]Column-Stores vs. Row-Stores: How Different Are They Really? [sigmod08]

• [5]http://msdn.microsoft.com

• http://tdon.blog.me/ 외 다수의 블로그 등

참고 문헌