248│2013 기술백서 White Paper ORACLE EXADATA HCC 압축방식 이해하기 ㈜엑셈 컨설팅본부/DB컨설팅팀 김 철환 개요 시간이 지나면서 데이터는 급속하게 증가하고 있다. 데이터가 증가함에 따라 DBMS 에서 관리 되어지는 정보도 급속하게 증가 하고 있다. 이로 인해 저장공간의 부족으로 하드웨어 비용의 증 가와 데이터 처리 성능에 많은 문제 점들이 나타나고 있다. 이러한 문제점들을 해결하고자 ORACLE 에서는 EXADATA 라는 시스템을 통해 스토리지 공간 부족현상과 데이터 처리 성능을 향상시키고자 하였다. EXADATA 시스템이란 대용량 데이터베 이스에서 디스크 스토리지 시스템에서 데이터베이스 서버로 많은 데이터를 이동 시킬 때 발생하 는 많은 비효율을 하드웨어와 소프트웨어의 조합을 통해 해결 하고자 한 것이 EXADATA 시스템 이라 하는데 HCC (HYBRID COLUMNAR COMPRESSION) 라는 압축 기술을 통해 이와 같은 문제점들을 해결 할 수 있다. 본 장에서는 EXADATA 시스템의 HYBRID COLUMNAR COMPRESSION 압축을 중심으로 이야 기 할 것이다. 데이터 압축의 원리를 알아보고 디스크 공간 절약과 데이터 조회의 성능에 어떤 영향을 미치는지 비교해 보고자 한다. HCC 란 무엇이며 어떻게 동작하는지 알아보자. 데이터를 압축을 하게 되면 스토리지 공간을 절약 할 수 있다. 압축에도 여러 가지 방법으로 데 이터들을 압축 할 수 있으며 EXADATA 시스템에서는 HCC 라는 압축 방식을 통해 보다 진보된 방식으로 압축을 할 수 있다. HCC 이전에 압축 방식은 BLOCK 안에 중복된 값들을 하나의 값으 로 가지고 있고 그 값을 참조하는 주소 값을 통해서 중복 데이터를 접근하는 방식인 ROW 데이 터를 기반으로 하는 압축 방식 이였다.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
248│2013 기술백서 White Paper
ORACLE EXADATA HCC 압축방식 이해하기
㈜엑셈 컨설팅본부/DB컨설팅팀 김 철환
개요
시간이 지나면서 데이터는 급속하게 증가하고 있다. 데이터가 증가함에 따라 DBMS에서 관리
되어지는 정보도 급속하게 증가 하고 있다. 이로 인해 저장공간의 부족으로 하드웨어 비용의 증
가와 데이터 처리 성능에 많은 문제 점들이 나타나고 있다.
이러한 문제점들을 해결하고자 ORACLE 에서는 EXADATA라는 시스템을 통해 스토리지 공간
부족현상과 데이터 처리 성능을 향상시키고자 하였다. EXADATA시스템이란 대용량 데이터베
이스에서 디스크 스토리지 시스템에서 데이터베이스 서버로 많은 데이터를 이동 시킬 때 발생하
는 많은 비효율을 하드웨어와 소프트웨어의 조합을 통해 해결 하고자 한 것이 EXADATA 시스템
이라 하는데 HCC (HYBRID COLUMNAR COMPRESSION) 라는 압축 기술을 통해 이와 같은
문제점들을 해결 할 수 있다.
본 장에서는 EXADATA 시스템의 HYBRID COLUMNAR COMPRESSION 압축을 중심으로 이야
기 할 것이다. 데이터 압축의 원리를 알아보고 디스크 공간 절약과 데이터 조회의 성능에 어떤
영향을 미치는지 비교해 보고자 한다.
HCC 란 무엇이며 어떻게 동작하는지 알아보자.
데이터를 압축을 하게 되면 스토리지 공간을 절약 할 수 있다. 압축에도 여러 가지 방법으로 데
이터들을 압축 할 수 있으며 EXADATA 시스템에서는 HCC 라는 압축 방식을 통해 보다 진보된
방식으로 압축을 할 수 있다. HCC 이전에 압축 방식은 BLOCK 안에 중복된 값들을 하나의 값으
로 가지고 있고 그 값을 참조하는 주소 값을 통해서 중복 데이터를 접근하는 방식인 ROW 데이
터를 기반으로 하는 압축 방식 이였다.
Part 1 ORACLE │249
ROW 기반 압축에서 진보된 형태의 압축이 HCC 압축이라고 할 수 있으며 HCC 압축 방식은
EXADATA에서만 사용 할 수 있다. HCC(HYBRID COLUMNAR COMPRESSION) 이란 칼럼기
반 압축 방식으로 같은 유형의 데이터와 비슷한 칼럼 속성을 인접하여 저장하면 보다 효과적인
압축을 하여 스토리지 공간을 효율적으로 줄일 수 있다. 칼럼과 ROW 의 조합으로 저장공간의
효율성과 좋은 성능을 기대할 수 있는 HYBRID 압축 방식이다.
[그림1] COMPRESSION UNIT의 배치 구조
HCC 압축 방식은 더 이상 ROW 단위로 데이터를 저장하지 않고 CU(COMPRESSION UNIT) 단
위로 저장 된다. 그림 1과 같이 하나의 CU 을 보통 32K나 64K 구성 되어 있다. CU는 여러 개
의 BLOCK 을 가지고 있으며 CU 안에 데이터들은 칼럼으로 다시 재 구성된다.
이렇게 구성된 CU의 장점은 CU을 한번만 읽으므로 ROW 전체를 읽을 수 있는 장점이 있지만
칼럼 전체를 읽으려면 모든 UN을 읽어야만 하기 때문에 완벽한 칼럼 기반 압축 방식이라고는
할 수 없다. 완벽한 칼럼 방식으로 구성 되었다면 모든 CU을 읽지 않고 모든 칼럼들을 읽었을
것이다.
하지만 HCC 압축은 칼럼 형태의 압축의 장점인 디스크 절약과 ROW 형태의 압축의 장점인 조
회 성능을 모두 만족 시킬 수 있는 HYBRID 압축 이라고 하겠다.
HCC 압축에는 어떤 유형들이 있을까?
HCC 방식은 여러 가지 유형이 존재하며 아래 표를 통해서 각 유형들의 특징을 볼 수 있다. 아래
표를 참고하여 테스트를 통해 압축 유형들의 특징들을 구체적으로 알아 보도록 하자.
250│2013 기술백서 White Paper
압축 유형 설명 예상 압축률
QUERY LOW
HCC 레벨1 은 LZO 압축 알고리즘을 사용한다 이 레벨은 가장 낮
은 압축률을 제공하지만, 압축 및 압축해제 작업을 위해 최소한
의 CPU를 필요로 한다 이 알고리즘은QUERYLOW 알고리즘은 압
축보다는 속도를 극대화할 수 있도록 최적화되었다. 이 알고리즘
의 압축해제는 대단히 빠르다 일부 문서에서 이 레벨을
WAREHOUSE LOW 지칭하는 것을 볼 수 있다.
4X
QUERY HIGH HCC 레벨2는 ZLlB(gzip) 압축 알고리즘을 사용한다 일부 문서는
이 레벨을 WAREHOUSE HIGH로 지칭한다 6X
ARCHIVE LOW
HCC 레벨3 또한 ZLlB(gzip) 알고리즘을 사용하지만. QUERYHIGH
보다 더 높은 압축 레벨이다. 그러나 데이터에 따라 압축률은
QUERY HIGH보다 높지 않을 수도 있다.
7X
ARCHIVE HIGH
HCC 레벨4 압축은 Bzip2 압축을 사용한다 이것은 사용 가능한
가장 높은 레벨의 압축이지만, 단연코 가장 CPU 집약적이다.
압축 시간은 종종 레벨2와 3보다 몇 배ARCHIVE HIGH 느리다.
그러나 대상 데이터에 따라 압축률은 ARCHIVELOW보다 많이 높
지 않을 수도 있다 이 레벨은 데이터 압축에 필요한 시간은 상대
적으로 덜 중요하지만 심각한 공간 부족을 겪는 상황을 대비한
것이다.
12X
[표 1-1 ] 압축유형
표 1-1에서 살펴본 압축 유형들을 통해 각각의 특징들을 테스트를 통해 살펴 보도록 하자.
테스트 테이블 생성 스크립트
CREATE TABLE HCC_TEST AS SELECT * FROM DBA_OBJECTS;
INSERT INTO HCC_TEST AS SELECT * FROM HCC_TEST ; (x 10)
-- 테스트 테이블의 SEGMENT SIZE
SELECT SUM(BYTES)/1024/1024 BYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST';
BYTES
---------
1600
Part 1 ORACLE │251
-- HCC 레벨 1
CREATE TABLE HCC_TEST_HCC1 COMPRESS FOR QUERY LOW AS SELECT * FROM HCC_TEST ;
SQL Execution Time > 00:00:20.031
SQL> SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC1';
MBYTES
---------
200
-- HCC 레벨 2
CREATE TABLE HCC_TEST_HCC2 COMPRESS FOR QUERY HIGH AS SELECT * FROM HCC_TEST ;
SQL Execution Time > 00:00:40.794
SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC2';
MBYTES
---------
104
-- HCC 레벨 3
CREATE TABLE HCC_TEST_HCC3 COMPRESS FOR ARCHIVE LOW AS SELECT * FROM HCC_TEST ;
SQL Execution Time > 00:00:40.108
SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC3';
MBYTES
---------
104
-- HCC 레벨 4
CREATE TABLE HCC_TEST_HCC4 COMPRESS FOR ARCHIVE HIGH AS SELECT * FROM HCC_TEST ;
SQL Execution Time > 00:04:01.146
SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC4';
MBYTES
---------
72
252│2013 기술백서 White Paper
압축유형에 따른 테스트 결과
테이블 명 압축방법 압축률 적재시간
HCC_TEST_HCC1 QUERY LOW 8 00:00:20
HCC_TEST_HCC2 QUERY HIGH 15.4 00:00:40
HCC_TEST_HCC3 ARCHIVE LOW 15.4 00:00:40
HCC_TEST_HCC4 ARCHIVE HIGH 22.2 00:04:01
[표 2-1 ] 압축유형 테스트 결과
표 1 압축 유형 테스트 결과를 살펴보면 압축 단계가 높을 수록 압축률이 높아 진다. 즉 압축 레
벨이 높을수록 스토리지 공간을 절약 할 수가 있다. QUERY HIGH을 보면 QUERY LOW 비해
압축률이 7배 정도 좋아졌지만 적재시간도 2배 정도 소요 되었다. ARCHIVE LOW 보면
QUERY HIGH와 거의 차이를 보이지 않고 있다. ARCHIVE HIGH을 보면 압축률이 ARCHIVE
LOW 비해 7배 정도 좋아 졌지만 시간은 4배 정도 더 느려졌다.
결과적으로 레벨의 단계가 높을 수록 압축률은 좋아 졌지만 적재는 더 많은 시간을 요구 하고 있
다. 또한 압축 하는 동안 많은 시간이 소요 된다면 시스템 자원도 오랜 시간 동안 사용 해야 할
것이다.
HCC 압축과 QUERY 성능과의 관계
HCC 압축과 QUERY 의 성능을 알아보려고 한다. 여기서 2가지 테스트를 해 보겠다. I/O 집약
적인 QUERY 성능 테스트와 CPU 작업 집약적인 QUERY 성능 테스트를 해 보겠다. 이렇게 테스
트를 하는 이유는 쿼리에 상황에 따라서 성능에 차이를 보이기 때문이다.
Part 1 ORACLE │253
I/O 집약적인 QUERY
SQL> select sum(OBJECT_ID) from HCC_TEST;
SUM(OBJECT_ID)
--------------
7.4e+011
SQL Execution Time > 00:02:51.123
SQL> select sum(OBJECT_ID) from HCC_TEST_HCC1;
SUM(OBJECT_ID)
--------------
7.4e+011
SQL Execution Time > 00:01:31.967
SQL> select sum(OBJECT_ID) from HCC_TEST_HCC2;
SUM(OBJECT_ID)
--------------
7.4e+011
SQL Execution Time > 00:01:13.045
SQL> select sum(OBJECT_ID) from HCC_TEST_HCC3;
SUM(OBJECT_ID)
--------------
7.4e+011
SQL Execution Time > 00:01:14.014
SQL> select sum(OBJECT_ID) from HCC_TEST_HCC4;
SUM(OBJECT_ID)
--------------
7.4e+011
SQL Execution Time > 00:01:58.043
254│2013 기술백서 White Paper
CPU 집약적인 QUERY
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST',METHOD_OPT =>' for all columns
size 1');
PL/SQL executed.
SQL Execution Time > 00:00:13.054
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST_HCC1', METHOD_OPT =>' for all
columns size 1');
PL/SQL executed.
SQL Execution Time > 00:00:16.911
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST_HCC2', METHOD_OPT =>' for all
columns size 1');
PL/SQL executed.
SQL Execution Time > 00:00:19.859
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('BIZMAX', 'HCC_TEST_HCC3', METHOD_OPT =>' for all
columns size 1');
PL/SQL executed.
SQL Execution Time > 00:00:19.891
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS ('BIZMAX', 'HCC_TEST_HCC4', METHOD_OPT =>' for all
columns size 1');
PL/SQL executed.
SQL Execution Time > 00:00:33.322
HCC압축과 QUERY 성능 테스트 결과
테이블 명 I/O집약적 CPU 집약적
HCC_TEST 00:02:51 00:00:13
HCC_TEST_HCC1 00:01:31 00:00:16
HCC_TEST_HCC2 00:01:13 00:00:19
HCC_TEST_HCC3 00:01:14 00:00:19
HCC_TEST_HCC4 00:01:58 00:00:33
[표 2-2 ] HCC 압축과 QUERY 성능 테스트 결과
Part 1 ORACLE │255
표 2-2 을 보면 I/O 집약적인 QUERY와 CPU 집약적인 QUERY에 대해 성능에 차이가 존재한
다. I/O 집약적인 작업일 경우에는 HCC 압축 전화 후를 비교해 보면 각 HCC 압축 레벨마다 조
금의 차이는 보이지만 압축 하기 전보다 모두 좋은 성능을 보였지만 CPU 집약적 작업은 압축 하
기 전 보다 모두 더 나쁜 성능을 보였다.
이렇게 QUERY 의 형태 (I/O 집약적인 QUERY와 CPU 집약적인 QUERY)에 따라서 실행 결과
가 달라진 이유는 I/O 집약적인 작업은 QUERY 조회 시 압축해제에 따른 CPU 사용보다 HCC 압
축으로 읽어야 할 BLOCK 수의 감소 효율이 더 좋았기 때문이고 CPU 집약적 작업이 압축 전 데
이터 보다 좋지 못한 성능을 보인 이유는 압축해제에 사용된 CPU 리소스 사용과 통계정보 생성
에서 사용한 CPU 사용 리소스가 HCC 압축으로 읽어야 할 BLOCK 수의 감소 효율 보다 좋지 못
했기 때문이다. 따라서 압축된 데이터는 각 QUERY 상황에 따라서 성능이 달라질 것이다.
DML(INSERT, UPDATE) 사용시 HCC 압축 방법과 유의점
INSERT 시 HCC 압축하기
INSERT 통해 데이터 압축을 할 경우 DIRECT PATH LOAD 일 때만 HCC 형태로 압축이 이루어
진다.
아래 테스트를 통해 확인해 보도록 하자.
-- INSERT HCC 압축 하기
SQL> TRUNCATE TABLE HCC_TEST;
ALTER TABLE HCC_TEST NOCOMPRESS;
INSERT INTO HCC_TEST SELECT * FROM HCC_TEST_HCC1;
COMMIT;
SQL> SELECT ROUND(SUM(BYTES)/1024/1024) FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST';
ROUND(SUM(BYTES)/1024/1024)
---------------------------
1600
SQL> TRUNCATE TABLE HCC_TEST;
256│2013 기술백서 White Paper
Statement Processed.
SQL Execution Time > 00:00:01.982
ALTER TABLE HCC_TEST COMPRESS FOR ARCHIVE LOW ;
INSERT INTO HCC_TEST SELECT * FROM HCC_TEST_HCC1;
COMMIT;
SQL> SELECT ROUND(SUM(BYTES)/1024/1024) FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST';
ROUND(SUM(BYTES)/1024/1024)
---------------------------
1536
SQL> TRUNCATE TABLE HCC_TEST;
Statement Processed.
SQL Execution Time > 00:00:01.982
ALTER TABLE HCC_TEST COMPRESS FOR ARCHIVE LOW ;
INSERT /*+APPEND*/ INTO HCC_TEST SELECT * FROM HCC_TEST_HCC1;
COMMIT;
SQL> SELECT ROUND(SUM(BYTES)/1024/1024) FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST';
ROUND(SUM(BYTES)/1024/1024)
---------------------------
104
CREATE TABLE HCC_TEST_HCC3 COMPRESS FOR ARCHIVE LOW AS SELECT * FROM HCC_TEST ;
SQL Execution Time > 00:00:40.108
SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_HCC3';
MBYTES
---------
104
테이블을 생성 후 ALTER 명령어를 통해 테이블 형태를 ARCHIVE LOW 형태의 압축 형태로 테
이블로 변경 하였다. 테이블은 압축 형태로 변경 되었지만 DIRECT PATH LOAD 발생하지 않은
Part 1 ORACLE │257
상태에서 데이터 적재와 원본 테이블의 SEGMENT 차이는 거의 없었다. 하지만 DIRECT PATH
LOAD 발생한 데이터 적재는 HCC 형태의 ARCHIVE LOW 형태의 압축이 이루어 졌다.
UPDATE 시 HCC 압축하기
HCC 가 이루어진 데이터에 대해서 UPDATE가 발생하게 되면 압축은 해제된다.
아래 테스트를 통해서 알아 보도록 하자.
DROP TABLE HCC_TEST_UPDATE PURGE;
CREATE TABLE HCC_TEST_UPDATE NOLOGGING AS SELECT * FROM HCC_TEST_HCC1 WHERE ROWNUM < 200000;
SELECT SUM(BYTES)/1024/1024 MBYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME='HCC_TEST_UPDATE';
MBYTES
---------
24
EXEC DBMS_STATS.GATHER_TABLE_STATS ('BIZMAX', 'HCC_TEST_UPDATE', METHOD_OPT =>' for all
columns size 1')
SELECT TABLE_NAME,BLOCKS,CHAIN_CNT FROM DBA_TABLES WHERE TABLE_NAME = 'HCC_TEST_UPDATE';