Cluster Table 구조와 적용: Index Cluster·Hash Cluster

핵심 요약

Table Cluster는 같은 Cluster Key 값을 가진 관련 Row를 같은 Data Block에 물리적으로 함께 저장하는 영구 저장 구조입니다.

일반 Heap Table

DEPT Segment
  deptno=10 Row

EMP Segment
  deptno=10 Row들

Join·조회
  → DEPT Block 접근
  → EMP Index·Table Block 접근

Table Cluster

Cluster Key deptno=10의 Block
  DEPT Row
  EMP Row 1
  EMP Row 2
  EMP Row 3

Join·조회
  → 같은 Cluster Block에서 관련 Row 처리 가능

Oracle의 대표 Cluster 방식입니다.

Index Cluster
  Cluster Key
  → Cluster Index Entry
  → 해당 Key의 Cluster Block·Chain

Hash Cluster
  Hash(cluster_key)
  → Hash Value·Bucket
  → 해당 Bucket Block·Overflow Chain

Cluster는 Join Algorithm이 아닙니다.

Table Cluster
  = Row의 물리 저장 방식

Nested Loops·Hash Join·Merge Join
  = SQL 실행 시 Row Source를 결합하는 Join 방식

이 이론의 범위

이 이론은 SQLP의 SQL 고급활용 및 튜닝 → 인덱스 튜닝 → 테이블 액세스 최소화 범위에서 Index Cluster·Hash Cluster의 저장 구조, 조회 경로, 공간·DML 조건을 다룹니다.

학습 목표

이 이론을 학습한 뒤에는 다음을 설명할 수 있어야 합니다.

• Heap Table과 Table Cluster의 물리 배치 차이를 설명한다.
• Cluster Key와 Primary Key의 역할을 구분한다.
• Index Cluster의 Cluster Index Entry와 TABLE ACCESS CLUSTER를 설명한다.
• Cluster Index의 Unique Scan과 Cluster Key 아래 여러 Row를 구분한다.
• SIZE를 한 Cluster Key의 전체 Row 공간으로 산정하는 이유를 설명한다.
• Hash Cluster의 Hash Value·Bucket·Collision·Overflow를 설명한다.
• HASHKEYS와 초기 공간·Prime Number 조정의 관계를 설명한다.
• Hash Cluster가 등치 조회에 강하고 Range 조회에 불리한 이유를 설명한다.
• Single-Table·Sorted Hash Cluster의 적용 조건을 설명한다.
• Cluster Key Update·Hot Key·Full Scan·빈번한 DML의 위험을 설명한다.
• USER_CLUSTERS와 실행계획·Runtime 통계로 실제 비용을 검증한다.
• Heap Table+Index·IOT·Partitioning 대안과 전체 Workload 비용을 비교한다.

1. Table Cluster의 물리 구조

1.1 Heap Table

일반 Heap Table은 각 Table이 별도 Data Segment를 가집니다.

DEPT Table Segment
EMP Table Segment

같은 deptno의 Parent·Child Row가 물리적으로 같은 Block에 있다는 보장은 없습니다.

SELECT d.deptno,
       d.dname,
       e.empno,
       e.ename
FROM   dept d
JOIN   emp e
  ON   e.deptno = d.deptno
WHERE  d.deptno = :deptno;

일반적인 후보입니다.

DEPT Index·Table Access
→ EMP Index·Table Access
→ Join

1.2 Table Cluster

Cluster에 포함된 Table들은 하나의 Cluster Data Segment를 공유할 수 있습니다.

Cluster Key = deptno

Block Group for deptno=10
  DEPT_C Row
  EMP_C Rows

Block Group for deptno=20
  DEPT_C Row
  EMP_C Rows

Oracle 공식 설명처럼 같은 Cluster Key 값을 가진 여러 Table의 Row를 같은 Block에 저장할 수 있습니다.

이점입니다.

• 관련 Table Join의 Disk·Logical I/O 감소 가능
• Cluster Key 값을 Row마다 반복 저장하는 비용 감소 가능
• 공통 Key 반복 조회의 물리적 근접성

2. Cluster Key와 Primary Key

2.1 Cluster Key

Cluster Key는 Cluster에 속한 Table들이 공유하는 Column 또는 Column 집합입니다.

Cluster Key: deptno

특징입니다.

• 여러 Row가 같은 값을 가질 수 있음
• 여러 Table이 같은 Key를 공유할 수 있음
• Row의 물리 저장 영역을 결정
• 반드시 Row를 유일하게 식별하지 않음

2.2 Primary Key

Primary Key는 한 Table 안의 Row를 유일하게 식별합니다.

DEPT PK: deptno
EMP PK : empno
Cluster Key: deptno

EMP에서는 여러 사원이 같은 deptno를 가질 수 있으므로 Cluster Key와 Primary Key는 다릅니다.

Primary Key
  → 논리적 유일성

Cluster Key
  → 물리 배치 기준

3. Index Cluster

Index Cluster는 B-tree Cluster Index로 Cluster Key가 저장된 Block을 찾습니다.

Cluster Index
  deptno=10 → Cluster Block Address
  deptno=20 → Cluster Block Address

Oracle 공식 구조입니다.

• Cluster Index는 Cluster Key에 대한 B-tree Index
• Cluster Table에 Row를 입력하기 전에 Cluster Index가 필요
• Cluster Index Entry는 Cluster Key 값과 해당 Data Block Address를 연결
• 같은 Key의 여러 Row가 Cluster Block 또는 Block Chain에 저장

3.1 생성 예제

CREATE CLUSTER dept_emp_cluster (
    deptno NUMBER(4)
)
SIZE 2048
INDEX;

CREATE INDEX dept_emp_cluster_ix
ON CLUSTER dept_emp_cluster;

CREATE TABLE dept_c (
    deptno NUMBER(4)    NOT NULL,
    dname  VARCHAR2(30) NOT NULL,
    loc    VARCHAR2(30)
)
CLUSTER dept_emp_cluster(deptno);

CREATE TABLE emp_c (
    empno  NUMBER       NOT NULL,
    ename  VARCHAR2(30) NOT NULL,
    deptno NUMBER(4)    NOT NULL,
    sal    NUMBER
)
CLUSTER dept_emp_cluster(deptno);

3.2 조회 경로

SELECT empno,
       ename
FROM   emp_c
WHERE  deptno = 30;

가능한 실행계획입니다.

TABLE ACCESS CLUSTER EMP_C
  INDEX UNIQUE SCAN DEPT_EMP_CLUSTER_IX

처리 흐름입니다.

1. Cluster Index에서 deptno=30 Entry 탐색
2. Entry가 가리키는 Cluster Block Address 확인
3. 해당 Key의 EMP_C Row 읽기

3.3 Cluster Index의 Unique Scan 해석

INDEX UNIQUE SCAN은 Cluster Key Entry 하나를 찾는다는 뜻입니다.

Cluster Index Entry deptno=30
  → 하나

Cluster Key 30 아래 EMP Row
  → 여러 개 가능

일반 Table의 Unique Index로 최종 Row 한 건을 찾는 의미와 혼동하지 않습니다.

4. Index Cluster의 장점과 한계

장점

• 공통 Cluster Key로 여러 Table을 자주 함께 조회
• 같은 Key의 Parent·Child Row를 가까운 Block에서 처리
• Cluster Index가 Row마다가 아니라 Cluster Key 단위로 Block을 찾음
• B-tree Cluster Index를 이용한 등치 조회
• Cluster Key의 일부 Range 탐색 가능성

한계

• 같은 Cluster Key에 Row가 너무 많으면 Block Chain 증가
• Hot Key에 Insert·Update가 집중되면 Block 경합 가능
• Cluster Key Update 시 다른 Key 영역으로 Row 이동 비용 가능
• Cluster에 없는 조건은 별도 Index 필요
• 빈번한 DML·Full Scan·TRUNCATE 요구에 부적합할 수 있음
• 여러 Table이 같은 Segment를 공유해 공간·운영 분석 복잡

Oracle은 Clustered Table을 주로 조회하고 관련 Row를 자주 함께 사용하는 경우에 고려하며, 빈번한 Update·Full Table Scan·TRUNCATE 요구가 있는 경우에는 일반적으로 부적합하다고 설명합니다.

5. SIZE의 의미

SIZE는 Cluster Key 하나 또는 Hash Value 하나와 연결된 모든 Row를 저장하는 평균 공간을 추정합니다.

CREATE CLUSTER dept_emp_cluster (
    deptno NUMBER(4)
)
SIZE 2048;

산정 요소입니다.

Key당 DEPT Row 수
+ Key당 EMP Row 수
+ 평균 Row 길이
+ Row·Block Overhead
+ 향후 증가 여유

Row 한 건의 크기만 의미하지 않습니다.

5.1 SIZE가 너무 작은 경우

한 Key의 Row 집합이 예상 공간 초과
→ 추가 Block·Chain·Overflow
→ 같은 Key 조회에서 추가 Block I/O

5.2 SIZE가 너무 큰 경우

Key별 과도한 예약 공간
→ Block 내부 미사용 공간
→ Segment 크기 증가
→ Cache 효율 저하 가능

5.3 Indexed Cluster의 SIZE

SIZE를 생략하면 Oracle은 Cluster Key 값당 한 Data Block을 예약하는 방향으로 계산할 수 있습니다. 실제 Row 분포와 Block Size를 기준으로 명시적 산정을 검토합니다.

6. Hash Cluster

Hash Cluster는 별도 Cluster Index 없이 Cluster Key에 Hash 함수를 적용해 Bucket Block을 계산합니다.

cluster_key
→ Hash Function
→ Hash Value
→ Bucket Block Address

CREATE CLUSTER customer_hash_cluster (
    customer_id NUMBER
)
SIZE 1024
HASHKEYS 100003;

CREATE TABLE customer_profile_h (
    customer_id NUMBER        NOT NULL,
    customer_nm VARCHAR2(100) NOT NULL,
    grade_code  VARCHAR2(10)
)
CLUSTER customer_hash_cluster(customer_id);

6.1 조회 경로

SELECT customer_nm,
       grade_code
FROM   customer_profile_h
WHERE  customer_id = :customer_id;

가능한 Plan입니다.

TABLE ACCESS HASH CUSTOMER_PROFILE_H

처리 흐름입니다.

1. customer_id에 Hash 함수 적용
2. Hash Value 계산
3. 대응 Bucket Block 접근
4. 실제 Cluster Key를 확인해 Row 반환

별도의 Cluster Index I/O가 없다는 점이 핵심입니다.

6.2 Hash Cluster에서 Data가 Index 역할

Oracle은 Hash Cluster를 “Data가 Index”인 구조로 설명합니다.

Indexed Cluster
  Cluster Index
  + Cluster Data

Hash Cluster
  Hash 계산
  + Cluster Data
  별도 Cluster Index 없음

7. Hash Cluster가 유리한 조건

Oracle 공식 기준입니다.

• 대부분의 조회가 Cluster Key 등치 조건
• 조회가 DML보다 훨씬 많음
• Table 크기·Key 개수·Key당 공간이 비교적 안정적
• Hash Key 분포가 예측 가능
• Range·정렬 요구가 중요하지 않음

WHERE customer_id = :customer_id

적합도가 낮은 조건입니다.

WHERE customer_id BETWEEN :low AND :high
ORDER BY customer_id

Hash 함수는 원래 Key의 대소·인접 순서를 보존하지 않습니다.

등치
  → Hash Value 직접 계산 가능

Range
  → 중간의 모든 가능한 Key를 Hash할 수 없음
  → 별도 Index가 없다면 Full Scan 가능

8. HASHKEYS와 초기 공간

HASHKEYS는 Hash Cluster가 사용할 Hash Value·Bucket의 수를 지정합니다.

HASHKEYS 100000

Oracle은 Row 분산을 위해 지정값을 가까운 상위 Prime Number로 조정할 수 있습니다.

지정 HASHKEYS 500
실제 Hash Value 수 503 가능

8.1 초기 공간 개념

Hash Cluster는 생성 시 SIZE와 HASHKEYS를 기준으로 필요한 공간을 미리 확보합니다.

개념식입니다.

예상 Hash 저장 공간
  ≈ HASHKEYS × SIZE

실제 Data Block 수는 Block Size·Block Overhead·한 Block에 배치되는 Hash Key 수를 반영합니다.

8.2 HASHKEYS가 너무 작은 경우

실제 Distinct Key > Hash Values
→ 서로 다른 Key가 같은 Hash Value
→ Collision·Overflow Block 증가
→ 등치 조회에서 여러 Block 확인

8.3 HASHKEYS가 너무 큰 경우

사용하지 않는 Bucket·예약 공간 증가
→ 초기 Segment 공간 낭비
→ Cache·Backup 공간 증가 가능

Hash Cluster는 공간을 미리 배치하므로 Key 증가량을 과소·과대 예측하는 비용이 큽니다.

9. Hash Collision과 Overflow

Hash Collision은 서로 다른 Cluster Key가 같은 Hash Value를 얻는 현상입니다.

customer_id=100 → Hash 25
customer_id=725 → Hash 25

Oracle은 Bucket 안에서 실제 Cluster Key를 확인해 올바른 Row를 구분합니다.

9.1 Collision과 여유 공간이 있는 경우

같은 Bucket Block 안에 두 Key Row 저장
→ 한 Block 확인으로 끝날 수 있음

9.2 Bucket이 가득 찬 경우

기본 Bucket Block 가득 참
→ Overflow Block 연결
→ Collision Key 또는 큰 Key Row 집합 저장

조회입니다.

Hash Value 25 계산
→ 기본 Bucket Block 확인
→ Overflow Chain 확인
→ 실제 Cluster Key 비교

Collision과 SIZE 부족이 겹치면 추가 I/O가 커질 수 있습니다.

10. SIZE와 HASHKEYS의 Trade-off

10.1 SIZE 과소

• Key당 Row 집합이 Bucket 공간 초과
• Overflow Block·Chain 증가
• 같은 Key 등치 조회에서 추가 I/O

10.2 SIZE 과대

• Bucket별 미사용 공간 증가
• Segment 초기 할당 증가
• 공간 효율 저하

10.3 HASHKEYS 과소

• 여러 Cluster Key의 Hash Collision 증가
• Overflow 가능성 증가
• Query당 확인 Block 증가

10.4 HASHKEYS 과대

• 실제 사용되지 않는 Hash Value 공간 증가
• 초기 Segment·Backup 공간 부담

Hash Cluster 설계
  = Key 수 예측
  + Key당 Row·Byte 예측
  + Collision 허용 수준
  + 조회 성능과 공간 효율의 Trade-off

Hash Cluster의 SIZE, HASHKEYS, HASH IS를 변경하려면 일반적으로 Cluster를 다시 생성하고 Data를 복사해야 하므로 초기 산정이 중요합니다.

11. Single-Table Hash Cluster

Single-Table Hash Cluster는 한 Cluster에 한 Table만 허용하는 최적화된 Hash Cluster입니다.

CREATE CLUSTER customer_lookup_cluster (
    customer_id NUMBER
)
SIZE 512
SINGLE TABLE
HASHKEYS 500000;

대표 조건입니다.

• 한 Table만 저장
• Hash Key와 Row가 대체로 일대일
• Primary Key 등치 Lookup이 핵심
• Key 수·Row 크기가 안정적

customer_id=:id
→ Hash Bucket
→ 한 Row

SINGLE TABLE Clause는 Hash Cluster에서만 사용할 수 있고 HASHKEYS가 필요합니다.

12. Sorted Hash Cluster

Sorted Hash Cluster는 각 Hash Value에 대응하는 Row를 지정된 Sort Column 순서로 저장합니다.

개념적 예입니다.

Hash Key: telephone_number
Sort Key: call_timestamp, call_duration

CREATE CLUSTER call_detail_cluster (
    telephone_number NUMBER,
    call_timestamp   NUMBER SORT,
    call_duration    NUMBER SORT
)
HASHKEYS 10000
HASH IS telephone_number
SIZE 256;

장점입니다.

전화번호 등치로 Bucket 접근
→ Bucket 안의 통화 Row를 시간 순서로 읽기
→ 반복 Sort·Logical I/O 감소 가능

적합 조건입니다.

• Hash Key 등치 조회
• 해당 Key의 Row를 항상 특정 순서로 소비
• Key당 Row 수·공간을 예측 가능

일반 Hash Cluster가 모든 Range·정렬을 지원한다는 뜻은 아닙니다. Sort 기능은 Bucket 내부의 지정된 Sort Column에 한정해 설계합니다.

13. Index Cluster와 Hash Cluster 비교

14. Cluster Key Update와 DML

14.1 Cluster Key Update

Cluster Key는 Row의 물리 저장 영역을 결정합니다.

deptno 10 → 20 Update

기존 Key 10 영역
  → Row 제거

새 Key 20 영역
  → Row 저장

Cluster Key 변경은 일반 Non-Key Column Update보다 Row 이동·Block 관리·Redo·Undo 비용이 커질 수 있습니다.

14.2 Hot Key

한 Cluster Key에 Insert 집중
→ 같은 Cluster Block·Chain에 동시 접근
→ Block 경합·Chain 증가 가능

예시입니다.

• 모든 미처리 Job이 status='READY'
• 특정 Tenant에 Traffic 집중
• 하나의 인기 상품·계정에 Child Row 집중

14.3 Full Scan·TRUNCATE·운영

여러 Table이 같은 Cluster Segment를 공유하므로 Table별 독립 운영이 제한될 수 있습니다.

• Full Scan 중심 업무는 Cluster 물리 배치 이점이 작음
• 빈번한 Update는 Block·Chain 유지비 증가
• Clustered Table의 Truncate 요구는 구조상 제약·운영 복잡성 증가
• Backup·Move·Rebuild·Space 분석이 Heap Table보다 복잡

15. Data Dictionary 확인

SELECT cluster_name,
       cluster_type,
       function,
       hashkeys,
       key_size,
       single_table,
       tablespace_name
FROM   user_clusters
WHERE  cluster_name IN (
    'DEPT_EMP_CLUSTER',
    'CUSTOMER_HASH_CLUSTER'
);

대표 해석입니다.

CLUSTER_TYPE = INDEX
  → Indexed Cluster

CLUSTER_TYPE = HASH
  → Hash Cluster

HASHKEYS
  → Hash Value·Bucket 수

KEY_SIZE
  → Cluster Key 크기 관련 정보

SINGLE_TABLE
  → Single-Table Hash Cluster 여부

Cluster Column 매핑입니다.

SELECT cluster_name,
       table_name,
       tab_column_name,
       clu_column_name
FROM   user_clu_columns
WHERE  cluster_name = 'DEPT_EMP_CLUSTER';

Hash Function을 명시했다면 다음 계열 View도 확인할 수 있습니다.

USER_CLUSTER_HASH_EXPRESSIONS

16. 실행계획과 Runtime 검증

16.1 Index Cluster

TABLE ACCESS CLUSTER EMP_C
  INDEX UNIQUE SCAN DEPT_EMP_CLUSTER_IX

확인합니다.

• Cluster Index Starts·A-Rows·Buffers·Reads
• TABLE ACCESS CLUSTER A-Rows·Buffers
• Key당 Row 수
• Cluster Block Chain 길이
• 같은 Key의 여러 Table Join I/O
• Hot Key 동시성

16.2 Hash Cluster

TABLE ACCESS HASH CUSTOMER_PROFILE_H

확인합니다.

• 등치 Access Predicate
• A-Rows·Buffers·Reads
• Bucket·Overflow Block 수
• Collision Key 조회의 추가 I/O
• Range 조건에서 Full Scan 전환 여부

16.3 동일 Workload 비교

Heap Table + B-tree Index
Index Cluster
Hash Cluster
IOT

동일하게 맞춥니다.

• SQL 결과
• Bind 값·Data Type
• Fetch 범위
• Data 규모·분포
• Cache·동시성
• Statistics
• DML 비율

측정합니다.

• Starts·A-Rows
• Buffers·Reads
• CPU·Elapsed·P95
• Segment Blocks·Used Space
• INSERT·UPDATE·DELETE TPS
• Redo·Undo
• Block Chain·Collision
• Lock·Hot Block

17. 적용 판단 절차

1. 함께 조회하는 Table과 공통 Key를 식별한다.
2. Cluster Key가 실제 Join·Lookup Predicate인지 확인한다.
3. Key당 Row 수·Byte·증가량을 계산한다.
4. 등치·Range·정렬·Full Scan 비율을 분류한다.
5. Index Cluster·Hash·Single-Table·Sorted Hash 후보를 구분한다.
6. SIZE·HASHKEYS·Collision·Overflow를 운영 최대치로 산정한다.
7. Cluster Key Update·Hot Key·동시 DML을 평가한다.
8. Heap+Index·IOT·Partitioning과 Runtime 비용을 비교한다.
9. 실제 규모로 Buffers·Reads·P95·Space·Redo를 반복 측정한다.
10. 재생성·Data 이동·Rollback 계획을 포함해 적용한다.

자주 혼동하는 판단