design of flash-based dbms: an in-page logging approach

Database & Information System Laboratory Database & Information System Laboratory

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

한국외국어대학교 컴퓨터및정보통신공학과DISLAB

박성환 ([email protected])

DISLab DISLab

Made By Hackereyes 2

목차목차

1. 서론

2. 디자인 원칙1. 플래시 메모리의 특성2. 이전 디자인의 문제점3. 디자인 정책

3. In-Page logging approach1. 기본 개념2. IPL 의 설계3. 합병 연산

4. 성능 평가1. 디스크 기반 데이터베이스 서버의 성능2. TPC-C benchmark test3. 요약

5. 복구 지원1. 추가적인 logging 과 data 구조2. Transaction commit3. Transaction abort4. System 재 부팅

6. 관련 연구

7. 결론

DISLab DISLab

Made By Hackereyes 3

서론서론

• 최근 플래시 메모리의 인기가 높아짐– PDA’s , MP3 player , Mobile phone , Digital camera 에 탑재– 최근 10 Gbytes 가 넘는 NAND 플래시 메모리가 탑재되어 출시됨

• 플래시 메모리에 DBMS 를 적용시키는 것이 어렵지 않음– 플래시 메모리의 가격이 낮아지고 , 대용량화 되며 , 성능이 좋아지고

있음

• 이 논문에서는 , 플래시 메모리 기반 데이터베이스 서버를 위한 IPL (In-Page Logging) 을 제안함

• IPL 은 자연스럽게 transaction 의 복구를 지원이 가능함

DISLab DISLab

Made By Hackereyes

Magnetic Magnetic 디스크디스크 vs. NAND vs. NAND 플래시 메모리플래시 메모리

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

4

DISLab DISLab

Made By Hackereyes

OLTPOLTP 에 대한 플래시 메모리의 특성에 대한 플래시 메모리의 특성

• OLTP – On-Line Transaction Processing– 네트워크상의 여러 이용자가 실시간으로 데이터베이스의 데이터를

갱신하거나 조회하는 등의 단위 작업을 처리하는 방식

• 플래시 메모리는 OLTP 에서 처럼 임의적인 위치에 매우 작은 쓰기 연산이 발생되면 , 성능이 매우 나쁘다고 알려져 있음– FTL 상에서의 이야기로 생각됨

• 따라서 , 플래시 메모리는 이러한 패턴의 I/O 를 효율적으로 처리할 수 있어야 함

5

DISLab DISLab

Made By Hackereyes

IPLIPL 의 제안의 제안

• 플래시 메모리 기반의 데이터베이스 서버를 위한 IPL 기법을 제안

• 데이터 페이지에 업데이트 요청이 들어오면 , 페이지 전체를 업데이트 하지 않고 , 수정되는 것에 대한 정보만을 기록– 페이지 변화에 대한 log 들을 sector 단위로 플래시 메모리의 log

영역에 저장

• 이러한 log 들은 합병 연산 시에 데이터 페이지와 병합될 수 있음

6

DISLab DISLab

Made By Hackereyes

IPLIPL 의 간단 요약의 간단 요약

• IPL 은 플래시 메모리의 단점을 극복하고 , magnetic 디스크를 대체시킬 플래시 메모리를 위해서 제안되었음– 경험적인 실험에 의해 IPL 이 OLTP 와 같은 전통적인 데이터베이스의

쓰기 성능을 증진시킬 수 있음이 증명됨

• IPL 디자인은 기존 데이터베이스 서버의 구조의 변화를 최소화 시키면서 , 최고의 성능을 달성할 수 있음

• IPL 의 기본적인 디자인을 조금만 수정함으로 해서 , 적은 비용으로 데이터베이스 시스템의 복구가 가능함

7


2. 2. 디자인 원칙디자인 원칙

2-1. 플래시 메모리의 특성

8

DISLab DISLab

Made By Hackereyes

No In-Place No In-Place 업데이트업데이트

• Magnetic 디스크는 같은 자리에 효율적으로 업데이트가 가능

• 플래시 메모리의 경우 같은 자리의 업데이트는 불가능– 해당 블록의 다른 페이지들을 복사한 뒤 블록을 소거하고 , 업데이트를

한 뒤 , 다른 페이지들을 갱신해야 함 ( 매우 비 효율적 )

• 작은 자료의 업데이트는 소거와 쓰기의 overhead 가 발생

• 이를 개선하기 위해 저장 서브시스템의 새로운 디자인이 필요함

9

DISLab DISLab

Made By Hackereyes

No No 기계적기계적 지연지연

• Magnetic 디스크는 seek 나 rotation 시간이 자료 입출력의 시간 지연을 가져옴– 읽기 /쓰기 시간이 일정하지 않은 경우가 발생함

• 이에 반해 , 플래시 메모리는 입출력 시에 지연 없이 동일한 시간에 읽기 /쓰기가 가능함

• 데이터베이스는 인접한 자료를 물리적으로도 인접하게 하려는 경향이 있음– 플래시 메모리에서는 이러한 제약이 필요 없음

10

DISLab DISLab

Made By Hackereyes

다른 읽기다른 읽기 //쓰기 연산 속도쓰기 연산 속도

• 플래시 메모리는 읽기와 쓰기의 속도가 다름– 쓰기 연산 시 셀 (cell) 에 충전하는 시간이 읽기 연산보다 오래 걸림

• 기존 데이터베이스는 이러한 플래시 메모리의 특성이 고려되어 있지 않음– 플래시 메모리 기반 응용 데이터베이스는 이러한 특징을 고려해야 함

• 비교적 오랜 시간이 걸리는 쓰기 연산을 줄여야만 함– 플래시 메모리의 쓰기 연산은 부가적으로 소거 연산을 가져옴– 소거 연산은 쓰기 연산에 비해 더 오랜 시간이 걸림

11



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

12

DISLab DISLab

Made By Hackereyes

디스크 기반 데이터베이스디스크 기반 데이터베이스

• 대부분의 디스크 기반 데이터베이스의 특징– 페이지 I/O 단위 메커니즘을 사용– 하드웨어 특성을 이용한 순차적인 접근을 활용– In-place 로 데이터를 업데이트가 가능하기 때문에 잦은 업데이트를 잘

처리하는 편임

• Magnetic 디스크가 플래시 메모리로 대체된다면– 데이터베이스의 In-place 업데이트는 많은 소거와 쓰기 연산을 가져옴– 이는 , 큰 지연을 가져오게 됨– 또한 , 플래시 메모리는 한 블록에 일정 수의 소거 연산이 수행되면 ,

데이터의 신뢰성을 보장하지 못함

13

DISLab DISLab

Made By Hackereyes

순차적인순차적인 LoggingLogging

• 대부분의 플래시 메모리 장비는 수명을 위해 소거 횟수 평준화(wear leveling) 을 수행

• Log 기반 플래시 파일 시스템 중에 하나인 , ELF 는 새로운 순차적인 log entry 를 사용함으로써 소거 횟수 평준화를 달성함– 이를 사용함으로써 업데이트는 빈 섹터가 존재하면 소거연산을 하지

않아도 됨

• 하지만 , 이러한 순차적인 logging 은 데이터베이스의 전체적인 성능을 향상시키지는 않음– 읽기 연산 시 부가적인 오버헤드가 있음– 빈 섹터를 빠르게 소비함

14

DISLab DISLab

Made By Hackereyes

디스크 기반 서버 성능디스크 기반 서버 성능

• Magnetic 디스크는 순차적인 위치보다 임의적인 위치에 읽기 /쓰기 연산이 더 오래 걸림– Seek 와 rotation 시간이 오래 걸림

• 플래시 메모리는 순차적인 위치나 임의적인 위치의 읽기 연산은 비슷한 시간이 걸림

• 플래시 메모리는 순차적인 위치의 쓰기 연산보다 임의적인 위치의 쓰기 연산이 더 오래 걸림– 더 많은 소거와 쓰기 연산을 가져옴

15



2-3. 디자인의 정책

16

DISLab DISLab

Made By Hackereyes

디자인 정책디자인 정책

• 플래시 메모리 기반의 데이터베이스 서버를 설계 시 두 가지 수준을 고려해야 함– 휘발성 RAM 메모리– 비 휘발성 플래시 메모리

1. Log record 들은 플래시 메모리 전반에 걸쳐 분산되어도 상관없으며 , 순차적으로 기록할 필요가 없음

1. 임의적인 위치 접근 속도가 순차적인 위치 접근 속도와 같음2. 읽기와 쓰기 속도가 다름

2. Erase-before-write 의 제약을 극복해야 함

3. DBMS 의 전반적인 구조의 수정을 최소화 해야 함

17


3. In-Page Logging approach3. In-Page Logging approach

3-1. 기본 개념3-2. IPL 디자인3-3. 합병 연산

18

DISLab DISLab

Made By Hackereyes

기본 개념기본 개념

• 쓰기 연산이 발생되면 , 전체 페이지를 기록하지 않고 변화된 부분만 한 페이지 (log) 에 기록함

• 기존 디스크 기반의 데이터베이스에서 log 는 순차적으로 저장됨– 디스크 기반에서는 seek 와 rotation 시간을 줄이기 위함– 데이터베이스에서 읽기를 요청하면 , 해당 log 를 탐색하여 본 페이지와

합쳐서 처리해야 함• Overhead 가 있음

• 반면 , 플래시 메모리에서는 임의적인 위치에 기록하여도 지연시간이 없음– Log 를 순차적으로 기록할 이유가 없음

• 때문에 , log 를 같은 erase unit 에 데이터 페이지와 같이 저장

• 이를 IPL(In-Page Logging) 이라 함

19

DISLab DISLab

Made By Hackereyes

기본 개념기본 개념 (Cont.)(Cont.)

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

• 쓰기 연산의 비용이 읽기 연산의 비용보다 더 크기 때문

20

DISLab DISLab

Made By Hackereyes

IPLIPL 의 디자인의 디자인

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

21

DISLab DISLab

Made By Hackereyes

IPLIPL 의 디자인 의 디자인 (Cont.)(Cont.)

• IPL 은 데이터 페이지가 dirty 될 때 log 섹터를 할당 받아서 변화만을 기록함– 이는 모두 메모리 버퍼에서 일어남

• 메모리에 있는 log 섹터는 플래시 메모리 해당 블록의 log 영역에 기록되면 해제됨– 플래시 메모리에 영구 기록될 시에 버퍼에서 해제함– 블록에 포함된 페이지들의 log 섹터는 해당 블록의 log 영역에 기록

• In-memory log 섹터는 다음의 경우 플래시 메모리에 기록함– Log 섹터가 꽉 찼을 경우– 버퍼 관리자가 dirty 페이지를 victim 으로 선정했을 경우

22

DISLab DISLab

Made By Hackereyes

IPLIPL 의 디자인 의 디자인 (Cont.)(Cont.)

• In-memory log 섹터는 쓰기 버퍼와 같은 역할을 함– 여러 log record 들이 한 번에 같이 기록될 수 있음– 잦은 소거 연산도 피할 수 있음

• Log 섹터를 기록시에는 데이터 페이지를 기록할 필요가 없음– 변화된 부분들이 모두 log 섹터에 있기 때문

23

DISLab DISLab

Made By Hackereyes

IPLIPL 을 위한 저장 관리자을 위한 저장 관리자

• 플래시 메모리의 블록은 데이터 페이지 영역과 log 영역으로 구분 되어야 함– 이를 저장 관리자가 지원해야 함

• 예– Large block 의 경우 한 블록은 128K 임– 각각 8K 크기의 데이터 페이지 15 개– 각각 512B 크기의 log 섹터 16 개

• 만약 log 영역이 꽉 차게 되면 , 데이터 영역과 log 영역을 새로운 빈 블록에 합병– 저장 관리자는 IPL 에 맞는 합병 연산을 지원해야 함

• 합병연산은 뒤에 자세히 다룸

24

DISLab DISLab

Made By Hackereyes

읽기 연산의 수정읽기 연산의 수정

• 읽기 연산은 이전 페이지와 이와 연관된 log 를 읽어 새로운 페이지로 보여줘야 함

• 이는 I/O 시간과 CPU 계산 시간이 걸림– I/O 시간 ( 이전 페이지와 log 섹터를 읽음 )– CPU 계산 시간 ( 이전 페이지와 log 섹터를 합쳐서 최신 페이지를

생성 )

• 앞에서도 언급했듯이 , 읽기 연산의 오버헤드는 IPL 을 사용함으로서 얻어지는 쓰기와 소거 연산의 회수 감소로 보상 받을 수 있음

25

DISLab DISLab

Made By Hackereyes

합병 연산합병 연산

• In-memory log 섹터는 제한되어 있으며 , 플래시 메모리의 log 영역이 가득 차게 되면 , 합병 연산이 필요함

• 이는 IPL 저장 관리자가 수행

• 기본적으로 합병연산은 읽기나 쓰기 연산보다 오래 걸림

• 합병 비용 식

– Kd와 kl : Erase unit 안의 데이터 섹터와 log 섹터의 개수– 추가적으로 데이터 페이지와 log record 들을 합치는 연산 비용이 듬

• 합병 연산이 완료되면 , 새로운 블록에 대한 매핑 정보를 갱신해야 함

26

erasewritedreadldmerge CCkCkkC )(

DISLab DISLab

Made By Hackereyes

합병 연산 알고리즘합병 연산 알고리즘

27


4. 4. 성능 평가성능 평가

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

28

DISLab DISLab

Made By Hackereyes

실험 환경실험 환경

Magnetic 디스크 Flash Memory

CPU / RAM 2.0 GHz Intel Pentium IV processer / 1GB RAM

ConnectionType

IDE/ATA interface

StorageDevice

Seagate Barracuda 7200.7 ST380011AM-Tron MSD-P35

With Samsung K9WAG08U1A 16 Gbits SLC NAND Flash

DB (Size of buffer pool)

20 Mbytes

DB (Page Size) 8 Kbytes

29

DISLab DISLab

Made By Hackereyes

실험 환경 실험 환경 (Cont.)(Cont.)

• Raw 장비로 설정하고 , logging 옵션을 주지 않음• 캐싱이나 logging 시의 간섭을 피하기 위함• 대부분의 I/O 는 데이터 페이지나 인덱스 노드에 집중될 것임

• 실험 테이블 생성• 650 bytes 크기의 record 640,000 개 삽입• 데이터베이스 페이지 = 10 record 삽입됨• 데이터베이스 페이지는 총 64,000 개가 사용되며 , 플래시

메모리의 블록은 총 4,000 개가 필요함

• 실험 테이블에 처음 두 개의 column 은 integer 타입

30

)160(mod_

160/_

2

1

idrecordcol

idrecordcol

DISLab DISLab

Made By Hackereyes

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

31

읽기 질의 패턴

Q1 순차적으로 64,000 페이지들을 탐색

Q2연속된 16 개의 페이지를 임의로 선정하여 한번에 읽음 . 64,000 개의 모든 페이지가 단 한번만 읽어지도록 계속 반복함 .

Q316 개의 페이지 단위로 한 페이지씩 읽어 들임 .Ex) 0,16,32,…,63984,1,17,33,…

쓰기 질의 패턴

Q4 순차적으로 64,000 페이지들 모두를 업데이트함

Q516 개의 페이지 단위로 한 페이지씩 업데이트함Ex) 0,16,32,…,63984,1,17,33,…

Q6128 개의 페이지 단위로 한 페이지씩 업데이트함Ex) 0,128,256,…,63872,1,129,257,…

DISLab DISLab

Made By Hackereyes

읽기읽기 //쓰기 성능쓰기 성능

• 일반적인 시계 (the wall clock) 로 측정

• 읽기 성능– 디스크는 임의적으로 읽을 수록 seek 와 rotation 시간이 오래 걸림– 플래시 메모리는 디스크와 같은 기계적 지연 시간이 없음

• 쓰기 성능– 디스크의 경우 읽기와 비슷한 경향을 보임– 플래시 메모리는 놀랍게도 , 임의적인 위치의 쓰기 연산인 경우 디스크보다

성능이 나쁨• 이는 많은 소거와 쓰기 연산이 발생하여 지연이 큼

32

DISLab DISLab

Made By Hackereyes

버퍼의 영향버퍼의 영향

• 플래시 메모리는 소거 연산을 피하기 위해 버퍼의 용량을 늘림– 실험에서는 플래시 메모리가 16 Mbytes 의 버퍼를 사용함– 1 Mbytes 는 8개의 erase unit(128K) 을 버퍼링 가능함

• Q4의 경우 , 순차적인 업데이트는 4,000 개의 erase unit 이 순차적으로 버퍼에 복사되고 , 소거되는 모습을 보임– 버퍼의 활용도가 매우 높음

• Q5나 Q6의 경우 , erase unit 의 한 페이지만 버퍼에 복사되고 , 16개의 erase unit 이 할당되면 , 다시 플래시 메모리에 업데이트 되는 모습을 보임– 버퍼의 활용도가 매우 낮음

33


4. 4. 성능 평가성능 평가

4-2. TPC-C Benchmark Test

34

DISLab DISLab

Made By Hackereyes

TPC-C Trace TPC-C Trace 생성생성

• TPC-C benchmark 를 생성하기 위해 Hammerora 를 사용함– Open source tool– TPC-C version 5.1 을 지원

• 리눅스 플랫폼에서 기존 데이터베이스 서버를 통해 Hammerora 를 수행– 변수를 둠

• 데이터베이스의 크기• 질의를 내리는 사용자 수• 시스템 버퍼 풀의 크기

– 아래와 같은 설정에서 log record 들을 뽑아냄• 단 , 데이터베이스는 log record 에 쓰기 연산에 정보만을 기록• 하지만 , 이 논문에서 필요한 정보는 쓰기 연산임

35

표시 의 미

100M.20M.10u 100 Mbytes 데이터베이스 , 20 Mbytes 버퍼 풀 , 10 명의 사용자

1G.20M.100u 1 Gbytes 데이터베이스 , 20 Mbytes 버퍼 풀 , 100 명의 사용자

1G.40M.100u 1 Gbytes 데이터베이스 , 40 Mbytes 버퍼 풀 , 100 명의 사용자

DISLab DISLab

Made By Hackereyes

TPC-C BenchmarkTPC-C Benchmark 의 업데이트 패턴 의 업데이트 패턴 (1)(1)

• 평균 log 의 크기는 50 bytes 를 넘지 않음– 보통 플래시 메모리의 1섹터의 크기가 512bytes 임– 메모리 버퍼에 10 개 이상의 log 를 저장할 때까지는 플래시 메모리에

기록할 필요가 없음을 의미함• 10 개의 log 를 모아서 기록이 가능함

36

DISLab DISLab

Made By Hackereyes

TPC-C BenchmarkTPC-C Benchmark 의 업데이트 패턴 의 업데이트 패턴 (2)(2)

• (a) : 페이지가 기록되기 전에 생성하는 log 들의 지역성의 정도– 특정 페이지들에 잦은 업데이트가 있음을 볼 수 있음

• (b) : 실제 물리적인 페이지의 업데이트의 지역성– 역시 , 특정 페이지에 쓰기 연산이 몰려있음

• (c) : 물리적인 erase unit 의 소거 연산도 특정 블록에 치우쳐 있음

37

DISLab DISLab

Made By Hackereyes

쓰기 성능 평가쓰기 성능 평가

• 본 논문에서는 TPC-C 에서 생성된 log 를 실험하기 위해 simulator 를 작성함

• 4가지 타입의 log record– 삽입 , 삭제 , 업데이트– 데이터 페이지의 쓰기

• 해당 log 의 타입에 따라 logging 의 수를 계산하거나 , 쓰기 , 합병에 대한 수를 계산함

38

DISLab DISLab

Made By Hackereyes

Log Log 영역 크기에 따른 영역 크기에 따른 IPLIPL 의 성능의 성능

• 가장 좋은 성능을 내는 log 영역의 크기를 측정하기 위해 erase unit 의 log 영역의 크기를 가변적으로 실험함– 8 Kbytes ~ 64 Kbytes

• 총 섹터 쓰기 연산 수– 업데이트 참조 패턴과 데이터베이스의 버퍼 replacement 정책에 의해

결정되는 값– 이는 log 영역의 크기와 독립적인 값임

• 작은 버퍼의 크기는 in-memory log 섹터를 자주 플래시 메모리에 기록하게 하지만 , 섹터의 쓰기 연산 수는 업데이트 참조의 수와 비교하여 월등히 줄어 듬

39

DISLab DISLab

Made By Hackereyes

Log Log 영역 크기에 따른 영역 크기에 따른 IPLIPL 의 성능 의 성능 (Cont.)(Cont.)

• 한편 , 합병 연산의 수는 log 영역의 크기에 영향을 받음

• Hot 페이지의 잦은 업데이트는 log 영역이 작을 때 더 심한 합병을 유발할 수 있음

40

DISLab DISLab

Made By Hackereyes

IPL IPL 성능 평가 정규식성능 평가 정규식

• 삽입 , 삭제 , 업데이트 연산에 대한 IPL 정규식

• (a) : erase unit 의 log 영역의 크기에 따른 예상 쓰기 시간– Log 영역을 키움에 따라 비용은 크게 줄어 듬

• (b) : log 영역을 키움에 따라 데이터베이스의 크기 변화량– 하찮은 정도임– 플래시 메모리의 가격은 계속 떨어지고 , 성능은 계속 좋아짐

41

msstIPL 20)merges of #(200)tessector wri of #( X X

DISLab DISLab

Made By Hackereyes

버퍼 크기에 따른 버퍼 크기에 따른 IPLIPL 의 성능의 성능

• (a) : 버퍼 크기에 따른 총 섹터 쓰기 연산의 수

• (b) : 버퍼 크기에 따른 합병 연산의 수

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

42

mstconv 20 x writes)page of # x α(

DISLab DISLab

Made By Hackereyes

요 약요 약

• 블록 활용도가 높은 플래시 메모리일수록 개인 미디어 플레이어에 채택될 가능성이 높음– 순차적인 접근 패턴에 대해서 읽기 /쓰기 성능이 높음

• 하지만 , Table 3 에서 보듯이 , OLPT 와 같은 타입의 패턴엔 플래시 메모리가 매우 약한 모습을 보임

• 때문에 , 플래시 메모리의 제약사항들을 극복할 수 있는 IPL 기법을 제안함

43


5. 5. 복구 지원복구 지원

5-1. 추가적인 Logging 과 데이터 구조5-2. Transaction Commit5-3. Transaction Abort5-4. 시스템 재 시작

44

DISLab DISLab

Made By Hackereyes

복구복구 지원지원

• 추가적으로 transaction log 를 사용함 – 이는 복구가 필요한 시점에 log 들의 상태를 알 수 있음

• 버퍼에 있는 dirty 페이지들의 리스트를 유지함– Committing transaction 이나 aborting transaction 은

transaction 이 추가한 log record 를 포함하고 있는 log 섹터를 빠르게 찾아낼 수 있음

45

DISLab DISLab

Made By Hackereyes

Transaction CommitTransaction 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 와 데이터 페이지를 병합하여 처리하기 때문

46

DISLab DISLab

Made By Hackereyes

Transaction AbortTransaction Abort

• Transaction T 가 취소된다면 , memory 에 남아있는 log 를 dirty 페이지 리스트를 이용해 삭제함– 데이터 페이지와 연결도 연결해제함

• 하지만 , 이미 플래시 메모리에 flush 된 log 들이 존재할 수 있음– 더군다나 , 복잡하게도 합병연산은 예전 버전의 log record 을

적용하여 새로운 버전의 데이터 페이지를 생성함– 합병이 완료되면 , 예전 블록에 있던 log 들은 무시되는 것과 같음

• 따로 분리된 UNDO 를 위한 log 기법이 있지 않는 이상 , 취소된 transaction 이 생성한 변경값들을 rollback 하는 것은 불가능함

• 이러한 문제를 해결하기 위해 선택적 합병 (selective merge) 을 제안함

47

DISLab DISLab

Made By Hackereyes

선택적 합병선택적 합병

• 합병이 호출될 때 , log 에 관련된 transaction 이 아직 활성화 되어 있는 상태이면 , 데이터 페이지와 log 를 병합하지 않고 log 그대로 복사함

• 만약 rollback 이 필요한 상황이 되면 , 해당 log 를 버리면 됨– 아직 데이터 페이지에 log 가 반영되지 않은 상태– 해당 log 의 transaction 이 commit 되지 않으면 읽기 작업 시 log 를

반영하지 않음

• IPL 저장 관리자는 선택적 합병이 호출되면 해당 블록에 log 를 개개 별로 검사하여 , transaction 의 상태를 확인함– Commit 시 : 데이터 페이지와 log 를 병합하여 복사– Abort 시 : 데이터 페이지만을 복사– Active 시 : 데이터 페이지와 log 를 그대로 복사

• 이때 , 여러 log 들은 더 적은 수의 log 로 합쳐져서 복사할 수 있음

48

DISLab DISLab

Made By Hackereyes

선택적 합병선택적 합병 (Cont.)(Cont.)

• 어떠한 경우에는 , 각각 log 섹터들과 연관된 transaction 들이 모두 활성화 상태일 수 있음– 이는 곧 다시 합병 연산을 유발할 것임– 추가적인 쓰기와 소거 연산이 발생된 것이라고 볼 수 있음

• 이를 해결하기 위한 방법– 합병될 erase unit 이 분리된 다른 erase unit 에 overflow log

섹터를 가지게 함

• 선택적 합병 호출 시 , 해당 erase unit 의 log 가 얼마나 새로운 erase unit 에 복사될 지 (fraction) 를 계산– 임계 (Threshold)값을 넘어가면 , 합병할 erase unit 은 그대로 둠– In-memory 에 있는 log 들을 overflow 영역에 있는 분리된 erase

unit 에 기록함

49

DISLab DISLab

Made By Hackereyes

선택적 합병선택적 합병 (Cont.)(Cont.)

50

DISLab DISLab

Made By Hackereyes

선택적 합병 선택적 합병 (Cont.)(Cont.)

• 기존의 합병 연산을 선택적 합병으로 대체하게 되면 , UNDO 수행이 필요 없음– 취소나 , 미 완료된 Transaction 의 경우

• 취소나 , 미 완료된 Transaction 의 Log record 들은 IPL 저장 관리자에 의해서 무효화 처리가 됨– 이는 나중에 합병 시 버려지게 됨

51

DISLab DISLab

Made By Hackereyes

시스템 재 시작시스템 재 시작

• IPL 저장 관리자는 결국 REDO 와 UNDO 수행을 함축적으로 수행하고 있음– 일반적인 처리 과정에서 위의 작업을 하고 있음

• 데이터베이스 서버가 시스템 실패로부터 복구를 할 때 , 실패할 시점에 transaction 들의 상태를 알기 위해서 , transaction log 를 검사함– Commit 나 abort 된 transaction 의 log 는 이미 기록되어 있음– Active였던 transaction 의 log 들을 위해서 재 시작 시에 해당

transaction 의 abort log 를 추가시켜줌• 해당 transaction 에 관련된 log 들은 나중에 알아서 abort 될 것임

52


6. 6. 관련 연구관련 연구

53

DISLab DISLab

Made By Hackereyes

Commit Commit 시간시간

• 기존 디스크 기반 상업적 데이터베이스는 in-place 업데이트를 하며 , no-force 버퍼 정책을 수행– 항상 commit 시에는 log 를 log 의 끝에 기록해서 , 기계적 지연을

최소화함

• IPL 의 경우 commit 시에 흩어져서 log 가 기록됨– 그래도 기계적 지연은 없음

• Postgres– No overwrite 저장 관리자 지원

• 기계적 지연을 최소화 하기 위함– 본 데이터 페이지의 변화를 delta record 를 추가적으로 기록하는 방식– Commit 시에 transaction 이 사용한 모든 관련된 데이터 페이지를

임의적인 위치의 I/O 로 flush 해야 함– 변화된 기록들을 잘 탐색해야 하며 , 복구가 중요함– IPL 과 비슷함 – FeRAM 과 같은 stable 메인 메모리가 필요함

54

DISLab DISLab

Made By Hackereyes

PicoDBMSPicoDBMS 과 과 FTLFTL

• PicoDBMS– 90년도 후반에 EEPROM 을 위한 데이터베이스– Smartcard 에 주로 사용– EEPROM 의 주요 bottleneck 은 쓰기 성능에서 발생함

• 읽기 연산에 비해 쓰기가 매우 느림• 플래시 메모리와 비슷한 특성임

– EEPROM 은 in-place 업데이트를 지원• 플래시 메모리와는 다른 특성임

– PicoDBMS 은 플래시 메모리에 적용 시 매우 성능이 나쁠 것임

• FTL – 주요 목적은 작고 임의적인 위치의 업데이트가 들어와도 , 소거 연산을

최소화 하는 것임– 디스크 기반의 파일 시스템 (FAT , I-node 등등 ) 에서 발생되는 업데이트는

작은 영역 (Meta-data) 에 한정됨– 이에 반해 , 데이터베이스는 매우 넓은 범위에 업데이트가 일어남– 즉 , 데이터베이스의 workload 를 FTL 로 처리하는 것은 비효율적임

55

DISLab DISLab

Made By Hackereyes

데이터베이스 저장 기법의 분류데이터베이스 저장 기법의 분류

56


7. 7. 결론결론

57

DISLab DISLab

Made By Hackereyes

결론결론

• 광범위한 컴퓨팅 플랫폼에서 플래시 메모리는 디스크를 대체하고 있음– 멀티미디어 응용 프로그램들은 비디오나 오디오 같은 크고 순차적인

접근을 함– 데이터베이스는 임의적인 위치에 아주 작은 읽기와 쓰기 접근을 함

• 플래시 메모리의 erase-before-write 의 특성 때문에 기존 디스크 기반 데이터베이스는 수정되어야 함

• IPL 은 OLTP타입 응용 프로그램과 같은 패턴의 쓰기 성능을 증진 시킬 수 있음을 증명

• 게다가 , IPL 디자인은 transaction 의 복구까지 지원하도록 확장이 가능함

58

design of flash-based dbms: an in-page logging approach

Documents