데이터베이스의 대용량화, 일명 VLDB(Very Large DataBase)로 인한 가장 큰 이슈는 성능에 관한 이슈와 대용량 데이터를 저장해야 함에 따라 발생하는 비용 증가를 꼽을 수 있다.

성능에 관한 이슈를 보면 많은 서적과 관련 담당자들의 인식변화로 인해 여러 가지 튜닝 방법을 통해 기존 시스템의 자원을 최대한 활용하려는 움직임이 많은 곳에서 포착되고 있다.

대용량 데이터를 저장함에 따라 발생하는 비용 증가는 DBMS를 사용하는 어떤 곳이든 예외가 되지 않을 것이고 상용 DBMS가 도입된 이후 지금까지 끊이지 않는 이슈이며 데이터의 증가에 따른 추세로 볼 때 앞으로도 그럴 것이다.

데이터 증가에 따른 용량 증설은 불가항력이라고 할 만큼 어쩔 수 없는 문제이지만 그 증설 규모 산정에 대해 적합한지는 고민해 봐야 한다.

운영 중인 데이터의 속성을 나누면 크게 운영 데이터와 이력데이터로 나눌 수 있다.

운영에 필요한 메타데이터의 증가는 스토리지 증설을 위한 비용을 고민할 만큼 빠르진 않다. 문제가 되는 것은 이력 데이터들이다.

이 이력 데이터들이 급속도로 증가하면서 스토리지 증설에 관한 고민을 낳는다. 이 이력 데이터들을 두 분류로 나누면 누적만이 발생하는 데이터와 갱신 작업이 수반되는 데이터로 나눌 수 있다.

다행스러운 점은 이러한 이력 데이터들은 메타데이터에 의해 반복적으로 발생하는 데이터라는 것이다.

예를 들면, 통신사에서 고객 전화번호는 메타데이터에 해당될 것이며 한 고객이 남기는 여러 건의 통화 내역이 이력 데이터가 된다는 뜻이다.

반복적이라는 것은 그만큼 중복 데이터들이 생겨나게 되고 오라클에서 제공하는 COMPRESS 기능 적용시 효과를 볼 수 있는 대상이 된다는 의미다.

COMPRESS 기능과 스토리지 증설은 무슨 관계일까?

일반적으로 스토리지 증설의 기준은 스토리지 사용률과 데이터 증가량에 의해 결정되는데 데이터 증가 자체는 어쩔 수 없는 문제이지만 증가하는 데이터를 스토리지 용량으로 봤을 때 그 데이터 전부를 증설 대상 기준으로 삼는 것보다 DBMS 자체에서 제공하는 COMPRESS 기능을 적용한 후 증설 용량을 계산한다면 스토리지 증설은 불가항력이지만 그 규모에서 절감 효과를 얻을 수 있게 된다.

예를 들면 운영 중인 데이터의 증가량이 2009년에 10TB(Tera Byte)라고 할 때 이를 그대로 증설 기준으로 삼는다면, 2010년에도 데이터 증가를 예상해 10TB 분량을 증설 기준으로 삼게 될 테지만, 이를 COMPRESS 기능을 적용해 5TB로 줄일 수 있다면 2010년에는 기존의 스토리지를 재활용해 스토리지 증설이 필요 없을 수도 있으며 2011년에는 5TB 분량의 스토리지만 증설하면 될 것이다.

그렇다면 무조건 COMPRESS 기능을 적용한다면 옳은 일인가?

COMPRESS 기능을 적용할 때에는 그에 따른 득과 실을 확실히 따져 봐야 한다.

COMPRESS 기능을 적용한다면 분명 스토리지 부분에서 많은 절감을 할 수 있지만 스토리지를 절약하고서 다른 부분에서 잃는 것이 많다면 이 또한 안 될 것이기 때문이다.

ORACLE COMPRESS

ORACLE에서도 다른 DBMS와 마찬가지로 단일 TABLE부터 PARTITION TABLE, INDEX까지 다양한 COMPRESS 기능을 제공하고 있다.

그렇지만 제공하는 기능을 무조건 적용한다고 해서 그 효과를 발휘할 수 있을까? DBMS에서 제공하는 모든 기능과 마찬가지로 COMPRESS 기능 또한 장단점이 존재하고 있다.

TABLE COMPRESS의 장단점은 무엇인가?

11g까지 ORACLE이 버전업되면서 COMPRESS 기능에 대해 많은 기술을 적용하고 있지만 아직까지 DML이 많은 TABLE에 대해 COMPRESS는 취약한 것이 분명하다.

일반적인 INSERT 작업에 대해서는 각각 성능의 차이가 발생하지 않으며 DELETE 처리에서는 오히려 COMPRESS한 TABLE이 좋은 성능을 보인다. 그렇지만 UPDATE에 대해서는 오히려 COMPRESS하기 전의 TABLE보다 CPU의 사용률이 증가하며 그 처리 속도 또한 현저히 떨어지게 된다.

아마도 이 부분이 COMPRESS 기능을 알면서도 시스템에 적용시키는 것을 망설이게 하는 가장 큰 요인이라고 할 수 있으며 특히 온라인 트랜잭션이 많은 OLTP 환경에서는 그 적용 정도를 찾아보기 힘들게 하는 요인이 된다.

COMPRESS 적용 대상

가장 널리 알려진 적용 대상으로 DW 환경에서의 COMPRESS 적용을 들 수 있다. DW 환경의 특성상 대용량 데이터의 조회가 많고 트랜잭션의 빈도는 낮아 UPDATE에 대한 COMPRESS 기능의 성능 저하 영향이 많지 않을 뿐더러 COMPRESS로 인해 동일한 블록에서 많은 데이터 저장이 가능하므로 COMPRESS 전보다 블록 I/O를 감소시켜 조회 성능의 향상까지 얻을 수 있다.

실제 PARTITION TABLE에 대해 TABLE COMPRESS 기능을 적용해 대량 조회 I/O 감소와 적용된 TABLE들에 대해 60~70%에 가까운 스토리지 절약 효과를 본 사례도 존재한다.

OLTP 환경에서의 COMPRESS

그렇다면 과연 OLTP 환경의 COMPRESS는 적용 불가의 영역인가?

앞서 이야기한 운영 중인 데이터의 속성을 따져 보면 OLTP 환경에서도 충분히 COMPRESS 기능을 활용 가능한 영역이 있음을 알 수 있다.

스토리지 증설의 문제가 되는 이력 데이터들에 대해 UPDATE 작업이 수반될 수 있는 데이터가 존재하 는 TABLE들을 제외하더라도 INSERT 작업만 일어나는 TABLE들에 대해서는 PARTITION 기법과 병행한다면 COMPRESS에 대해 충분히 효과를 볼 수 있을 것이며 UPDATE가 일어나는 TABLE이라 할지라도 UPDATE 처리의 유형에 따라 PARTITION 적용을 통해 그 활용 정도는 더 넓어질 것이다.

필자가 과거 근무했던 곳에서는 DML이 빈번하게 일어나는 TABLE이 존재했다.

그러나 이 DML은 당일에 한해 가장 빈번 했으며 주기 측면에서 일주일이 지난 데이터에 대해선 DML 발 생이 일어나지 않고 데이터의 보관 주기는 3년 동안 이력을 관리 해야 하는 TABLE이었다.

COMPRESS 대상으로 보면 DML이 빈번하므로 COMPRESS 적용 대상 TABLE로 보기에는 힘든 TABLE이다.

그러나 이 TABLE에 대해 월 단위 혹은 년 단위 PARTITION 작업이 되어 있었다면 이야기는 달라진다. UPDATE 발생 가능 주기에서 벗어난 PARTITION에 대해서는 충분히 COMPRESS가 가능한 TABLE로 분류되었을 것이다.

다른 예를 들면 INSERT 작업만 발생하며 해당 TABLE의 크기가 워낙 대용량이라 일 단위 파티션을 사용하고도 조회 성능 향상을 위한 Clustering Factor 작업을 매일 수행했다.

개별 INSERT에 대한 COMPRESS가 수행되지 않는 점을 감안하거나 COMPRESS에 대한 부담으로 당일에 한해서는 일반 PARTITION으로 운영하더라도 Clustering Factor 작업과 병행해 COMPRESS를 함께 진행했다면 다른 문제없이 스토리지 절감 효과와 함께 COMPRESS로 인한 조회 성능 향상까지 기대할 수 있었을 것이다.

특정한 몇 개의 시스템에서 예를 들었지만 많은 시스템에서 저러한 유형의 데이터들을 가지고 있을 것이며 COMPRESS가 적용될 수 있는 대상은 DW 환경이든 OLTP 환경이든 분명히 존재할 것이다.

단지 DW 환경이 적용 대상의 폭이 넓고 보편적일 뿐이다. 스토리지 증설에 대한 부담을 가지고 있으면서도 아직까지 COMPRESS를 고려해 보지 않았다면 고민하고 테스트하고 적용해 보자.

아무리 고민해도 적용이 망설여진다면 작은 일부분이라도 적용해서 그 효과 및 영향을 직접 확인해 보는 것도 한 가지 방법이 될 수 있다.