 |
|
In Memory Databases vs. Solid State Disks
Oracle Tips by Burleson Consulting |
In Memory
Databases vs. Solid
State Disks
By
Woody Hutsell and Jamon Bowen
In-memory databases have
recently become an intriguing topic for the database industry. With the
mainstream availability of 64-bit servers with many gigabytes of memory a
completely RAM based database solution is a tempting prospect to a much wider
audience (See
Oracle's Times Ten and Oracle Cohesion Suite).
Using RA to speed Oracle application performance is not
new. Many database users in the Federal, Financial, and
Telecommunications fields, Solid State Disks have been providing a RAM based
database solution for decades. The question is which of these options is
best:
-
Full SSD - Replace disks with Solid-state.
-
Large data buffer - Cache 100% of data in
db_cache_size region.
-
Times Ten - Using Oracle's in-memory database.
The performance of any
memory based database solution eclipses the performance of a hard disk-based
database. Let's compare SSD with in-memory database solutions.
|
SSD |
In-Memory DBMS |
Ease of implementation |
Easy |
Hard |
Costs |
Low |
High |
Write performance |
Improved |
No change |
Reliability |
Excellent |
Dicey |
Availability |
Better |
Good |
Scalability |
Better |
Good |
Sharing |
Many servers |
One server |
ROI |
Better |
Good |
Ease of
Implementation
The obvious benefit from hardware-level SSD if the low
risk, because you do not need to alter a single line of code in your
application.
Installing in-memory
databases requires applications to be modified and in some cases, entirely
re-written. These projects are fraught with risk. Any new software development
effort requires people, time and money and as the in-memory database solution
has not been tested in a production environment, it is not clear that the
transition will help performance until all of the resources have already been
invested.
Solid state disk systems
can be attached to existing servers and storage networks without requiring any
application code changes.
Lower
Cost
In-memory databases have
four significant cost components:
1) application life cycle costs;
2) cost for
the memory in the server;
3) costs associated with additional processors and
4)
license costs for the in-memory software.
The cost for memory in a
server increases dramatically as higher capacities of memory are used. Low
density memory chips provide a good price per capacity, but the highest density
DIMMS are very costly. Further, with most computing architectures, there is a
direct relationship between the size of the memory and the number of server
processors.
Adding memory to
accommodate an in-memory database often requires buying additional processors.
The cost per processor is notable and probably wasted as the application needing
a memory database likely does not require additional processing power. Finally,
many in-memory database vendors charge for their software based on a mix of
total memory capacity and number of server processors. When all costs are
calculated, solid state disk systems offer a more economical option.
Dramatically Improved Write Performance
In-memory databases are
only useful for accelerating reads. These databases have to persist writes to a
journal or log that is on a hard disk based system. This is done to preserve
data integrity in the event of a server crash or power outage. Therefore, an
application with even medium write load could be slowed down by an in-memory
database.
Reliability
Solid State disks
incorporate enterprise class storage system reliability features, providing
advanced memory protections schemes such as ECC
and Chipkill (allowing a memory chip to fail lost without data loss).
Enterprise class solid
state disks incorporate redundant batteries and disks with the intelligence to
reliably persist the data to disk. This provides a nonvolatile system that
server memory cannot match. It is not uncommon for large in-memory databases to
have frequent outages to replace bad memory. Each occurrence causes application
downtime to replace them memory and additional time for data to be reloaded into
the memory subsystem.
Availability
Using solid state disks as
part of a high performance database allows the storage and server components of
an application to be decoupled from one another. This allows the server
component of the application to be protected from server crashes and application
bugs by deploying a Real Application Cluster with several nodes without
exponentially increasing the memory costs. In extremely high availability system
the Solid State Disks can be mirrored to provide an added level of protection.
Scalability
Solid State disk offer a
truly scalable approach to high performance databases. Additional storage can be
easily added as the system scales, with production systems deployed in the
Terabyte range. Additionally, in stark contrast the price of server memory, the
price for adding capacity to solid state disks decreases as the total capacity
increases.
Shareability
Solid state disks, like
those offered by Texas Memory Systems can be shared across multiple servers
simultaneously. This allows the one time memory investment to benefit multiple
servers at one time. An in-memory database is only useful to one server
Long-term
ROI
When the time comes for an
in-memory database server to be upgraded through a tech-refresh, which is
probably every 24-36 months, it is likely that all of the memory purchased for
that server will be discarded because the new server will require a new type of
memory. An external solid state disk can be attached to new servers and continue
to provide many more years of benefits.
 |
If you like Oracle tuning, see the book "Oracle
Tuning: The Definitive Reference", with 950 pages of tuning tips and
scripts.
You can buy it direct from the publisher for 30%-off and get
instant access to the code depot of Oracle tuning scripts. |