13. 9장 : STORING DATA - DISKS AND FILES (3)

디스크 공간 관리 <> 파일, 인덱스 관리 의 중간계층!

=> RAM 기반 API를 사용한 파일 및 인덱스 관리를 지원하고

디스크 드라이브 작업을 디스크 공간 관리자와 연결한다.

 

파일, 인덱스 관리자는 페이지가 RAM에 있다는걸 가정하고 동작함!!

즉, API로 "페이지 3을 주세요" 라는 요청이 들어왔을 때 버퍼 관리자는 이게 RAM에 있는지 확인하고

없으면 disk space management한테 요쳥해서 페이지3을 RAM으로 올리는 역할을 한다.

 

이 때 버퍼 관리자는 RAM의 버퍼풀에서 페이지를 관리한다.

 

...-> 전체적으로.. 캐시의 동작과 비슷하게 생각하면 될것같다!!

 

아무튼 버퍼 관리자의 동작에서 고려해야 할것은

 

1. 업데이트 된 페이지를 어떻게 할것인지

2. 버퍼풀이 가득차면 어떻게 할것인지

 

가 있다.

 

Dirty Pages

업데이트 된 페이지!

 

일단 RAM에서 페이지가 업데이트되면 -> flag로 나타낸다.

dirty page가 되면, disk에 다시 작성해주면 된다.

 

Buffer Manager State

버퍼메니저가 버퍼풀을 어떻게 관리하는것인지에 대한것이다.

시스템이 부팅되면, 버퍼풀로 사용할 큰 메모리범위를 malloc한다.

-> 이 메모리는 페이지와 같은 사이즈인 "프레임" 단위로 관리된다.

(큰 사이즈를 malloc하고, 프레임단위로 관리하는것)

 

버퍼풀에는 버퍼풀에 대한 메타데이터도 같이 관리된다.

메타데이터에는 각 프레임에 몇번 페이지가 올라와 있는지,

dirty page인지, pin count 등등의 정보가 관리된다 (작은 테이블로 생각가능)

 

버퍼풀에 올라온 페이지는 페이지 ID 기준으로 인덱싱 된다

즉.. 페이지 ID를 기준으로 몇번 프레임에 올라와 있는지 확인할 수 있다.

 

* 핀 카운트 : task의 수 (해당 페이지를 이용하는)

== 해당 페이지를 사용하려는 쿼리의 개수

 

일단 페이지 요청이 들어오면...

1. pin count가 0인 페이지를 먼저 선택

1-a pint count가 0인 페이가 여러개일 때 페이지 교체정책을 도입한다.

2. dirty면, 디스크에 작성 한 다음에 clean

3. 해당 프레임에 요청받은 페이지를 작성하고

4. pin count를 증가시킨 다음에 해당 프레임 주소를 반환한다.

 

 * pin count의 주기

pin count가 0인 프레임이 없으면, 버퍼풀에 더이상 새로운 페이지를 올릴수가 없다. 

작업이 종료되면 pin count를 최대한 빨리 감소시켜야 하낟.

 

페이지 교체 정책

어떤 기준으로 버퍼풀에서 내릴 페이지를 선택할것인가?

 

LRU

least recently used

제일 먼 시점에 사용했던 페이지를 교체

-> temporal locality를 고려한 정책!!

 

* 이 정책을 위해 가장 최근에 pin count가 감소한 시점을 저장하는 last used column이 메타데이터에 포함된다.

-> last used 값이 가장 "작은"값을 교체한다.

 

단점 :  last used 값이 가장 작은 값을 찾으려면 선형시간이 필요하다. 우선순위힙을 사용한다고 해도 log시간이 걸린다

-> 너무 오래걸림! (상수시간안에 찾고싶음)

Clock

LRU 랑 비슷한 방식으로 동작하지만, 완벽하진 않음

 

-> 프레임들을 원형큐로 관리한다!!

그리고 가장 최근에 접근한 페이지의 fererecde bit를 보고 결정한다.

 

referece bit가 1이라는건 최근에 접근했다는 뜻이니까

 

clock hand가 원형큐를 빙글빙글 돌면서 0인 프레임을 찾는다.

이 때 1인애들은 0으로 초기화 하면서 돌아간다 (기회주는것!)

clock hand가 돌아오기 전에 또 접근되면 reference bit가 1이된다.

 

-> LRU의 단점인 min값 찾기가 필요없다.

 

 

LRU, CLOCK의 취약점

대량의 데이터를 순서대로 반복해서 읽을 때 문제가 발생한다.

 

버퍼풀에 프레임이 6개이고, 파일에 페이지가 7개 있다고 가정하면...

 

파일을 순서대로 여러번 읽을 때, 1, 2, 3,4, 5, 6, 7 순서대로 읽을것이다.

 

처음에 6까지는 버퍼풀에 올라간다. 7을 읽을때 캐시미스가 나고, 1번대신 7이 올라간다 [7 2 3 4 5 6]

다시 1을 읽을차례지만,, 또 캐시미스로 2를 내리고 1이 올라간다 [7 1 3 4 5 6 ]

 

... 이게 반복되면 파일을 읽는동안 캐시히트는 한번도 발생하지 않는다.

 

=> Sequential Flooding

 

MRU

Most recently used

위에 나온 sequential flooding 문제를 해결하는 방법이다!

LRU와 반대로, 가장 최근에 접근했던 페이지를 내린다.

 

=> 위랑 똑같은 예시를 반복하면 cache rate가 50%까지 증가한다.

 

... 계산해보면 MRU를 사용하면 한번의 반복마다 B-1 개의 hit가 발생하는것을 알 수 있다.

 

prefetch

sequetial scan 에서는 프리패치를 사용하는것이 가장 좋다.

=> 연속된 페이지를 한번에 요청하는것!

 

* Disk와 CPU는 병렬작업이 가능하다!

즉 Disk I/O가 일어난는동안, CPU는 다른 일을 할 수 있다.

 

- LRU : random access에 좋음

- MRU : 반복전인 sequential 접근에 좋음 (join이라던지)

 

즉 I/O 패턴에 따라 적절한 방식을 섞어서 사용하는게 좋다.

 

Two General Approaches

두개의 방식 (LRU, MRU)를 적절히 섞어 쓰기 위해서는 DBMS가 버퍼메니저에 도움을 주는 방법이 있다.

 

DBMS가 지금 쿼리 패턴을 파악해서, 버퍼메니저한테 어떤 정책을 선택하는게 좋은지 언질을 주는것이다.

 

아니면 2Q, LRU-2 같은 다른 방법들도 존재한다.

 

*postgrsql은 CLOCK을 사용한다구 한다!

 

DBMS VS OS Buffer Cache

오..ㅋㅋㅋㅋㅋ 운영체제의 캐시와 비교한다!

 

문제1 이식성

-> 서로 다른 운영체제의 캐시 정책이 달라서 DBMS의 일관성이 없어짐

 

문제2 DBMS 성능에 문제를 줄 수 있음

DBMS가 지원해야 하는 다양한 기능 (복구, 페이지관리, 페이지 교체 정책 관리 등등..) 을 운영체제의 캐시관리로 맡기면 불가능함!