Oracle Table 압축

지난 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은 이와 같은 과제를 해결할 수 있는 포괄적인 기술들을 수용하고 있다.

Oracle11g에서 제공하는 수 많은 혁신적인 기술들을 활용하여, 고객은 어떤 형태의 데이터라고 해도 쉽게 압축할 수 있다.

일반적인 정형 데이터나 문서, 이미지, 멀티미디어 등의 비정형 데이터, 그리고 백업 받은 데이터까지도 압축하여 보관할 수 있으며, 네트워크 통신에서도 압축을 지원한다.

이 같은 압축 기술은 자원 사용율의 효율성을 극대화시키며 전체 자원의 요구량과 비용을 줄여주게 된다.

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의 차이는 거의 없다.

Benefits of Table Compression

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> (…) COMPRESS FOR ALL OPERATIONS

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

„ ALTER TABLE <table_name> (…) COMPRESS

→ 이후 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 with difference

„ 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)

Test for Table Compression

Requirements for Comparing Storage

Granting Privileges to the SH User

테스트를 위해서 기본적으로 sh 계정과 별도의 tablespace 를 만들어서 진행합니다.

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

Compressed table와 uncompressed table 생성

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

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

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

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

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

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

Test 결과

Storage Compression-rate Comparison

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

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

Oracle 10g 결과

Oracle 11g 결과

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 한 결과로 전부 압축한 테이블 보다는 다소 높지만 압축 효과는 확연히 확인할 수 있다.

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

. sales_compress_oltp : 레코드 없는 압축 테이블 생성 후 추가 insert 한 테이블 은 DML 에서 전부 압축한 테이블 보다는 빠르다.

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

비교 결과

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

고객은 이 기능을 사용하여 Direct Loading이나 CTAS등과 같은 작업을 통해 벌크 로딩을 수행하면서 데이터를 압축할 수 있었지만,

벌크로 로딩하면서 압축된 데이터에 대해 DML 작업이 발생하면 이후부터는 압축이 풀린 상태로 관리되었기 때문에 INSERT, UPDATE, DELETE와 같은 일반적인 데이터 작업에서는 압축을 활용할 수 없었다.

Oracle11g 에 와서는 일반적인 DML 작업에 대해서도 압축이 가능해졌기 때문에, DW 시스템에서 코드성이나 분석 Dimension 테이블에만 적용하던 것에서 벗어나, OLTP 시스템에서 데이터에 대한 변경이 발생하는 테이블에 대해서도 압축을 사용할 수 있게 되었다.

Oracle에서 사용하는 압축 메커니즘은 블록 단위로 압축되며, 반복되는 데이터를 블록 헤더에 한 번만 저장하는 방식을 사용하고 있다. 이것은 압축을 풀기 위해 해야할 불필요한 연산 작업을 없앰으로써, 압축 해제의 오버헤드를 최소화 시키는 역할을 하고 있다.

이로써, 변경이 발생하지 않거나 미미한 코드성 테이블에 대해서는 OLTP 시스템이라고 하더라도 Oracle11g의 Advanced Compression Option을 사용하여 압축해 놓는다면, 고가의 고성능 스토리지를 한층 더 효율적으로 활용할 수 있을 것이다.

또한, Information Lifecycle Management(ILM)의 관점에서 현재 online으로 사용할 데이터는 아니지만 정해진 보관 기간 동안 저장되어 있어야 할 데이터에 대해서도 Oracle11g 의 Advanced Compression Option을 이용하여 압축하면 방대한 저장 데이터를 더 적은 비용으로 보관 및 관리할 수 있다.

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