서울대학교 데이터사이언스대학원 정형수 교수님의 "빅데이터 및 지식 관리 시스템 2" 강의를 필기한 내용입니다.
완성되지 않은 강의록
- 사진이랑 보충 설명 넣고, vDriver 는 별도의 논문 리뷰 작물로 분리할 계획입니다.
- 그리고 작물 migration 이후에는 alias 도 바꿔주는 것 잊지 말자.
Long Lived Transaction, LLT
- 보통 disk-based DBMS 에서 MVCC version GC 를 할 때는, oldest txn 을 기준으로 그 이전 애들을 GC watermark 로 찍어놓고 걔네들을 GC한다.
- 그럼 당연히 Long-Lived Transaction (LLT) 가 생기면 이 하나의 LLT 때문에 GC watermark 가 바뀌지 않아 version 들이 GC 되지 않고, 따라서 query 도 느려지고 storage 사용량도 늘게 된다.
- MySQL 은 N2O 여서 LLT 가 page read latch 를 전부 붙잡고 있기 때문에 latch overhead 가 커지고,
- Postgres 에서는 in-row 방식인데 GC 가 안되기 때문에 table size 가 커져 계속 index split 이 발생하여 그것으로 인한 overhead 가 커진다.
- 이런 GC watermark 방식 말고 version chain 에서 중간에 것을 다 GC 하기 위해서는 각 version 이 존재하는 page 를 하나하나 읽어서 RID pointer 를 바꾸는 작업을 계속 해야되기 때문에 매우 느리다.
Version Driver (vDriver, SIGMOD’20)
- SSD page erase 처럼, page 에 비슷한 lifetime 을 갖는 version 들을 모아놓고 lifetime 이 만료되면 page 를 통으로 날리는 방법을 사용해보자가 이 논문의 아이디어
- SIRO
- Off-row versioning 은 version store 에 들어가기 때문에
- recovery 시에 version traversal 도 힘들고 이 데이터들이 recovery undo log 로 사용되기 때문에 dead version 이 되어도 함부로 지우지 못한다.
- table size 는 커지지 않아 index 의 크기가 작다
- 반면에 In-row versioning 은 version 들이 동일 table 에 있기 때문에
- recovery 시에 version traversal 이 유리하지만
- index SMO 가 너무 많이 발생한다
- 그래서 최신 commit version 만을 inline 하여 recovery 에서는 해당 inlining 된 version 을 사용하여 version storage 에서의 recovery 의 역할을 없애고 나머지는 전부 version storage 로 보내서 table size 도 안커지게 하는 것이 SIRO 다
- Off-row versioning 은 version store 에 들어가기 때문에
- SIRO 를 사용하면 version 의 lifetime 을 알 수 있다.
- Disk-based 에서는 version 의 lifetime 을 정확하게 알기 힘들다
- 원래의 version lifetime 은 해당 version 을 생성한 txn 의 commit time ~ 다음 version 을 생성한 txn 의 commit time 인데
- Disk-based DB 에서는 (Postgres 기준) commit time 이 아닌 begin time 을 적고 이놈이 commit 되었는지는 log 를 통해 확인하기 때문
- 근데 SIRO 를 쓰면 commit 되었을 때 inlining 되고 다음 version 이 commit 되면 원래 inlining 되어있던 놈이 version storage 로 빠지므로 이 두 시간 간격을 이용하면 version storage 로 빠지는 version 에 대해 lifetime 을 알아낼 수 있다.
- Version classification
- 위에서 알아낸 version lifetime 으로 version hot/cold 를 classification 하고, 별도의 storage 에 저장한다.
- 그리고, 어떤 txn 이 LLT 라고 판단되면 그놈이 볼 수 있는 데이터도 별도로 classification 한다
- Pruning
- 1st pruning
- Version lifetime 을 알아냈는데, 운좋게 이놈이 dead zone 에 포함되어 있는 dead version 이면 version storage 로 보내지 않고 그냥 DRAM 에서 날려버린다.
- 이놈의 효과는 굉장히 좋다: 실제로 돌려보면 최소 75% 가 1st pruning 에 걸린다고 한다 (zipfian 1.4)
- zipfian 0 (all uniform) 의 경우에는 97% 까지 올라간다고 한다
- 2nd pruning
- Version classification 을 한 다음에 각 class 별로 buffer 를 사용하게 되는데, 이때 buffer 의 page 에 대해 그 안의 모든 version 의 ts 최소와 ts 최대를 추적한 다음
- 만약에 이 page 가 evict 될 때 저 ts 들을 이용해 만약에 이 page 전체에 대해 이놈을 볼 수 있는 txn 이 없다면 (즉, 이 page 의 version 전체가 dead zone 에 걸린다면) 이 page 도 disk 로 flush 하지 않고 그냥 DRAM 선에서 날려버린다.
- 이걸로 zipfian 1.4 에서도 90% 까지 올릴 수 있다고 한다.
- 1st pruning