IBM DB2 UDB Blog Center

머리말

데이터베이스 워크로드는 항상 변화하기 마련이다. 워크로드와 실행 환경은 증가하는 사용자들, 쿼리 패턴의 변화, 관리 태스크 실행, 다른 애플리케이션들이 사용하는 리소스의 변화와 같은 다양한 요소들 때문에 시간의 흐름에 따라 변하기 마련이다. 따라서, 숙련된 관리자가 어떤 한 시점에 시스템 튜닝을 하더라도, 또 다른 시점에는 이러한 튜닝이 최적 상태가 아니다. 변경 사항들은 (일 또는 주 단위가 아닌) 초 단위로 발생하기 때문에 관리자가 대응할 시간이 없다. 데이터베이스 메모리 설정은 이 같은 시스템 환경의 변화에 취약하고 응답 시간에 심각한 영향을 미칠 수 있다.

데이터베이스 메모리 설정을 자동으로 튜닝하고, 런타임 시 동적으로 조정하여 퍼포먼스를 최적화 하고 관리자의 생산성을 높이는, DB2 9의 새로운 자가 튜닝(self-tuning) 메모리 관리 기능을 소개한다.

작동 방법

DB2 9의 자가-튜닝 메모리 기능은 시작 시 여러 메모리 구성 매개변수에 대한 값을 자동으로 설정하여 메모리 설정 태스크를 단순화 한다. 자가 튜닝(self-tuning) 메모리 매니저는 지능형 제어와 피드백 메커니즘을 사용하여 워크로드 특성, 메모리 사용, 데이터베이스의 다양한 공유 리소스에 대한 수요 등을 지속적으로 추적하여, 필요할 때 마다 메모리 사용을 동적으로 조정한다. 예를 들어, 정렬(sort) 작업에 더 많은 메모리가 필요하고, 몇몇 버퍼풀(buffer pool)이 메모리를 초과하면, 메모리 튜너(tuner)는 초과된 버퍼 풀 메모리를 비우고 이것을 정렬 힙(sort heap)에 할당한다.

그림 1. 데이터베이스 메모리

Windows®와 AIX® 플랫폼에서, 자가 튜닝 메모리 기능은 전체적인 데이터베이스 메모리 요구량을 파악하고, 데이터베이스 메모리 사용량을 동적으로 조정한다. 이 플랫폼에서는 데이터베이스 리소스들간 메모리 활용도를 동적으로 조정하는 것 외에도, DB2는 워크로드가 메모리를 요구하는 만큼 물리적 메모리를 소비하고, 데이터베이스 메모리 요구량이 낮을 때 다른 태스크와 애플리케이션을 위해 그 메모리를 비워둔다.

자가-튜닝(self-tuning) 메모리 실행하기

메모리 자가-튜닝은 데이터베이스 공유 메모리 리소스에서 실행된다. 이 리소스에는 다음 사항들이 포함된다:

• 버퍼 풀(Buffer pools) (ALTER BUFFERPOOL과 CREATE BUFFERPOOL 문으로 제어됨)
• 패키지 캐시(Package cache) (pckcachesz 설정 매개변수에 의해 제어됨)
• 잠금 메모리(Locking memory) (locklist와 maxlocks 설정 매개변수에 의해 제어됨)
• 정렬 메모리(Sort memory) (sheapthres_shr와 sortheap 설정 매개변수에 의해 제어됨)
• 총 데이터베이스 공유 메모리(Total database shared memory) (database_memory 설정 매개변수에 의해 제어됨)

자가-튜닝(self-tuning) 메모리는 self_tuning_mem 데이터베이스 설정 매개변수를 사용하여 실행된다. DB2 9에서, 새로운 데이터를 만들 때 (파티션되지 않은 데이터베이스의 경우) 자가 튜닝(self-tuning) 메모리는 자동으로 실행된다. self_tuning_mem이 ON으로 설정되고, 위에 열거된 리소스용 데이터베이스 매개변수들이 AUTOMATIC으로 설정된다. 이전 버전의 DB2에서 마이그레이션 된 기존 데이터베이스의 경우, 자가 튜닝 메모리는 직접 실행되어야 한다. 모든 데이터베이스 메모리 리소스들을 자동으로 관리되도록 하는 대신, 원하는 메모리 리소스들(매개변수들)만 AUTOMATIC으로 설정할 수도 있다.

효용성

일반적으로, 최적의 연산을 위해 데이터베이스 메모리 매개변수를 설정하는 일은 복잡하고 시간이 많이 든다. 데이터베이스용 메모리 매개변수를 자동으로 설정함으로서, DB2 9은 데이터 서버를 설정하는 태스크를 단순화 한다. 이로서 DBA 생산성이 향상되고, 관리자는 다른 중요한 태스크에 집중할 수 있는 여유도 생긴다.

메모리 설정을 단순화 하는 것 외에도, 이 새로운 자가 튜닝 메모리 기능은 워크로드의 중요한 변경에 대해 동적이고 반응성이 뛰어난 고급 설정을 제공하여 퍼포먼스를 향상시킨다.

이러한 기능은 같은 시스템에서 여러 데이터베이스들이 실행되고 있을 때, 특정 데이터베이스가 피크 타임에 더 많은 메모리를 소비하도록 자동으로 설정하고, 다른 데이터베이스와 워크로드가 필요로 할 때를 대비하여 비워두기 때문에 이 효과적이다.

자가-튜닝(self-tuning) 메모리 수행 결과

그림 2의 그래프는 사용자의 요구에 따라 설정된 벤치마크에 대한 DB2 자가 튜닝 메모리 실행 모습이다. DB2는 자동으로 데이터베이스 공유 메모리(왼쪽 그래프)를 늘려 워크로드 요구를 충족시키고, 쿼리 처리량도 여기에 상응하여 증가세를 보인다. (오른쪽 그래프)

그림 2. 자동 튜닝이 시스템 퍼포먼스에 미치는 영향

맺음말

DB2 9의 자가-튜닝 메모리는 많은 시간을 절약하고, 메모리 튜닝을 단순화 하며, 퍼포먼스를 자동으로 최적화 할 수 있는 혁신적인 기능이다. DB2 9을 다운로드 하고 이러한 기능을 직접 경험해 보기 바란다.

기사의 원문보기

• Introducing DB2 9, Part 3: Self-tuning memory in DB2 9

참고자료

교육

• DB2 Express-C
  
  
• IBM DB2 'Viper' revs XML engine
  
  
• articles about DB2 9 on developerWorks.
  
  
• 한국 developerWorks Information Management 존
  
  
• developerWorks DB2 for Linux, UNIX, and Windows resource page
  
  
• developerWorks technical events and Webcasts
  
  

제품 및 기술 얻기

• DB2 9 다운로드
  
  
• DB2 Express-C 다운로드
  
  
• IBM 평가판 SW
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 블로그
  

머리말

대용량 데이터베이스와 테이블 관리는 어려운 일이다. 테이블 크기가 커지면, 그렇게 큰 테이블에서 전체적으로 모든 데이터를 관리하는 것보다 데이터를 몇 개의 청크(chunks) 혹은 범위를 제한하여 관리하는 것이 더 쉬운 방법이 될 수 있다. 이러한 데이터 관리 방식은 새로운 데이터의 청크(chunks)나 범위가 추가되거나 오래된 데이터가 빈번히 테이블에서 삭제될 때 특히 유용하다. (예를 들어, 데이터 웨어하우징 환경에서는 일반적인 롤인과 롤아웃 작동).

DB2 9의 테이블 (범위) 파티셔닝 기능으로 관리가 쉬워지고, 퍼포먼스가 높아지며, 대용량 데이터베이스의 확장성도 더욱 향상된다.

테이블 파티셔닝이란?

테이블 파티셔닝(종종 ‘범위 파티셔닝’이라 불리운다.)은 데이터 구성 스킴(scheme)으로서, 한 개 이상의 테이블 칼럼의 값에 따라, 테이블 데이터는 데이터 파티션이라고 하는(데이터베이스 파티션이나 DPF와 혼돈하지 않길 바란다.) 여러 스토리지 객체들로 나뉘어 진다. 이러한 스토리지 객체들은 다른 테이블 공간 또는 같은 테이블 공간, 또는 이 두 가지를 혼용하여 존재할 수 있다.

DB2 9은 다양한 애트리뷰트에 따라서 데이터 파티션이나 데이터 범위를 지원한다. 일반적으로 사용되는 파티셔닝 스킴은 날짜이다. 데이터 파티션에서 연도(year)나 달(month)별로 데이터를 묶을 수 있다. 또한 파티셔닝에는 숫자 애트리뷰트도 가능하다. 예를 들어, 1에서 백만 까지의 ID를 가진 기록들이 하나의 데이터 파티션에 저장되고, 백만에서 2백만 까지의 ID가 또 다른 데이터 파티션에 저장된다. 또는, 하나의 데이터 파티션에 A-C로 시작하는 이름을 가진 고객들을 저장하고, 두 번째 파티션에는 D-M, 세 번째 데이터 파티션에는 N-Q, 마지막 데이터 파티션에는 R-Z 등으로 저장할 수 있다.

(데이터 파티션 연산에 유용한) 이름이나 숫자로 데이터 파티션을 참조하는 옵션이 있지만, 데이터 파티션은 애플리케이션에 대해 투명하다. 다시 말해서, 애플리케이션은 칼럼과 테이블 이름을 지정하여 데이터에 액세스 할 수 있고, 데이터가 어떤 데이터 파티션에 있는지를 알 수 있다.

DB2 for Linux®, UNIX®, Windows®의 테이블 파티셔닝 기능은 DB2 for z/OS®, Informix® Dynamic Server, Informix Extended Parallel Server의 파티셔닝 기능과 비슷하다. DB2 for z/OS, DB2 for iSeries™와 DB2 for Linux, UNIX, Windows는 공통모듈을 사용하지만, 하위세트(subset)의 구현은 다르다. DB2 for Linux, UNIX, Windows는 다른 두 제품의 신택스 보다 훨씬 더 간결한 축약 신택스를 사용한다.

테이블 파티셔닝 효과

DB2 9의 테이블 파티셔닝의 효과는 다음과 같다:

• 대용량 테이블의 관리 향상
• 데이터 파티션 경감을 통한 쿼리 퍼포먼스 향상
• 빠른 온라인 데이터 롤-인 / 롤-아웃
• 스토리지 비용의 최적화
• 더 커진 테이블 용량
• 더욱 유연해진 인덱스 배치

관리 향상: DB2 9에서는 다양한 데이터 파티션들이 독립적으로 관리된다. 예를 들어, 전체 테이블 대신 개별 데이터 파티션을 백업 및 복원할 수 있다. 따라서 시간이 오래 걸리는 관리 작업을 더 작은 작업 단위로 나눌 수 있는 것이다.

쿼리 퍼포먼스 향상: DB2 옵티마이저는 데이터 파티션을 인식한다. 따라서 쿼리가 실행 중일 때 오직 관련 데이터 파티션만 스캔된다. 쿼리에 영향을 받지 않는 데이터 파티션은 스캔하지 않도록 하여 퍼포먼스를 높인다.

그림 1. 관련 파티션만 스캐닝 하기

빠른 롤-인 / 롤-아웃 : DB2 9은 데이터베이스를 끄지 않아도 테이블에서 데이터 파티션을 쉽게 추가 또는 제거할 수 있다. 이 기능은 의사 결정 지원(decision-support) 쿼리를 실행하기 위해 데이터를 자주 로딩 또는 삭제해야 하는 데이터 웨어아우스 환경에 특히 유용하게 사용된다. 어떤 보험 데이터 웨어하우스에 3년 간의 클레임 내역이 저장되어 있다고 가정해 보자. 매 달 웨어하우스로 로딩 및 롤아웃 되면서, 가장 오래된 달은 활성 테이블에서 압축 및 제거(롤아웃) 될 수 있다. 이렇게 데이터 파티션을 롤아웃 하는 방식은 delete 문 수행 log를 남길 필요가 없기 때문에 더욱 효율적이다.

스토리지 비용의 최적화: DB2 9의 테이블 파티셔닝은 계층적 스토리지 모델과 더 잘 통합된다. 가장 활성화 된 데이터 파티션에 가장 빠르고 비싼 스토리지 하드웨어를 사용하기만 해도 DB2 9은 전체 스토리지 비용을 최적화 하고 퍼포먼스를 높일 수 있다. 최근 세 달 동안의 데이터에 대해서만 대부분의 쿼리가 실행한다면, 오래된 데이터에 대해서는 좀 더 느리고 덜 비싼 스토리지 하드웨어를 할당할 수 있다.

더욱 커진 테이블 용량: 파티셔닝 없이는 스토리지 객체(테이블)가 보유할 수 있는 최대 데이터의 양이 제한된다. 하지만 테이블의 콘텐트를 여러 스토리지 객체나 데이터 파티션으로 나누고, 각각의 테이블 파티션이 파티션 되지 않은 테이블이 보유할 수 있는 데이터 만큼을 지원한다고 볼 때 가상으로는 무제한 크기의 데이터베이스를 효과적으로 만들 수 있다.

더욱 유연해진 인덱스 배치: DB2 9에서는 파티션 테이블용 인덱스들이 고유의 스토리지 객체(테이블 공간)에 저장될 수 있다. 파티션 되지 않은 테이블의 경우 같은 스토리지 객체에 저장되는 것과는 반대되는 이치이다. 이러한 인덱스 배치로 인해, 테이블에 있는 인덱스 데이터로 효율적인 동시 액세스가 가능해져서, 더욱 빠른 인덱스 연산(드롭 인덱스, 온라인 인덱스 생성, 인덱스 재구성)이 가능하고, 테이블 증가를 관리하며, I/O 경쟁을 줄일 수 있다.

테이블 파티션 생성 및 사용

DB2에서는 테이블 파티션 생성이 매우 유연하다. 예를 들어, 1년치 데이터가 있고, 이것을 날짜 별로 파티션 하여, 한 분기씩 개별 데이터 파티션에 있도록 한다. 아래 create 테이블 신택스는 이를 쉽게 수행하는 방법을 설명한다. 또한 그래픽 DB2 Control Center를 사용하여 데이터 파티션을 생성 및 관리할 수 있다.

CREATE TABLE orders(id INT, shipdate DATE, …)

  PARTITION BY RANGE(shipdate)

    (

    STARTING '1/1/2006' ENDING '12/31/2006' 

      EVERY 3 MONTHS

    )

이렇게 하면 네 개의 데이터 파티션을 가진 테이블이 만들어지고 각각 세 달치의 데이터를 갖게 된다.

그림 2. 네 개의 데이터 파티션을 가진 테이블

예제에서 설명하는 것처럼, 데이터 파티션 범위를 구체적으로 지정하고, 시작과 종료 범위를 만들고, 각 데이터 파티션에 이름을 짓는 것이 가능하다. 데이터 파티션의 네이밍은 DETACH 같은 데이터 파티션 조작을 수행하는데 유용하다.

CREATE TABLE orders(id INT, shipdate DATE, …)

  PARTITION BY RANGE(shipdate)

    (

  PARTITION 4q05 STARTING MINVALUE,

    PARTITION 1q06 STARTING '1/1/2006',

    PARTITION 2q06 STARTING '4/1/2006',

    PARTITION 3q06 STARTING '7/1/2006',

    PARTITION 4q06 STARTING '10/1/2006' 

                  ENDING ‘12/31/2006'

    )

테이블 파티셔닝을 사용하면 데이터를 동시에 롤인, 롤아웃 할 수 있다. ALTER TABLE 명령어의 ATTACH와 DETACH 옵션들은 이러한 수행을 하도록 한다. DETACH를 사용하여 기존 데이터 파티션이나 값의 범위가 별개의 테이블로 나뉜다. 롤아웃(분리된) 테이블은 드롭(삭제) 혹은 별도로 저장되거나 느린 스토리지로 옮겨질 수 있다.

마지막 예제에서 만들어진 주문 테이블에 단 1년짜리(2006) 데이터를 저장해야 할 경우도 있다. 오래된(2006년 이전) 데이터를 포함하고 있는 파티션에 DETACH 연산을 수행할 수 있다.

ALTER TABLE orders 

	DETACH PARTITION qold INTO oldorders

이와 마찬가지로, 한 테이블에 있는 새로운 데이터 파티션으로서 데이터를 붙이는(attach하는) 것(롤인) 역시 쉽다. 롤인 될 데이터는 처음 개별(스테이징) 테이블에 로딩되고 필요에 따라 변환 및 제거 과정을 거치며 이미 존재하는 테이블에 추가(attach)된다.(추가해주세요) 그 예가 아래 보여진다.

// CREATE TABLE neworders

// load / insert desired data into neworders

// transform or cleanse new data if neeeded

  ALTER TABLE orders

  	ATTACH PARTITION 1q07

  	STARTING '01/01/2007'

  	ENDING   '03/31/2007'

  	FROM TABLE neworders 

// COMMIT 

// SET INTEGRITY …

// COMMIT

롤인 된 데이터가 애플리케이션에 보이기 전에 (새로운 데이터의 유효성을 검사하고 글로벌 인덱스를 관리하기 위해) SET INTEGRITY 문의 실행으로 작업이 확약될 필요가 있다.

그림 3은 이전 예제에 사용되었던 주문 테이블의 롤-인 / 롤-아웃 데이터 모습이다.

그림 3. 데이터 파티션 롤-인 / 롤-아웃

테이블 파티셔닝과 기타 구성 스킴

DB2 9의 테이블 파티셔닝은 다른 데이터 구성 스킴들과 결합하여 사용되거나 독립적으로 사용될 수 있다. CREATE TABLE 문의 각 구절에는 데이터가 구성되는 방법을 나타내는 알고리즘이 포함되어 있다. 다음 세 개의 구문들은 조합되어 사용될 수 있는 데이터 구성 레벨이다.

• DISTRIBUTE BY -- 데이터를 공평하게 데이터베이스 파티션에 분산한다. 이 구절을 사용하여 인트라쿼리(intraquery) 병렬 처리가 가능하고 각 데이터베이스 파티션에 로드를 분산할 수 있다. 이 개념은 데이터베이스 파티셔닝으로 알려져 있고 DB2에서 Database Partitioning Feature (DPF)를 사용하여 실행한다.
• PARTITION BY -- 같은 데이터 파티션에 같은 차원의 비슷한 값으로 행(row)을 그룹핑한다. 이 개념은 테이블 파티셔닝이라고 한다.
• ORGANIZE BY -- 같은 테이블 확장에서 여러 차원에 대한 비슷한 값으로 행을 그룹핑 한다. 이 개념은 다차원 클러스터링(MDC)이라고 한다.

이 신택스를 사용하면 구절 간 일관성을 유지하는 것이 가능하고 미래의 데이터 구성 알고리즘도 가능하다. CREATE TABLE 문의 DISTRIBUTE BY와 PARTITION BY를 결합하면 데이터는 여러 테이블 공간에 걸쳐 존재하며 데이터베이스 파티션 전반으로 확대된다.

DB2 9은 데이터를 동시에 그룹핑하는 세 개의 방법을 지원하는 최초의 데이터 서버이다. 이는 데이터 관리와 정보 가용성을 향상시키는 크나큰 혁신이다.

그림 4는 서로 연결되어 사용되는 세 개의 DB2 데이터 구성 스킴이다:

그림 4. 세 개의 DB2 데이터 구성 스킴

맺음말

DB2 9의 테이블 파티셔닝은 큰 볼륨을 쉽고 빠르게 관리할 수 있는 강력한 기능을 제공한다. DB2 9을 다운로드 하여 이 글에서 설명한 기능과 기타 기능들을 직접 경험해 보기 바란다.

기사의 원문보기

• Introducing DB2 9, Part 2: Table partitioning in DB2 9

참고자료

교육

• DB2 Express-C
  
  
• DB2 Viper: Range Partitioning and Large RID support
  
  
• articles about DB2 Viper (developerWorks)
  
  
• 한국 developerWorks Information Management 존
  
  
• developerWorks DB2 for Linux, UNIX, and Windows resource page
  
  
• developerWorks technical events and webcasts
  
  

제품 및 기술 얻기

• DB2 9 다운로드
  
  
• DB2 Express-C 다운로드
  
  
• IBM 평가판 SW
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 블로그
  

머리말

디스크 스토리지 시스템들은 데이터베이스 솔루션에 있어서 가장 값비싼 부분이 되기도 한다. 큰 웨어하우스나 많은 양의 데이터를 갖고 있는 데이터베이스의 경우, 스토리지 서브시스템(subsystem)의 비용은 하드웨어 서버와 데이터 서버 소프트웨어 비용을 합친 것을 거뜬히 넘는다. 따라서 스토리지 서브시스템을 조금만 줄여도 전체적인 데이터베이스 솔루션에 상당한 비용 절감 효과를 거둘 수 있다.

행(row) 데이터를 압축하여 스토리지 요구량 줄이고, I/O 효율성을 높이며, 디스크에서 데이터로 더욱 빠르게 액세스 할 수 있는 DB2 9 (이전 코드명 "DB2 Viper") Venom 기술을 소개하고자 한다.

데이터 행(row) 압축 - 어떻게 동작하는가

DB2 9의 "Venom" 기술은 데이터 레코드를 압축할 때 알고리즘에 기반한 딕셔너리를 사용한다. DB2 9은 반복되거나 중복된 데이터가 있는 테이블을 검사하고, 그러한 반복 엔트리에 간단한 숫자 키를 할당하는 딕셔너리를 구축하여, 데이터베이스 테이블에 있는 여러 행(rows)을 압축한다. 텍스트 데이터는 앞뒤로 붙는 공백문자들이나 반복되는 문자열이 많기 때문에 압축이 잘 이루어진다.

DB2는 단순히 특정 필드나 행의 일부가 아닌, 전체 행을 검사하여 반복되는 엔트리나 패턴들이 있는지를 검사한다. 다음 예제를 보자.

Dept 칼럼에서 반복되는 값("500")이 압축되고, 그 외에도 City, State, ZipCode 칼럼에서 반복되는 패턴("Plano, TX, 24355") 역시 하나의 값으로 압축된다. 그림 1은 DB2가 정상적인 방법으로 열을 저장하는 방법과 압축 포맷으로 저장하는 방법을 비교한 것이다.

압축/비압축 검색을 위한 딕셔너리는 데이터베이스 내 비밀 객체에 저장되고, 작은 공간을 차지하며, 빠른 액세스를 위해 메모리에 캐싱된다. 아주 큰 테이블이라 할지라도 압축 딕셔너리는 대게 100 KB 정도이다. 특정 데이터 세트가 압축을 잘 못하거나 많이 압축할 수 없는 데이터 크기가 있을 수 있다. DB2는 지능형 알고리즘을 갖고 있어 이 같은 상황을 파악하고 디스크 공간 절약이라는 효용성이 없다고 판단되면 압축을 하지 않는다.

DB2 for Linux®, UNIX®, Windows®의 데이터 열 압축 기능은 DB2 for z/OS®의 기능과 비슷하다. 하지만 이것은 다른 데이터베이스 벤더들이 제공하는 페이지 레벨 압축 기술과는 다르다. 여기에서 압축 딕셔너리는 데이터베이스의 각 페이지에 대해 만들어진다. 페이지 레벨이 아닌 테이블에서 압축 딕셔너리를 만들기 때문에 전체 테이블의 패턴들이 분석되고 디스크 절약 효과도 높아지게 되는 것이다.

압축 활성화하기

DB2의 데이터 행 압축은 COMPRESS YES 옵션을 사용하여 테이블이 만들어질 때 이루어진다. 또한, ALTER TABLE 명령어를 사용하여 기존 테이블에도 이를 적용할 수 있다. 예를 들어,

CREATE TABLE Sales COMPRESS YES

또는,

ALTER TABLE Sales COMPRESS YES

압축은 테이블 딕셔너리가 생성되어야만 가능하다. 이는 대게 테이블 REORG 단계 동안 발생한다.

큰 테이블을 압축할 때 테이블과 함께 "대표" 세트나 샘플 데이터를 먼저 파퓰레이트 하는 것이 유용하다. 작은 데이터 세트를 사용하면 압축 딕셔너리를 만드는 과정은 매우 빨라질 수 있다. 올바른 대표 샘플 세트라면 테이블에 새로운 데이터가 들어올지라도 이에 대한 별도의 분석이 필요 없이 압축은 잘 적용된다. 하지만 테이블에 저장된 데이터 유형이 여러 번 변화하면 딕셔너리는 REORG를 사용하여 최신 데이터를 반영한다.

압축률 추정하기

DB2에서는 특정 테이블이나 데이터 세트의 압축에 대한 판단을 위해 압축 비율을 추정할 수 있는 INSPECT를 제공한다. 이 툴은 테이블 데이터 샘플을 모아서 압축 딕셔너리를 만든다. 이 딕셔너리는 샘플에 포함된 레코드에 대한 압축률을 테스트할 때 사용된다. 이러한 테스트를 통해서 압축률이 추정된다.

INSPECT ROWCOMPESTIMATE TABLE NAME Sales … 

		RESULTS KEEP <filename>

	

db2inspf <filename> <outfile>

결과를 보려면 INSPECT의 아웃풋을 DB2 유틸리티를 사용하여 포맷해야 한다. 파일은 db2dump 디렉토리에 있다. 샘플 아웃풋은 아래 내용을 참조하라.

  DATABASE: TEST  

  VERSION : SQL09010 

  2005-12-01-13.12.21.232959



  Action: ROWCOMPESTIMATE TABLE

  Schema name: RSAHUJA 

  Table name: Sales 

  ... 

      Percentage of bytes saved from compression: 66 

      Compression dictionary size: 2176 bytes. 

  ... 

데이터 열 압축의 효용성

"Venom" 압축 기술은, 데이터 저장에 필요한 디스크 공간 (그리고 디스크 하위 시스템 주변장치)을 줄여서 스토리지 비용을 50% 이상 절약할 수 있다. 로그 레코드 내에서 DB2가 사용자 데이터를 압축하기 때문에 데이터베이스 로그 크기도 줄어든다.

어떤 경우에는 퍼포먼스까지 높인다. 압축/비압축이 CPU 오버헤드를 야기하긴 하지만, 어떤 상황에서는 퍼포먼스를 높이기도 한다. 디스크에 존재하는 데이터에 액세스 하는 것은 가장 더딘 데이터베이스 작동이라 할 수 있다. 압축된 데이터를 디스크에 저장하여, 더 적은 I/O 연산으로 같은 양의 데이터를 가져오거나 저장한다. 따라서 디스크 I/O 중심의 워크로드의 경우(디스크에 존재하는 데이터에 액세스 되기를 기다리거나 유휴상태일 때) 쿼리 처리 시간이 매우 빨라진다.

더욱이 DB2는 디스크와 메모리(DB2 버퍼 풀)에 압축된 데이터를 저장하기 때문에 사용된 메모리 양이 줄어들고, 다른 데이터베이스나 시스템 작동을 위한 여유 공간이 남는다. 이로서 쿼리나 다른 연산에 대해 데이터베이스 퍼포먼스는 더욱더 높아지는 것이다.

샘플 결과

DB2의 데이터 열 압축 기능을 사용했을 때 어느 만큼의 공간이 절약되는지는 데이터 마다 다르다. DB2 9 베타 버전을 사용하는 사람들은 50% 이상을 절약했다고 하고, 어떤 대형 데이터베이스의 경우 80%까지 절약했다고도 한다. 어떤 데이터 세트의 경우 32KB 페이지를 사용한 179.9GB 테이블은 42.5GB로 줄어들었다. 76.4%나 절약된 것이다.

다음 차트는 다른 테이블에서 DB2 데이터 열 압축 기능을 사용했을 때 어느 만큼의 공간 절약 효과를 거두었는지를 보여주는 예제이다.

InfoWorld의 Sean McCown은 다음과 같이 설명한다.

"새로운 압축 방식은 데이터 유형에 따라 평균 45%에서 75% 정도의 스토리지 절약 효과를 거두고 있다. 이를 테스트 하기 위해 숫자와 텍스트 데이터가 혼합된 40GB 테이블 (약 5억 줄)을 만들어서 이것을 압축된 테이블 포맷으로 반출했다. 압축된 테이블의 크기는 약 17.75GB가 되었다. 56%나 줄어든 것이다."

자세한 내용은 참고자료 섹션을 참조하라.

DB2의 다른 압축 형태

"Venom" 기술의 일부인 데이터 열 압축 외에도 DB2는 스토리지 요구 사항을 더욱 줄일 수 있는 다른 방식들도 제공한다.

• NULL 값과 디폴트 값 압축
• 데이터베이스 백업 압축
• XML 태그 대체
• 다차원 클러스터링

NULL 값과 디폴트 값 압축

DB2 for Linux, UNIX, and Windows, Version 8부터는, NULL 값, 길이가 0인 데이터, 시스템 디폴트 값에 스토리지가 사용되지 않는다.

데이터베이스 백업 압축

DB2 for Linux, UNIX, and Windows V8의 Fixpak 4 이후부터 이러한 압축 기능은 더 작은 백업 이미지를 만들어 백업 스토리지 요구량을 줄일 뿐만 아니라 시스템 간 백업도 이동하기가 더욱 쉬워졌다.

XML 태그 대체

XML의 장황한 특성 상 XML 조각과 문서들은 많은 디스크 공간을 소비하기 마련이다. DB2 9은 파싱된 계층형 포맷으로 XML 데이터를 저장하고 태그 이름(가령, employee)을 정수 값(4와 같은)으로 바꾼다. 반복되는 태그에는 같은 숫자 값이 할당된다. 정수 값을 사용하여 텍스트 태그를 저장하면 공간 소비율을 줄일 뿐만 아니라 데이터를 쿼리 할 때도 높은 퍼포먼스를 누릴 수 있다. 더욱이 데이터 행 압축 같은 XML 태그 파싱(정수 값으로 대체하기)은 별도로(사용자가 신경 쓸 필요 없이) 수행되고 사용자와 애플리케이션에 완전히 투명하다.

다차원 클러스터링

인덱스 압축 형태도 V8.1부터는 가능해졌다. 블록 인덱스를 통해서 인덱스 공간이 상당히 많이 절약된다. 이곳에서는 수 천 개의 레코드에 하나의 키(인덱스 엔트리)가 사용된다. (레코드 당 하나의 키가 아니다.)

결론

DB2 9의 데이터 열 압축은 디스크 공간과 스토리지 비용을 많이 줄일 수 있는 혁신적인 신기능이라 할 수 있다. DB2 9을 다운로드 하여 직접 경험해 보기 바란다.

기사의 원문보기

• Introducing DB2 9, Part 1: Data compression in DB2 9

참고자료

교육

• DB2 Express-C
  
  
• IBM DB2 "Viper" revs XML engine InfoWorld
  
  
• DB2 9 관련 기술자료
  
  
• 한국 developerWorks Information Management 존
  
  
• developerWorks DB2 for Linux, UNIX, and Windows resource page
  
  
• developerWorks technical events and Webcasts
  
  

제품 및 기술 얻기

• DB2 9 다운로드
  
  
• DB2 Express-C 다운로드
  
  
• IBM trial software
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 블로그