데이터의 증가는 데이터베이스 안에 대용량의 테이블이 존재한다는 의미다. 대용량의 테이블이라면 관리 및 성능을 고려하여 파티션 테이블의 아키텍처를 적용하는 경우가 다반사일 것이다. 테이블에 파티션 아키텍처가 적용된다면 해당 테이블의 인덱스는 파티션 인덱스가 적용되어야만 관리와 성능을 최적화할 수 있다. 이와 같은 이유에서 파티션 인덱스의 사용은 점점 증가하게 되는 것이다. 이제는 파티션 인덱스의 최적화된 적용을 이해해야 할 것이다. 지난 호까지는 파티션 인덱스의 종류인 글로벌 인덱스와 로컬 인덱스 그리고 PREFIX 인덱스와 NONOREFIX 인덱스를 확인해 보았다. 이번 호에서는 이와 같은 파티션 아키텍처를 조합한 파티션 인덱스의 최적화에 대해 함께 확인해 보자.
글로벌과 로컬, PREFIX와 NONPREFIX를 조합하자
글로벌과 로컬, PREFIX와 NONPREFIX는 각각 파티션 인덱스의 아키텍처가 된다. 우리가 파티션 인덱스를 생성하는 경우에 로컬 인덱스와 같이 하나의 파티션 아키텍처 만으로 파티션 인덱스를 생성할 수는 없다. 그렇다면 파티션 인덱스는 어떻게 생성해야 하는가?
● 파티션 인덱스 - 관리의 아키텍처 + 운영의 아키텍처
파티션 인덱스는 이와 같이 관리를 좌우하는 파티션 아키텍처와 운영을 좌우하는 운영의 아키텍처를 조합하여 구성하게 된다. 이는 무엇을 의미하는가?
파티션 인덱스의 아키텍처 중 관리의 아키텍처는 로컬 인덱스와 글로벌 인덱스가 존재한다. 이는 각각의 인덱스 파티션 아키텍처가 다음과 같은 특징을 가지기 때문이다.
● 로컬 인덱스 - 파티션 테이블의 구조와 파티션 인덱스의 구조를 동일하게 하여 대부분의 작업이 파티션 별로 가능하므로 보관 주기 관리 등의 파티션별 작업을 독립적으로 수행할 수 있다.
● 글로벌 인덱스 - 파티션 테이블의 구조와 파티션 인덱스의 구조가 동일하지 않기 때문에 파티션 별 작업을 수행하는 경우 전체 파티션 테이블 및 파티션 인덱스에 대한 액세스가 불가능하게 된다.
이런 특징에 의해 로컬 파티션 인덱스는 테이블의 관리에 유리하게 되며 글로벌 파티션 인덱스는 인덱스의 관리에 불리하게 된다.
파티션 인덱스의 관리의 아키텍처가 이와 같다면 성능의 아키텍처는 어떠한가? 파티션 인덱스의 성능에 대한 아키텍처는 다음과 같이 구분될 것이다.
● PREFIX 인덱스 - 인덱스 첫 번째 칼럼이 SQL의 WHERE 조건에서 동일(=) 조건으로 조회될 경우 하나의 인덱스 파티션만을 액세스하게 되므로 테이블을 전체 액세스하는 최악의 성능을 사전에 방지할 수 있으므로 성능에 유리할 수 있다.
● NONPREFIX 인덱스 - 인덱스 첫 번째 칼럼이 SQL의 WHERE 조건에서 동일(=) 조건으로 조회되더라도 모든 인덱스 파티션을 액세스해야 하므로 SQL이 최적화되지 않는다면 엄청난 성능 저하가 발생할 수 있다.
이와 같이 제한적이지만 PREFIX 인덱스가 NONPREFIX 인덱스에 비해 성능을 보장할 수 있는 보호막을 가지게 된다.
파티션 인덱스는 이처럼 관리의 아키텍처와 성능의 아키텍처의 조합에 의해 종류가 구분된다. 따라서 다음과 같이 파티션 인덱스를 생성할 수 있을 것이다.
● 로컬 PREFIX 인덱스
● 로컬 NONPREFIX 인덱스
● 글로벌 PREFIX 인덱스
● 글로벌 NONPREFIX 인덱스
● NON-PARTIONED 인덱스
파티션 테이블의 인덱스는 이렇게 다섯 개의 종류가 존재하게 된다. 앞의 종류에서 NON-PARTIONED 인덱스를 제외하면 각각의 인덱스는 관리의 아키텍처와 성능의 아키텍처를 모두 갖게 된다. NON-PARTITIONED 인덱스의 경우에는 테이블에 파티션 아키텍처를 적용하여 특정 칼럼을 기준으로 데이터를 물리적으로 분리하였으나 인덱스는 분리하지 않고 하나의 물리적 구조로 구성하는 경우이다. 위의 인덱스 중 글로벌 NONPREFIX 인덱스는 실제 존재하지 않게 된다. 왜 글로벌 NONPREFIX 인덱스는 존재하지 않는 것일까? 그 이유는 생각보다 매우 간단하다. 해당 인덱스는 글로벌이므로 관리가 불리할 수 있으며 NONPREFIX 인덱스이기 때문에 성능에 대한 보호막을 가지지 못해 해당 인덱스를 이용하는 SQL이 최적화되어 있지 않다면 성능 저하를 야기시킬 수 있게 된다. 이와 같이 단점인 아키텍처만을 모아서 파티션 인덱스를 구성한다면 우리가 얻을 수 있는 이득은 무엇인가? 아마도 어떠한 이득도 기대할 수 없을 것이다. 이와 같은 이유에서 글로벌 NONPREFIX 인덱스는 실제 존재하지 않게 된다.
그렇다면 로컬 PREFIX 인덱스는 어떠한가? 로컬 PREFIX 인덱스는 로컬의 아키텍처를 상속받기 때문에 각각의 파티션 별로 독립적인 작업이 가능하다. 그렇기 때문에 인덱스의 관리에는 많은 장점이 존재하게 될 것이다. 또한, PREFIX 인덱스이므로 해당 인덱스의 첫 번째 칼럼에 대해 WHERHE 조건이 동일(=) 조건이라면 하나의 인덱스 파티션만을 액세스하게 된다. 물론, 동일 조건이 아니라도 하나의 인덱스 파티션만을 액세스해서 원하는 결과를 모두 추출할 수 있다면 하나의 인덱스 파티션만을 액세스하게 될 것이다. 이처럼 PREFIX 인덱스이므로 제한적으로나마 성능을 보호할 수 있는 보호막을 가지게 된다.
로컬 NONPREFIX 인덱스는 어떠한가? 로컬 파티션의 특징을 상속 받게 되므로 관리에는 용이하지만 NONPREFIX 인덱스이므로 성능에 대한 보호막이 존재하지 않게 된다. 마찬가지로 글로벌 PREFIX 인덱스의 경우에는 관리는 용이하지 않지만 제한적으로 해당 인덱스를 이용하는 SQL의 성능을 보장하는 특징을 상속 받게 된다.
최적의 파티션 인덱스를 선택하자
앞서 확인한 결과를 보면 가장 좋은 인덱스는 로컬 PREFIX 인덱스로 확인될 것이다. 그렇다면 파티션 테이블의 인덱스는 모두 로컬 PREFIX 인덱스로 생성해야 하는가? 그것은 아닐 것이다, 아무리 아키텍처가 좋다고 해도 사용 못할 수도 있는 것이다
예를 들어, 테이블은 YYYYMMDD 칼럼의 값을 파티션의 키 칼럼으로 월 단위로 범위 파티션을 적용하여 구성했다고 가정하자. 해당 테이블을 액세스하는 SQL 중에는 WHERE 조건 절에 고객번호 칼럼만이 조건으로 제공된다면 해당 SQL이 PREFIX 파티션으로 구성된 인덱스를 이용할 수 있겠는가? 일반적이라면 고객번호 인덱스를 생성해야 하므로 YYYYMMDD 칼럼으로 구성된 파티션 테이블에는 고객번호 칼럼을 이용하여 PREFIX 인덱스를 구성할 수 없게 된다. 하지만, 해당 SQL의 성능을 고려하여 앞에서와 같은 인덱스는 반드시 필요하게 되므로 NONPREFIX 인덱스를 생성해야 할 것이다. 이와 같이 인덱스는 해당 테이블을 액세스하는 SQL에 의해 좌우되므로 무조건 로컬 PREFIX 인덱스로 생성할 수는 없는 것이다. 또한, NONPREFIX 인덱스가 항상 성능 저하를 발생시키는 것은 아니다. 우리가 인덱스에 맞게 SQL을 최적화한다면 우리는 로컬 NONPREFIX 인덱스 또한 매우 효과적으로 사용할 수 있게 된다.
이제 파티션 테이블에 인덱스 생성을 요청할 경우 일반 인덱스 생성을 요청해서는 안 될 것이다. 정확히 로컬 PREFIX 인덱스인지 아니면 로컬 NONPREFIX 인덱스인지를 구분해야 하며 그에 따른 SQL 최적화를 동시에 수행해야 할 것이다. 이와 같은 업무 절차가 파티션 인덱스를 효과적으로 사용하는 지름길이 될 것이다.