1 / 10

Flash Device Support for Database Management.

Flash Device Support for Database Management. . Authors: Philippe Bonnet, Luc Bouganim . In the 5th Biennial Conference on Innovative Data Research (CIDR) 2011. Presented by: Emery Mizero Computer Science Department February 23 rd , 2011. 0. Outline. Problem Statement

paprika
Download Presentation

Flash Device Support for Database Management.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Flash Device Support for Database Management. Authors: Philippe Bonnet, Luc Bouganim. In the 5th Biennial Conference on Innovative Data Research (CIDR) 2011 Presented by: Emery MizeroComputer Science Department February 23rd, 2011

  2. 0. Outline • Problem Statement • Flash Device characteristics • Minimal FTL vs. Bimodal FTL • Narrow Bimodal Flash Devices • Rich Bimodal Flash Devices • Conclusion • References

  3. 1. Problem Statement • Lack of consistent I/O behavior across Flash Device Models. • No Reference DBMS design for Flash • No Performance Model for Flash • Define how Flash devices should support DBMS • Provide DBMS a little more control over I/O behavior • How can Flash devices provide DBMS with guarantees over I/O behavior?

  4. 2. Flash Devices Characteristics • The Good * Great Performance (40 MB/s Reads, 10 MB/s Writes) * Low energy consumption * Potentially safe to power failure • The Bad * Write Granularity (page level) * Erase Before Writes (block level) * Sequential writes within a block * Limited Lifetime • The Flash Translation Layer (FTL) * out-of-place updates using log blocks * Garbage collection * Mapping between logical address space and Physical Flash space

  5. 3. Minimal vs. Bimodal FTL • Bimodal FTL + Optimal mapping for optimal blocks (DBMS guarantees to respect constraints C1-C3) + Other FTL mapping for non-optimal blocks (For other I/O patterns, the FTL enforces the constraints) * Sequential and semi-random write => optimal mapping • Minimal FTL + DBMS can issue I/O at page granularity. + DBMS rely on the Trim command to erase a flash block before write + DBMS can write flash page within a block in sequence. - DBMS cannot implement wear-leveling (guarantee the lifetime of a devices

  6. 3. Minimal vs. Bimodal FTL (…)

  7. 4. Narrow Bimodal Flash Devices • Interface is reduced to read/write/trim commands • The Flash exposes two constants:LBS (logical block size); LPS (logical page size) • Pages are written in the order that I/O are submitted. • Following information is maintained within the mapping in cache: • Physical Block ID • Current position with block • A bit flag for optimal mapping • Wear-leveling performed without knowledge of stored data • Non-optimized utilization of controller cache • Flash chip complexity managed at DBMS level

  8. 5. Rich Bimodal Flash Devices • From optimal block to optimal chunk => reduce the size of metadata.(explicit DBMS declaration of larger chunks to the Flash device) • Choosing highly erased blocks to store data with low erase frequency => Minimize block movements from FTL wear-leveling algorithms • Caching last written flash page into safe buffer; and written to flash when full (Append data structures: log records or table in append mode) • Caching payload: Only caching using useful data to be written thus avoiding caching of data that already exist in memory • Reading payload: Only transmitting useful data (within a page) from the chip to the controller and onto the host. • Nameless writes: Typically for temporary data, DBMS issues writes with no address. The FTL handles it and returns handle for future reference. • Reorganization for Free: the FTL wear-leveling mechanism involves the DBMS to do some of the work.

  9. 6. Conclusion • Flash should provide I/O guarantees. Why? • DBMS can devise stable and efficient IO management mechanisms. • What should the DB community do? • Guide the evolution of Flash devices so that guarantees can be enforced • Define the characteristics of the Flash Translation Layer that should be adopted on Flash devices across manufactures and Model.

  10. 7. Important References and Future work • Important References: • L. Bouganim, B. Jonsson, and P. Bonnet. uFLIP:UnderstandingFlash IO Patterns. In CIDR, 2009. • http://uflip.inria.fr/~uFLIP/ • Future work: • Explore the design space of Narrow Bimodal Flash devices for a optimized baseline design. • Following that would be to explore the design space of Rich Bimodal Flash devices.

More Related