Database Storage

DBMS를 개발할 때는 아래의 사항을 고려해야 한다.

• 가용한 메모리보다 큰 데이터를 처리할 수 있어야 한다.
• Disk I/O는 성능저하의 원인이기 때문에 신중하게 사용해야 한다.
• Disk에서의 탐색은 Random보다 Sequential access가 더 빠르기 때문에 순차탐색을 최대화 해야한다.

 

이 사항들을 염두하고 DB 저장소를 관리하는 법을 알아보자.

 

File Storage

DBMS는 그들만의 file format을 이용하거나, OS에서 제공하는 파일 시스템을 이용해서 데이터베이스를 관리한다.

이런 파일들은 Storage Manager가 관리해준다.

 

Storage Manager

기본적으로 데이터베이스의 파일을 여러 page 단위로 쪼개어 관리하게 된다.

여기서 page는 데이터가 들어있는 고정된 크기의 블록인데, 이 크기는 보통 4~16KB단위로 관리된다.

페이지에는 tuples, meta-data, index, log 등등 여러 정보가 저장되는데, 

대부분의 시스템에서는 위의 정보가 한 페이지에 섞여 저장되지 않고 용도별로 분류되어 저장한다.

또한, 각 페이지는 그 페이지를 읽기 위한 meta-data를 스스로 저장한다.

그리고, 각 페이지는 고유의 ID값을 갖고 있다.

 

따라서 데이터를 저장할 때는 페이지 단위로 저장장치에 쓰여지고, 읽어올 수 있다.

또한, 페이지 단위로 저장장치에 쓰여지거나 쓰여지지 않거나가 보장된다. (일부만 저장되는 일이 없음)

 

Heap File

Storage Manager의 파일 관리 기법중 하나로, 정렬되지 않은 page의 집합을 heap file라 부른다.

 

하나의 파일만으로 관리되는 DBMS에서 heap file 구조를 사용할 때는 페이지를 가져오는 방식이 간단하다.

 

하지만, 여러개의 파일로 관리되는 DBMS에서 heap file 구조를 사용할 때는 페이지를 가져오기 위해

파일의 상태를 관리하는 메타데이터가 필요하게 된다.

 

그 역할을 Directory page가 수행하게 되는데, 이 페이지에선 아래와 같은 메타데이터가 필수적으로 저장되야 한다.

• 각 페이지가 디스크 어디에 존재하는지
• 페이지별로 남은 공간이 얼마나 되는지
• 사용하지 않은 페이지는 얼마나 있는지

 

또한, 위 모든 정보는 반드시 실제 페이지와 동기화 되어야 한다.

 

Page Layout

각 페이지는 크게 두 영역으로 나뉘어 데이터를 관리한다.

 

- Page header

페이지 헤더에는 페이지에 대한 모든 메타데이터가 담겨있다.

(페이지 크기, 스키마, 체크섬, DBMS 버전, 트랜젝션 접근정보, 압축기법 등)

 

- Data

Tuple, Log 기반 저장방법이 있는데, Tuple 기반 저장방법에 대해서만 알아보자.

 

Idea 1

header에는 튜플의 개수만 저장하면 되지만, 이런 단순한 구조는 아래와 같은 문제점이 있다.

• 튜플 삭제시 빈공간의 처리가 어렵다
• 가변 길이의 튜플 저장이 어렵다

 

Idea 2 - Slotted Pages

header에는 slot의 개수와 마지막으로 사용된 slot의 시작위치를 저장한다.

이 방법은 Slot Array에서 각 Tuple의 시작 위치를 저장하고, 가변 길이의 튜플을 페이지 끝에서부터 저장할 수 있다.

 

데이터가 삭제되는 경우 주기적으로 조각모음하도록 개발할 수도 있다.

 

여기서 각각의 튜플은 고유의 ID값을 갖게되는데, 이 ID값은 DBMS 내부적으로

튜플을 관리하기 위해 사용하는 값이기 때문에, 서비스 개발시에는 이를 사용하면 안된다.

 

Tuple Layout

튜플은 byte의 배열 형태로 저장되는데, 이를 해석하는 것은 DBMS마다 다르다.

또한, 튜플역시 header를 갖고 있는데,

튜플의 Visiblity 정보, null값 처리를 위핸 Bit Map과 같은 데이터가 저장된다.

하지만, 스키마에 대한 데이터는 저장하지 않는다. (저장공간 절약을 위함)

 

스키마에 대한 정보는 page header의 메타데이터 형태로 저장되고,

튜플은 그 순서에 따라 데이터를 저장할 뿐이다.

 

하지만 성능향상을 꾀하기 위해 관계형 DB가 아닌 DB에서는 순서를 깨뜨리며 저장하는 경우도 있다. (Denormalize)

pre join 하여 관련 있는 튜플을 하나의 튜플에 모아 저장함으로써

Disk I/O를 줄일 수 있다.