FaCE is a new low-overhead caching strategy that uses flash memory as an extension to the RAM buffer of database systems. FaCE aims at improving the transaction throughput as well as shortening the recovery time from a system failure. In the paper, author has implemented the FaCE scheme in the PostgreSQL 8.4 database server. But we implemented the FaCE scheme in the MySQL 5.6.26. FaCE paper (VLDB) (215 downloads)
Disparity in SSD Write Performance
There exists a substantial disparity between random and sequential performance measured in terms of bandwidth for write operations. The sequential write bandwidth of 840 Pro SSD was about seven times higher than its random write bandwidth. The ratio was five in the case of Intel DC S3500 SSD. The DC S3500 is a datacenter oriented SSD. Our work on FaCE aims at developing a new
ash caching method that exploits maximally the superior sequential write performance of flash memory SSDs.
Cost-Effectiveness of Flash Cache
Considering the current price gap between hard disk and ash memory SSD storages, for applications dealing with large scale data, it will be economically more sensible to use flash memory drives to supplement disk drives rather than to replace them.
- IOPS/$: SSDs >> HDDs
- GB/$: HDDs >> SSDs
Therefore, it is more sensible to use SSDs to supplement HDDs, rather than to replace them.
The FaCE System
Above figure illustrates the main components and their interactions of a caching system deployed for a database system, when the flash cache is enabled. The main interactions between the components are summarized as follows.
- When the database server requests a data page that is not in memory (i.e., the RAM buffer), the flash cache is searched for the page. (A list of pages cached in flash memory is maintained in the RAM buffer to support the search operations.)
- If the page is found in the flash cache (i.e., flash hit), it is fetched from the flash cache. Otherwise, it is fetched from disk.
- When a page is swapped out of the RAM buffer, different actions can be taken on the page depending on whether it is clean or dirty.
If it is clean, the page is discarded or staged in to the flash cache.
If it is dirty, the page is written back to disk or staged in to the flash cache, or both.
- When a page is staged out of the flash cache, different actions can be taken on the page depending on whether it is clean or dirty.
If it is clean, the page is just discarded.
If it is dirty, the page is written to disk unless it was already written to disk when evicted from the RAM buffer.
Evidently from the key interactions described above, the fundamental issues are when and which data pages should be staged in to or out of the flash cache.
The FaCE caching scheme focuses on how exactly data pages are to be staged in the flash cache and how the flash cache should be managed. Specifically, in the rest of this section, we discuss alternative strategies towards the following three key questions and justify the choices made for the FaCE scheme:
When a dirty page is evicted from the RAM buffer, does it have to be written through to disk as well as the flash cache or only to the flash cache?
Which replacement algorithm is better suited to exploiting flash memory as an extended cache?
When a clean page is evicted from the RAM buer, does it have to be cached in flash memory at all or given as much preference as a dirty page?
both clean and dirty page
Please refer to the paper for details
MySQL with FaCE
We implemented FaCE scheme on MySQL 5.6.26. You can see the all source code in the Github repository.
- FaCE can be used to recover the system more quickly
- We don’t need to use DoubleWrite Buffer for recovery
- Reduce two writes(DWB+DB file) to one(FaCE)
The database size was set to approximately 50GB, and the DRAM buffer pool was limited to 1GB in order to amplify I/O effects for a relatively small database. The number of concurrent clients was set to 32. The benchmark database and workload were created by the tpcc-mysql. We used two types of storage device. One is a commodity SSD, Samsung 840 PRO SSD. And the other is a RAID-0 disk array with 8 drives. The benchmark result is as follows.
As you can see, in case of FaCE, transaction throughput increased about two times compared to the original MySQL.
We proposed a low-overhead caching method called FaCE that utilizes flash memory as an extension to a DRAM buffer for a recoverable database. FaCE caches data pages in flash memory on exit from the RAM buffer. By basing its caching decision solely on the RAM buffer replacement, the flash cache is capable of sustaining high hit rates without incurring excessive run-time overheads for monitoring access patterns, identifying hot and cold data items, and migrating them between flash memory and disk drives.
We have implemented FaCE and its optimization strategies within the MySQL open source database server, and demonstrated that FaCE achieves a significant improvement in the transaction throughput.
We have also made a few important observations about the effectiveness of FaCE as a flash caching method.
- FaCE demonstrates that adding flash memory as a cache extension is more cost effective than increasing the size of a DRAM buffer.
- the optimization strategies (i.e., GSC) of FaCE indicate that turning small random writes to large sequential ones is critical to maximizing the I/O throughput of a flash caching device so as to achieve scalable transaction throughput.
- the mvFIFO replacement of FaCE enables efficient and persistent management of the metadata directory for the flash cache, and allows more sustainable I/O performance for higher transaction throughput.
- FaCE takes advantage of the non-volatility of flash memory to minimize the recovery overhead and accelerate the system restart from a failure. Since most data pages needed during the recovery phase tend to be found in the flash cache, the recovery time can be shortened significantly.