Design of Flash-Based DBMS: An In-Page Logging Approach

1. Design of Flash-Based DBMS: An In-Page Logging Approach 한국외국어대학교 컴퓨터및정보통신공학과 DISLAB 박성환 (shpark@dislab.hufs.ac.kr)

2. 목차 • 서론 • 디자인 원칙 • 플래시 메모리의 특성 • 이전 디자인의 문제점 • 디자인 정책 • In-Page loggingapproach • 기본 개념 • IPL의 설계 • 합병 연산 • 성능 평가 • 디스크 기반 데이터베이스 서버의 성능 • TPC-C benchmarktest • 요약 • 복구 지원 • 추가적인 logging과 data 구조 • Transaction commit • Transaction abort • System 재 부팅 • 관련 연구 • 결론

3. 서론 • 최근 플래시 메모리의 인기가 높아짐 • PDA’s , MP3 player , Mobile phone , Digital camera 에 탑재 • 최근 10 Gbytes가 넘는 NAND 플래시 메모리가 탑재되어 출시됨 • 플래시 메모리에 DBMS를 적용시키는 것이 어렵지 않음 • 플래시 메모리의 가격이 낮아지고, 대용량화 되며, 성능이 좋아지고 있음 • 이 논문에서는, 플래시 메모리 기반 데이터베이스 서버를 위한 IPL (In-Page Logging)을 제안함 • IPL은 자연스럽게 transaction의 복구를 지원이 가능함

4. Magnetic 디스크 vs. NAND 플래시 메모리 • 최근 같은 크기의 I/O 속도를 비교해 보면 NAND 플래시 메모리가 더 빠름

5. OLTP에 대한 플래시 메모리의 특성 • OLTP • On-Line Transaction Processing • 네트워크상의 여러 이용자가 실시간으로 데이터베이스의 데이터를 갱신하거나 조회하는 등의 단위 작업을 처리하는 방식 • 플래시 메모리는 OLTP에서 처럼 임의적인 위치에 매우 작은 쓰기 연산이 발생되면, 성능이 매우 나쁘다고 알려져 있음 • FTL 상에서의 이야기로 생각됨 • 따라서, 플래시 메모리는 이러한 패턴의 I/O를 효율적으로 처리할 수 있어야 함

6. IPL의 제안 • 플래시 메모리 기반의 데이터베이스 서버를 위한 IPL기법을 제안 • 데이터 페이지에 업데이트 요청이 들어오면, 페이지 전체를 업데이트 하지 않고, 수정되는 것에 대한 정보만을 기록 • 페이지 변화에 대한 log들을 sector단위로 플래시 메모리의 log 영역에 저장 • 이러한 log들은 합병 연산 시에 데이터 페이지와 병합될 수 있음

7. IPL의 간단 요약 • IPL은 플래시 메모리의 단점을 극복하고, magnetic 디스크를 대체시킬 플래시 메모리를 위해서 제안되었음 • 경험적인 실험에 의해 IPL이 OLTP와 같은 전통적인 데이터베이스의 쓰기 성능을 증진시킬 수 있음이 증명됨 • IPL 디자인은 기존 데이터베이스 서버의 구조의 변화를 최소화 시키면서, 최고의 성능을 달성할 수 있음 • IPL의 기본적인 디자인을 조금만 수정함으로 해서, 적은 비용으로 데이터베이스 시스템의 복구가 가능함

8. 2. 디자인 원칙 2-1. 플래시 메모리의 특성

9. No In-Place 업데이트 • Magnetic 디스크는 같은 자리에 효율적으로 업데이트가 가능 • 플래시 메모리의 경우 같은 자리의 업데이트는 불가능 • 해당 블록의 다른 페이지들을 복사한 뒤 블록을 소거하고, 업데이트를 한 뒤, 다른 페이지들을 갱신해야 함 (매우 비 효율적) • 작은 자료의 업데이트는 소거와 쓰기의 overhead가 발생 • 이를 개선하기 위해 저장 서브시스템의 새로운 디자인이 필요함

10. No 기계적지연 • Magnetic 디스크는 seek나 rotation 시간이 자료 입출력의 시간 지연을 가져옴 • 읽기/쓰기 시간이 일정하지 않은 경우가 발생함 • 이에 반해, 플래시 메모리는 입출력 시에 지연 없이 동일한 시간에 읽기/쓰기가 가능함 • 데이터베이스는 인접한 자료를 물리적으로도 인접하게 하려는 경향이 있음 • 플래시 메모리에서는 이러한 제약이 필요 없음

11. 다른 읽기/쓰기 연산 속도 • 플래시 메모리는 읽기와 쓰기의 속도가 다름 • 쓰기 연산 시 셀(cell)에 충전하는 시간이 읽기 연산보다 오래 걸림 • 기존 데이터베이스는 이러한 플래시 메모리의 특성이 고려되어 있지 않음 • 플래시 메모리 기반 응용 데이터베이스는 이러한 특징을 고려해야 함 • 비교적 오랜 시간이 걸리는 쓰기 연산을 줄여야만 함 • 플래시 메모리의 쓰기 연산은 부가적으로 소거 연산을 가져옴 • 소거 연산은 쓰기 연산에 비해 더 오랜 시간이 걸림

12. 2. 디자인 원칙 2-2. 이전 디자인의 문제점

13. 디스크 기반 데이터베이스 • 대부분의 디스크 기반 데이터베이스의 특징 • 페이지 I/O 단위 메커니즘을 사용 • 하드웨어 특성을 이용한 순차적인 접근을 활용 • In-place로 데이터를 업데이트가 가능하기 때문에 잦은 업데이트를 잘 처리하는 편임 • Magnetic 디스크가 플래시 메모리로 대체된다면 • 데이터베이스의 In-place 업데이트는 많은 소거와 쓰기 연산을 가져옴 • 이는, 큰 지연을 가져오게 됨 • 또한, 플래시 메모리는 한 블록에 일정 수의 소거 연산이 수행되면, 데이터의 신뢰성을 보장하지 못함

14. 순차적인 Logging • 대부분의 플래시 메모리 장비는 수명을 위해 소거 횟수 평준화(wear leveling)을 수행 • Log기반 플래시 파일 시스템 중에 하나인, ELF는 새로운 순차적인 log entry를 사용함으로써 소거 횟수 평준화를 달성함 • 이를 사용함으로써 업데이트는 빈 섹터가 존재하면 소거연산을 하지 않아도 됨 • 하지만, 이러한순차적인 logging은 데이터베이스의 전체적인 성능을 향상시키지는 않음 • 읽기 연산 시 부가적인 오버헤드가 있음 • 빈 섹터를 빠르게 소비함

15. 디스크 기반 서버 성능 • Magnetic 디스크는 순차적인 위치보다 임의적인 위치에 읽기/쓰기 연산이 더 오래 걸림 • Seek와 rotation시간이 오래 걸림 • 플래시 메모리는 순차적인 위치나 임의적인 위치의 읽기 연산은 비슷한 시간이 걸림 • 플래시 메모리는 순차적인 위치의 쓰기 연산보다 임의적인 위치의 쓰기 연산이 더 오래 걸림 • 더 많은 소거와 쓰기 연산을 가져옴

16. 2. 디자인 원칙 2-3. 디자인의 정책

17. 디자인 정책 • 플래시 메모리 기반의 데이터베이스 서버를 설계 시 두 가지 수준을 고려해야 함 • 휘발성 RAM 메모리 • 비 휘발성 플래시 메모리 • Log record들은 플래시 메모리 전반에 걸쳐 분산되어도 상관없으며, 순차적으로 기록할 필요가 없음 • 임의적인 위치 접근속도가 순차적인 위치 접근 속도와 같음 • 읽기와 쓰기 속도가 다름 • Erase-before-write 의 제약을 극복해야 함 • DBMS의 전반적인 구조의 수정을 최소화 해야 함

18. 3. In-Page Logging approach 3-1. 기본 개념 3-2. IPL 디자인 3-3. 합병 연산

19. 기본 개념 • 쓰기 연산이 발생되면, 전체 페이지를 기록하지 않고변화된 부분만 한 페이지(log)에 기록함 • 기존 디스크 기반의 데이터베이스에서 log는 순차적으로 저장됨 • 디스크 기반에서는 seek와 rotation 시간을 줄이기 위함 • 데이터베이스에서 읽기를 요청하면, 해당 log를 탐색하여 본 페이지와 합쳐서 처리해야 함 • Overhead가 있음 • 반면, 플래시 메모리에서는 임의적인 위치에 기록하여도 지연시간이 없음 • Log를 순차적으로 기록할 이유가 없음 • 때문에, log를 같은 erase unit에 데이터 페이지와 같이 저장 • 이를 IPL(In-Page Logging)이라 함

20. 기본 개념 (Cont.) • 현 버전의 페이지를 요청 받으면 예전 페이지와 이와 관련된 log들을 읽어 현 버전을 반환해줘야 함 • 이는 부가적인 작업이 필요함 • 하지만, IPL기법을 통해 쓰기 연산을 줄일 수 있음 • IPL 기법은 전반적인 쓰기 연산의 비용을 개선 가능함 • 쓰기 연산의 비용이 읽기 연산의 비용보다 더 크기 때문

21. IPL의 디자인 • IPL이 최소한의 비용으로 동작하기 위해서는 데이터베이스의 수정이 불가피함 • 버퍼 매니저 (Buffer manager) • 저장 매니저 (Storage manager)

22. IPL의 디자인 (Cont.) • IPL은 데이터 페이지가 dirty될 때 log 섹터를 할당 받아서 변화만을 기록함 • 이는 모두 메모리 버퍼에서 일어남 • 메모리에 있는 log 섹터는 플래시 메모리 해당 블록의 log 영역에 기록되면 해제됨 • 플래시 메모리에 영구 기록될 시에 버퍼에서 해제함 • 블록에 포함된 페이지들의 log 섹터는 해당 블록의 log 영역에 기록 • In-memory log 섹터는 다음의 경우 플래시 메모리에 기록함 • Log 섹터가 꽉 찼을 경우 • 버퍼 관리자가 dirty 페이지를 victim으로 선정했을 경우

23. IPL의 디자인 (Cont.) • In-memory log 섹터는 쓰기 버퍼와 같은 역할을 함 • 여러 log record들이 한 번에 같이 기록될 수 있음 • 잦은 소거 연산도 피할 수 있음 • Log 섹터를 기록시에는 데이터 페이지를 기록할 필요가 없음 • 변화된 부분들이 모두 log 섹터에 있기 때문

24. IPL을 위한 저장 관리자 • 플래시 메모리의 블록은 데이터 페이지 영역과 log 영역으로 구분 되어야 함 • 이를 저장 관리자가 지원해야 함 • 예 • Large block의 경우 한 블록은 128K임 • 각각 8K크기의 데이터 페이지 15개 • 각각 512B크기의 log 섹터 16개 • 만약 log 영역이 꽉 차게 되면, 데이터 영역과 log 영역을 새로운 빈 블록에 합병 • 저장 관리자는 IPL에 맞는 합병 연산을 지원해야 함 • 합병연산은 뒤에 자세히 다룸

25. 읽기 연산의 수정 • 읽기 연산은 이전 페이지와 이와 연관된 log를 읽어 새로운 페이지로 보여줘야 함 • 이는 I/O 시간과 CPU 계산 시간이 걸림 • I/O 시간 (이전 페이지와 log 섹터를 읽음) • CPU 계산 시간 (이전 페이지와 log 섹터를 합쳐서 최신 페이지를 생성) • 앞에서도 언급했듯이, 읽기 연산의 오버헤드는 IPL을 사용함으로서 얻어지는 쓰기와 소거 연산의 회수 감소로 보상 받을 수 있음

26. 합병 연산 • In-memory log 섹터는 제한되어 있으며, 플래시 메모리의 log 영역이 가득 차게 되면, 합병 연산이 필요함 • 이는 IPL 저장 관리자가 수행 • 기본적으로 합병연산은 읽기나 쓰기 연산보다 오래 걸림 • 합병 비용 식 • Kd와 kl: Erase unit안의 데이터 섹터와 log 섹터의 개수 • 추가적으로 데이터 페이지와 log record들을 합치는 연산 비용이 듬 • 합병 연산이 완료되면, 새로운 블록에 대한 매핑 정보를 갱신해야 함

27. 합병 연산 알고리즘

28. 4. 성능 평가 4-1. 디스크 기반 데이터베이스 서버 성능

29. 실험 환경

30. 실험 환경 (Cont.) • Raw 장비로 설정하고, logging 옵션을 주지 않음 • 캐싱이나 logging시의 간섭을 피하기 위함 • 대부분의 I/O는 데이터 페이지나 인덱스 노드에 집중될 것임 • 실험 테이블 생성 • 650 bytes크기의 record 640,000개 삽입 • 데이터베이스 페이지 = 10 record 삽입됨 • 데이터베이스 페이지는 총 64,000개가 사용되며, 플래시 메모리의 블록은 총 4,000개가 필요함 • 실험 테이블에 처음 두 개의 column은 integer 타입

31. 읽기/쓰기 성능 평가 질의 패턴

32. 읽기/쓰기 성능 • 일반적인 시계 (the wall clock)로 측정 • 읽기 성능 • 디스크는 임의적으로 읽을 수록 seek와 rotation 시간이 오래 걸림 • 플래시 메모리는 디스크와 같은 기계적 지연 시간이 없음 • 쓰기 성능 • 디스크의 경우 읽기와 비슷한 경향을 보임 • 플래시 메모리는 놀랍게도, 임의적인 위치의 쓰기 연산인 경우 디스크보다 성능이 나쁨 • 이는 많은 소거와 쓰기 연산이 발생하여 지연이 큼

33. 버퍼의 영향 • 플래시 메모리는 소거 연산을 피하기 위해 버퍼의 용량을 늘림 • 실험에서는 플래시 메모리가 16 Mbytes의 버퍼를 사용함 • 1 Mbytes는 8개의 erase unit(128K)을 버퍼링 가능함 • Q4의경우, 순차적인 업데이트는 4,000개의 erase unit이 순차적으로 버퍼에 복사되고, 소거되는 모습을 보임 • 버퍼의 활용도가 매우 높음 • Q5나Q6의 경우, erase unit의 한 페이지만 버퍼에 복사되고, 16개의 erase unit이 할당되면, 다시 플래시 메모리에 업데이트 되는 모습을 보임 • 버퍼의 활용도가 매우 낮음

34. 4. 성능 평가 4-2. TPC-C Benchmark Test

35. TPC-C Trace 생성 • TPC-C benchmark를 생성하기 위해 Hammerora 를사용함 • Open source tool • TPC-C version 5.1을 지원 • 리눅스 플랫폼에서 기존 데이터베이스 서버를 통해 Hammerora를 수행 • 변수를 둠 • 데이터베이스의 크기 • 질의를 내리는 사용자 수 • 시스템 버퍼 풀의 크기 • 아래와 같은 설정에서 log record들을 뽑아냄 • 단, 데이터베이스는 log record에 쓰기 연산에 정보만을 기록 • 하지만, 이 논문에서 필요한 정보는 쓰기 연산임

36. TPC-C Benchmark의 업데이트 패턴 (1) • 평균 log의 크기는 50 bytes를 넘지 않음 • 보통 플래시 메모리의 1섹터의 크기가 512bytes임 • 메모리 버퍼에 10개 이상의 log를 저장할 때까지는플래시 메모리에 기록할 필요가 없음을 의미함 • 10개의 log를 모아서 기록이 가능함

37. TPC-C Benchmark의 업데이트 패턴 (2) • (a) : 페이지가 기록되기 전에 생성하는 log들의 지역성의 정도 • 특정 페이지들에 잦은 업데이트가 있음을 볼 수 있음 • (b) : 실제 물리적인 페이지의 업데이트의 지역성 • 역시, 특정 페이지에 쓰기 연산이 몰려있음 • (c) : 물리적인 erase unit의 소거 연산도 특정 블록에 치우쳐 있음

38. 쓰기 성능 평가 • 본 논문에서는 TPC-C에서 생성된 log를 실험하기 위해 simulator를 작성함 • 4가지 타입의 log record • 삽입, 삭제, 업데이트 • 데이터 페이지의 쓰기 • 해당 log의 타입에 따라 logging의 수를 계산하거나, 쓰기, 합병에 대한 수를 계산함

39. Log 영역 크기에 따른 IPL의 성능 • 가장 좋은 성능을 내는 log영역의 크기를 측정하기 위해 erase unit의 log 영역의 크기를 가변적으로 실험함 • 8 Kbytes ~ 64 Kbytes • 총 섹터 쓰기 연산 수 • 업데이트 참조 패턴과 데이터베이스의 버퍼 replacement 정책에 의해 결정되는 값 • 이는 log 영역의 크기와 독립적인 값임 • 작은 버퍼의 크기는 in-memory log 섹터를 자주 플래시 메모리에 기록하게 하지만, 섹터의 쓰기 연산 수는 업데이트 참조의 수와 비교하여 월등히 줄어 듬

40. Log 영역 크기에 따른 IPL의 성능 (Cont.) • 한편, 합병 연산의 수는 log 영역의 크기에 영향을 받음 • Hot 페이지의 잦은 업데이트는 log 영역이 작을 때 더 심한 합병을 유발할 수 있음

41. IPL 성능 평가 정규식 • 삽입, 삭제, 업데이트연산에 대한 IPL 정규식 • (a) : erase unit의 log 영역의 크기에 따른 예상 쓰기 시간 • Log영역을 키움에 따라 비용은 크게 줄어 듬 • (b) : log 영역을 키움에 따라 데이터베이스의 크기 변화량 • 하찮은 정도임 • 플래시 메모리의 가격은 계속 떨어지고, 성능은 계속 좋아짐

42. 버퍼 크기에 따른 IPL의 성능 • (a) : 버퍼 크기에 따른 총 섹터 쓰기 연산의 수 • (b) : 버퍼 크기에 따른 합병 연산의 수 • (c) : 버퍼 크기에 따른 기존 데이터베이스와 IPL이 적용된 데이터베이스의 쓰기 연산 시간 비교 • a 페이지 쓰기 연산으로 인해 erase unit이 복사되고 소거될 가능성 • 이전 결과에 의해 90%와 50%로 두고 실험

43. 요 약 • 블록 활용도가 높은 플래시 메모리일수록 개인 미디어 플레이어에 채택될 가능성이 높음 • 순차적인 접근 패턴에 대해서 읽기/쓰기 성능이 높음 • 하지만, Table 3에서 보듯이, OLPT와 같은 타입의 패턴엔 플래시 메모리가 매우 약한 모습을 보임 • 때문에, 플래시 메모리의 제약사항들을 극복할 수 있는 IPL기법을 제안함

44. 5. 복구 지원 5-1. 추가적인 Logging과 데이터 구조 5-2. Transaction Commit 5-3. Transaction Abort 5-4. 시스템 재 시작

45. 복구지원 • 추가적으로 transaction log를 사용함 • 이는 복구가 필요한 시점에 log들의 상태를 알 수 있음 • 버퍼에 있는 dirty 페이지들의 리스트를 유지함 • Committing transaction 이나 aborting transaction은 transaction이 추가한 log record를 포함하고 있는 log 섹터를 빠르게 찾아낼 수 있음

46. Transaction Commit • No-force 버퍼 관리자 정책 • Log를 매번 stable 저장소에 저장하지 않고 commit시나 버퍼가 가득찬 경우에 flush함 • 시스템 실패 시, REDO log를 통해서 복구를 수행 • IPL의 경우 • Transaction이 commit시에 in-memory log를 flush함 • 버퍼가 가득 차거나, 연관된 데이터 페이지가 victim으로 선정되면, log를 기록함 • IPL의 log는 append only로 연속되게 저장되지 않으며, 연관된 데이터 페이지와 같은 블록의 log 영역에 저장됨 • 이로 인한 쓰기 연산 시 비용이 더 들지 않음 • IPL은 시스템 재시작시 REDO 수행을 하지 않아도 됨 • IPL의 읽기 연산에서 log와 데이터 페이지를 병합하여 처리하기 때문

47. Transaction Abort • Transaction T가 취소된다면, memory에 남아있는 log를 dirty 페이지 리스트를 이용해 삭제함 • 데이터 페이지와 연결도 연결해제함 • 하지만, 이미 플래시 메모리에 flush된 log들이 존재할 수 있음 • 더군다나, 복잡하게도 합병연산은 예전 버전의 log record을 적용하여 새로운 버전의 데이터 페이지를 생성함 • 합병이 완료되면, 예전 블록에 있던 log들은 무시되는 것과 같음 • 따로 분리된 UNDO를 위한 log 기법이 있지 않는 이상, 취소된 transaction이 생성한 변경값들을 rollback하는 것은 불가능함 • 이러한 문제를 해결하기 위해 선택적 합병(selective merge)을 제안함

48. 선택적 합병 • 합병이 호출될 때, log에 관련된 transaction이 아직 활성화 되어 있는 상태이면, 데이터 페이지와 log를 병합하지 않고 log 그대로 복사함 • 만약 rollback이 필요한 상황이 되면, 해당 log를 버리면 됨 • 아직 데이터 페이지에 log가 반영되지 않은 상태 • 해당 log의 transaction이 commit되지 않으면 읽기 작업 시 log를 반영하지 않음 • IPL 저장 관리자는 선택적 합병이 호출되면 해당 블록에 log를 개개 별로 검사하여, transaction의 상태를 확인함 • Commit시 : 데이터 페이지와 log를 병합하여 복사 • Abort시 : 데이터 페이지만을 복사 • Active시 : 데이터 페이지와 log를 그대로 복사 • 이때, 여러 log들은 더 적은 수의 log로 합쳐져서 복사할 수 있음

49. 선택적 합병 (Cont.) • 어떠한 경우에는, 각각 log 섹터들과 연관된 transaction들이 모두 활성화 상태일 수 있음 • 이는 곧 다시 합병 연산을 유발할 것임 • 추가적인 쓰기와 소거 연산이 발생된 것이라고 볼 수 있음 • 이를 해결하기 위한 방법 • 합병될 erase unit이 분리된 다른 erase unit에 overflow log 섹터를 가지게 함 • 선택적 합병호출 시, 해당 erase unit의 log가 얼마나 새로운 erase unit에 복사될 지(fraction)를 계산 • 임계(Threshold)값을 넘어가면, 합병할 erase unit은 그대로 둠 • In-memory에 있는 log들을 overflow 영역에 있는 분리된 erase unit에 기록함

50. 선택적 합병 (Cont.)