In-memory database

From Wikipedia, the free encyclopedia
Jump to: navigation, search

An in-memory database (IMDB; also main memory database system or MMDB or memory resident database) is a database management system that primarily relies on main memory for computer data storage. It is contrasted with database management systems that employ a disk storage mechanism. Main memory databases are faster than disk-optimized databases since the internal optimization algorithms are simpler and execute fewer CPU instructions. Accessing data in memory eliminates seek time when querying the data, which provides faster and more predictable performance than disk.[1][2]

In applications where response time is critical, such as telecommunications network equipment and mobile advertising networks, main memory databases are often used.[3] IMDBs have gained a lot of traction, especially in the data analytics space, starting mid-2000s mainly due to cheaper RAM.[4][5]

With the introduction of NVDIMM technology, in-memory databases will now be able to run at full speed and maintain data in the event of power failure.[6][7][8]

ACID support[edit]

In their simplest form, main memory databases store data on volatile memory devices. These devices lose all stored information when the device loses power or is reset. In this case, MMDBs can be said to lack support for the durability portion of the ACID (atomicity, consistency, isolation, durability) properties. Volatile memory-based MMDBs can, and often do, support the other three ACID properties of atomicity, consistency and isolation. However, since Non-Volatile DIMMs (NVDIMM) have become available, most future IMDB or MMDB installations will indeed have the durability to meet full ACID support.

Many MMDBs have added durability via the following mechanisms:

  • Snapshot files, or, checkpoint images, which record the state of the database at a given moment in time. These are typically generated periodically, or, at least when the MMDB does a controlled shut-down. While they give a measure of persistence to the data (in that not everything is lost in the case of a system crash) they only offer partial durability (as 'recent' changes will be lost). For full durability, they will need to be supplemented by one of the following:
  • Transaction logging, which records changes to the database in a journal file and facilitates automatic recovery of an in-memory database.
  • Non-Volatile DIMM (NVDIMM), a memory module that has a DRAM interface, often combined with NAND flash for the Non-Volatile data security. The first NVDIMM solutions were designed with supercapacitors instead of batteries for the backup power source. With this storage, MMDB or IMDB can resume securely from its state upon reboot.
  • Non-volatile random access memory (NVRAM), usually in the form of static RAM backed up with battery power (battery RAM), or an electrically erasable programmable ROM (EEPROM). With this storage, the MMDB system can recover the data store from its last consistent state upon reboot.
  • High availability implementations that rely on database replication, with automatic failover to an identical standby database in the event of primary database failure. To protect against loss of data in the case of a complete system crash, replication of a MMDB is normally used in conjunction with one or more of the mechanisms listed above.

Some MMDBs allow the database schema to specify different durability requirements for selected areas of the database - thus, faster-changing data that can easily be regenerated or that has no meaning after a system shut-down would not need to be journaled for durability (though it would have to be replicated for high availability), whereas configuration information would be flagged as needing preservation.

Hybrids with on-disk databases[edit]

The first database engine to support both in-memory and on-disk tables in a single database was WebDNA: it was released in 1995. The advantage to this approach is flexibility: the developer can strike a balance between performance (which is enhanced by sorting, storing and retrieving specified data entirely in memory, rather than going to disk); cost, because a less costly hard disk can be substituted for more memory; persistence; and form factor, because RAM chips cannot approach the density of a small hard drive.

Gartner in its 2014 Who's Who in In memory DBMSs, references Altibase HDB (Hybrid database) as an enterprise level hybrid database that supports full ACID and can persist data in memory or disk.[9]

Manufacturing efficiency is another reason a combined in-memory/on-disk database system may be chosen. Some device product lines, especially in consumer electronics, include some units with permanent storage, and others that rely on memory for storage (set-top boxes, for example). If such devices require a database system, a manufacturer can adopt a hybrid database system at lower and upper cost, and with less code customization, than using separate in-memory and on-disk databases, respectively, for its disk-less and disk-based products.

Storage memory[edit]

Another variation is to have large amounts of nonvolatile memory in the server. For example Flash memory chips as addressable memory rather than structured as disk arrays. A database in this form of memory combines very fast access speed with persistence over reboots and power losses.[10]

See also[edit]


  • Jack Belzer. Encyclopedia of Computer Science and Technology - Volume 14: Very Large Data Base Systems to Zero-Memory and Markov Information Source. Marcel Dekker Inc. ISBN 0-8247-2214-0. 

External links[edit]