TABLE COMPRESSION

Compress 배경

지난 10 년 동안 기업에서 다루어지는 데이터는 기하급수적으로 증가하고 있다.
최근에는 기업 데이터의 영역이 기존의 정형 데이터에서 비정형 데이터 확대되어 증가의 속도는 더욱 빨라지고 있다.

-- 많은 양의 정보(History data)를 장기간 보관하도록 요구하는 SOX나 HIPPA와 같은 규범들
– Broadband 기술의 발전으로 인터넷에 분산된 rich & multimedia contents
– Web 2.0의 등장으로 인한 UCC(User Created Contents)

일반적인 정형 데이터

  • 문서, 이미지, 멀티미디어 등의 비정형 데이터
  • 백업 데이터
  • 네트워크 통신

IT관리자들이 폭증하는 데이터 관리하며 겪는 과제

  • 스토리지 투입비용 증가
    (스토리지의 MB 당 비용은 감소되었으나 실시간 제공해야하는 데이터 량이 급증)
  • 데이터 크기가 폭증되더라도 애플리케이션의 확장성이나 가용성 및 성능은 유지해야만 함.

Oracle Database 11g의 압축기술

오라클은 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)
  (or CREATE TABLE <table_name> (...) COMPRESS FOR OLTP)
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을 확인한다.

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할 수 있다.

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을 사용할 수 있다.

  • 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할 수 있다.

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

결론

  • Direct Loading이나 CTAS등과 같은 작업을 통해 벌크 로딩을 수행하면서 데이터를 압축할 수 있었지만, 벌크로 로딩하면서 압축된 데이터에 대해 DML 작업이 발생하면 이후부터는 압축이 풀린 상태로 관리되었기 때문에 일반적인 데이터 작업에서는 압축을 활용할 수 없었다.
  • Oracle11g에와서는 일반적인 DML 작업에 대해서도 압축이 가능해졌기 때문에, OLTP 시스템에서 데이터에 대한 변경이 발생하는 테이블에 대해서도 압축을 사용할 수 있게 되었다.