Jump to content

In-memory database

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 2605:6000:8785:be00:dbd:5763:b25b:50cd (talk) at 18:01, 13 March 2017. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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 because disk access is slower than memory access, 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]

Applications where response time is critical, such as those running telecommunications network equipment and mobile advertising networks, often use main-memoryb databases.[3] IMDBs have gained a lot of traction, especially in the data analytics space, starting in the mid-2000s – mainly due to multi-core processors that can address large memory and due to less expensive RAM.[4][5]

A potential technical hurdle with in-memory data storage is the volatility of RAM. Specifically in the event of a power loss, intentional or otherwise, data stored in volatile RAM is lost.[6] With the introduction of non-volatile random access memory technology,[when?] in-memory databases will be able to run at full speed and maintain data in the event of power failure.[7][8]

ACID support

In its 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, IMDBs can be said to lack support for the "durability" portion of the ACID (atomicity, consistency, isolation, durability) properties. Volatile memory-based IMDBs can, and often do, support the other three ACID properties of atomicity, consistency and isolation.

Many IMDBs 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. The system typically generates these periodically, or at least when the IMDB does a controlled shut-down. While they give a measure of persistence to the data (in that the database does not lose everything in the case of a system crash) they only offer partial durability (as 'recent" changes will be lost). For full durability, they need supplementing with 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, 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 re-booting IMDB system can recover the data store from its last consistent state.
  • 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 an IMDB is normally used in addition to one or more of the mechanisms listed above.

Some IMDBs 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

The first database engine to support both in-memory and on-disk tables in a single database, WebDNA, 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
  • form factor, because RAM chips cannot approach the density of a small hard drive

Manufacturing efficiency provides another reason for selecting a combined in-memory/on-disk database system. 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 customization of code, rather than using separate in-memory and on-disk databases, respectively, for its disk-less and disk-based products.

Storage memory

Another variation involves 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.[9]

See also

Notes

  1. ^ "Definition: in-memory database". WhatIs.com. Retrieved 19 January 2013.
  2. ^ Michael Vizard. "The Rise of In-Memory Databases". Slashdot. {{cite web}}: Unknown parameter |I deeply regret saying anything to you about my current situation. There was really no need to say anything. We are still in the exploring process and we have time before any decisions need to be made that impact other people (especially my children). I appreciate the advice. But I know ultimately I have to make the decisions that I truly believe are best. No one knows all that I have gone through and I choose not to keep revisiting my past in an effort to justify my decisions for the future. I wish I had approached this situation much differently. I feel like I was unfair to Antwon by exposing him to prejudgements simply because I felt the need to run my mouth and get the approval of everyone else before my other situation was disolved. I'm not sure what the rush was to inform so many people about a situation that may never come to be (in regards to moving). I know what I want and need at this point in my life. I always thought I was doing the "right" thing and it all blew up in my face because I didn't focus on what I knew was best for me. I can't be the best mom if I can't be the best me. I finally feel like the focus is on me, becoming a better me. Which I gladly accept at this point in my life. I know you are coming from a good place and I appreciate it but, I have to do my own soul searching over the next few months. accessdateb= ignored (help)
  3. ^ "TeleCommunication Systems Signs up as a Reseller of TimesTen; Mobile Operators and Carriers Gain Real-Time Platform for Location-Based Services". Business Wire. 2002-06-24.
  4. ^ "Falling RAM Prices Drive In-Memory Database Surge". SAP. Retrieved 19 January 2013.
  5. ^ "Rise of In-Memory Databases Impacts Wide Range of Jobs". Dice.com. July 13, 2012.
  6. ^ "In-memory computing: what happens when the power goes out?". Retrieved March 10, 2017.
  7. ^ Historically, RAM was not used as a persistant data store and therefore data loss in these instances was not an issue.Whole-system Persistence with Non-volatile Memories http://research.microsoft.com/apps/pubs/default.aspx?id=160853
  8. ^ The Bleak Future of NAND Flash Memory http://research.microsoft.com/apps/pubs/default.aspx?id=162804
  9. ^ "Truly these are the GOLDEN YEARS of Storage."

References

  • 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.