안녕하세요. DB2 및 XpertMon 사용자 여러분!
㈜ 아이티엑스퍼트그룹 DB 사업부입니다.
저번 뉴스레터에서 말씀드린대로, XpertMon for DB2 UDB V2.0이
한국정보통신기술협회(TTA) 로부터 GS인증(Good Software) 를 획득하였습니다.
GS마크를 획득한 소프트웨어의 경우, 공공기관을 대상으로 우선 구매 대상이 되며,
조달청 제3자 단가계약이 가능합니다.
앞으로도 계속적인 관심과 격려 부탁드립니다.
이번주와 다음주 뉴스레터에서는 V8의 새로운 기능 중 MDC(Multi-Dimensional Clustering)에
대해 살펴보도록 하겠습니다.
이번주는 MDC에 대한 기본적인 설명을 드리고, 다음주 뉴스레터에서는 V8.2.2에 추가된
MDC 기능에 대해 설명드리도록 하겠습니다.

---

MDC (Multi-Dimensional Clustering)
기존 Clustering
지금까지는 각 테이블에서 하나의 인덱스를 Clustering Index 로 지명하고,
해당 Index 키값과 같은 물리적 순서로 데이터를 저장하는 방법이 사용되어왔습니다.
DB 설계시에 특정 컬럼을 선택하고, 해당 컬럼대로 데이터를 저장하는 이러한 방법은,
쿼리시에 I/O 를 줄여 성능을 향상할 수 있는 결과를 가져왔습니다.
하지만 이 경우에 만약 insert 해야하는 정확한 페이지에 공간이 부족하게 되는 경우에는
해당 row가 다른 곳에 저장되게 됨으로써, REORG를 수행하지 않으면, I/O cost가 늘어나
성능이 저하될 수 있는 단점이 있었습니다.

V8.1 의 새로운 Clustering 기법
MDC 기능을 사용하면, 동시에 여러 개의 다른 방법으로 데이터가 Clustering 될 수 있습니다.
아래와 같이 ORGANIZE BY SQL 절을 사용하여, 데이터를 Clustering 하기 원하는 컬럼명을 적습니다.
예를 들어 아래와 같이 PRODUCT_SALES 테이블은 region과 type 이라는 컬럼으로 각각 clustering 하려고 합니다.


데이터 입력
다음의 데이터를 입력합니다.

REGION	TYPE	DATE	PRODUCT_CODE
NORTH	SOFTWARE	01/02/03	3443
NORTH	SOFTWARE	03/03/03	5446
NORTH	HARDWARE	10/12/02	6654
NORTH	ACCESSORIES	21/03/03	5566
NORTH	ACCESSORIES	14/01/03	3443
EAST	HARDWARE	16/11/02	2344
EAST	ACCESSORIES	02/11/02	6543
EAST	ACCESSORIES	23/01/03	7567
EAST	ACCESSORIES	14/02/03	3345
SOUTH	HARDWARE	01/12/02	6632
SOUTH	SOFTWARE	31/01/03	3443
SOUTH	SOFTWARE	21/12/02	5674
SOUTH	SOFTWARE	25/12/02	8734
WEST	HARDWARE	01/01/03	2323
WEST	HARDWARE	14/02/03	8734

MDC 테이블은 Extent 크기와 동일한 Block 으로 구성됩니다.
각 Block에는 Cell이라고 불리는 특정 clustering dimension row 값들로 채워집니다.
위의 예에서 각각의 블록은 특정 region 과 product type 값들로 구성됩니다.
위에서 region과 product type 의 unique 조합은 8개 ( 즉, cell이 8개) 이므로,
각 cell 별로 하나씩의 block 을 갖는다고 하면, 최소한 8개의 block 이 생성될 것입니다.
INSERT 시에는 해당 row의 clustering dimension 값을 체크해서, 거기에 맞는 block으로
데이터가 입력됩니다. 만약 해당 block에 충분한 공간이 없으면, 새로운 block을 찾아보거나
아니면 새로운 블록을 할당하여 거기에 데이터를 입력합니다.

MDC 테이블 구조
그럼 실제로 optimizer 는 어떻게 MDC 데이터에 억세스할까요?
MDC 테이블을 작성하면, 자동적으로 2개의 새로운 타입의 인덱스가 생성됩니다.
둘 다 구조적으로는 일반적인 RID 인덱스와 동일하지만, index 가 가리키는 point 가
특정 row가 아닌 block을 가리킨다는 것만 다릅니다.
따라서 이러한 “block index” 는 일반적인 인덱스보다 크기가 더 작습니다.
먼저 “composite block index “ ( 복합 블록 인덱스, INDEXTYPE= BLOK ) 는
모든 dimension 에 걸쳐 1개 작성됩니다.
이 index는 insert 시에 해당 row가 어느 block에 들어가야되는지 판단하는데 사용됩니다.
또한 각각의 dimension 마다 “dimension block index “( INDEXTYPE=DIM) 가 1개씩 작성됩니다.
이 인덱스는 각각의 dimension 값을 가지고 있고, 해당 dimension 값과 관련된 block을
가리키는 포인터를 가지고 있습니다.

따라서 위의 예에서는 자동적으로 3개의 인덱스가 작성될 것입니다.
( 1개의 “composite block index” 와 2개, 즉 REGION 과 TYPE 에 대한 각각의 “dimension block index” ) 이 방법으로 인덱스를 구성하면, REGION 과 TYPE에 의해 동시에 데이터를 효과적으로
clustering 할 수 있게 됩니다.
또한, 일반적인 인덱스가 한 개의 pointer로 하나의 row를 찾을 수 있는 것에 반하여,
한 개의 index pointer로 block안에 있는 모든 row들을 찾을 수 있으므로,
access 측면에서도 매우 효과적입니다.

Explain 수행

• Region이 NORTH인 모든 Row의 PRODUCT_CODE를 추출하는 쿼리를 수행합니다.
  
• Explain 을 수행하여 해당 쿼리의 Access path를 살펴봅니다.
  
  

위의 Explain 정보에서 보여지는 것같이, REGION 이 NORTH인 모든 블록을 검색하기 위해
REGION 컬럼에 존재하는 dimension index “SYSIBM.SQL050803104118420” 가 사용되었음을
볼 수 있습니다.
이 쿼리를 만족시키는 블록을 Access 하는데 이 인덱스를 사용하는 것이 가장 효과적일 것입니다.
특히 block index scan을 할 때, DB2 는 “block look-ahead prefetching” 기법을
사용할 수 있습니다.
이것은 prefetcher가 적합한 블록 인덱스에서 해당되는 인덱스 페이지를 prefetch 할 뿐만
아니라 각 적합한 블록 ID와 일치하는 데이터 페이지의 전체 Extent를 프리페치 하는 것을 의미합니다.

Report 기능을 이용한 수행 결과 비교
일반적인 테이블의 쿼리 수행시간과 MDC 쿼리 수행시간을 비교해보도록 하겠습니다.

일반적인 테이블의 인덱스를 사용했을 경우와 MDC 의 block index 를 사용했을 경우의 비교입니다.
첫번째 결과가 일반 테이블이며, 두번째 결과가 MDC 테이블입니다.
비교 내용에서 보면, 수행시간은 비슷하다 하더라도 CPU time이 일반테이블이 더 높음을
볼 수 있습니다.
그것은 index 의 logical read 수 ( 265: 9) 가 MDC 가 현저하게 작기 때문입니다.
따라서, MDC의 경우, Index를 잘 사용하면 비슷한 수행시간이다 하더라도 좀 더 적은
자원을 가지고 쿼리를 수행할 수 있음을 알 수 있습니다.

결론
조금 복잡하긴 하지만, MDC 를 구축하면 많은 장점이 있습니다.
MDC는 물리적으로 많은 다른 방법으로 데이터를 Clustering 합니다.
그리고 MDC에 생성되는 block index 는 일반적인 인덱스보다 그 크기가 매우 작습니다
특히 Business Intelligence와 Data Warehousing Application 환경에서 복잡한 타입의
Query 성능을 빠르게 향상시킬 수 있습니다.

---

XpertMon for DB2 UDB V2
DB 사업부
Tel : 02-2108-1458
Fax : 02-2108-1459
Mobile : 011-896-6545
E-mail : hjlee@iteg.co.kr
URL : http://iteg.co.kr