CUBRID 2008 R4.0 버전 이상부터는 커버링 인덱스를 지원합니다, 커버링 인덱스는 “A covering index is a special case where the index itself contains the required data field(s) and can return the data.”라고 하는데 원문을 해석하면 커버링 인덱스는 인덱스 자체에 필수 데이터 필드가 들어 있고 데이터를 반환할 수 있는 특별한 인덱스라고 해석됩니다, 다시 정리하면 하나의 질의 내에 특정 인덱스를 구성하는 컬럼만 사용하는 경우 커버링 인덱스를 사용하게 됩니다.
아래 예제-1)에서 SELECT 질의의 WHERE 조건에 사용된 컬럼 i와, SELECT 리스트로 주어진 컬럼 j는 모두 인덱스 idx를 구성하는 컬럼입니다. 이와 같은 경우에 CUBRID는 SELECT 질의를 수행할 때 커버링 인덱스를 스캔 하게 됩니다, 이는 하나의 인덱스가 SELECT 문이 요구하는 조건과 결과를 모두 포함하고 있기 때문에 가능한 일입니다.
예제-1)
CREATE TABLE tbl (i INT, j INT);
CREATE INDEX idx ON tbl(i, j);
SELECT j FROM tbl WHERE i > 0;
CUBRID는 B+Tree를 이용하여 인덱스를 구현하고 있습니다, B+Tree는 다음 그림과 같이 루트 노드, leaf 노드, non-leaf 노드로 구성되는데 leaf 노드에는 데이터 행(row)의 위치(OID, Object Identifier)가 저장되고 데이터는 힙(heap) 파일 내에 저장이 되며 데이터의 저장 순서는 인덱스의 순서와 관련이 없습니다.
위에서 언급한대로 CUBRID의 인덱스 구조에서는 데이터가 인덱스 외부에 위치하며 데이터의 저장 순서는 인덱스 구성에 영향을 주지 않습니다, 이와 같은 형태의 인덱스를 non-clustered 인덱스라고 부릅니다. 이 구조에서는 인덱스가 데이터의 위치만 가지고 있기 때문에 인덱스 탐색 중에 데이터를 읽어와야 하고 그로 인해 디스크 Random access I/O가 추가로 발생할 수 있습니다.
그런데, 만약 이 때 사용되는 인덱스 내에서 SELECT 질의에 대한 결과를 모두 얻을 수 있는 상황이라면 힙 파일에 저장되어 있는 데이터를 읽어오지 않아도 인덱스 키의 값으로 결과를 만들어 낼 수 있을 것입니다, 이와 같이 인덱스가 하나의 질의를 모두 “커버”한 경우에 대해서 “커버링 인덱스”라고 말합니다.
커버링 인덱스는 I/O양을 줄일 수 있는 방법으로 알려져 있습니다, 힙 파일에서 데이터를 읽어오지 않음으로 인해 줄어드는 I/O 외에도, 일반적으로 인덱스 키가 데이터 행 전체의 크기보다 훨씬 작다는 점, 질의 처리에 인덱스를 자주 사용하게 되면 인덱스가 CUBRID 메모리 버퍼에 캐싱(caching)되어 있을 가능성이 높은 점이 I/O를 줄이는 역할을 합니다. 또한 인덱스는 값에 따라 정렬되어 있기 때문에 순차적(sequential) 접근이 가능하므로 데이터를 읽기 위해 힙 파일을 랜덤(random)하게 접근하는 것에 비해 I/O 비용이 적게 드는 장점도 생각해 볼 수 있습니다.
앞서 설명한 것과 같이, 커버링 인덱스는 많은 양의 I/O를 줄일 수 있고 SELECT 질의의 성능을 향상시킬 수 있습니다. 하지만 커버링 인덱스를 사용하기 위해 무작정 인덱스 컬럼을 늘이거나 인덱스를 추가로 생성하게 되면 그에 따른 인덱스 관리 비용이 증가하고 입력/갱신 비용이 증가할 수 있습니다, 따라서 커버링 인덱스 사용 여부를 결정할 때에는 질의의 성능, I/O 비용, 저장 공간에 대한 비용 등을 전체적으로 고려해야 합니다, 일반적으로 데이터 행 전체의 크기에 비해 인덱스 키의 크기가 작고 커버링 인덱스를 이용하는 질의가 자주 수행되는 것이 확실하다면 커버링 인덱스를 사용하는 편이 합리적입니다.
CUBRID에서 커버링 인덱스가 사용되는 것을 확인하기 위해서는 질의 실행 계획(plan)을 확인하면 됩니다, 앞서 예를 든 질의의 쿼리를 살펴보면 예제-2)와 같이 “covers”라는 단어를 확인할 수 있습니다, 인덱스 스캔 계획에서 “covers”라는 단어가 보이면 커버링 인덱스가 사용된 것입니다.
예제-2)
Query plan
iscan
class: tbl node[0]
index: idx term[0] (covers)
cost: fixed 0(0.0/0.0) var 1(0.0/1.0) card 0
Query plan 통계 정보 확인 방법은 CUBRID 온라인 매뉴얼을 참고해주시기 바랍니다. (https://www.cubrid.org/manual/ko/9.3.0/sql/tuning.html)
