[DAP 전문가 가이드] 5.1.1 저장 공간 설계

 

 

테이블

- 테이블은 행과 컬럼으로 구성되는 가장 기본적인 데이터베이스 객체로 데이터베이스 내에서 모든 데이터는 테이블을 통해 저장된다.

- 상용 DBMS들은 데이터를 저장하는 방식이 상이한 여러 종류의 테이블을 제공하고 있으므로 테이블 설계 시에 성능, 확장성, 가용성 등을 고려해 테이블 유형을 선택하여야 한다.

- 테이블, 컬럼 등 데이터베이스에서 사용되는 객체의 명명 규칙은 표준화 관점에서 별도로 정의한다.

 

테이블

- 테이블은 데이터의 저장 형태, 파티션 여부, 데이터의 유지 기간 등에 따라 다양하게 분류할 수 있다.

• Heap-Organized Table
  • 대부분의 상용 DBMS에서 표준 테이블로 사용하고 있는 테이블 형태로, 테이블 내에서 로우의 저장 위치는 특정 속성의 값에 기초하지 않고 해당 로우가 삽입될 때 결정된다.
• Clustered Index Table
  • Primary Key 값이나 인덱스 키 값의 순서로 데이터가 저장되는 테이블을 클러스터 인덱스라 한다.
  • 클러스터 인덱스는 B 트리의 리프 노드에 RID 대신 데이터 페이지가 존재하는 구조이다.
  • 데이터 페이지가 검색하고자 하는 키 값의 순서로 정렬되어 있기 때문에 프리 패치가 가능하고, 인덱스에서 테이블로 탐침하는 경로가 단축되기 때문에 일반적인 인덱스를 이용하는 것보다 데이터를 더 빠르게 액세스할 수 있다.
  • 그러나 데이터가 삽입될 때 키 순서에 따라 지정된 위치에 저장되어야 하므로 데이터 페이지를 유지하는 데 많은 비용이 발생한다.
• Partitioned Table
  • 파티셔닝은 대용량의 테이블을 파티션이라는 보다 작은 논리적인 단위로 나눔으로써 성능이 저하되는 것을 방지하고 관리를 보다 수월하게 하고자 하는 개념으로, 파티셔닝을 하는 방식에 따라 범위 분할, 해쉬 분할, 결합 분할 등이 있다.
  • 파티셔닝은 대용량 데이터를 관리하는 데 아주 효과적이지만 무조건 파티션만 한다고 해서 파티션이 가지고 있는 이점을 모두 취할 수 있는 것은 아니다. 잘못된 인덱스가 오히려 처리 속도에 나쁜 영향을 미치듯이 파티션 키를 어떻게 구성하느냐에 따라 많은 비효율을 초래할 수도 있으므로 전략적인 관점에서 파티션 키가 결정되어야 한다.
• External Table
  • 외부 파일을 마치 데이터베이스 안에 존재하는 일반 테이블 형태로 이용할 수 있는 데이터베이스 객체이다.
• Temporary Table
  • 트랜잭션이나 세션별로 데이터를 저장하고 처리할 수 있는 임시 테이블이다.
  • 저장된 데이터는 트랜잭션이 종료되면 휘발되며, 다른 세션에서 처리되는 데이터는 공유할 수 없다.
  • 절차적인 처리를 하기 위해 임시적으로 사용할 수 있는 테이블이다.

 

컬럼

- 테이블을 구성하는 요소로, 데이터 타입과 길이로 정의된다.

- 비교 연산에서 두 컬럼이 서로 데이터 타입과 길이가 다르면 DBMS는 내부적으로 데이터 타입을 변형한 후 비교 연산을 수행하므로 컬럼이 서로 참조 관계일 경우는 가능한 한 동일한 데이터 타입과 길이를 사용해야 한다.

- 컬럼 데이터 타입에 따라 물리적인 컬럼 순서 조정이 필요하다.

• 고정 길이 컬럼이고 Not Null인 컬럼은 선두에 정의한다.
• 가변 길이 컬럼을 뒤편으로 배치한다.
• Null 값이 많을 것으로 예상되는 컬럼을 뒤편으로 배치한다.

데이터 타입과 길이 지정 시 고려 사항

• 가변 길이 데이터 타입은 예상되는 최대 길이로 정의한다.
• 고정 길이 데이터 타입은 최소의 길이를 지정한다.
• 소수점 이하 자리 수의 정의는 반올림되어 저장되므로 정확성을 확인하고 정의한다.

테이블 설계 시 고려 사항

• 컬럼 데이터 길이 합이 1블록 사이즈보다 큰 경우 수직 분할을 고려한다. 1블록 사이즈보다 크면 체인이 발생하여 속도 저하 현상을 유발한다.
• 컬럼 길이가 길고 특정 컬럼의 사용 빈도 차이가 심한 경우이거나 각기 다른 사용자 그룹이 특정 컬럼만을 사용하고 같이 처리되는 경우가 드문 경우는 수직 분할을 고려한다.
• 수직 분할을 고려할 때는 분할되는 테이블이 하나의 트랜잭션에 의해 동시에 처리되는 경우나 조인이 빈번히 발생되는 경우가 없어야 한다.
• "주문일자", "계약일자" 등과 같이 검색 조건으로 빈번하게 사용되는 컬럼은 시간 데이터 타입을 사용하면 비교 연산을 하거나 조인일 때 동일 데이터 타입으로 가공하는 경우가 일어날 수 있으므로 액세스 측면만 고려한다면 문자 타입을 사용하는 것이 더 효율적이다.
• 사건의 일자나 시간을 기록하는 속성을 문자 타입으로 정의하면 일자 범위를 벗어나는 값이 입력될 수 있으므로 처리 시 문제가 발생하지 않도록 하려면 오류 데이터들을 클린징하거나 제외하기 위한 복잡한 로직을 추가해야 한다.

 

테이블과 테이블스페이스

- 테이블은 테이블스페이스라는 논리적인 단위를 이용하여 관리하고, 테이블스페이스는 물리적인 데이터 파일을 지정하여 저장된다.

- 테이블, 테이블스페이스, 데이터 파일로 분리하여 관리함으로써 논리적인 구성이 물리적인 구성에 종속되지 않고 투명성을 보장할 수 있다.

- 테이블스페이스는 저장되는 내용에 따라 테이블용, 인덱스용, 임시용을 구분하여 설계한다.

- 백업 단위나 공간 확장 단위인 물리적인 파일 크기를 적정하게 유지하기 위해서이다.

 

데이터용/인덱스용 테이블스페이스 설계 유형

• 테이블이 저장되는 테이블스페이스는 업무별로 지정한다.
• 대용량 테이블은 독립적인 테이블스페이스를 지정한다.
• 테이블과 인덱스는 분리하여 저장한다.
• LOB 타입 데이터는 독립적인 공간을 지정한다.

용량 설계

용량 설계 목적

• 정확한 데이터 용량을 예측하여 저장 공간을 효과적으로 사용하고 저장 공간에 대한 확장성을 보장하여 가용성을 높이기 위함
• H/W 특성을 고려하여 디스크 채널 병목을 최소화하기 위함
• 디스크 I/O를 분산하여 접근 성능을 향상하기 위함
• 테이블이나 인덱스에 맞는 저장 옵션을 지정하기 위함

테이블 저장 옵션에 대한 고려 사항

• 초기 사이즈, 증가 사이즈
• 트랜잭션 관련 옵션
• 최대 사이즈와 자동 증가

저장 용량 설계 절차

• 용량 분석 : 데이터 증가 예상 건수, 주기, Row Length 등을 고려함
• 객체별 용량 산정 : 테이블, 인덱스에 대한 크기
• 테이블스페이스별 용량 산정 : 테이블스페이스별 객체 용량의 합계
• 디스크 용량 산정 : 테이블스페이스에 따른 디스크 용량과 I/O 분산 설계