1.3. 클러스터링 테이블

1.3. 클러스터링 테이블
- 분리형 : Random Access 발생

- 일체형 : 다양한 Access 지원에 대한 부담

- 처리할 절대 범위가 넓을 경우 인덱스만으로 해결 불가


1.3.1. 클러스터링 테이블의 개념
- 저장 공간을 지닌 Object로 Table의 상위 개념

- Multi Table Clustering (공단의 비유)

- Single Table Clustering (창고의 비유)

- 정해진 컬럼값을 기준으로 동일한 값을 가진 하나 이상의 테이블의 로우를 같은 장소에 저장하는 물리적 기법

- Clustering Factor : 액세스하려는 데이터들의 모여있는 정도로 물리적 액세스 양을 결정


1.3.2. 단일테이블 클러스터링
- 단위 클러스터에 하나의 테이블만 생성

- 클러스터 인덱스는 클러스터키 컬럼값에 단 하나만 존재하며 클러스터 스캔에 사용

- 클러스터키 값 : 동일한 클러스터키 값은 단 한번만 저장됨
 로우에는 클러스터 키 ID만 저장
 블록 헤더에 클러스터기 ID와 클러스터키 값 저장 (다중테이블 클러스터링과 동일)

- 클러스터키 변경시 row migration과 동일하게 row 위치만 이동하고 이주한 rowid를 기존 위치에 남김
 row 길이 증가나 새로운 row의 입력으로 여러 블록에 걸쳐 데이터를 저장하는 row chaining 발생

- 클러스터 인덱스를 한번 액세스하여 여러 건의 테이블 row를 한번에 스캔하므로 random access 감소

- 분포도
 분포도가 좁은 컬럼을 클러스터링하면 단위 클러스터의 row 수가 적어 일반 인덱스 스캔과 차이 없음
 분포도가 넓어야 한번의 클러스터 인덱스 스캔으로 액세스하는 row의 수가 많아지게 되어 더 효율적임

- 지정된 위치를 찾아 저장해야하므로 추가적인 부하 발생


1.3.3. 다중테이블 클러스터링
- 단위 클러스터에 두개 이상의 테이블을 함께 저장 (조인 속도 향상)

- 단위 클러스터에는 동일한 클러스터키 값을 저장할 필요 없음
 각 row에 클러스터키 ID만 저장 / 블록 헤더에 클러스터키 정보 저장

- 지역적 투명성
 같은 클러스터 내에서도 테이블 간의 독립성 보장
 각각의 테이블을 별도 액세스 가능 / 테이블의 고유 인덱스 생성 가능

- 효율적인 테이블 간의 조인
 제1 정규화에 의해 분할된 테이블을 하나의 테이블처럼 연결시켜줌
 random access 감소 : join 값을 클러스터키로 지정하여 여러 개의 테이블을 같은 블록에 저장

- 클러스터링 도입으로 테이블의 유연성은 훼손됨
 효율적으로 조인할 수 있는 방법을 찾아볼 것!


1.3.4. 클러스터링 테이블의 비용
- 클러스터링의 역할
 액세스 형태를 모두 수집, 분석하여 적은 비용이 드는 인덱스로 해결하도록 노력

- 입력시의 부하
 클러스터키 값에 따라 저장 위치가 달라짐
 키 값이 다를 경우 여러개의 블록에 따로 저장될 수 있음
 일반 테이블의 경우, 값이 다르더라도 같은 블록에 한꺼번에 저장되는 것과 비교됨
 일반 테이블이라도 여러개의 인덱스가 존재할 경우 위치 선정에 따른 부하가 발생
 클러스터링 도입으로 인덱스의 개수가 줄어든다면 부하 증가의 염려를 줄일 수 있음

- 수정시의 부하
 클러스터키 컬럼값의 수정시 row migration 발생하여 clustering factor 저하
 클러스터키 컬럼이 아닌 데이터의 수정은 일반 테이블의 수정과 동일하여 추가적인 부하가 없음
 수정이 빈번한 컬럼을 클러스터키 컬럼으로 지정하지 않도록 할 것

- 삭제시의 부하
 클러스터링 테이블의 모든 row를 삭제하더라도 인덱스는 그대로 존재함
 테이블 drop의 경우 row를 제거하는 것이지 단위 클러스터를 제거하는 것이 아님
 따라서, delete를 수행하게 되어 많은 부하가 발생하게 됨
 새로운 클러스터에 데이터를 생성하고 rename하는 방법이 바람직함

- DROP CLUSTER cluster_name
  INCLUDING TABLES
  CASCADE CONSTRAINTS;
 제약조건, 테이블, 사전 정보 모두 삭제

- TRUNCATE CLUSTER cluster_name REUSE STORAGE;
 현재 저장공간과 사전 정보를 유지하고자 할 때 유용함


1.3.5. 해쉬 클러스터링
- 해쉬 클러스터링의 특징
 SIZE, HASHKEY, HASH IS 파라미터는 변경 불가
 = 조건의 액세스만 가능
 클러스터 생성시 저장공간이 미리 할당됨
 단위 클러스터보다 많은 row가 입력시 overflow 영역에 저장
 컬럼값이 고르게 분포되지 않을 경우 해쉬키 값의 충돌 발생
 해쉬 함수로 계산된 값으로 직접 테이블 액세스 (인덱스보다 효율적)

- 활용 범위
 데이터의 증가가 없는 테이블에 적용 (해쉬키의 개수는 변경 불가)
 = 조건을 사용하는 경우에만 적용
 클러스터키 컬럼의 값이 균등한 경우에만 사용 (overflow, 키 값 충돌 방지)
 코드 관리 테이블, 우편번호, 사용자 정보 관리 테이블에 활용 가능
 해쉬 파티션 : 해쉬 클러스터링의 발전된 개념으로 대량의 데이터 저장시에 적합함

- HASHKEYS : 해쉬키 값의 개수로 지정한 값보다 큰 소수가 적용됨
 초기 저장공간을 할당하는데 적용됨

- HASH IS : 해쉬함수를 지정함
 클러스터키 값이 다르면 해쉬값도 최대한 달라지도록 할 것! (overflow 방지)
 해쉬 함수를 적용한 결과는 양수여야 함
 적용할 때마다 결과값이 변하는 것(SYSDATE,ROWNUM 등)을 제외한 SQL 수식 사용
 사용자 정의 함수를 해쉬 함수의 일부로 사용할 수 없음

- SIZE : 단위 클러스터의 크기 지정
 DB_BLOCK_SIZE 보다 클 경우 O/S의 블록 크기를 사용
 미지정시 하나의 데이터 블록을 단위 클러스터에 할당
 USER_CLUSTERS에 있는 KEY_SIZE 컬럼을 참조할 것

- Overflow 방지를 위해 SIZE 값은 약간 여유있게 지정할 것

- 단일테이블 해쉬 클러스터
 단 하나의 테이블만 클러스터에 저장 => 효율적인 액세스 가능