One of those capabilities added to previously transactionally-focused databases, per my last post, is in-memory architectures. In-memory is the current fastest commercial medium for data storage, upwards of thousands of times faster than HDD. Naturally, it is expensive relatively speaking or it would be more pervasive now. However, the price point has lowered and we are having an in-memory hardware renaissance.
Now that we have multi-core processors that truly maximize the value of hardware and the price of memory precipitously dropping, we are able to use “more of” something that we have used for quite some time, but only for a very small slice of data – memory. Next generation CPUs will have thousands of cores, expanding the addressable memory tremendously.
In-memory capabilities will be the corporate standard for the near future, especially for traditional databases, where disk I/O is the undisputed weak-link and bottleneck. In-Memory systems do not have disk I/O. Access to databases in main memory is up to 10,000 times faster than access from storage drives. Near-future blade servers will have up to 500 gigabytes of RAM. Already systems are being sold with up to 50 terabytes of main memory. Compression techniques can make this effectively 10x – 20x that size.
There are currently few database systems that would claim to be absent any in-memory capabilities and with a roadmap with near-term very strong in-memory capabilities. These are fully functional relational systems that excel when real-time, delay-free access to data can be utilized and delays have measurable negative impact on the business.
The key to in-memory performance is hardware exploitation by the software. Using high levels of caching speeds up retrieval but does nothing for writes. Managing a cache is overhead on the system. Also simply putting a traditional database in RAM has been shown to dramatically underperform an in-memory database system, especially in the area of writes.
There are also variants of In-memory like the Vector Processing done by IBM’s BLU Acceleration, which is exploiting the firmware commands in the Intel chips. With a single instruction, you can retrieve multiple data sets. This is a form of “in chip” processing, likely to usher In-memory into its place as key to future processing.
Most software does not exploit multi-core and is not core aware.
There are multiple features for adding persistence to In-memory systems. These include periodic snapshots, keeping multiple copies of the database in memory, using non-volatile RAM and disk-based persistence.
Some DBMS take in-memory a step further by considering the relative priority of data and, though all data is backed by disk, it will automatically transfer it in and out of memory as appropriate. It’s in-memory driven by data temperature (and this extends to HDD and SSD). You still need to allocate the memory (and SSD) initially but whatever you allocate will be intelligently utilized.
You are looking at the future of processing with In-Memory processing, whether for an operational or an analytic system. It’s possible to store your whole operational or analytic database entirely in RAM as the primary persistence layer. With the increasing number of cores (multi-core CPUs) becoming standard, CPUs are able to process increased data volumes in parallel. Main memory is no longer a limited resource. These systems recognize this and fully exploit main memory. Caches and layers are eliminated because the entire physical database is sitting on the motherboard and is therefore in memory all the time. And it’s been proven to be nearly linearly scalable. HDD may find its rightful spot as archive, backup and NoSQL storage.
In-memory performance is increasing the threshold (data size, complexity) where NoSQL systems and Hadoop make sense.
Leading platforms will undoubtedly be In-Memory over the next 5-10 years. Be prepared. A fair question for any CIO in any organization large or small is “Are we exploiting In-memory processing?” If not, why not? If the business is incapable of capitalizing on the benefits, that might be an area worth improving. If you can achieve an order of magnitude improvement in transactional speed or value-added quality, market share is not far behind.
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.