Paper_Scalable database logging for multicores

Editor's Notes

• #3: 크게는 논문의 motivation과 design, implementation 순서로 설명 드림.
• #4: 먼저, 현재 상용화되어있는 데이터베이스의 주요 특징은 다음 두 가지임. 먼저, 기존의 WAL 프로토콜로 인한 문제를 짚음. 이것은 뒷장에서 자세히 설명함. 또, ACID property 중 본 논문에서는 본인들의 아이디어에서 Atomicity와 Durability 측면을 특히 강조함. 특히, Durability와 performance의 trade-off를 짚었음. 기존 DB들은 여기 표와 같이 performance(속도)가 느린 것을 해결하기 위해 durability를 포기하거나, durability를 위해 속도를 조금 포기하는 옵션을 제공함. (여기서 제시한 아이디어가 두 간극을 줄임)
• #5: 다음은 앞서 언급한 WAL protocol에 대한 것임. 기존에는 WAL을 위해 다음 그림과 같은 아키텍처를 주로 사용함. 여기서 저자들은 두 가지 이슈를 제시함. 첫번째는 central log buffer 자체의 scalability, 두번째는 synchronous I/O delay임.
• #6: 먼저, central log buffer의 scalability 문제임. 이 예시대로, central log buffer를 공유자원으로 두고 lock을 사용한 방식은 multicore 환경에서 성능적 한계가 있음.
• #7: 먼저, central log buffer의 scalability 문제임.
• #8: 먼저, central log buffer의 scalability 문제임.
• #9: 먼저, central log buffer의 scalability 문제임.
• #10: 먼저, central log buffer의 scalability 문제임.
• #11: 먼저, central log buffer의 scalability 문제임.
• #12: 먼저, central log buffer의 scalability 문제임.
• #13: 다음은 synchronous I/O delay 문제임. 기존 WAL protocol에 의하면 thread는 log를 먼저 쓰고 storage에 flush한 뒤에야, 실제 데이터를 write하는 order를 지켜야함. 이 때, flush, 즉 disk I/O를 하느라 thread가 기다려야하는 시간을 synchronous I/O delay라고 함. 스토리지 디바이스로 HDD 대신 NVM을 쓰면 delay가 줄기는 하지만 이 논문에서 제안한 방법을 사용하면 더 성능이 좋다고 저자들은 이야기함.
• #14: 여기까지의 내용을 정리하면, 현존하는 DB의 central log buffer 방식이 scalability에 있어서 한계가 있고, synchronous I/O delay 등 성능상의 문제가 있다는 점을 모티베이션으로 했음. 저자들은 이를 해결하기 위해 멀티코어에서의 Parallel logging를 제안함. 그것을 ELEDA라고 하며, 기존 central log buffer의 성능적 병목을 해결하는 concurrent data structure를 활용해서 atomicity와 durability를 보장하면서도 성능이 좋은 트랜잭션 시스템이라고 이야기함. 성과를 간단히 언급하면, WiredTiger와 Shore-MT라는 DB에 이를 적용해서 성능적 향상을 보았다고함. 예를들면, 가장 좋은 케이스의 경우 트랜잭션 throughput이 3백90만 Transaction per second까지 향상됨을 보였음.
• #15: 이제 본격적으로 디자인에 대한 내용임. 저자들은 ELEDA의 핵심 디자인 기법을 Grasshopper라 이름지었음. 앞서 말한 멀티코어에서의 Parallel logging 기법을 구현하는 데에는 다음과 같은 세가지 정도의 이슈가 있음.
• #16: 먼저, 각 로그의 시퀀셜리티를 보장해주어야함. 간단히 언급하면, ELEDA에서는 lock 대신 fetch and add operation을 활용해 transaction별로 고유한 번호를 부여했음. 이를 Log sequence number, LSN이라함.
• #17: central log buffer 앞 쪽부터 sequential한 log block들을 flush해주기 위해, 가장 처음 등장하는 hole이 어딨는지 빠르게 찾을 수 있어야함.
• #18: 마지막으로, concurrent하게 log를 버퍼링하고, 또 버퍼된 로그를 스토리지에 flush할 수 있어야함.
• #19: 정리하면, concurrent data structure와 기법으로, concurrent한 버퍼링 및 플러싱과 빠른 hole detection을 가능케해야함.
• #20: 이를 위해서 ELEDA에서 제안한 방식은 다음과 같음. 먼저, concurrent한 연산을 위해 thread를 세 가지 타입으로 정의함. 먼저 hole을 트래킹하는 worker, worker가 찾아준 SBL 정보로 flush를 하는 flusher, 그리고 log를 버퍼에 copy하고 GC 등의 작업을 하는 기존 DB thread들임. 세 thread는 central log buffer를 global 자료구조로 보고, worker는 hopping index table과 hopping, crawling list, min heap 세 자료구조를 사용함. 그리고 DB thread들은 thread 별로 crawling list, hopping list의 두 개의 list를 유지함. 이게 뭐하는 자료구조인지는 뒤에서 설명함.
• #21: 앞서서 간단히 언급했던 parallel logging의 구현 이슈를 더 자세히 설명함. DB thread가 transaction의 log를 buffer로 copy할 때에는 LSN(log sequence number)를 부여해서 각 thread가 독립적으로 서로 간섭 없이 (lock도 없이) central buffer에서 자신의 위치를 찾아 copy함.
• #22: 기존에는 flush할 때 hole이 있으면 log hole이 채워지는 것을 기다림. multicore여도 한꺼번에 내려서 multi로 하는 이점이 없었음. > algo (1) 버퍼 중간 중간에 연속된 로그가 생기면 flush하게 함. central buffer에 lock을 쓸 수도 있지만 오버헤드가 크므로 안 쓰고 thread가 각각 fetch & add 연산 수행. 이 때 발생하는 hole을 효과적으로 detect하는 알고리즘을 바로 설명하겠음.
• #23: hole을 detect하는 작업은 앞서말했듯 worker thread가 수행함. 여기서 grasshopper 알고리즘이 등장함.
• #24: worker가 유지하는 자료구조 중 하나인 hopping index table에는 central log buffer를 2의 H승이라고 표현된 DB의 한 페이지 크기 단위로 잘라서 보았을 때에 한 단위 안에 들어있는 log들의 크기를 저장함. 저 테이블을 차례로 보면서 그 값이 2의 H승으로 꽉 차있다면 log를 page 단위로 hopping함. 그 값이 만약 2의 H승보다 작다면 hole이 있다는 의미이므로 그 페이지의 시작점부터는 log 단위로 크롤링함.
• #25: 다음은 synchronous I/O delay에 대한 해법임. > algo (2) 이런 latency를 hiding하는 asynchronous I/O 제안함. thread가 만약 transaction 1 실행 중 log를 flush해야하는 경우가 생긴다면, 이걸 기다리지 않고 transaction 2로 context switching. 이 때 flush thread가 일을 다 끝내고 callback하면, 다시 trans 1로 돌아와서 실제 데이터 write 수행함.
• #26: 다시 정리하면, Thread type은 DB, worker, flusher. DB thread들 각각은 crawling-list와 hopping-list 한 쌍을 유지. 각각 c, h list라고 줄여부름. 이 때 c-list는 LSN 단위로, h-list는 DB 페이지 단위로 유지. worker는 min heap과 hopping index를 유지. 이 때 min heap은 c-list의 LSN의 최소들만 유지. 이것들이 실제로 쓰이는 과정을 설명하기 위해 앞에서 말한 기법을 data structure level에서 보여드리겠음.
• #27: 간단한 예시로 다음과 같이 스레드 1, 2, 3별로 log가 central buffer에 저렇게 위치한다고 가정. 또, DB page size는 4KB로 가정 단어 SDL: storage durable LSN SBL: sequentially buffered LSN LSN: log sequence number LSN hole: partially buffered log
• #28: 이런 상황에 worker thread의 hopping index table은 다음과 같이 값을 가지게됨. 단어 SDL: storage durable LSN SBL: sequentially buffered LSN LSN: log sequence number LSN hole: partially buffered log
• #29: 동시에 각 thread의 h-list와 c-list는 다음과 같은 모습을 보임. 말한대로 h-list는 page를 관리하고, c-list는 LSN(log)를 관리함. 이 때에, 각 thread의 c-list에서 최소의 LSN을 Min heap 구조로 유지함. 여기에는 생략했지만 DB thread가 LSN을 추가할 때마다 hopping index table의 값에 + log size해주며 채워감. 이 때에 DB thread들의 hopping index에 대한 multi write는 시스템적으로 불허함.
• #30: 이러한 상황에 worker thread가 어떻게 hole을 tracking하고 flusher thread에게 어떤 정보를 전달하는지 설명함. 먼저, worker는 hopping index table을 스캔해서 4KB가 되지 않는 곳의 인덱스에서 하나를 뺀 hopping boundary를 찾음. 즉, hole이 있는 페이지 구간의 직전 페이지 인덱스를 얻음. 여기서는 2. 그 후 page 2번과 관련된 모든 아이템들을 c-list와 h-list에서 지움. 그 후, 다시 heap을 build함. 이 3번까지의 작업을 끝내면 다음장과 같은 그림이 됨.
• #31: 이렇게됨. 여기서 min을 pop하여 SBL의 정보를 얻음.
• #32: 그 후, flusher는 LSN 1부터 7까지의 시퀀셜 로그를 스토리지에 플러시함. 여기까지가 ELEDA 및 grasshopper 알고리즘에 대한 주요 설명임.
• #33: 이에 대한 구현을 어떻게 할지는 다음과 같이 생각함. 앞서 정리한 표에 따른 자료구조와 메소드를 구현할 것임. 이 때, 논문의 표에 따르면 각 자료구조의 포인터에 대한 스레드 세 개의 접근 권한을 달리해서 lock 없는 concurrent logging을 완성하였으므로 저 정보를 참고하여야할 것임.
• #34: 특히, wiredtiger와 shore-mt 중 shore-mt에 대한 구현은 다음과 같이 언급함. Aether를 활용해서 shore-mt에 ELEDA를 구현했음. 이 때, 기존의 array-based logging subsystem을 ELEDA의 디자인대로 교체했고, transaction context switching을 위해서 flush pipelining을 구현했다고 함.
• #35: 이 외에 GC와 flush에 대한 구현도 더 고민해보아야할 것임. 특히 flusher thread 구현 시 한 번 flush할 때의 I/O 단위에 대해서는 저자도 여지를 남겨둠. 논문에서는 64와 512KiB 두 경우에 대해 평가했으며, 여전히 latency와 bandwidth 간 trade-off가 있어서 잘 조절해야한다고 언급함. (커뮤니티에 이 문제에 대해서 오픈 해놨다고 함.)
• #36: 또한, hopping index를 DB thread가 접근할 때 시스템적으로 한 번에 하나씩 시퀀셜하게만 허가한다는 점 등, concurrent design과 거리가 먼 것들이 추후 개선 대상이 될 수 있을 것이라 생각함. 그리고 evaluation의 카테고리는 다음과 같으며 일단은 생략하겠음
• #37: 다시 정리하면, 현존하는 DB의 central log buffer 방식이 scalability에 있어서 한계가 있고, synchronous I/O delay 등 성능상의 문제가 있다는 점을 모티베이션으로 했음. 저자들은 이를 해결하기 위해 멀티코어에서의 Parallel logging를 제안함. 그것을 ELEDA라고 하며, 기존 central log buffer의 성능적 병목을 해결하는 concurrent data structure를 활용해서 atomicity와 durability를 보장하면서도 성능이 좋은 트랜잭션 시스템이라고 이야기함. 성과를 간단히 언급하면, WiredTiger와 Shore-MT라는 DB에 이를 적용해서 성능적 향상을 보았다고함. 예를들면, 가장 좋은 케이스의 경우 트랜잭션 throughput이 390만 Transaction per second까지 향상됨을 보였음.
• #38: 앞으로 할 일을 대강 세 단계로 분류했음.
• #41: 어떤 부분 수정이 필요할 지 예상해볼 필요가 있음.
• #42: 사실 ELEDA 논문에서는 해당 버전의 shore-MT에 멀티코어 scalability를 제공하는 여러 기능(DB locking, latching, logging)이 이미 구현이 되어있다고 함. 따라서, 기존의 logging을 기반으로 optimization을 했다고 함. 최적화 파트는 밑줄로 표시된 부분으로 예상. Aether에서 Flush pipelining, Consolidation array 각각의 내용 이해할 필요가 있음. 특히, consolidation array! flush pipelining은 flush thread와 worker thread 간 통신 구현해야할 것. (SBL 정해지면 worker가 flusher에게 그 위치를 콜백으로 넘겨줘야함.)
• #43: Shore-MT(default) → Aether → ELEDA 각각이 어디까지 구현이 되어있는지 정의해야함. (ex) multi logging by DB threads, … 저 consolidation array가 어떤 기능 의미하는지 파악. 즉, 각 부분이 ELEDA의 어떤 모듈과 치환될 수 있는지 정의해야함.