클러스터 팩터의 정의를 이해하자.

앞서 클러스터 팩터에 대한 예제를 통해 개념을 확인해 보았다. 클러스터 팩터는 우리가 추출하고자 하는 데이터가 얼마나 동일한 블록에 저장되어 있는 가를 의미하게 된다. 그렇다면 진정 클러스터 팩터의 정의는 무엇인가 아래 그림을 확인해 보자.

클러스터 팩터는 위와 같이 정의할 수 있을 것이다. 인덱스를 통해 추출된 데이터가 100건이라고 가정하자. 인덱스를 엑세스한 후에는 테이블을 엑세스하게 되는 것은 당연한 사실일 것이다. 이 경우 인덱스에서 추출된 데이터는 100건의 데이터인데 테이블을 엑세스하는 블록의 개수가 100이라면 위의 공식에 대입해보면 1이라는 값이 추출된다. 이와 같다면 우리가 원하는 데이터는 각 블록에 1건의 데이터만이 존재한다는 의미가 된다. 그러므로 해당 엑세스는 클러스터 팩터가 불량하게 된다. 따라서 우리도 모르게 성능 저하가 발생할 수 있게 된다. 반대로 인덱스에서 100건의 데이터가 추출되었지만 테이블 블록은 2개만 엑세스 했다면 위의 공식에 적용하면 값은 100/2이므로 50의 값이 되어 양호한 클러스터 팩터가 될 것이다. 클러스터 팩터가 양호하면 엑세스하는 블록의 개수는 감소하므로 자연스럽게 성능은 향상 될 것이다.

위의 클러스터 팩터의 정의에서 우리는 무엇을 이해해야 하는 것일까 공식을 외운다고 우리가 클러스터 팩터에 대해 모든 것을 해결할 수 있는 것은 아니다. 우리에게 지금 필요한 것은 우리가 엑세스하는 데이터에 대해 클러스터 팩터를 최적화 한다면 우리는 성능을 향상시킬 수 있다는 것이다. 이제부터 클러스터 팩터의 속성을 파악하고 우리가 엑세스하고자 하는 데이터에 대해 클러스터 팩터를 최적화 하는 방법을 확인해 보자.

클러스터 팩터의 속성을 파악해라.

클러스터 팩터에는 우리가 아직까지 언급하지 않은 하나의 속성이 존재한다. 이 속성이야 말로 우리에게는 선택을 제공하게 된다. 그렇다면 이와 같은 클러스터 팩터의 속성은 무엇인가 바로 하나의 테이블에서는 하나의 컬럼에 의해서는 클러스터링 팩터를 최적화할 수 있다는 것이다. 이는 우리에게 클러스터 팩터를 양호하게 하는 방법에 많은 고려사항과 제한 사항을 제공하게 된다.

그렇다면 정말로 하나의 테이블은 하나의 컬럼으로만 클러스터 팩터를 양호하게 할 수 있는 것인가 앞서 언급한 거래내역 테이블을 다시 한번 확인해 보자. 거래내역 테이블은 거래일자 순으로 데이터가 저장되기 때문에 각각의 블록은 동일한 거래일자 데이터가 저장될 것이다. 그렇기 때문에 이 상태 그대로라면 해당 테이블은 거래일자 컬럼에 의해 클러스터 팩터가 최적화된다. 해당 거래내역 테이블은 거래일자 컬럼의 값으로도 조회를 하지만 카드번호 컬럼의 값으로 많은 조회가 발생한다고 가정하자. 그렇다면 거래일자로 조회하는 엑세스는 클러스터 팩터가 양호하기 때문에 자동으로 성능이 향상될 수 있지만 카드번호 컬럼으로 조회하는 엑세스는 클러스터 팩터가 양호하지 않기 때문에 해당 엑세스에 대해 서는 성능이 저하될 것이다. 이와 같은 경우 우리는 카드번호 컬럼으로 클러스터 팩터 최적화를 수행할 것이다.

거래내역 테이블에 대해 카드번호 컬럼으로 클러스터 최적화를 수행한다면 해당 거래내역 테이블에는 어떤 현상이 발생하게 되는가 카드번호 컬럼으로 클러스터 팩터를 최적화하므로 거래내역 테이블은 카드번호 컬럼의 값이 동일한 데이터들이 동일 블록에 저장될 것이다. 이와 같이 저장되어야만 우리는 거래내역 테이블이 카드번호 컬럼에 의해 클러스터 팩터가 양호하다고 이야기할 수 있을 것이다. 이와 같이 구성하는 방법을 클러스터 팩터 최적화라고 한다. 카드번호 컬럼으로 클러스터 팩터 최적화를 수행하면 어떤 현상이 발생하게 되는가

* 카드번호 컬럼 - 동일한 카드번호 컬럼의 값이 동일한 블록에 저장
* 거래일자 컬럼 - 서로 다른 거래일자 컬럼의 값이 동일한 블록에 저장

위와 같은 현상이 발생하게 된다. 이 뜻은 거래일자 컬럼의 값에 대해서는 기존에는 클러스터 팩터의 값이 양호 했지만 카드번호 컬럼으로 클러스터 팩터 값을 최적화한다면 더 이상 거래일자 컬럼의 값으로는 클러스터 팩터가 최적화되지 않는다는 의미가 된다.

2008년 4월 30일 사용한 거래내역 데이터를 확인해 보자. 2008년 4월 30일에 사용한 거래내역 데이터는 연속된 블록에 저장이 될 것이다. 따라서 해당 블록들을 확인해 본다면 동일한 2008년 4월 30일 데이터들이 저장될 것이다. 그렇기 때문에 거래일자 컬럼에 의해 클러스터 팩터가 최적화되었었다. 하지만 해당 데이터의 카드번호 값은 어떠한가 하루에 동일한 카드가 몇 번이나 사용이 되겠는가 업무적으로 다를 수 있지만 하나의 카드가 동일한 일자에 수 십번 아니 수 백번 사용하지는 않을 것이다. 그렇다는 이야기는 무엇인가 카드번호 컬럼으로 동일한 블록에 데이터를 저장하는 순간 거래일자 컬럼의 값은 더 이상 동일한 거래일자 값이 동일한 블록에 저장되지 못한다는 것이다. 그러므로 카드번호 컬럼으로 클러스터 팩터를 최적화 한다면 그 동안 클러스터 팩터가 양호했던 거래일자 컬럼의 클러스터 팩터는 불량해 지게 된다. 결국, 하나의 컬럼으로 클러스터 팩터를 최적화 한다면 다른 컬럼들은 일반적으로 클러스터 팩터가 불량하게 된다. 이는 무엇을 의미하는 것일까 카드번호 컬럼으로 클러스터 팩터를 최적화하여 카드번호 컬럼의 값으로 조회하는 엑세스의 성능을 최적화할 수 있지만 그에 반해 거래일자 컬럼으로 데이터를 엑세스하는 경우에는 클러스터 팩터가 불량해 지므로 성능은 저하될 수 있게 된다.

이처럼 클러스터 팩터의 최적화에는 장점과 단점이 존재하게 된다. 어떤 컬럼으로 클러스터 팩터를 최적화 한다면 다른 컬럼들의 클러스터 팩터는 불량해 지게 된다. 어떤 카드회사에서 필자가 실제로 거래내역 테이블에 대해 카드번호 컬럼으로 클러스터 팩터를 최적화해 보았었을 때의 일이다. 카드번호 컬럼으로 데이터를 엑세스하는 어플리케이션은 전체적으로 성능이 안정화되었다. 하지만 거래일자 컬럼으로 매일 작업을 수행하는 어플리케이션은 기존 성능에 비해 10배 정도의 성능 저하가 발생했었다. 그래서 개발자로부터 연락이 왔으며 필자는 내일이 되면 거래일자로 클러스터 팩터가 최적화되니 내일부터는 원래의 성능을 보장할 수 있을 거라 언급을 했다. 내일이 되자 필자가 말한 것이 현실로 나타났다. 기존 거래일자로 데이터를 엑세스하는 어플리케이션은 기존 성능을 보장 받게 되었다. 이는 무엇을 의미하는가 우리가 매우 자주 엑세스하는 테이블의 클러스터 팩터는 해당 테이블을 엑세스하는 어플리케이션에 엄청난 영향을 미친다는 것이다. 이와 같이 성능에 있어 큰 영향을 미치는 클러스터 팩터를 더 이상 무시해서는 안될 것이다. 우리가 프로젝트 중에 중요 테이블에 대해 클러스터 팩터를 고려했는지 안 했는지는 해당 시스템의 전체 성능에 있어 매우 중요한 역할을 수행하게 된다.

아직도 많은 사람들은 클러스터 팩터에 대한 중요성을 모르고 있는 것이 현실이다. 이는 관리자부터 클러스터 팩터에 대한 중요성을 인식해야지만 많은 시스템에 필요한 클러스터 팩터를 최적화할 수 있을 것이다. 대용량의 데이터가 되면서 그리고 많은 어플리케이션이 수행되는 시스템에서는 클러스터 팩터가 성능에 있어서는 매우 중요한 역할을 수행하게 된다. 이제는 더 이상 클러스터 팩터를 간과해서는 안될 것이다. 우리가 주로 엑세스하는 컬럼으로 클러스터 팩터를 최적화하는 순간 우리는 성능에 있어 새로운 세상을 펼칠 수 있을 것이다.

클러스터 팩터를 최적화화는 방법에는 많은 방법이 존재한다. 테이블 재구성부터 파티션 테이블을 이용하는 방법가지 여러 방법이 존재하며 이에 대한 방법은 다음 호에 자세히 언급하도록 하겠다. 우리가 생각하지 않는 클러스터 팩터에 대한 생각의 전환이야 말로 대용량 데이터베이스에 대해 성능을 최적화할 수 있는 중심에 있게 된다.

출처 : 한국데이터베이스진흥원

제공 : 데이터 전문가 지식포털 DBguide.net