물리적 데이터베이스 설계 (인덱스)

논리적인 설계의 데이터 구조를 장치상의 파일(물리적인 데이터 모델)로 사상(mapping)함

---

예상빈도, DB 질의, 트랜잭션 분석

조인연산의 속도 향상, 빈번하게 사용하는 애트리뷰트에 중점

---

데이터에대한 효율적인 접근을지원하기 위해

저장구조와 접근방식을 다룸

물리적 DB설게는 DBMS의 특성을 고려하여 진행

---

질의를 효율적으로 지원하기 위해선

인덱스구조를 사용

 

너무적은 인덱스정의 : 검색 연산이 효율적으로 지원되지 않음

너무많은 인덱스정의 : DB갱신시 시간이 많이 걸림

---

대부분의 경우 논리적 설계가 바로 물리적 설계로 사상됨

사용패턴에 대한 정보를 추가로 알게됨에 따라 시스템 성능을 추가로 향상가능

 

DBMS가 ANSI/SPARC 모델을 잘 따르면 물리적 변화가 논리적 설계 변화에 영향을 주지 않음(물리적데이터 독립성)

---

DB는 파일의 집합

파일은 레코드의 모임

레코드는 필드의 모임

 

레코드는 2가지로 나뉜다

고정길이 레코드 : 동일개수의 필드와 일정 크기를 갖는 필드로 이루어짐

가변길이 레코드 : 각 레코드마다 서로다른 필드 개수를 갖거나 각 필으 길이가 가변적임

---

DBMS는 운영체제와 상호작용하면서 디스크로부터 데이터를 읽음

 

운영체제 구성 요소중 파일 시스템이 DBMS와 상호작용한다

파일시스템은 보조 기억장치의 저장공간을 관리하는 시스템이다

 

파일시스템이 제공하는 서비스는 보통 다음과같다

프로그램이 요청한 공간의 할당

데이터에 대한 접근 제공

가용데이터에 대한 개요 제공

 

---

 

목차

1. 디스크의 개요와 특성

디스크는 데이터베이스가 저장되는 대표적인 보조기억장이다

 

2. 주기억 장치의 버퍼를 관리하는 방법

운영체제는 디스크의 블록을 주기억 장치의 버퍼로 읽는다

 

3.디스크 상의 레코드 배치와 클러스터링 

 

4.파일 조직 중 히프 파일과 순서 파일

 

5. 단일 단게 인덱스

 

6. 다단계 인덱스

 

7.인덱스 선정 지침과 DB 튜닝

 

 

---

디스크 구조

---

 

보조기억장치에서 주기억 장치로 이동하는 데이터의 단위는 블록이다.

주기억 장치에서는 페이지라는 용어를 사용

 

블록크기는 운영체제마다 다름

사용자가 블록 크기를 임의로 선정 불가능

전형적인 블록 크기는 4096바이트

각 파일은 고정된 크기의 블록들로 나누어져서 저장

 

주기억장치는 용량이 작고 휘발성이어서

DB는 디스크에 저장하여 관리

디스크는 장기간 보관하는데 주된 보조기억장치임

전체 데이터베이스(모든 릴레이션 및 연관된 접근 구조) 가 디스크에 저장됨

 

디스크는 직접 접근 장치임

디스크 상의 임의 위치에 있는 데이터르 바로 접근 가능

 

자기테이프는 주로 DB를 백업하기 위해 사용

자기테이프는 순차접근만 가능

디스크장치보다 속도가 느림

 

 

저장장치 계층구조

주기억<->디스크-테이프

 

 

디스크 구성

트랙 : 동심원으로 나눈것

섹터 : 중심으로부터 부채꼴 모양으로 나눈것

실린더 : 동일한 인덱스를 가진 트랙의 모임(디스크를 원통형으로 본 모양)

블록 : 트랙과 섹터를 교차했을때 그 한 부분

 

디스크는 자기 물질로 만들어진 여러 개의 판으로 이루어짐

각 면마다 디스크 헤더가 있음

각 판은 트랙과 섹터로 구분

 

정보는 디스크 표면 상의 동심원(트랙)을 따라 저장

디스크 팩에서 여러 개의 디스크 면 중 같은 지름을 갖는 트랙들을 실린더라 부름

 

한 트랙의 용량이 매우 크기 때문에 일반적으로 더 작은 단위인 섹터들로 구분

블록은 한 개 이상의 섹터들로 이루어짐

 

디스크장치의 물리적 특성은 회전 속도, 판의 개수, 각 면의트랙 수, 트랙 당 용량(바이트수)에 따라 달라짐

 

---

디스크 접근의 구성

 

seek time : 원하는 실린더 위에 디스크 헤드가 놓일때까지 걸리는 시간

실린더를 찾는데 소요되는 시간

보통 5~10ms

rotational delay : 블록이 디스크 헤드 밑에 올때까지 걸리는 시간

처리할 데이터가 있는 위치까지 오는 시간

평균 1/2 회전시간 만큼 걸림

7200rpm 회전속도의 디스크에서 약 4.2ms정도 소요

transfer time : 블록 크기와 버스 속도에 따라 달라짐

 

 

디스크에 임의 블록을 일거나 기록하는데 걸리는 시간

탐구시간(seek time) +

회전 지연 시간(rotational delay) +

전송 시간(transfer time)

 

탐색시간이 회전시연 시간보다 더 많은 시간 소요

 

 

디스크 접근에 소요되는 시간을 감소시키려면

평균 회전 지연 시간, 블록 전송횟수를 감소시켜야함

 

 

 

디스크 블록들을 순차적으로 접근하는 경우

연속된 블록들이 동일한 실린더 상에 위치한다고 가정하면

탐구시간은 0

 

다음에 읽을 데이터가 동일한 트랙 상에서 다음 블록에 위치한다면

회전지연시간은 0

 

따라서 임의 접근의 경우보다 순차 접근의 성능이 매우 빠름

 

DBMS는 가능한 순차접근을 이용하려 노력

 

디스크 상에 레코드들을 배치할 때 가능한 연관된 레코드들을 동일한 블록, 동일한 트랙, 동일한 실린더, 인접한 실린더 순으로 유지

 

블록의크기가 크면 연관된 데이터를 읽을때 동일 블럭에 있을 가능성이 높으므로 추가로 디스크를 접근할 필요를 줄일 수 있음

 

 

---

버퍼관리

---

 

DBMS의 성능은 디스크 입출력 횟수가 좌우

 

입출력 횟수를 줄이려면

많은 블록들을 주기억 장치에 유지

자주 참조되는 블록들을 주기억 장치에 유지

 

 

 

버퍼 : 디스크 블록들을 저장하는데 사용되는 주기억 장치의 공간

 

버퍼관리자 : 운영체제의 구성요쇼. 주기억 장치 내에서 버퍼 공간을 할당&관리

 

버퍼에 어떤 블록을 유지할것인가? (스케줄링 기법)

보통 LRU (Least Recently Used) 스케줄링 사용

가장 오래전에 참조된 블록을 교체하는 방식

 

LRU가 항상 우수한 성능을 보이는건 아니다

 

내용 읽기

데이터를 포함한 블록을 버퍼로 읽어옴->버퍼내에서 데이터를 찾아 응용에 전달

내용수정

버퍼에서 해당 데이터 갱신->갱신된 버퍼를 디스크에 기록

 

 

---

고정길이 레코드 /가변길이 레코드의 디스크상의 파일 레코드 배치

---

 

속성은 가변길이or고정길이다

ex BLOB 타입 같은건 가변길이고 TIME은 고정길이

 

 

한 릴레에션을 구성하는 레코드들의 모임은 블록들의 모임에 저장된다

이걸 파일이라 부른다.

 

한 파일에 속하는 블록들은 반드시 인접해 있을 필요는 없다.

 

인접할 블록들을 읽을때 탐구시간과 회전지연 시간이 들지 않기 때문에 입출력 속도가 빠르다.

따라서 블록들이 인접하도록 한 파일의 블록들을 재조직한다.

 

블록의 크기는 일반적으로 레코드보다 훨씬 크다.

많은 레코드들이 한 블록에 들어간다.

 

spanned record(신장된 레코드)

: 레코드 길이가 블록 크기를 초과하여 한 레코드를 두 개 이상의블록에 걸쳐져 저장한 것

 

BLOB(Binary Large Objecta)는 대규모 크기의 데이터를 저장할 때 사용하는데

실린더 상에서 인접한 블록들을 할당하여 저장한다.

 

채우기인수(fill factor) : 각 블록 레코드를 채우는 공간의 비율

 

빈 공간을 남겨두는 이유는 나중에 레코드가 삽입될 때 기존의 레코드들을 이동하는 가능성을 줄이기 위해

 

 

 

고정길이 레코드

레코드가 고정길이이면 관리가 단순해짐

 

n바이트 고정길이 레코드에서 레코드 i를 접근하려면

n * (n -1) + 1 의 위치에서 레코드를 읽으면 된다.

 

i번째 고정길이 레코드를 삭제할 때는 i+1, i+2... n번째를

n-1, n-2 ... n-1 로 한칸씩 옮겨서 자리를 채운다.

 

만약 i번째 레코드삭제시 마지막 n번째를 i번째로 옮기면 더 빨리 자리를 채울 수 있다.

 

가변길이 레코드

 

가변길이의경우 특정 레코드의 접근이 어려워진다.

레코드 삭제 후 그 공간에 길이가 더 긴 레코드를 삽입하려면 레코드들의 위치를 옮겨 필요한 공간을 만든다.

 

입출력을 최소화하기 위해

하나의 질의에서 함께 요구될 정보를 동일한 블록에 넣는 클러스터링을 활용할 수 있다.

 

 

 

클러스터링

• 화일 내의 클러스터링(intra-file clustering)

함께 검색될 가능성이 높은 레코드들을 물리적으로 가까운 곳에 모아두는것

 

 

• 화일 간 클러스터링(inter-file clustering)

함께 검색될 가능성이 높은 두 개 이상의 파일에 속한 레코드들을 디스크 상에서 물리적으로 가까운 고셍 저장하는 것

첫번째 클러슽러이 방법

 

 

 

클러스터링은 공통된 애트리뷰트르 사용해서

조인이 자주 이뤄지는 파일들에 대해서만 하는것이 좋다.

 

클러스터링 

조인 성능은 향상

 

다음은 저하

파일전체탐색연산

레코드 삽입연산

조인애트리뷰트 수정연산

 

 

 

---

파일 조직

---

 

파일 조직 : 파일 내의 데이터를 보조기억 장치에서 블록과 레코드들로 배치하는 것

 

유형

heap file 히프파일

레코드들이 삽입된 순서대로 파일에 저장

 

새로 삽입된건 제일 끝에 위치

삽입이 쉽고 레코드들의 순서는 없음

 

원하는 레코드를 찾으려면

순치적으로 접근

 

삭제시

 

원하는 레코드를 찾고

그 레코드를 삭제

삭제된 레코드가 차지하던 공간은 재사용하지 않는다.

 

재사용하려면 파일의 끝대신 파일 중간에서 빈자리를 찾아야 하므로 삽입 시간이 증가한다.

 

재사용되지않아 빈공간으로  남아있어 나중엔 파일 크기가 증가하게 된다.

 

검색시 빈 공간도 검사하게 되므로 검색시간이 오래걸리게 된다.

 

성능을 유지하기 위해 주기적으로 재조직할 필요가 있음

 

재조직시 빈 공간을 회수해서 자유공간에 반환

 

주로 사용

릴레이션 데이터를 한꺼번에 적재(bulk loading)

릴레이션에 몇개의 블록들만 있을때

모든 튜플들이 검색 위주로 사용될때

 

효율

SELECT * FROM 테이블1 

 

비효율

SELECT 속성1 FROM 테이블1

 

b개의 블록이 있을때 원하는 블록을 찾기위해

평균적으로 b/2개의 블록을 읽어햐 한다.

 

WHERE 사용시에도 비효율

 

SELECT * FROM 테이블1 WHERE 속성1 = 3;

b개의 블록을 모두 읽어야한다.

모든 레코드에 접근해야하기 때문

 

범위 조회도 비효울

 

SELECT * FROM 테이블1 WHERE 속성1 > 30

모든 레코드에 접근해야함

 

갱신하는데도 시간이 많이 걸림

 

 

 

 

 

 

 

sequential file 순차파일

기준에 따라 정렬된 파일. 하나 이상의 필드 값에 따라 순서대로 저장된 파일

 

레코드의 탐색키(search key) 값의 순서에 따라 저장됨

 

탐색키 : 순차파일을 정렬하는데 사용되는 필드

 

레코드들을 순차접근하는 응용에 적합

 

정렬된 필드를 사용하여 특정 레코드를 접근하는 경우 이진탐색!을 사용하여 탐색시간을 줄일 수 있다.

 

 

삽입 연산시

레코드의 순서고려. 많은 시간이 걸릴 수 있음

 

삽입 위치를 찾은 후 빈공간이 있으면 삽입

없으면 오버플로 블록에 넣거나 레코드를 이동해서 빈공간을 만듬

 

삭제 연산시

사용하던 공간을 빈 공간으로 남김 

heap file과 마찬가지로 주기적으로 순차파일을 재조직함

 

기본인덱스가 순차파일에 정의되지 않는 한 순차 파일은 데이터베이스응용에 거의 사용되지 않는다.

 

탐색 키를 기반으로 한 조회연산은 효율적이나

그외에 삽입 삭제 그외 필드를 이용한 조회는 시간이 많이 소요된다.

 

 

 

 

 

 

indexed sequential file 인덱스된 순차파일

 

인덱스된 순차파일은 인덱스를 통해서 임의의 레코드를 접근할 수 잇는 파일

인덱스 자체가 파일을 의미하게된다.

 

 

hash file 직접파일