[DB] 데이터베이스 버퍼

Buffer management(버퍼 관리)

데이터베이스 파일과 메인 메모리는 fixed-length 블럭으로 나뉘어져있음

데이터베이스 시스템은 memory와 disk의 블럭 연산을 최소화하도록 설계됨 (디스크의 접근 오버헤드가 크기 때문)

Buffer manager : 데이터베이스 시스템 버퍼를 관리

버퍼 매니저의 역할

데이터 read 시

1. 버퍼 내에 요청된 블럭이 있는지 확인 -> 있으면 넘겨줌
2. disk 에서 읽어옴 -> 버퍼가 가득 찼으면 victim block 을 선정 후 쫓아냄
1. victim block 이 write 된 적이 있는 dirty block 이면 write back
2. 따라서 보통 read only block 을 선정
3. 읽어와서 넘겨줌

Victim block 전략

LRU : Least Recently Used

LRU 가 최악의 성능을 내는 경우 : join

Pinned block : Victim 으로 절대 선정되어서는 안되는 block

예를 들어 commit 되기 전의 log block -> 없으면 recovery 불가

Toss-immediate strategy : 특정 블럭이 다시 사용되지 않을것 같으면 바로 free -> join 용 블럭

MRU(Most Recently Used)

 

버퍼 매니저는 디스크에 강제로 write 하는 forced output 기능이 있음

데이터 페이지 버퍼링

WAL(Write Ahead Logging)

버퍼에 자리가 없어서 vicitm block 을 선정하여 쫓아내는데 해당 블럭에 아직 커밋되지 않은 데이터가 있을 수 있음

그런 경우 버퍼의 로그 정보를 반드시 먼저 디스크에 저장하고, 해당 블럭을 쫓아내는 기법을 WAL 이라 함

 

Latches : victim 으로 선정된 블럭에 write 하면 연산이 꼬이므로 이를 막기 위해 X-lock 을 잠시 거는것

 

버퍼 구현

• Real main memory : 다른 어플리케이션에 의해 조각나있는 경우가 많음
• Virtual Memory : 주로 사용
• Dual paging 문제
  디비가 어떤 페이지의 블럭을 요청했는데 Buffer Manager 상에서는 메인 메모리에 있다고 생각하지만 OS가 메모리 관리를 위해 swap 영역으로 내쫓은 상태라면 해당 페이지를 다시 메모리로 불러와야하는 추가 연산이 필요함

Slotted page structure

헤더와 실제 레코드 사이에는 공백이 있음 (레코드가 추가되면 헤더 뒤에 포인터가 추가되어야 해서 그런게 아닐까)