 |
|
Using solid-state disks to improve I/O
speed on optimized databases
Oracle Tips by Mike Ault |
Let's go
solid
What I am referring to is the new trend (well, actually
it has been around since the 90's) to move databases to
solid state drives. In almost all cases this form of
going solid leads to measurable performance improvements
by elimination of the various latencies involved with
the standard computer disk drive assemblies. Of course
the removal of disk rotational and arm latencies is just
one of the things that solid state drives bring to the
table, the other is access to your data at near-memory
speeds.
What solid state drives mean to an application is that
if your application is currently suffering from IO
problems some if not all of them are relieved. However,
the benefits are a bit lop sided depending on the
predominant type of IO wait your system is seeing. If
your IO waits are due to contention during the retrieval
of information (SELECT statements) then you can expect a
dramatic increase in performance. In tests against
standard disk arrays using the TPC-H benchmark I was
able to achieve a 176 times performance increase for
primarily retrieval based transactions. For what I refer
to as IUD transactions (INSERT, UPDATE and DELETE) only
a 30-60% performance improvement was shown.
Remember that retrieval requires no additional
processing once the data location is returned from the
search process, while IUD involves data verification via
indexes, constraints and other internal processes that
tend to slow down the process thus reducing the
performance gains. Does solid state disk (SSD)
technology eliminate waits? Of course not, what it does
is reduce their duration. For example, looking at load
times:
Load Graph Using SSD
You can from the graph that load times for standard
disks was on the average about 30% slower than the load
times for an equivalent SSD drive array.
However looking at query response time, we see an
entirely different picture:
SSD Queries
When we compare the SSD times with the same queries,
same OS settings and same layout on standard drives, we
see a dramatic difference (notice the scale on this next
graph is logarithmic, not linear):
ATA Queries
The second graph really drives home the point, I had to
make it logarithmic because of the great differences in
time duration for the various queries when going to
disks. What required a couple of hours (running the 20+
base queries) on SSD required 3 days on the average for
the ATA drives.
Of course we don't remove the IO waits by using SSD,
their duration is simply reduced to the point they are
not a big factor anymore. Of course, for scalability and
such you still will need to tune SQL.
Some how, I see going solid in our future.
For a complete copy of the testing, see the new book "Oracle
tuning with solid-state disk" and
my newest book, "Oracle
RAC and Grid tuning with SSD".
Market Survey of SSD vendors for
Oracle:
There are many vendors who offer rack-mount solid-state disk that
work with Oracle databases, and the competitive market ensures that
product offerings will continuously improve while prices fall.
SearchStorage notes that SSD is will soon replace platter disks and that
hundreds of SSD vendors may enter the market:
"The number of vendors in this category could rise to several
hundred in the next 3 years as enterprise users become more familiar
with the benefits of this type of storage."
As of January 2015, many of the major hardware vendors (including Sun and
EMC) are replacing slow disks with RAM-based disks, and
Sun announced that all
of their large servers will offer SSD.
Here are the major SSD vendors for Oracle databases
(vendors are listed alphabetically):
2008 rack mount SSD Performance Statistics
SearchStorage has done a comprehensive survey of rack mount SSD
vendors, and lists these SSD rack mount vendors, with this showing the
fastest rack-mount SSD devices:
| manufacturer |
model |
technology |
interface |
performance metrics and notes |
|
IBM |
RamSan-400 |
RAM SSD |
Fibre
Channel
InfiniBand
|
3,000MB/s random
sustained external throughput, 400,000 random IOPS |
|
Violin Memory |
Violin 1010 |
RAM SSD
|
PCIe
|
1,400MB/s read,
1,00MB/s write with ×4 PCIe, 3 microseconds latency |
|
Solid Access Technologies |
USSD 200FC |
RAM SSD |
Fibre Channel
SAS
SCSI
|
391MB/s random
sustained read or write per port (full duplex is 719MB/s), with
8 x 4Gbps FC ports aggregated throughput is approx 2,000MB/s,
320,000 IOPS |
|
Curtis |
HyperXCLR R1000 |
RAM SSD |
Fibre Channel
|
197MB/s sustained
R/W transfer rate, 35,000 IOPS |
Choosing the right SSD for Oracle
When evaluating SSD for Oracle databases you need
to consider performance (throughput and response time), reliability (Mean Time Between failures) and
TCO (total cost of ownership). Most SSD vendors will provide a
test RAM disk array for benchmark testing so that you can choose the
vendor who offers the best price/performance ratio.
Burleson Consulting does not partner with any SSD vendors and we
provide independent advice in this constantly-changing market. BC
was one of the earliest adopters of SSD for Oracle and we have been
deploying SSD on Oracle database since 2005 and we have experienced SSD
experts to help any Oracle shop evaluate whether SSD
is right for your application. BC experts can also help you choose
the SSD that is best for your database. Just
call 800-766-1884 or e-mail.:
 for
SSD support details. DRAM SSD
vs. Flash SSD
With all
the talk about the Oracle “flash cache”, it is important to note that there
are two types of SSD, and only DRAM SSD is suitable for Oracle database
storage. The flash type SSD suffers from serious shortcomings, namely
a degradation of access speed over time. At first, Flash SSD is 5
times faster than a platter disk, but after some usage the average read time
becomes far slower than a hard drive. For Oracle, only rack-mounted
DRAM SSD is acceptable for good performance:
|
|
Avg. Read speed
|
Avg. write speed
|
|
Platter disk
|
10.0 ms.
|
7.0 ms.
|
|
DRAM SSD
|
0.4 ms.
|
0.4 ms.
|
|
Flash SSD
|
1.7 ms.
|
94.5 ms.
|
|
