서울대학교 데이터사이언스대학원 정형수 교수님의 "빅데이터 및 지식 관리 시스템 2" 강의를 필기한 내용입니다.
Logging Bottleneck
- 보통 DBMS 에서 제일 bottleneck 이 되는 포인트는 buffer pool, lock table, log buffer 이다.
- 순위로 보면 lock table > log > buffer pool 이다.
- 여기에 index 도 buffer pool 과 비슷하게 bottleneck 이 된다고 한다.
- WAL principal 을 간단히 복습해 보면
- Commit 직전 혹은 Data page 가 replace 되어 flush 되기 직전에
- Log buffer 를 flush 하여서 항상 log 는 data 보다 앞서서 (Write-ahead) 저장되게 하는 것.
- Log 는 무한히 늘어나는 virtual file 에 저장되고, 이 file 에서의 offset 이 LSN 으로써 사용된다.
- 여기서 당연히 bottleneck 이 되는 포인트는 log buffer 는 sequential 하게 (overlap 혹은 hole 이 없이) 채워져야 하기 때문에 sequentiality overhead 가 발생한다.
- 즉, buffer 에 들어갈때 latch 를 잡고 이런 정렬 작업을 해주게 되고,
- 이로 인해 thrashing 이 발생하게 된다.
- 이놈을 해결하기 위해 지켜져야 하는 invariant 는 sequentiality of logging 이다.
- 즉, 순서대로, overlap, hole 이 없이 저장되어야 한다는 것.
- 일단 순서대로, overlap 없이 저장하는 것은 atomic FAA 로 unique 하게 증가시켜서 자리를 받는 것으로 해결할 수 있다.
- 하지만 hole 없이 flush 하기 위해서는 어디까지 flush 할지 결정해야 한다.
- 지금 자리만 선점해놓는 매커니즘이기 때문에 실제로 copy 가 이루어져서 어디까지가 overlap, hole 이 없는지 확인해야 한다.
- 이러한 boundary 를 Recoverable Logging Boundary (RLB) 라고 한다.
Eleda (VLDB’18)
내용 옮겨짐
Border-Collie (SIGMOD’19)
내용 옮겨짐