[바미] 새로 쓴, 대용량 데이터 베이스 솔루션 Vol.1 - 1장 데이터 저장구조와 특징

들어가기 전에..

해당 글은 새로 쓴 대용량 데이터 베이스 솔루션 책을 공부한 내용을 정리하였습니다.

새롭게 안 사실들

PK와 FK의 개념 재적립

• PK는 각 테이블의 고유한 식별자 역할을 하는 컬럼
• FK는 테이블 간의 관계를 정의하기 위해 사용되는 컬럼

DB도 임의의 위치에 저장된다.

프로그래밍 언어의 변수만 임의의 위치에 저장되는 줄 알았는데 분리형 테이블에서 데이터가 저장될 때 '임의의 위치'에 저장된다는 것을 새롭게 알게 되었다. 

분리형 테이블에 사용되는 주요 개념들

데이터 블록

데이터를 저장하는 가장 기본 단위로, Block은 논리적이지만 디스크에 물리적으로 매핑되며 데이터 삽입 시 빈 공간(Free Space)이 있는 블록을 찾아 데이터를 저장하게 된다.

프리 리스트(Free List)

블록이 새 데이터를 저장할 수 있는 여유 공간을 관리하는데 데이터를 삽입할 때 프리 리스트에 있는 블록을 참조하여 빈 공간이 있는 블록에 데이터를 저장한다.

ROWID

데이터가 테이블스페이스 내의 위치를 나타내는 식별자이다. Object ID, 파일 번호, 블록 번호, 슬롯 번호로 구성되며, 이를 통해 물리적으로 데이터의 위치를 찾을 수 있다.

분리형 테이블 저장 방식

분리형 테이블은 데이터를 주 테이블(Main Table)과 세부 테이블(Detail Table)로 나누어 저장하며, 각 테이블의 물리적 저장 방식이 핵심이다.

 

먼저, 데이터를 삽입할 때 프리 리스트(Free List)에서 빈 공간이 있는 블록을 탐색하게 된다. 블록에 여유 공간이 있으면 데이터를 저장하고, 블록 헤더에 데이터의 위치를 기록하게 된다.

그 다음, 데이터는 슬롯(Slot) 단위로 블록에 저장되며, 각 슬롯은 ROWID를 통해 참조된다. 데이터를 삽입하거나 삭제할 경우, 블록 내부의 여유 공간(Free Space)이 동적으로 조정된다.

주 테이블에는 핵심 데이터가 저장되고, 세부 테이블에는 추가적인 데이터가 저장된다. 두 테이블은 Foreign Key(FK)를 통해 논리적으로 연결되며, 필요 시 JOIN 연산을 통해 데이터를 결합한다.

마지막으로, 데이터가 삭제되면 블록에 빈 공간이 생기게 되는데 이 빈 공간은 Free List에 등록되어 재사용되지만, 일정 수준 이상의 단편화(Free Space Fragmentation)가 발생하면 블록 재정렬(Condensing)이 필요할 수 있다.

클러스터링 팩터(Clustering Factor)에 대하여

규모에 따른 테이블 엑세스 처리 방안들

해시 클러스터링

---

공부한 내용들

제 1장 데이터 저장구조와 특징

1.1 테이블과 인덱스의 분리형

• 테이블과 인덱스를 분리하는 이유는 데이터베이스 성능과 효율성을 극대화하기 위함이다.
• 데이터는 테이블에 저장되지만, 인덱스는 별도로 관리되어 테이블 데이터에 빠르게 접근할 수 있도록 돕는다.
• 테이블과 인덱스가 논리적으로 연결되어 있지만, 물리적으로는 독립적으로 저장되어 관리된다.
• 이 구조를 통해 데이터 접근 비용을 줄이고, 성능 저하를 최소화할 수 있다.

1.1.1 분리형 테이블의 구조

• 분리형 테이블의 개념
  • 데이터를 주 테이블(Main Table)과 세부 테이블(Detail Table)로 나누어 저장하는 방식이다.
  • 주 테이블 - 핵심 데이터를 저장.
  • 세부 테이블 - 부가적인 데이터를 저장하며 Foreign Key(FK)를 통해 주 테이블과 연결된다.
• 데이터 저장 과정
  • 데이터는 프리 리스트(Free List)에서 빈 블록을 찾아 저장된다.
  • 저장된 데이터는 슬롯(Slot) 단위로 관리되며, 각 슬롯의 물리적 위치는 ROWID를 통해 참조된다.
  • ROWID는 Object ID, File 번호, Block 번호, Slot 번호로 구성되어 데이터의 위치를 빠르게 찾을 수 있다.
• JOIN 연산을 통한 결합
  • 주 테이블과 세부 테이블에 나누어 저장된 데이터는 필요 시 JOIN 연산을 통해 결합된다.
  • 이를 통해 데이터 중복을 최소화하고 저장 공간을 효율적으로 사용한다.
• 단편화와 최적화
  • 데이터 삭제 시 블록 내부에 빈 공간이 생기고, 이는 Free List에 등록되어 재사용된다.
  • 단편화(Fragmentation)가 심해지면 블록 재정렬(Condensing)을 통해 최적화할 수 있다.

1.1.2 클러스터링 팩터(Clustering Factor)

클러스터링 팩터(Clustering Factor)는 인덱스의 논리적 순서와 데이터의 물리적 저장 순서가 얼마나 일치하는지를 나타내는 지표이다.

• 낮은 클러스터링 팩터 - 데이터의 논리적 순서와 물리적 순서가 일치해 연속된 블록에서 데이터를 읽을 수 있다. 성능이 최적화된다.
• 높은 클러스터링 팩터 - 데이터의 논리적 순서와 물리적 순서가 불일치하여 여러 블록에 걸쳐 데이터를 읽어야 한다. 성능이 저하된다.

클러스터링 팩터와 인덱스 성능

• 인덱스 스캔
  • 클러스터링 팩터가 낮으면 범위 검색 시 인접한 데이터가 한 번의 블록 접근으로 읽히므로 I/O 비용이 줄어든다.
  • 반면 클러스터링 팩터가 높으면 인덱스를 통해 데이터를 찾아도 랜덤 I/O가 많아져 성능이 저하된다.
• 인덱스와 테이블의 구조적 차이
  • 인덱스는 키 값의 순서대로 저장되지만, 테이블의 데이터는 물리적 공간에 저장된다.
  • 테이블의 데이터가 순서대로 저장되지 않으면, 인덱스가 가리키는 데이터가 여러 블록에 흩어져 클러스터링 팩터가 높아진다.

최적화 방법

• 데이터 재정렬
  
  • 테이블 데이터를 인덱스 키 순서대로 재정렬하면 클러스터링 팩터를 낮출 수 있다.
• 단편화 최소화
  • 데이터 삽입, 삭제 과정에서 발생하는 단편화(Fragmentation)를 줄이는 전략이 필요하다.

1.1.3 분리형 테이블의 엑세스 영향요소

• 넓은 범위의 엑세스 처리에 대한 대처방안
  • 소형 테이블 - 데이터가 작아서 블록 수가 적기 때문에 빠르게 처리 가능. 테이블 전체를 스캔하는 경우에도 성능 부담이 적음.
  • 중형 테이블 - 블록 수가 늘어나며 성능 저하가 발생할 수 있음. 인덱스를 활용해 엑세스를 최적화하고 불필요한 전체 스캔을 줄이는 것이 중요함.
  • 대형 테이블 - 데이터 양이 많아지면서 엑세스 부하가 커짐. 병렬처리(Parallel Processing)나 파티션을 활용해 데이터 분산 처리하는 것이 필요함.
• 클러스터링 팩터 향상 전략
  클러스터링 팩터는 데이터가 인덱스 순서와 테이블의 물리적 저장 순서가 얼마나 일치하는지를 나타냄. 클러스터링 팩터가 낮을수록 엑세스 성능이 향상됨.
  • 전략 - 데이터를 재정렬하거나 재구성하는 방식으로 클러스터링 팩터를 개선해 인덱스 엑세스 효율을 높임. 주기적으로 테이블을 재구성(Condensing)하는 것이 필요함.

1.2 인덱스 일체형 테이블(Index-Organized Table)

인덱스 일체형 테이블은 데이터가 인덱스 구조에 직접 저장되며, B-Tree 인덱스를 활용해 데이터를 관리함. 이를 통해 테이블 데이터와 인덱스를 하나로 결합하여 성능을 개선함.

1.2.1 분리형과 일체형의 비교

• 분리형 테이블 - 테이블과 인덱스를 별도로 관리하며 구조적으로 유연함. 대규모 데이터 처리에 적합하지만 엑세스 비용이 높음.
• 일체형 테이블 - 인덱스와 데이터를 결합해 빠른 엑세스를 제공하지만, 구조가 제한적이며 LOB 데이터 처리가 어려움.

1.2.2 일체형 테이블의 구조 및 특징

일체형 테이블은 기존 B-Tree 인덱스와 달리 ROWID를 사용하지 않는다. 이는 테이블과 인덱스가 통합된 구조로, 데이터 접근 시 인덱스에서 ROWID를 찾아 테이블 데이터를 참조할 필요가 없기 때문이다. 이러한 구조의 장점은 논리적 접근 횟수가 줄어들고, 

B-Tree 인덱스를 통해 인덱스 탐색 후 스캔하는 과정을 단축할 수 있다는 점이다. 

하지만 소량의 랜덤 액세스에는 효율적이지 않으며, 넓은 범위의 스캔 작업에서 효과적으로 동작한다.

또한, 인덱스와 데이터가 동일한 블록에 저장되므로 인덱스를 스캔하는 경우에도 효율성이 높아진다. 

하지만 기존 B-Tree 인덱스가 제공하는 추가적인 인덱스 생성 기능(Secondary Index)을 사용할 수 없다는 제한이 있다. 

이는 사용 범위를 특정한 상황으로 제한하게 만든다. 따라서 일체형 테이블은 데이터를 기본키로 액세스하거나 넓은 범위의 데이터를 효율적으로 관리하고자 할 때 적합하다.

1.2.3 논리적 ROWID와 물리적 주소 (Physical Guess)

일체형 테이블은 물리적 주소를 통해 데이터 위치를 직접 참조할 수 없기 때문에 논리적 ROWID를 사용한다. 이는 물리적 주소를 대체하며, 기본키를 사용해 데이터를 구분하고, 인덱스를 통해 데이터를 빠르게 검색하는 데 활용된다. 논리적 ROWID는 B-Tree 인덱스의 리프 노드(Leaf Node)에서 데이터를 참조하며, 키 값의 변화로 인해 데이터 위치가 변경되지 않도록 설계되었다.

물리적 주소 정보는 데이터 블록의 위치를 추정하는 데 활용되며, 이를 Physical Guess라고 한다. 추가적인 인덱스를 사용하는 경우, 물리적 주소를 참조해 데이터 블록을 액세스한 뒤 기본키 정보를 확인해 데이터의 정확성을 검증한다. 만약 물리적 추정치의 정확도가 낮다면 기본키를 통해 액세스를 시도할 수 있다.

물리적 위치정보의 사용 여부와 일체형 구조 적용 상황

• 물리적 위치정보를 사용하지 않는 경우
  • 추가 인덱스를 액세스하며 기본키 정보를 통해 데이터에 접근한다.
  • 기본키를 활용해 데이터 블록을 액세스하는 방식이다.
• 물리적 위치정보를 사용하는 경우
  • 물리적 위치정보를 통해 블록을 참조한 뒤, 기본키를 검증해 정확한 데이터에 접근한다.
  • 물리적 정보가 부정확하다면 기본키 기반의 액세스로 전환한다.

일체형 구조가 적합한 경우

• 키워드 검색용 테이블
• 전자 카탈로그 테이블
• OLAP의 디멘션 테이블
• 데이터가 기본키를 기반으로 검색되거나, 트랜잭션이 빈번하지 않은 테이블 

이와 같은 상황에서 일체형 구조는 물리적 위치정보를 활용하거나 논리적 ROWID로 데이터를 효율적으로 관리할 수 있다.

1.2.4 오버플로우 영역 (Overflow Area)

오버플로우 영역의 개념

인덱스와 모든 컬럼이 같은 장소에 위치하여 로우를 액세스하는 방식은 이상적이나, 저장 공간의 분할 또는 밀도가 나빠지는 경우 로우 길이가 길어지고 데이터의 부하가 증가할 수 있다. 이를 해결하기 위해, 적절한 컬럼을 분리하여 오버플로우 영역에 분산 저장함으로써 액세스 효율성을 높이는 방법을 제안함.

오버플로우 영역의 사용 목적

로우 길이가 길어질수록 발생하는 부하를 줄이기 위해, 일부 컬럼을 오버플로우 영역에 저장하여 인덱스와 분리된 공간을 마련한다.

• PCTTHRESHOLD - 로우 길이와 블록 크기를 기준으로, 특정 임계치를 초과하는 컬럼은 오버플로우로 이동시킨다.
• INCLUDING - 기준 컬럼을 설정하여, 해당 컬럼 이후부터는 오버플로우 영역에 저장하도록 지정한다.

효율적 활용 방안

• 로우 체인이 발생할 가능성을 낮추고, 액세스 성공률을 높인다.
• 리프노드의 저장밀도를 최적화함으로써 인덱스와 오버플로우 영역 간의 전략적 구분으로 효율성을 강화한다.

1.2.5 일체형 테이블의 생성

구성 요소 및 생성 문법

일체형 테이블은 아래와 같은 파라미터로 정의된다. (Oracle Database에서만 지원되는 고유한 기능임.)

• ORGANIZATION INDEX - 일체형 테이블 생성 명령.
• TABLESPACE - 인덱스 및 오버플로우 데이터가 저장될 테이블스페이스.
• PCTTHRESHOLD - 로우 길이와 블록 크기를 기준으로, 특정 임계치 초과 시 데이터를 오버플로우로 이동.
• INCLUDING - 기준 컬럼을 설정하여 오버플로우 영역에 저장할 컬럼 범위를 지정.
• OVERFLOW TABLESPACE - 오버플로우 영역의 데이터를 저장할 별도 테이블스페이스 지정.

설정 시 고려사항

• INCLUDING을 활용하여, 특정 컬럼 이후의 데이터를 오버플로우로 이동시킴으로써 인덱스와 데이터의 분리를 최적화.
• PCTTHRESHOLD 값을 설정해 저장 밀도를 조정하며, 과도한 체인 발생을 방지.
• 오버플로우 테이블스페이스는 데이터의 분산 저장을 가능하게 하며, 별도의 저장 공간을 설정할 수 있다.

전략적 적용 사례

• 주요 컬럼 및 후속 컬럼의 액세스 패턴 분석을 통해 효율적인 인덱스와 오버플로우의 분리를 수행.
• 데이터를 분석하여 인덱스 영역과 오버플로우 영역을 설정함으로써 높은 액세스 효율성을 달성.

1.3 클러스터링 테이블

• 클러스터링 테이블은 테이블과 인덱스의 분리형, 일체형 구조의 한계를 극복하고자 제안된 데이터베이스 저장 방식이다.
• 기존의 분리형 테이블은 랜덤 액세스에서 부하가 크고, 일체형 테이블은 다양한 데이터 액세스 패턴에 대응하기 어렵다.
• 클러스터링 테이블은 데이터를 묶어서 저장하며, 특히 대량 데이터에 적합한 구조로 설계된다.

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

• 클러스터링은 공장과 제품으로 비유될 수 있다.
• 테이블은 공장을 의미하며, 클러스터는 공장 내의 섹션(작업 공간)이다.
• 동일한 제품(동일한 클러스터 키를 가진 데이터)은 같은 섹션에 저장된다.
• 이런 저장 방식은 데이터를 찾기 위해 공장 전체를 탐색하지 않고, 특정 섹션만 확인하도록 설계된다.
• 클러스터는 창고의 섹션과 비슷하다. 동일한 클러스터 키를 가진 데이터를 하나의 섹션에 저장한다.
• 저장된 데이터는 같은 키 값을 가진 로우가 물리적으로 인접해 있다.

클러스터링 팩터(Clustering Factor)

• 물리적으로 얼마나 데이터가 근접해 저장되어 있는지를 나타내는 지표다.
• 클러스터링 팩터가 높을수록 관련 데이터가 인접해 있고, 데이터 접근 성능이 개선된다.

클러스터링의 유형

• 단일 테이블 클러스터링(Single-Table Clustering)
  • 하나의 테이블 데이터를 클러스터링.
  • 특정 컬럼의 범위 검색이 많을 때 적합.
• 다중 테이블 클러스터링(Multi-Table Clustering)
  • 여러 테이블 데이터를 공통 클러스터 키 기준으로 묶어 저장.
  • 테이블 간 Join 연산이 빈번한 경우 효과적.

1.3.2 단일 테이블 클러스터링

• 단일 테이블 클러스터링은 하나의 테이블 내 데이터를 클러스터링하여 저장.
• 특정 컬럼 값을 기준으로 데이터를 물리적으로 정렬하여 저장.

특징

• 특정 컬럼의 범위 검색이 많은 경우 적합.
• 물리적 데이터 정렬로 인해 데이터 접근 속도가 향상.

장점

• 범위 검색 및 특정 조건 검색이 효율적으로 처리됨.
• 동일한 클러스터 키 값을 가진 데이터가 물리적으로 근접하여 저장.

단점

• 클러스터 키 값 변경이나 데이터 추가/삭제 시 블록 이동 발생 가능.
• 설계 및 관리 복잡성이 증가.

1.3.3 다중 테이블 클러스터링

• 다중 테이블 클러스터링은 단일 클러스터에 두 개 이상의 테이블을 저장하는 방식.
• 동일한 클러스터 키 값을 가진 테이블의 로우가 물리적으로 같은 블록에 저장.
• 테이블 간의 조인 효율을 극대화하기 위해 사용.
• 클러스터 블록 내부에 테이블 간의 관계 데이터를 밀집시켜 효율적인 검색 가능.
• 로우는 클러스터 ID와 클러스터 키 값을 가짐.

특징

• 조인 최적화 - 동일한 클러스터 키를 가진 데이터가 물리적으로 가까이 저장되어, 조인 연산 시 성능 향상.
• 독립성 - 각 테이블은 자신만의 고유한 인덱스를 유지하며, 클러스터링된 구조 내에서 데이터를 독립적으로 조회 가능.
• 지역 투명성(Location Transparency) - 데이터가 어느 위치에 저장되어 있든지 상관없이 테이블 간 관계를 유지.

장점

• 테이블 간 조인의 효율성 증대.
• 물리적 근접성으로 데이터 접근 속도가 향상.

단점

• 클러스터 키의 변경, 데이터 추가/삭제로 인해 블록 이동 발생.
• 설계 및 관리의 복잡성 증가.

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

비용 요인

• 클러스터링 테이블의 생성과 유지에는 추가적인 저장 비용과 연산 비용이 발생.
• 삽입(INSERT), 수정(UPDATE), 삭제(DELETE) 시, 정렬과 블록 이동으로 인한 부하가 클 수 있음.

클러스터링으로 인한 부하

• 클러스터링은 조회 성능을 높이는 것이 주요 목적이지만, 삽입, 수정, 삭제 작업에서는 추가적인 부하가 발생.
• 이러한 부하는 클러스터 키의 설계와 데이터 배치 방식에 따라 다르게 나타남.
• 따라서 클러스터링을 도입하기 전, 클러스터링으로 인한 부하의 정도를 정확히 파악하고, 최적의 선택이 무엇인지 판단해야 함.

효율적으로 쓰려면

• 데이터 변경 빈도가 낮고 조회 빈도가 높은 테이블에 적합.
• 클러스터 키 설계 시 데이터의 균등한 분포를 고려하여 불필요한 블록 낭비 방지.

주의점

• 잘못 설계된 클러스터 키는 성능 저하를 유발할 수 있음.
• 데이터가 비효율적으로 배치되면 블록 내 저장 공간 낭비가 발생.
• 설계 초기에 클러스터링을 적용해야 할 대상과 방식에 대한 면밀한 검토가 필요.

클러스터링 테이블의 부하

입력(INSERT) 시의 부하

• 작업 부하
  • 클러스터링 테이블에 데이터를 입력할 경우, 정해진 위치를 찾아 저장해야 하므로 일반 테이블보다 더 많은 부하가 발생.
  • 프리리스트(Freelist)를 더 많이 요구하며, 클러스터 키 값에 따라 블록 저장 위치가 결정됨.
• 추가 블록 생성
  • 특정 블록에 저장할 데이터가 초과되면 새로운 블록이 할당되어야 하며, 이 과정에서 추가적인 저장 작업이 유발됨.
  • 빈번한 블록 생성은 특히 대량의 데이터를 처리할 때 더 큰 부하를 초래.
• 성능 최적화 방안
  • 데이터 입력 작업이 발생할 빈도와 규모를 미리 예측하여 프리리스트를 최적화.
  • 클러스터 키 설계 시 균등 분포를 보장하여 데이터 집중화를 방지.

수정(UPDATE) 시의 부하

• 변경 작업의 영향
  • 클러스터 키 값 변경 시, 기존의 데이터 위치를 새로 저장해야 하므로 추가적인 입력 작업과 블록 이동이 발생.
  • 이로 인해 클러스터링 테이블의 체인 생성 가능성이 증가하며, 액세스 성능 저하를 초래.
• 기존 블록 유지
  • 기존 위치에 남아 있는 ROWID 정보를 활용해 수정된 데이터를 새로운 블록에 저장하는 방식 사용.
  • 이는 블록 이동으로 인한 추가 비용을 줄이지만, 설계 단계에서 클러스터 키 변경이 최소화되도록 설계해야 함.

삭제(DELETE) 시의 부하

• 데이터 삭제 방식
  • 클러스터링 테이블에서의 삭제는 일반 테이블과 유사하지만, 클러스터 키 구조를 유지하기 위해 추가적인 작업이 필요.
  • 삭제된 로우의 공간이 즉각적으로 회수되지 않아 향후 데이터 입력 시 효율성이 저하될 수 있음.
• 롤백 처리
  • 삭제 작업 중 롤백(Segment)에 저장된 정보를 사용하여 복구 가능.
  • 불필요한 저장 공간 낭비를 방지하기 위해 정기적인 블록 재사용 전략 필요.
• DROP과 TRUNCATE 차이
  • DROP은 클러스터와 모든 데이터를 삭제하며 저장 공간을 초기화.
  • TRUNCATE는 데이터만 삭제하며 저장 공간을 재사용할 수 있도록 설계.

1.3.5 해시 클러스터링

해시 클러스터링의 특징

• 고정된 해시 함수 기반
  • 해시 클러스터링은 데이터를 저장할 위치를 해시 값으로 결정하여 정해진 위치에 데이터를 저장.
  • 해시 값은 테이블 생성 시 정의되며, 이후 변경 불가.
• 미리 할당된 저장 공간
  • 해시 클러스터링 테이블은 생성 시 저장 공간을 미리 할당.
  • 공간의 부족을 방지하기 위해 충분한 크기의 HASHKEYS와 SIZE를 설정해야 함.
• 충돌 관리
  • 동일한 해시 값을 가진 데이터는 오버플로우 영역에 저장됨.
  • 충돌이 자주 발생하면 성능 저하가 유발될 수 있음.
• 인덱스 없는 데이터 액세스
  • 물리적 인덱스를 사용하지 않고 해시 계산을 통해 직접 데이터에 접근 가능.
• 제약 사항
  • SIZE, HASHKEYS, HASH IS와 같은 해시 클러스터링의 주요 파라미터는 테이블 생성 후 변경 불가.

해시 클러스터링의 활용 범위

• 적합하지 않은 경우
  • 지속적으로 대량의 데이터가 증가하는 테이블에는 적합하지 않음.
  • 클러스터링 컬럼의 분포가 균등하지 않은 경우 오버플로우 영역에 데이터가 집중되어 효율이 저하.
• 적합한 사용 사례
  • 소량의 데이터를 관리하거나 우편번호, 사원 정보, 시스템 사용자 정보 등 고정된 범위 내 데이터를 관리.
  • 검색 조건이 = 연산자로 한정된 경우.
• 이론적 사용
  • 단일 테이블 클러스터링의 목적으로 활용 가능하나, 대규모 데이터에서는 해시 파티션을 사용하는 것이 더 적합.

해시 클러스터의 정의

CREATE CLUSTER 구문을 사용해 해시 클러스터를 정의할 수 있음

CREATE CLUSTER [schema.]cluster (column datatype ...)
   HASHKEYS integer
   [HASH IS expression]
   [PCTFREE integer]
   [PCTUSED integer]
   [INITRANS integer]
   [MAXTRANS integer]
   [SIZE integer [K | M]]
   [storage-clause]
   [TABLESPACE tablespace];

 

• HASHKEYS - 해시 값의 개수를 설정. 일반적으로 소수(Prime number)를 사용하여 해시 충돌을 최소화.
• HASH IS - 해시 함수를 정의. 기본값으로 제공되는 함수를 사용하거나 사용자 정의 함수를 설정 가능.
• SIZE - 블록당 저장 가능한 데이터의 크기. 블록 크기를 고려하여 적절히 설정.

단일 테이블 해시 클러스터

• 개념
  • 단일 테이블 해시 클러스터는 해시 클러스터링을 단일 테이블에만 적용하여 효율성을 높임.
  • 인덱스를 생략하고 해시 값을 통해 데이터에 접근 가능.
• 구현 예시

CREATE CLUSTER order_item (order_no NUMBER(6))
   SIZE 512
   SINGLE TABLE
   HASHKEYS 1000;

 

해시 클러스터링은 데이터를 고정된 위치에 저장하여 빠른 액세스를 제공하지만, 설정 및 설계가 적절하지 않으면 성능 저하가 발생할 수 있기 때문에 데이터의 분포, 충돌 관리, 저장 공간 설계를 고려하여 해시 클러스터링을 사용해야 함.

 

Start : 24. 12. 17
End: 24. 12. 31