by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

3.클러스터링의 활용




I. Overview


1. Clustering factor


Fig 1. Clustering Factor


  1. 정의 
    ① 데이터가 테이블 전체에 무작위로 분산된 정도. 즉 테이블 내 데이터의 흩어진 정도를 숫자로 표시
    ② 인덱스를 스캔하는 동안 방문(access)하는 테이블의 데이터 블록의 개수
  2. 좋은 clustering factor : 인덱스 키의 순서가 테이블 row의 순서와 비슷
  3. 나쁜 clustering factor : 인덱스 키의 순서가 테이블 row의 순서와 맞지 않은 정도가 심함
  4. 정렬 계수(sort factor)가 아님 : 거의 정렬된 채로 rows 간에 서로 근처에 모여(군집)있기만 하면 됨
  • 인덱스와 테이블의 정렬 순서가 반드시 일치하지 않아도 서로 모여있는 정도가 같으면 clustering factor가 좋음

    Fig 2. Table and Index Order
    【 출처 : CBO Fundamentals(Chapter 4) 】


2. Cluster

  1. 정의 : 하나이상의 테이블 그룹이 같은 데이터 블록을 공유해서 저장하는 방법

    |align=center!
    Fig 3. Clustered Table Data
    【 출처 : http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/clustrs.htm#ADMIN018

  2. 장점
    ① 공유 column(조인의 연결고리)이 있는 테이블을 cluster화하여 수행속도를 향상
    ② Disk I/O감소 : cluster된 테이블의 조인 시 접근 시간이 단축됨
    ③ 저장 공간 절약 : 각각의 cluster key 값은 cluster(cluster 인덱스 포함)에 한번만 저장되므로 저장공간이 절약

  3. 특징
    ① 지정된 column값의 순서대로 row를 저장시키는 방법 : Random access의 감소를 위해 정해진 column을 기준으로 동일한 값을 가진 하나 이상의 테이블의 row를 같은 장소에 저장
    ② 하나 혹은 그 이상의 테이블을 같은 cluster내 저장 가능
    ③ access 기법이 아니라 access 효율향상을 위한 물리적 저장기법
    ④ 검색의 효율을 높여주나 입력, 수정, 삭제 시는 부하 증가
    ⑤ 분포도가 넓을 수록 오히려 유리 : 분포도가 넓은 테이블의 clustering은 오히려 저장공간 절약
    ⑥ clustering 인덱스는 clustering column의 값마다 하나씩의 인덱스 row를 가짐
    ⑦ clustering의 효과는 clustering factor와 비례관계 

  4. cluster 구성 순서 : cluster 생성 → cluster 테이블 생성 → cluster 인덱스 생성 → 테이블에 삽입(insert)수행
    • 에러 메시지 : ORA-02032 CANNOT INSERT INTO CLUSTERED TABLE (MetaLink : 1044389.6)

  5. 선정 기준
    ① 6 블록 이상의 테이블
    ② 다량의 범위를 자주 access 해야 하는 경우
    ③ 인덱스를 사용한 처리가 부담이 되는 넓은 분포도
    ④ 여러 개의 테이블이 빈번한 조인을 일으킬 때
    ⑤ 반복 column이 정규화 작업에 의해 어쩔 수 없이 분할된 경우
    ⑥ UNION, DISTINCT, ORDER BY, GROUP BY 가 빈번한 column이면 고려해 볼 것
    ⑦ 수정이 자주 발생하지 않는 column

  6. 고려사항
    ① 데이터 처리(입력, 수정, 삭제)에 오버헤드 발생주의
    ② 인덱스로도 충분한 범위는 clustering 효과가 없음
    ③ cluster key는 수정이 빈번하지 않을 것
    ④ 각종 access 형태에 대해 인덱스와 적절한 역할 분담
    ⑤ clustering은 기존의 인덱스의 수를 감소시킴(인덱스 재구성)
    ⑥ cluster parameter 의 적절한 지정
    ⑦ cluster key 별 row 수의 편차가 심하지 않을 것
    ⑧ cluster에 데이터 입력 시 row가 적은 테이블부터 실시할 것
    ⑨ clustering 된 테이블 조인 시 row 수의 역순으로 FROM 절에 기술할 것
    ⑩ cluster key를 첫 번째로 하는 인덱스는 생성하지 말 것 

  7. Cluster Parameter
    ① Size : cluster 의 크기 지정
    ② Storage : 저장공간의 효율적인 활용
    ③ PCTUSED & PCTFREE : chain 감소
    ④ PCTFREE : row의 길이 증가를 대비하기 위해 여유공간(Free Space) 지정

  8. Cluster table sizing 

II. Single-clustering

- 처리범위가 넓어 문제가 발생되는 경우는 단일 테이블 clustering

- 한 block을 초과하는 경우가 대부분 : row chain여부와 상관없이 하나 이상의 chain block을 가짐 

III. Multi-cluster

- 조인이 많아 문제가 발생되는 경우는 다중 테이블 clustering 

- 실행계획

【 SQL 】 【 실행계획 】
SELECT ...............
FROM  emp e,dept d
WHERE e.deptno = d.deptno
AND d.deptno like '11%';
SELECT STATEMENT   
 NESTED LOOPS
②TABLE ACCESS (CLUSTER) OF 'DEPT'
①  INDEX (RANGE SCAN) OF 'DEPT_CLUSTER_IDX' (CLUSTER)
③TABLE ACCESS (CLUSTER) OF 'EMP'


IV. Clustering table 비용

- 검색의 효율은 높여주나, 입력 - 수정 - 삭제 시 부하 발생

  1. 입력 시 부하
    1) SORT된 대상은 입력부하 감소
    2) 일반 인덱스에 저장은 분리형과 동일 : 일반 인덱스도 정해진 위치에 저장
    3) Cluster Key Value에 따라 정해진 위치에 저장
    4) 각 rows에 따라 저장 위치가 달라지므로 free list 요구 횟수 증가
    5) 테이블에 저장되는 시간은 일반 테이블에 비해 더 소요되지만 인덱스의 개수가 감소되어 전체적으로 소요되는 시간은 큰 차이 없음

  2. 수정시의 부하
    1) Cluster Key Value 변경 : 기존 rowid를 변경하지 못하므로 cluster chain이 발생
    2) Cluster Key Value가 아닌 경우 : 일반 테이블과 동일
    3) 새로운 INSERT가 발생하는 개념
    4) 아주 빈번하지 않는다면 큰 부하는 없음
    5) Clustering factor가 나빠지므로 필요할 경우 정기적인 재생성 수행
    6) Row chaining
    ⓐ 단일 테이블 상의 특정 Row의 길이가 증가해서 더 이상 동일한 데이터 block에 들어갈 수 없을 때 발생
    ⓑ 이때 RDBMS는 또 다른 데이터 block을 찾고, 이 데이터 block은 원래 block과 연결되어 있음
    ⓒ 이 경우 데이터 block이 하나의 I/O 작업과 동일한 양을 수행하기 위해 두 개의 I/O를 사용해야 함
    ⓓ 데이터베이스 성능 저하의 원인

  3. 삭제 시의 부하
    1) Delete
    ① 테이블의 row삭제 후 인덱스 row삭제 : 인덱스 개수가 적다면 일반 테이블보다 유리할 수 있음
    2) Drop
    ① DDL이지만 Rollback Segment 사용- cluster에는 하나 이상의 테이블이 있는데, 이들이 독립적인 테이블로 존재하는 것이 아니라 cluster 내의 row로 존재하므로, Drop은 row 일부를 제거하는 것과 유사하므로 Delete 개념이 됨
    ② 심각한 부하 발생 우려
    ③ clustering factor 악화
    ④ Drop 대신 재생성할 것
    ⑤ truncate : Cluster Index Data를 삭제하지 않음
    ⑥ 일반 인덱스에 비해 부하가 동일하거나 감소
    ⑦ 참고 : http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_10006.htm#SQLRF01707

    • Row Migration
      ⓐ Data Block상의 하나의 Row는 길이가 증가하면서 갱신되며, Block의 Free space가 0%일 때, Row Migration(이주) 발생
      ⓑ 전체 Row가 들어갈 만한 크기의 새로운 Block에 Row에 대한 Data가 Migration 됨
      ⓒ 이 경우 ORACLE은 Row에 대한 정보를 가져오기 위해 하나 이상의 Data Block을 반드시 읽어야 하므로 I/O Perfmance는 감소
    • Clustering 테이블에서 row chaining
      ⓐ 전제 : General table column = clustering table row
      ⓑ Clustering 테이블에서 row chaining은 column의 길이 증가를 의미 = row의 증가
      ⓒ Cluster size 초과 no : chain block은 cluster key column에 따라 부여 받고, 같은 key value를 가진 rows은 같은 chain block에 저장되므로 일반 테이블보다는 적은 chain block을 가지므로 영향은 적음

V. Hash Clustered Table


  1. 특징
    1) Cluster Index를 사용하지 않고 hash 함수를 사용하여 table access
    2) "="로만 access
    3) 코드를 관리하는 소형 테이블, 우편번호, 시스템 사용자 정보를 관리하는 테이블에 활용

About Doc.

  • 최초작성자 : 박혜은
  • 최초작성일 : 2009년 2월 21일
  • 이 문서는 오라클클럽 대용량 데이터베이스 스터디 모임에서 작성하였습니다.
  • 이 문서의 내용은 이화식님의 대용량 데이터베이스 솔루션1과 Jonathan Lewis 의 CBO Fundamentals를 참고했습니다.

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.