By Francisco Fronda, BiTMICRO Networks
INTRODUCTION
The purpose of this document is to
provide the reader valuable insights into the write endurance aspects
of using Flash memory-based solid state disks within typically encountered
database applications in an enterprise environment. The same principles
used in this paper will also apply to applications that are flat
file based as opposed to relational databases.
Despite having already considered using non-volatile solid state
disks to complement traditional mechanical drive based storage in
an attempt to enhance overall application performance, the reader
may want to be advised of how any issues concerning solid state
flash disk write endurance limitations are addressed with confidence.
Flash Memory and Write Endurance
Flash memory is a form of EEPROM that allows multiple memory locations
to be erased or written in one programming operation. Normal EEPROM
only allows one location at a time to be erased or written, meaning
that Flash can operate at higher effective speeds when the systems
using it read and write to different locations at the same time.
All types of Flash memory and EEPROM wear out after a certain number
of erase operations.
Flash memory is classified into two main types: NOR Flash and NAND
Flash. The names refer to the type of logic gate used in each storage
cell. Some flash solid state disks utilize NAND Flash since it has
faster erase and write times, higher density, and lower cost per
bit than NOR Flash, and about ten times the endurance. Most NAND
Flash manufacturers today claim a write endurance of 1 million write
cycles per block.
Intelligent Flash drives will use a combination of write-back cache,
wear leveling and bad block auto-remapping techniques that virtually
extend Flash memory erase/write endurance by several orders of magnitude.
Database Application I/O Workload Profile
Let us examine different database applications and database functions,
and their typical I/O workload profiles that determine the nature
of access to disk. They will usually differ in terms of the frequency
and size of the I/O requests, and whether or not access to the data
will mostly be sequential or random.
The key high-level application types include transaction processing,
decision support and batch processing systems. In this section we
will examine the various access patterns on database files and select
a typical application for the purpose of studying solid state flash
disk write endurance when used within a database environment.
A study of the best practices in using SSD to derive performance
benefits where hot (heavily used) files are used in a database application
scenario is another extensive topic that is better discussed in
a separate paper. Batch Processing
In enterprise applications, batch processing is the most likely
application to produce significant sequential I/O on the data files.
Typical examples will be bulk loading of data warehouses, high-speed
data acquisition and video-on-demand content loading applications.
Disk access profile will mostly be sequential in nature and with
a very high percentage of writes versus reads, which essentially
poses a worst case scenario for determining Flash memory disk write
endurance.
Decision Support System (DSS)
Decision support or data warehousing applications perform queries
on a large amount of data, usually gathered from OLTP applications,
and provide competitive information to the decision-makers in an
organization. Decision support systems must handle complex queries
on data that is less frequently updated than OLTP systems.
DSS is characteristic of multiple users executing complicated joins
and aggregations on large sets of data. Even though many of the
operations could use some sequential processing, contention with
other users and join and indexing operations result in a fairly
random access pattern to the data and index files.
Assuming that the database is dedicated to the DSS application,
few updates will be done to the database during heavy query. Due
to its mostly query-based nature versus updates for disk access,
DSS applications may not be the best candidate for a study on the
write endurance of flash solid state disks.
Online Transaction Processing (OLTP)
Online transaction processing (OLTP) applications are high-throughput,
insert/update intensive systems. These systems are usually characterized
by constantly growing large volumes of data that large number of
users access concurrently. Examples of typical OLTP applications
are order processing applications, banking applications and reservation
systems.
The I/O profile resulting from this load is heavy random reads and
writes across the data and index files. The transaction logs, however,
are hit with a heavy stream of sequential write operations of 2K-16K
bytes in size. This makes an OLTP application a better example of
a typical database application for our purpose when compared to
DSS and batch applications.
The choice of the type of RAID for the solid state flash disk's
use of the database or parts of it will impact more on the system's
overall performance improvements and not on write endurance of the
flash solid state disk. The case presented in the succeeding sections
uses interleaved parity RAID 5 that involves one physical write
to the stripe (or drive) per logical write, just like other basic
types of RAID (0, 1, 2, 3 or 4).
Characteristics of OLTP and DSS are summarized in Table 1.
| Characteristics |
OLTP |
DSS |
| Transaction |
Regular business transactions, Heavy
on retrievals, and updates Short and quick queries |
Ad hoc queries on historical data
Heavy on retrievals, light on updates Complex and long running
queries |
| Performance |
User response time critical |
Complex queries User response not
critical |
| Concurrent Users |
Many |
Few |
| Disk I/O |
- 60 - 80 % reads
- 20 - 40% writes
- Frequent disk writes
- New records are continually added and existing records
are updated or deleted
|
- 90% reads
- 10 % writes (except during builds)
- Relatively few disk writes
- Pages are moved in and out of cache
|
Table 1: Characteristics of OLTP and DSS
Page: 1 | 2
| 3
| 4
| NEXT
|
