1.3 클러스터링 테이블

  • 분리형 인덱스는 대량의 데이터를 범위처리할 경우 랜덤 발생으로 인한 부하 발생
  • 일체형 인덱스는 랜덤은 없어졌지만 다양한 액세스 형태가 나타나는 경후로 인한 부하 발생
    \-> 이러한 문제를 해결하기 위한 여러가지 방법들이 많고 주어진 상황에 따라 미묘하게 달라지는데 가장 큰 해결방안으로 클러스터링을 들 수 있다.

1.3.1 클러스터링 테이블의 개념

  • 클러스터는 하나의 오브젝트.
  • 정해진 컬럼값을 기준으로 동일한 값을 가진 하나 이상의 테이블의 로우를 같은 장소에 저장하는 물리적인 기법.
    \->그것이 하나의 테이블을 대상으로 모아 두웠다면 해당 테이블에 대한 대량의 범위처리 운송단가를 줄일 수 있고
    하나 이상의 테이블을 대상으로 모아 두웠다면 조인의 연결에 의한 운송단가를 줄 일 수 있다는 의미
  • 테이블은 클러스터 오브젝트 내에 생성되는 것으로 테이블의 상위개념.(테이블이 없는 클러스터는 무의미)
  • 인덱스 클러스터와 해쉬함수 클러스터가 있고 인덱스6 클러스터에는 단일테이블 클러스터링과 다중테이블 클러스터링이 있음
  • 클러스터를 정의해야 클러스터에 테이블 생성 할 수 있다.
  • 클러스터에 데이터를 저장하기 위해서는 테이블 생성은 물론 클러스터 인덱스도 생성되어야 한다.
    \->일반 인덱스와의 차이
    • 클러스터링되어 있다는 요소만 더 가지고 있음
    • 규칙기준 옵티마이져시에 일반 인덱스보다 높은 랭킹을 부여 받음
    • 비용기준 옵티마이져에서는 보다 적은 비용으로 취급되는 역할?

1.3.2 단일테이블 클러스터링

  • 넒은 범위의 데이터를 동시에 액세스하고자 할때 주로 사용
  • 위 그림은 하나의 블럭에 최대 2개의 단위 클러스터만 존재할 수 있도록 크기(SIZE)를 지정 한 것으로 가정 했을 경우.
  • 위 그림에서 클러스터 키는 모두 로우에 가지고 있는것으로 표현되어있지만 실제로는 블럭헤더에 클러스터키ID와 클러스터키를 가지고 있다.(클러스터키가 되는 컬럼값은 한번만 저장됨을 의미)
  • 만약 어떤 로우에 클러스터키가 되는 컬럼값이 수정된다면 수정된 값에 맞는 단위클러스터로 이동해야 하는데 이럴 경우 ROWID는 새로 이주해 가야할 곳의 ROWID를 남겨두고 현재 ROWID정보를 가지고있는체 이동하게 된다.
  • 일반 인덱스 스캔에 5~8배 향상 기대
  • 좁은 분포도에서는 같은 단위 클러스터에 속한 로우 수가 적어짐을 의미 일반 인덱스를 사용한 것보다 효과가 떨어질 수 있음
  • 지정된 위치에 저장되어야 하기 때문에 검색을 제외한 모든 경우 부하가 발생

1.3.3 다중테이블 클러스터링

  • 단위 클러스터에 두개 이상의 테이블을 함께 저장하는것.
  • 위 그림에서 클러스터키 컬럼 DEPTNO이다
  • 각 로우는 클러스터키ID를 가지고 있고 블럭헤더에는 클러스터키ID와 클러스터키 정보를 가지고 있다. 따라서 단위클러스터 안에서는 클러스터키 값을 가지고 있을 필요가 없고(회색으로 표시된 값들이 이에 해당함) 실제로 저장되지 않는다.
  • 정규화작업으로 분할된 테이블들을 마치 하나의 테이블처럼 액세스할 수 있다.
  • 제 1정규화작업에 의해서 한테이블에서 별개의 테이블로 분할 된 테이블은 정규화작업 이전에 한레코드에 있어서 액세스 할 수 있었으나 분할 된 후 일일이 키 값을 가지고 조인을 통해 하는 부담이 있고 서로 테이블의 로우가 주변에 모여있다고 확신 할 수도 없다. 이러한 경우 다중 테이블 클러스터링으로 몇 가지 불만이 해소된다.
  • 단점
    • 클러스터링된 테이블간의 연결도 중요하지만 수많은 다른테이블들과의 관계를 맺고자 하는 경우.

1.3.4 클러스터링 테이블의 비용

  • 관계형 데이터베이스의 최대 약점인 넓은 범위 처리를 해결해주고 조인의 효율성을 크게 높여주는 등의 이득이 많지만 그거에 따르는 대가가 필요하다.
  • 클러스터링에게 어떤 역할을 맡길 것인가?
    • 해결해야할 액세스 형태를 모두 수집하고 인덱스로 해결할 수 있는 방안이 있는 강구.
    • 클러스터링 도입으로 인한 부하의 부담도 고려되.
  • 클러스터링에 인한 부하는 어느 정도인가?
    • 클러스터링은 단지 검색의 효율만 높여 줄뿐 입력, 수정, 삭제 시는 추가적인 부하가 발생
  1. 입력(insert)시의 부하
    • 정해진 위치에 저장되어야 하기 때문에 부하가 발생 한다.
    • 일반테이블에 데이터 입력시에는 저장공간을 할당받아 무조건 저장하고 블럭이 PCTFREE에 도달하면 새로운 프리리스트를 요구하여 다른 블럭에 저장
    • 클러스터키 값에 따라 저장위치가 달라지므로 FREELIST요구 횟수가 증가(100개를 저장하려고 할때 최악의 경우 100번의 FREELIST요청)
    • 수십, 수백개 이내의 로우의 경우는 큰 문제가 되지 않으나 수천개 이상의 데이타 입력시 주의해야함.
    • 일반 테이블에서도 인덱스로 인한 입력시 부하가 발생하지만 클러스터링만큼은 아니며 클러스터링을 도입한다면 기존의 인덱스와 클러스터링간의 전략적인 구성으로 인덱스 수는 감소하여야 한다.(그래도 부하는 있다)
  2. 수정(updaet)시의 부하
    • 클러스터키 컬럼의 값을 수정하는 경우 : 변경된 클러스터 키 컬럼의 단위 클러스터 내로 이동해야 하기때문에 부하가 발생하나 이는 일반테이블에서 더이상 로우를 추가 저장 할 수 없어 다른 블럭으로 이주하는 것과 거의 동의하다. 이 말은 곧 클러스터키 수정으로 인해 특별히 더 부하가 있다거나 하지 않다는 것을 의미하며 문제는 동일한 클러스터키 값을 가진 로우가 여러 블럭에 흩어지는 현상이 발생하여 액세스할 블록 수가 증가함으로 원래의 목적이 희석 될 수 있다는 것이다 따라서 수정이 빈번한 컬럼을 클러스터키 컬럼으로 지정하면 좋지 않다.
    • 클러스터키 컬럼이 아닌 일반 컬럼을 수정하는 경우는 일반 테이블 수정과 동일하다
  1. 삭제(delete)시의 부하
    • 클러스터링테이블에 로우를 삭제하더라도 클러스터 인덱스는 그대로 존재하기 때문에 추가적인 처리가 발생하지 않는다.
    • 다만 클러스터링 테이블 DROP시에 내부적으로는 롤백 세그먼트를 받아 데이타를 저장하고 DELETE를 한다. 그 이유는 한 단위 클러스터에 2개의 테이블이 저장되어있다면 단위클러스터의 일부분을 삭제하겠다는 것이 단위 클러스터를 삭제 하려는 것이 아니므로 클러스터 입장에서는 DELETE 할 수 밖에 없다. 이런 작업이 많은 부하를 줄 뿐 아니라 큰 롤백 세그먼트가 필요하게 된다.

1.3.5 해쉬(HASH) 클러스터링

  • 클러스터링이라기 보다 일종의 인덱스를 대신하는 개념
  • 해쉬값을 이용해 테이블의 데이타를 정해진 위치에 저장하고(클러스터링개념) 우리가 원하는 값을 찾아간다(인덱스개념)
  • 아주 특정한 경우에 한정되어 사용됨

  1. 해쉬 클러스터링의 특징
    • SIZE, HASHKEYS, HASH IS 파라미터는 변경 할 수 없다.
    • '='로만 액세스해야 한다.
    • 클러스터가 생성되면서 저장공간이 미리 할당된다.
    • 지정된 단위 클러스터 보다 많은 로우가 들어오면 OVERFLOW영역에 저장된다.
    • 컬럼의 값이 고르게 분포되어 있지 않으면 해쉬키 값의 충돌(COLLISION)이 발생한다.
    • 인덱스를 경유하지 않고 해쉬 함수로 계산된 값으로 직접 테이블 액세스하므로 인덱스보다 효율적인 액세스를 할 수 있다.
  1. 해쉬 클러스터링의 활용 범위
    • 사전에 해쉬키의 개수와 저장공간을 확보해야 하기때문에 지속적으로 대량의 데이타가 증가하는 테이블에는 적용하지 않는 것이 좋다.
    • 내용적으로 항상 '='을 사용하는 경우만 사용 가능
    • 클러스터키 컬럼의 균등한 분포에 적당
    • 대량의 데이터를 해쉬 클러스터에 저장시키고자한다면 해쉬 파티션을 사용하는 것이 옳다.
  2. 해쉬 클러스터의 정의

CREATE CLUSTER[schema.] cluster
(column datatype[,column datatype]...)
HASHKEYS integer
[HASH IS expression]
[PCTFREE interger]
{PCTUSED integer}
[INITRANS interger]
[MAXTRANS integer]
[SIZE interger[K|M]]
[storage_clasue]
[TABLESPACE tablespace]

  • HASHKEYS
    • 해쉬 클러스터를 작성하기 위해 명시
    • 명시하지 않으면 인덱스 클러스터가 기본 값으로 생성
    • 해쉬 키 값의 개수를 지정
    • 소수가 아닐 경우 다음으로 높은 소수로 결정(예 : 100이면 101선택)
    • 최소 값 : 2
  • HASH IS
    • 해쉬 값으로 사용할 컬럼을 지정
    • 클러스터 키는 NUMBER 데이타 타입의 단일 컬럼이어야 함
    • 해쉬 함수를 적용한 결과는 양수이어야 함
    • 사용자 정의 해쉬 함수 사용 가능, 생략시 시스템 내부 함수 사용
  • SIZE
    • 데이타 블록에 할당될 해쉬 키의 수 지정
    • 해쉬 키에 대해 모든 행들을 저장하기 위해 필요한 평균 공간 설정
    • 해쉬 클러스터가 단일 테이블로 구성되고 키 값에 대해 하나의 행만 가지면 SIZE 파라미터는 테이블의 평균 행 크기로 설정
    • 해쉬 클러스터가 단일 테이블로 구성되고 키 값에 대해 여러 개의 행을 가지면 SIZE 파라미터는 키 값에 대해 행의 수를 곱한 크기로 설정
    • 해쉬 클러스터가 복수 개의 테이블로 구성되면 SIZE 파라미터는 해쉬 값과 연관있는 모든 행을 포함하기 위한 평균 공간으로 설정
    • 지나치게 크게 설정하면 낭비되는 공간 증가

문서에 대하여

  • 이 문서는 오라클클럽 대용량 데이터베이스 스터디 모임에서 작성하였습니다.
  • {*}이 문서의 내용은 이화식님의 새로쓴 대용량 데이터베이스 솔루션을 참고했습니다.*
  • 이 문서를 다른 블로그나 홈페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^\^