BANGALORE, INDIA: In-memory database systems (IMDSs) store records in main memory, they never go to disk. Through this elimination of disk access, IMDSs claim significant performance gains over more familiar database management systems (DBMSs).

But, the fact that retrieval from memory trumps disk access for performance adds nothing new to database knowledge. Traditional databases have long offered caching as a way to hold frequently-used records in memory, in order to increase responsiveness. Do in-memory databases really offer anything new?

As it turns out, physical disk I/O is just the most final, and the most visible, link in a chain of processing inherent to traditional databases (let’s call them on-disk databases) and premised on the idea that data must ultimately reside in permanent storage. Caching boosts DBMSs’ performance, especially when an application is reading records; however, all DBMS updates are ultimately written through the cache, to disk.

IMDSs gain their advantage by eliminating or greatly mitigating this bundle of processing “costs,” including the following:

Caching

Ironically, while on-disk DBMSs use caching to boost performance, IMDSs gain considerable speed by dispensing with it. Processes that make up caching include cache coherence, which makes sure that an image of a database page in cache is consistent with the physical database page on disk and (when applicable) other caches in a distributed cache setting;  cache lookup, which determines if data requested by the application is in cache and, if not, retrieves the page; and least-recently used (LRU) algorithms within general cache management logic to keep frequently accessed data in cache and flush out less frequently accessed data.

Caching functions play out every time the application makes a function call to read a record from disk, draining CPU cycles and consuming memory. IMDSs impose no such overhead. Eliminating these processes (and others) also simplifies the overall design of IMDSs, resulting in a smaller code size and lower demands for memory and CPU cycles.

Data Transfer Overhead

Data transfer also causes on-disk databases to lag. With such DBMSs, the application works with a copy of the data contained in a program variable that is several times removed from the database. Consider the "handoffs" shown in below figure for an application to read a piece of data from an on-disk DBMS, modify it, and write that  data back to the database.

In contrast, with an IMDS, there are at most two copies of the data:  The copy within the database and possibly a working copy in local storage during the scope of a database transaction.

Operating System Dependency

Operating system dependency presents another significant performance variable. On-disk databases use the underlying file system to access data within the database. The quality of data-seeking functions provided by a particular OS (such as lseek() under Linux) will affect performance, for better or worse. In contrast, the in-memory database operates independent of the OS file system and is highly optimized for data access.