[오라클]성능 향상을 위한 파티션 테이블 사용은 필수!!!

성능 향상을 위한 파티션 테이블 사용은 필수

 

필요에 의해 파티션 테이블을 생성하는 경우 무엇을 최우선으로 고려하는가? 파티션 테이블은 보관 주기 관리와 성능 향상을 위해 이용한다. 그런데 파티션 테이블의 존재는 물론이고 이것의 사용에 따른 혜택조차 모르는 경우가 비일비재하다. 파티션 테이블을 사용함으로써 얻을 수 있는 혜택을 정확히 이해하지 못하기 때문에 사용을 꺼릴 수 밖에 없다. 지난 호의 파티션 테이블과 보관 주기 관리에 이어 파티션 테이블을 이용한 성능 향상을 확인해 보자.

 

 

배치 작업으로 아직도 밤을 세우는가

대부분의 웹사이트 관리자는 사이트 운영 중에 데이터베이스를 액세스하는 일 배치 작업 또는 월 배치 작업으로 밤을 세우는 경우가 많다. 어떤 사이트는 당연한 일로 여기며 순번을 정해 작업을 하는 경우도 있다. 그렇다면 대용량의 일 배치 작업 또는 월 배치 작업으로 밤을 세우는 것은 당연한 일인가. 맞을 수도 있고 틀릴 수도 있다. 하지만 분명한 것은 배치 작업에 사용되는 테이블을 파티션 테이블로 구성함으로써 배치 작업의 성능을 10배 이상 향상시킬 수 있다는 것이다. 

월 배치 작업은 전 달의 데이터를 액세스하여 우리가 원하는 리포트 또는 여러 가지 유형으로 데이터를 추출하는 것을 의미한다. 예를 들어, 10개월 보관 주기의 한달 치 데이터가 30GB인 테이블이 존재한다고 가정하자(전체 테이블의 크기는 300GB). 이러한 대용량 테이블은 어떤 방식으로 액세스하여 월 배치 작업을 수행해야 할까? 해당 테이블로부터 1개월 데이터를 액세스하는 방법에는 두 가지가 존재한다. 첫 번째 방법은 테이블을 전체 액세스하여 최근 1개월 데이터를 선택하고 나머지 데이터는 버리는 방법이다. 두 번째는 인덱스를 액세스하여 1개월의 데이터만 액세스하는 것이다. 

그럼 먼저 전체 데이터를 액세스한 후 최근 1개월 데이터만 선택하는 배치 작업의 형태를 보자. 전체 데이터를 액세스하려면 전체 테이블을 액세스해야 한다. 즉 300GB의 테이블을 모두 엑세스해야 한다. 300GB의 데이터를 모두 액세스한 후 270GB는 우리가 원하는 데이터가 아니므로 버리고 나머지 1개월 데이터인 30GB로 원하는 작업을 수행하게 된다. 하나의 작업에서 300GB의 데이터를 한번에 액세스하는 것은 결코 쉽지 않다. 300GB의 테이블을 전체 액세스하는 것은 해당 시스템에 엄청난 성능 저하를 발생시킨다는 것을 대부분의 사람들이 알고 있을 것이다. 

또한, 우여곡절 끝에 300GB를 액세스했다고 하더라도 270GB를 버린다는 것은 매우 비효율적이다. 데이터는 추출하는 것도 성능을 저하시키지만 버리는 것 또한 성능 저하를 발생시킨다. 버리는데도 확인 작업이 수행되기 때문이다. 이처럼 전체 데이터를 액세스하는 것은 추출할 때나 버릴 때 모든 작업에서 성능 저하를 발생시킨다. 그러므로 이 같은 작업을 수행한다면 원하는 시간에 작업을 종료할 수 없게 될 것이다. 하루가 아닌 이틀 또는 삼일 밤을 세워야 할지도 모르는 것이다. 

두 번째로 인덱스를 이용한 한달 치 데이터만 액세스하는 예를 확인해 보자. 인덱스를 생성한 후 해당 인덱스를 이용하여 원하는 월의 데이터를 액세스한다면 인덱스는 테이블보다 크기가 작으므로 30GB보다 작겠지만 테이블은 30GB를 액세스해야 한다. 이는 인덱스를 액세스한 후 테이블을 액세스해야 하기 때문이다. 이 같은 경우 랜덤 액세스가 30GB 발생하게 된다. 

랜덤 액세스는 데이터가 저장되어 있는 개개의 블록을 액세스하는 방식을 이용하며 인덱스를 액세스한 후 테이블을 액세스하는 경우에는 랜덤 액세스가 발생하게 된다. 인덱스를 액세스한 후 테이블을 액세스하는 경우 하나 하나의 데이터를 각각 액세스하게 된다. 이러한 랜덤 액세스로 인해 DB 관련 서적 대다수가 인덱스를 이용할 경우 해당 테이블의 3%~5% 미만을 액세스해야 한다고 이야기한다. 위의 경우는 인덱스 액세스 후 테이블을 액세스하는 비율이 10%에 해당하므로 인덱스를 이용해서는 안될 것이다. 물론, 데이터가 많으면 많을수록 랜덤 액세스에 대한 비율은 더 낮아져야만 성능을 보장할 수 있다. 

결국, 위의 경우 인덱스를 이용한 테이블을 액세스하게 되면 더 이상 성능을 보장할 수 없다. 전체 테이블을 모두 액세스하는 경우보다 성능이 저하될 수 있다는 것을 명심하길 바란다. 

그렇다면 어떻게 작업을 수행해야 할까? 이에 대한 해답은 파티션 테이블이다. 월별로 파티션 테이블을 생성한다면 월별로 데이터를 저장하게 된다. 이렇게 테이블을 구성한다면 원하는 파티션만 전체 스캔할 수 있다. 파티션 전체 스캔은 파티션 별로 데이터가 저장되므로 원하는 파티션만 액세스할 수 있다. 배치 작업을 수행하기 위한 해당 월만을 저장하는 파티션이 존재하게 되며 해당 월 파티션만을 전체 스캔할 수 있게 된다. 이와 같이 수행한다면 한달 치 데이터인 30GB만 액세스하므로 액세스 후 버려지는 데이터도 없어진다. 또한 인덱스를 이용하지 않고 원하는 파티션 전체만을 스캔하기 때문에 랜덤 액세스도 발생하지 않는다. 

이 같이 배치 작업은 파티션 테이블의 이용으로 최적화가 가능하다. 아울려 파티션 구조를 어떻게 구성하는가에 따라 일 배치 작업도 최적화된 액세스를 수행할 수 있을 것이다. 정규적인 대용량 배치 작업의 해결 방법은 파티션 테이블에 존재한다고 해도 과언이 아니다. 

파티션 테이블과 피라미드 원리

파티션 테이블은 전체 데이터를 기준 컬럼으로 분리하여 별도로 저장하는 테이블을 의미한다. 이러한 이유에서 파티션 테이블은 피라미드 원리와도 같다. 그렇다면 피라미드 원리라는 것은 무엇인가? 1,000개의 벽돌을 바닥에 깔고 피라미드를 쌓는다고 가정하자. 그러면 1,000개의 벽돌에 의해 만들어지는 피라미드의 높이가 결정될 것이다. 이번에는 피라미드의 바닥을 1,000개의 벽돌로 쌓는 것이 아닌 100개의 벽돌로 10개의 피라미드를 쌓는다고 가정해 보자. 

전체 바닥에 사용된 벽돌은 1,000개의 벽돌로 앞서 언급한 경우와 동일하다. 하지만 바닥의 벽돌 개수에 의해 피라미드의 높이는 달라진다. 1,000개의 벽돌로 쌓은 한 개의 피라미드와 100개의 벽돌로 쌓은 10개의 피라미드 중 어떤 것이 더 높을까? 당연히 1,000개의 벽돌로 쌓은 피라미드가 훨씬 높을 것이다. 

파티션 테이블도 이와 별반 다르지 않다. 각각의 데이터를 파티션으로 구성하기 때문에 해당 테이블의 인덱스 또한 파티션으로 구성할 수 있으며 이럴 때 인덱스는 피라미드 원리가 적용된다. 

예를 들어, 파티션 테이블이 아닌 일반 테이블에서 하나의 데이터를 추출하려면 1,000개의 벽돌로 피라미드를 쌓는 것처럼 맨 위에서 원하는 벽돌을 찾아가야 한다. 하지만 테이블과 인덱스를 파티션으로 구성한다면 100개의 벽돌로 만든 10개의 피라미드가 존재하는 것과 같은 이치여서 이중 원하는 피라미드의 바닥에 존재하는 벽돌을 찾을 수 있다. 과연 어느 방법이 원하는 벽돌을 찾는데 빠르겠는가? 

당연히 높이가 낮은 100개의 벽돌로 구성된 피라미드가 더 빠른 시간에 원하는 벽돌을 찾을 수 있을 것이다. 물론, 100개의 벽돌로 만든 10개의 피라미드 중 해당 벽돌을 가지고 있는 하나의 피라미드를 찾는 것은 데이터베이스의 옵티마이저가 바로 찾아주므로 해당 부분은 우리가 걱정할 필요는 없을 것이다. 

결국, 대용량 테이블에서 인덱스를 이용하여 한 건의 데이터를 액세스하는 경우 인덱스의 높이가 높은 일반 테이블 보다는 높이가 낮은 파티션 테이블과 파티션 인덱스를 이용하는 것이 더 유리하다. 

앞에서 확인한 것과 같이 배치 작업의 처리와 한 건의 데이터를 추출하는 작업에서 파티션 테이블은 일반 테이블보다 높은 성능을 보장할 수 있다. 이것만으로도 파티션 테이블을 사용해야 하는 이유는 충분하다. 이제 주저하지 말고 대용량 테이블에 대해 파티션 테이블을 적용하도록 하자. 

권순용 kwontra@hanmail.net｜SKC&C에서 DBA 업무를 담당하고 있다. 수 많은 프로젝트에서 DB 아키텍처, 모델링 및 튜닝을 수행했다. 저서로는 정보 문화사의 Perfect! Oracle 실전 튜닝과 초보자를 위한 오라클 10g가 있다. 현재 고급 튜닝 서적을 집필 중이며 성능 최적화와 관련된 특허 출원이 올해의 목표이다.