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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

합병 연산 알고리즘

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

실험 환경 Magnetic 디스크 Flash Memory CPU / RAM 2.0 GHz Intel Pentium IV processer / 1GB RAM Connection Type IDE/ATA interface Storage Device Seagate Barracuda 7200.7 ST380011A M-Tron MSD-P35 With Samsung K9WAG08U1A 16 Gbits SLC NAND Flash DB (Size of buffer pool) 20 Mbytes DB (Page Size) 8 Kbytes

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

읽기/쓰기 성능 평가 질의 패턴 읽기 질의 패턴 Q1 Q2 쓰기 질의 패턴 Q3 Q4 Q5 Q6 순차적으로 64,000 페이지들을 탐색 Q2 연속된 16개의 페이지를 임의로 선정하여 한번에 읽음. 64,000개의 모든 페이지가 단 한번만 읽어지도록 계속 반복함. Q3 16개의 페이지 단위로 한 페이지씩 읽어 들임. Ex) 0,16,32,…,63984,1,17,33,… 쓰기 질의 패턴 Q4 순차적으로 64,000 페이지들 모두를 업데이트함 Q5 16개의 페이지 단위로 한 페이지씩 업데이트함 Ex) 0,16,32,…,63984,1,17,33,… Q6 128개의 페이지 단위로 한 페이지씩 업데이트함 Ex) 0,128,256,…,63872,1,129,257,…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

선택적 합병 (Cont.)

선택적 합병 (Cont.) 기존의 합병 연산을 선택적 합병으로 대체하게 되면, UNDO 수행이 필요 없음 취소나, 미 완료된 Transaction의 경우 취소나, 미 완료된 Transaction의 Log record들은 IPL 저장 관리자에 의해서 무효화 처리가 됨 이는 나중에 합병 시 버려지게 됨

시스템 재 시작 IPL 저장 관리자는 결국 REDO와 UNDO 수행을 함축적으로 수행하고 있음 일반적인 처리 과정에서 위의 작업을 하고 있음 데이터베이스 서버가 시스템 실패로부터 복구를 할 때, 실패할 시점에 transaction들의 상태를 알기 위해서, transaction log를 검사함 Commit나 abort된 transaction의 log는 이미 기록되어 있음 Active였던 transaction의 log들을 위해서 재 시작 시에 해당 transaction의 abort log를 추가시켜줌 해당 transaction에 관련된 log들은 나중에 알아서 abort될 것임

6. 관련 연구

Commit 시간 기존 디스크 기반 상업적 데이터베이스는 in-place 업데이트를 하며, no-force 버퍼 정책을 수행 항상 commit시에는 log를 log의 끝에 기록해서, 기계적 지연을 최소화함 IPL의 경우 commit시에 흩어져서 log가 기록됨 그래도 기계적 지연은 없음 Postgres No overwrite 저장 관리자 지원 기계적 지연을 최소화 하기 위함 본 데이터 페이지의 변화를 delta record를 추가적으로 기록하는 방식 Commit 시에 transaction이 사용한 모든 관련된 데이터 페이지를 임의적인 위치의 I/O로 flush해야 함 변화된 기록들을 잘 탐색해야 하며, 복구가 중요함 IPL과 비슷함 FeRAM과 같은 stable 메인 메모리가 필요함

PicoDBMS과 FTL PicoDBMS FTL 90년도 후반에 EEPROM을 위한 데이터베이스 Smartcard에 주로 사용 EEPROM의 주요 bottleneck은 쓰기 성능에서 발생함 읽기 연산에 비해 쓰기가 매우 느림 플래시 메모리와 비슷한 특성임 EEPROM은 in-place 업데이트를 지원 플래시 메모리와는 다른 특성임 PicoDBMS은 플래시 메모리에 적용 시 매우 성능이 나쁠 것임 FTL 주요 목적은 작고 임의적인 위치의 업데이트가 들어와도, 소거 연산을 최소화 하는 것임 디스크 기반의 파일 시스템(FAT , I-node등등)에서 발생되는 업데이트는 작은 영역(Meta-data)에 한정됨 이에 반해, 데이터베이스는 매우 넓은 범위에 업데이트가 일어남 즉, 데이터베이스의 workload를 FTL로 처리하는 것은 비효율적임

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

7. 결론

결론 광범위한 컴퓨팅 플랫폼에서 플래시 메모리는 디스크를 대체하고 있음 멀티미디어 응용 프로그램들은 비디오나 오디오 같은 크고 순차적인 접근을 함 데이터베이스는 임의적인 위치에 아주 작은 읽기와 쓰기 접근을 함 플래시 메모리의 erase-before-write의 특성 때문에 기존 디스크 기반 데이터베이스는 수정되어야 함 IPL은 OLTP타입 응용 프로그램과 같은 패턴의 쓰기 성능을 증진 시킬 수 있음을 증명 게다가, IPL 디자인은 transaction의 복구까지 지원하도록 확장이 가능함