TeChnology & developer

60_ 11g의 Advanced Compression 상세 기술 자료

72_ Developer Power

TeChnology & developer 01

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료060

Autum

n 2012

11g의 Advanced Compression 상세 기술 자료

지난 10년 동안 기업에서 다루어지는 고객데이터와 영업활동 및 거래로부터 발생한 데이터는

기하급수적으로 증가해왔다. 최근에는 기업 데이터의 영역이 기존의 정형 데이터에서 비정형

데이터로까지 확대되고 있어서 그 증가의 속도는 더욱 빨라지고 있다.

Winter Corp에서 발표하는 기업 전산 시스템의 데이터 사이즈 통계에 따르면, 2003년에는 30TB의

FT(France Telecom)이 가장 큰 규모의 데이터베이스였고, 2005년에는 Yahoo의 100TB, 2006년 말에는

호주에서 150TB의 데이터베이스를 구축했으며, 최근에는 국내에서도 비슷하거나 그 이상의 규모를

가진 데이터베이스가 구축되고 있다.

이 같은 데이터의 폭발적인 증가 현상은 다음과 같은 요인들로 더욱 가속되고 있다.

- 많은 양의 정보(History data)를 장기간 보관하도록 요구하는 SOX나 HIPPA와 같은 규범들

- Broadband 기술의 발전으로 인터넷에 분산된 rich & multimedia contents

- Web 2.0의 등장으로 인한 UCC(User Created Contents)

전산 시스템의 환경이 이러하다보니, IT관리자들은 폭증하는 데이터를 제대로 관리해야 한다는

어려운 당면 과제에 봉착해 있다. 첫 번째로 어려운 문제는 스토리지에 투입되는 비용이 점점 더

증가하고 있다는 것이다. MB 당 비용은 큰 폭으로 떨어졌지만, Online으로 유지해야 하는 전체

데이터의 양이 폭발적으로 증가함으로써, 여전히 스토리지에 필요한 예산이 전체 IT 예산에서

가장 큰 부분을 차지하고 있는 것이다. 추가적으로, 데이터 크기가 폭증하는 한이 있더라도,

애플리케이션의 확장성이나 가용성 및 성능은 비즈니스가 요구하는 수준을 계속해서 유지해야만

하는 또 다른 과제를 던져주고 있다.

Oracle Database 11g의 Advanced Compression Option은 이와 같은 과제를 해결할 수 있는 포괄적인

기술들을 수용하고 있다. Oracle 11g에서 제공하는 수많은 역신적인 기술들을 활용하여, 고객은 어떤

형태의 데이터라고 해도 쉽게 압축할 수 있다. 일반적인 정형 데이터나 문서, 이미지, 멀티미디어

등의 비정형 데이터, 그리고 백업 받은 데이터까지도 압축하여 보관할 수 있으며, 네트워크

통신에서도 압축을 지원한다. 이 같은 압축 기술은 자원 사용율의 효율성을 극대화시키며 전체

자원의 요구량과 비용을 줄여주게 된다.

저자 - Oracle Technology Solution Consulting

Compression Algorithm

오라클은 9i부터 11g까지 Relational data를 처리하기 위한 특화된 알고리즘을 사용한다. 이 알고리

즘은 Database block 내, 다수의 Column까지도 중복된 값을 제거함으로써 Compression을 수행한

다. Compress 된 Block은 Compression과 관련된 Metadata를 Symbol table에 저장한다. 이 Table은

Block의 상단에 위치해 있다. Symbol table이 각 Block에 있다는 점만 제외하면 Uncompressed table과

Compressed table의 차이는 거의 없다.

1) 일반적으로 Table compression

기능을 통해 Storage 공간을 2~3배

줄일 수 있다.

2) Block을 Uncompress하지 않고

도 바로 Read할 수 있다.

→ 오히려, Access하는 Block 수

가 줄기 때문에 I /O를 감소시켜

Performance가 좋아질 수 있다.

3) Block 수가 감소한 만큼 Buffer

cache를 더 효율적으로 사용할 수

있다.

How to use Compression

■CREATE TABLE <table_name>

(…) COMPRESS;

= CREATE TABLE <table_name>

(…) COMPRESS FOR DIRECT_

LOAD OPERATIONS;

→ direct-path insert를 할 때만

compress된다.(9i와 10g에서 사용

한 방법)

■CREATE TABLE <table_name>

( … ) C O M P R E S S F O R A L L

OPERATIONS

→ direct-path insert뿐만 아니라 모든 DML이 적용된다. OLTP환경에 사용한다. (11g)

■ALTER TABLE <table_name> (…) COMPRESS

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료061

Autum

n 2012

<그림 2> 데이터 블럭 압축. 특정 시점마다 데이터 압축 진행

<그림 1> 압축 블럭과 일반 블럭 구조의 비교. 블럭의 해더에 심볼테이블을 통한 압축

TeChnology & developer 01

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료062

Autum

n 2012

→ 이후 data부터 compress하기 시작한다.

■ALTER TABLE <table_name> (…) NOCOMPRESS

→ 이후 data부터 uncompress된 상태로 insert 또는 update한다.

Compression of Partitioned Tables

■Table에 정의된 compression 속성과 각 Partition의 속성이 다르면 Partition의 속성이 우선한다.

To determine if a Table is Compressed

■*_TABLES의 COMPRESSION column을 확인한다.

■For Partitioned tables: *_TAB_PARTITIONS의 COMPRESSION column을 확인한다.

New Feature

10g의 Table Compression

■Compression 시기

새로운 Data를 Bulk insert나 Bulk load할 때 Compression을 사용할 수 있다.

→ batch process로 data를 load하는 DW에 이상적이다.

- Direct path SQL*Loader

- CREATE TABLE AS SELECT (CTAS) statements

- Parallel INSERT (or serial INSERT with an APPEND hint) statements

기존의 Data는 ALTER TABLE과 MOVE statement로 Compress할 수 있다. 이 과정에는 Exclusive lock이 사용

되며 어떠한 Update나 Load를 방지한다. 이것이 허용되지 않는다면 Redefinition utility (DBMS_REDEFINITION

PL/SQL package)를 사용할 수 있다.

■Note

Compression과 관련된 Overhead는 Bulk loading 중에 최대가 된다. 또한, Compress된 Table에 DML을 사용할

수 있지만 Bulk insertion이나 Bulk loading을 사용하지 않은 Data는 Compress되지 않는다. 결국 한 Table안에

Compress된 부분과 Uncompress된 부분이 공존하게 된다. Uncompressed table과 비교해서는 Update를 제외

한 다른 DML에서는 처리속도상의 차이가 거의 없다.

* OLTP 보다 DW에 유리하다.

* Enterprise Edition에 포함.

11g의 Table Compression

■Compression 시기

새로운 data를 Bulk insert나 Bulk load 또는 그냥 Insert, Update할 때 Compression을 사용할 수 있다.

→ Conventional DML에도 적용 가능하다.

- Direct path SQL*Loader

- CREATE TABLE AS SELECT (CTAS) statements

- Parallel INSERT (or serial INSERT with an APPEND hint) statements

- Single-row or array inserts

- Single-row or array updates

기존의 data는 ALTER TABLE과 MOVE statement로 compress할 수 있다. 이 과정에는 exclusive lock이 사용되

며 어떠한 update나 load를 방지한다. 이것이 허용되지 않는다면 redefinition utility (DBMS_REDEFINITION PL/

SQL package)를 사용할 수 있다.

■Note

Compression과 관련된 Overhead는 Bulk loading 중에 최대가 된다. 또한, Compress된 Table에 모든 DML을 사

용할 수 있다. Uncompressed table과 비교해서는 Update를 제외한 다른 DML에서는 처리속도상의 차이가 거의

없다.

* OLTP와 DW 환경에 둘 다 적용 가능하다.

→ 새로운 Data를 Write할 때마다 Block을 Compress하는 방식이 아니라 내부적인 Threshold를 넘으면 Batch

mode로 한번에 Compress하기 때문에 OLTP에 적용 가능하다.

* Oracle Advanced Compression Option에 포함. (for OLTP)

→ 11g Enterprise Edition에서는 10g 기술을 사용할 수 있다. (for DW)

Requirements for Comparing Storage

Granting Privileges to the SH User 테스트를 위해서 기본적으로 sh 계정과 별도의 Tablespace를 만들어서 진행

한다. 이는 차후 Storage 압축률과 DML 시간을 비교하는데 일관된 환경에서 테스트 할 수 있도록 제공된다.

Alter user sh identified by sh account unlock;

Grant create tablespace to sh;

Grant drop tablespace to sh;

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료063

Autum

n 2012

TeChnology & developer 01

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료064

Autum

n 2012

Compressed table과 uncompressed table 생성

테이블은 3가지로 나누어서 생성된다.

. nocompress : 압축되지 않은 테이블

. sales_compress_oltp : 레코드 없는 압축 테이블(single-row inserts)

. sales_compress_direct : 레코드 포함 압축 테이블(bulk load)

connect sh/sh

drop table sales_nocompress purge

/

drop table sales_compress_direct purge

/

drop table sales_compress_oltp purge

/

set echo on

set timing on

create table sales_nocompress

as select * from sales

/

create table sales_compress_direct compress

as select * from sales

/

create table sales_compress_oltp compress <-(for all operations)로 해야 하지만 Beta version인 관계로

불가.

as select * from sales

where 1=0

/

sales_compress_oltp : 레코드 없는 압축 테이블을 생성 후 추가로 Insert를 진행한다.

Select count(*) from sales_compress_oltp

/

0 rows selected.

SQL> @oltp_insert.sql

SQL> set timing on

SQL> declare

2

3 commit_after integer := 0 ;

4 loop_variable integer ;

5

6 cursor c_sales is

7 select prod_id

8 , cust_id

9 , time_id

10 , channel_id

11 , promo_id

12 , quantity_sold

13 , amount_sold

14 from sales ;

15

16 begin

17

18 for r_sales in c_sales

19 loop

20

21 if commit_after = 0

22 then

23

24 loop_variable := 0 ;

25

26 commit_after := round(dbms_random.value(1,1)) ;

27

28 end if ;

29

30 insert into sales_compress_oltp

31 (prod_id, cust_id, time_id, channel_id, promo_id, quantity_sold, amount_sold)

32 values

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료065

Autum

n 2012

TeChnology & developer 01

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료066

Autum

n 2012

33 ( r_sales.prod_id

34 , r_sales.cust_id

35 , r_sales.time_id

36 , r_sales.channel_id

37 , r_sales.promo_id

38 , r_sales.quantity_sold

39 , r_sales.amount_sold

40 ) ;

41

42 if loop_variable = commit_after

43 then

44 commit ;

45 commit_after := 0 ;

46 end if ;

47

48 loop_variable := loop_variable + 1 ;

49

50 end loop ;

51

52 end ;

53 /

PL/SQL procedure successfully completed.

Elapsed: 00:15:34.64

SQL> set timing off

동일한 레코드가 있음을 확인 할 수 있다.

SQL> select count(*) from SALES_NOCOMPRESS;

COUNT(*)

----------

918843

SQL> select count(*) from SALES_COMPRESS_OLTP;

COUNT(*)

----------

918843

SQL> select count(*) from SALES_COMPRESS_DIRECT;

COUNT(*)

----------

918843

Test 결과

Storage Compression-rate Comparison

동일한 레코드를 갖고 있는 3개의 테이블에 대해 각각의 Segment를 차지하는 공간을 비교해 본다.

여기서 sales_compress_direct 테이블이 13M로 가장 많이 압축된 것을 확인할 수 있다.

SQL> select segment_name, sum(bytes)/1024/1024 mb

2 from dba_segments

3 where owner = user

4 and segment_name in (‘SALES_NOCOMPRESS’,’SALES_COMPRESS_DIRECT’,’SALES_

COMPRESS_OLTP’)

5 group by segment_name

6 order by segment_name

7 /

10g 결과(참고)

SEGMENT_NAME MB

--------------------------------------------------------------------------------- ----------

SALES_NOCOMPRESS 36

SALES_COMPRESS_OLTP 32

SALES_COMPRESS_DIRECT 13

3 rows selected.

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료067

Autum

n 2012

TeChnology & developer 01

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료068

Autum

n 2012

11g 결과

SEGMENT_NAME MB

--------------------------------------------------------------------------------- ----------

SALES_NOCOMPRESS 36

SALES_COMPRESS_OLTP 17

SALES_COMPRESS_DIRECT 13

3 rows selected.

10g에서는 OLTP로 Insert작업을 수행한 Table은 Data가 압축이 되지 않은 것을 알 수 있다. 하지만 11g에서 OLTP

를 대상으로 만든 새로운 Feature, “Compress for all Operations”를 사용하지 않은 상태로 압축률이 더 좋아진 것

으로 보아 Enterprise Edition에서 기본적으로 제공하는 compression기능이 향상된 것으로 보인다.

DML Comparison

압축된 3개의 테이블에 대해서 동일한 delete 작업을 진행 하고자 한다. 각각의 시간을 비교해서 압축률에 따라 DML

시간에 어떠한, 그리고 얼마나 많은 영향이 있는지 확인하고자 한다.

• nocompress : 압축되지 않은 테이블

• sales_compress_oltp : 레코드 없는 압축 테이블

• sales_compress_direct : 레코드 포함 압축 테이블

압축률은 레코드와 테이블 모두 압축한 sales_compress_direct가 가장 높다.

SALES_COMPRESS_OLTP는 압축 테이블 생성 후 Insert한 결과로 전부 압축한 테이블 보다는 다소 높지만 압축

효과는 확연히 확인할 수 있다.

SQL> select table_name, compression from user_tables where table_name like ‘%COMPRESS%’;

TABLE_NAME COMPRESS

-------------------------------------- --------

SALES_NOCOMPRESS DISABLED

SALES_COMPRESS_DIRECT ENABLED

SALES_COMPRESS_OLTP ENABLED

3 rows selected.

• nocompress : 압축되지 않은 테이블 이 삭제작업 시 가장 빠르지만 큰 차이를 보이진 않는다.

SQL> set timing on

SQL> delete from sales_nocompress;

918843 rows deleted.

Elapsed: 00:00:34.59

SQL> set timing off

SQL>

• sales_compress_oltp : 레코드 없는 압축 테이블 생성 후 추가 Insert 한 테이블은 DML에서 전부 압축한 테이블

보다는 빠르다.

SQL> set timing on

SQL> delete from SALES_COMPRESS_OLTP;

918843 rows deleted.

Elapsed: 00:00:35.73

SQL> set timing off

SQL>

• sales_compress_direct : 레코드 포함한 전체 압축 테이블 이 압축 안한 테이블 보다 조금 느린 것을 확인 할 수 있다.

SQL> set timing on

SQL> delete from SALES_COMPRESS_DIRECT;

918843 rows deleted.

Elapsed: 00:00:38.82

SQL> set timing off

SQL>

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료069

Autum

n 2012

TeChnology & developer 01

ORA

CLE KOREA

MA

GA

ZINE

Technology & D

eveloper11 g 의

Advanced Com

pression 상

세 기

술 자

료070

Autum

n 2012

비교 결과

결론

Oracle 9i에서 벌크 로딩을 위한 테이블 압축을 도입했을 때부터 Oracle은 이미 업계에서 선구적 역할을 수행해 왔

다. 고객은 이 기능을 사용하여 Direct Loading이나 CTAS 등과 같은 작업을 통해 벌크 로딩을 수행하면서 데이터를

압축할 수 있었지만, 벌크로 로딩하면서 압축된 데이터에 대해 DML 작업이 발생하면 이후부터는 압축이 풀린 상태로

관리되었기 때문에 INSERT, UPDATE, DELETE와 같은 일반적인 데이터 작업에서는 압축을 활용할 수 없었다.

Oracle 11g에 와서는 일반적인 DML 작업에 대해서도 압축이 가능해졌기 때문에, DW 시스템에서 코드성이나 분석

Dimension 테이블에만 적용하던 것에서 벗어나, OLTP 시스템에서 데이터에 대한 변경이 발생하는 테이블에 대해서

도 압축을 사용할 수 있게 되었다.

Oracle에서 사용하는 압축 메커니즘은 블록 단위로 압축되며, 반복되는 데이터를 블록 헤더에 한 번만 저장하는 방식

을 사용하고 있다. 이것은 압축을 풀기 위해 해야할 불필요한 연산 작업을 없앰으로써, 압축 해제의 오버헤드를 최소화

시키는 역할을 하고 있다.

이로써, 변경이 발생하지 않거나 미미한 코드성 테이블에 대해서는 OLTP 시스템이라고 하더라도 Oracle 11g의

Advanced Compression Option을 사용하여 압축해 놓는다면, 고가의 고성능 스토리지를 한층 더 효율적으로 활

용할 수 있을 것이다. 또한, Information Lifecycle Management(ILM)의 관점에서 현재 Online으로 사용할 데이터

는 아니지만 정해진 보관 기간 동안 저장되어 있어야 할 데이터에 대해서도 Oracle 11g의 Advanced Compression

Option을 이용하여 압축하면 방대한 저장 데이터를 더 적은 비용으로 보관 및 관리할 수 있다. 축적되어 온 과거의 이

력 데이터를 관리해야 할 기업의 당면과제를 해결할 효율적인 솔루션인 것이다.

테이블명 Compress 방식 Storage (MB) DML (s)

nocompress 압축되지 않은 테이블 36 34.59

sales_compress_oltp 레코드 없는 압축 테이블 17 35.73

sales_compress_direct 레코드 포함 압축 테이블 13 38.82