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.