일체형 인덱스는 랜덤은 없어졌지만 다양한 액세스 형태가 나타나는 경후로 인한 부하 발생 \-> 이러한 문제를 해결하기 위한 여러가지 방법들이 많고 주어진 상황에 따라 미묘하게 달라지는데 가장 큰 해결방안으로 클러스터링을 들 수 있다.
1.3.1 클러스터링 테이블의 개념
클러스터는 하나의 오브젝트.
정해진 컬럼값을 기준으로 동일한 값을 가진 하나 이상의 테이블의 로우를 같은 장소에 저장하는 물리적인 기법. \->그것이 하나의 테이블을 대상으로 모아 두웠다면 해당 테이블에 대한 대량의 범위처리 운송단가를 줄일 수 있고 하나 이상의 테이블을 대상으로 모아 두웠다면 조인의 연결에 의한 운송단가를 줄 일 수 있다는 의미
테이블은 클러스터 오브젝트 내에 생성되는 것으로 테이블의 상위개념.(테이블이 없는 클러스터는 무의미)
클러스터에 데이터를 저장하기 위해서는 테이블 생성은 물론 클러스터 인덱스도 생성되어야 한다. \->일반 인덱스와의 차이
클러스터링되어 있다는 요소만 더 가지고 있음
규칙기준 옵티마이져시에 일반 인덱스보다 높은 랭킹을 부여 받음
비용기준 옵티마이져에서는 보다 적은 비용으로 취급되는 역할?
1.3.2 단일테이블 클러스터링
넒은 범위의 데이터를 동시에 액세스하고자 할때 주로 사용
위 그림은 하나의 블럭에 최대 2개의 단위 클러스터만 존재할 수 있도록 크기(SIZE)를 지정 한 것으로 가정 했을 경우.
위 그림에서 클러스터 키는 모두 로우에 가지고 있는것으로 표현되어있지만 실제로는 블럭헤더에 클러스터키ID와 클러스터키를 가지고 있다.(클러스터키가 되는 컬럼값은 한번만 저장됨을 의미)
만약 어떤 로우에 클러스터키가 되는 컬럼값이 수정된다면 수정된 값에 맞는 단위클러스터로 이동해야 하는데 이럴 경우 ROWID는 새로 이주해 가야할 곳의 ROWID를 남겨두고 현재 ROWID정보를 가지고있는체 이동하게 된다.
일반 인덱스 스캔에 5~8배 향상 기대
좁은 분포도에서는 같은 단위 클러스터에 속한 로우 수가 적어짐을 의미 일반 인덱스를 사용한 것보다 효과가 떨어질 수 있음
지정된 위치에 저장되어야 하기 때문에 검색을 제외한 모든 경우 부하가 발생
1.3.3 다중테이블 클러스터링
단위 클러스터에 두개 이상의 테이블을 함께 저장하는것.
위 그림에서 클러스터키 컬럼 DEPTNO이다
각 로우는 클러스터키ID를 가지고 있고 블럭헤더에는 클러스터키ID와 클러스터키 정보를 가지고 있다. 따라서 단위클러스터 안에서는 클러스터키 값을 가지고 있을 필요가 없고(회색으로 표시된 값들이 이에 해당함) 실제로 저장되지 않는다.
정규화작업으로 분할된 테이블들을 마치 하나의 테이블처럼 액세스할 수 있다.
제 1정규화작업에 의해서 한테이블에서 별개의 테이블로 분할 된 테이블은 정규화작업 이전에 한레코드에 있어서 액세스 할 수 있었으나 분할 된 후 일일이 키 값을 가지고 조인을 통해 하는 부담이 있고 서로 테이블의 로우가 주변에 모여있다고 확신 할 수도 없다. 이러한 경우 다중 테이블 클러스터링으로 몇 가지 불만이 해소된다.
단점
클러스터링된 테이블간의 연결도 중요하지만 수많은 다른테이블들과의 관계를 맺고자 하는 경우.
1.3.4 클러스터링 테이블의 비용
관계형 데이터베이스의 최대 약점인 넓은 범위 처리를 해결해주고 조인의 효율성을 크게 높여주는 등의 이득이 많지만 그거에 따르는 대가가 필요하다.
클러스터링에게 어떤 역할을 맡길 것인가?
해결해야할 액세스 형태를 모두 수집하고 인덱스로 해결할 수 있는 방안이 있는 강구.
클러스터링 도입으로 인한 부하의 부담도 고려되.
클러스터링에 인한 부하는 어느 정도인가?
클러스터링은 단지 검색의 효율만 높여 줄뿐 입력, 수정, 삭제 시는 추가적인 부하가 발생
입력(insert)시의 부하
정해진 위치에 저장되어야 하기 때문에 부하가 발생 한다.
일반테이블에 데이터 입력시에는 저장공간을 할당받아 무조건 저장하고 블럭이 PCTFREE에 도달하면 새로운 프리리스트를 요구하여 다른 블럭에 저장
클러스터키 값에 따라 저장위치가 달라지므로 FREELIST요구 횟수가 증가(100개를 저장하려고 할때 최악의 경우 100번의 FREELIST요청)
수십, 수백개 이내의 로우의 경우는 큰 문제가 되지 않으나 수천개 이상의 데이타 입력시 주의해야함.
일반 테이블에서도 인덱스로 인한 입력시 부하가 발생하지만 클러스터링만큼은 아니며 클러스터링을 도입한다면 기존의 인덱스와 클러스터링간의 전략적인 구성으로 인덱스 수는 감소하여야 한다.(그래도 부하는 있다)
수정(updaet)시의 부하
클러스터키 컬럼의 값을 수정하는 경우 : 변경된 클러스터 키 컬럼의 단위 클러스터 내로 이동해야 하기때문에 부하가 발생하나 이는 일반테이블에서 더이상 로우를 추가 저장 할 수 없어 다른 블럭으로 이주하는 것과 거의 동의하다. 이 말은 곧 클러스터키 수정으로 인해 특별히 더 부하가 있다거나 하지 않다는 것을 의미하며 문제는 동일한 클러스터키 값을 가진 로우가 여러 블럭에 흩어지는 현상이 발생하여 액세스할 블록 수가 증가함으로 원래의 목적이 희석 될 수 있다는 것이다 따라서 수정이 빈번한 컬럼을 클러스터키 컬럼으로 지정하면 좋지 않다.
클러스터키 컬럼이 아닌 일반 컬럼을 수정하는 경우는 일반 테이블 수정과 동일하다
삭제(delete)시의 부하
클러스터링테이블에 로우를 삭제하더라도 클러스터 인덱스는 그대로 존재하기 때문에 추가적인 처리가 발생하지 않는다.
다만 클러스터링 테이블 DROP시에 내부적으로는 롤백 세그먼트를 받아 데이타를 저장하고 DELETE를 한다. 그 이유는 한 단위 클러스터에 2개의 테이블이 저장되어있다면 단위클러스터의 일부분을 삭제하겠다는 것이 단위 클러스터를 삭제 하려는 것이 아니므로 클러스터 입장에서는 DELETE 할 수 밖에 없다. 이런 작업이 많은 부하를 줄 뿐 아니라 큰 롤백 세그먼트가 필요하게 된다.
1.3.5 해쉬(HASH) 클러스터링
클러스터링이라기 보다 일종의 인덱스를 대신하는 개념
해쉬값을 이용해 테이블의 데이타를 정해진 위치에 저장하고(클러스터링개념) 우리가 원하는 값을 찾아간다(인덱스개념)
아주 특정한 경우에 한정되어 사용됨
해쉬 클러스터링의 특징
SIZE, HASHKEYS, HASH IS 파라미터는 변경 할 수 없다.
'='로만 액세스해야 한다.
클러스터가 생성되면서 저장공간이 미리 할당된다.
지정된 단위 클러스터 보다 많은 로우가 들어오면 OVERFLOW영역에 저장된다.
컬럼의 값이 고르게 분포되어 있지 않으면 해쉬키 값의 충돌(COLLISION)이 발생한다.
인덱스를 경유하지 않고 해쉬 함수로 계산된 값으로 직접 테이블 액세스하므로 인덱스보다 효율적인 액세스를 할 수 있다.
해쉬 클러스터링의 활용 범위
사전에 해쉬키의 개수와 저장공간을 확보해야 하기때문에 지속적으로 대량의 데이타가 증가하는 테이블에는 적용하지 않는 것이 좋다.