Interview: Jeff Chang And Steve Graves Cover In-Memory Databases

DIMM modules are also available with built-in supercaps (Fig. 2). These are easier to install assuming there is sufficient headroom available for the complete package.

Wong: McObject develops an in-memory database system (IMDS). What is that and how is it relevant for designers of electronics?

Chang and Graves: A database management system (DBMS) is software used to store and organize data (the database) and to provide capabilities including database definition, configuration, population, querying and updates. A DBMS can be relatively simple, one-off code created for a specific application. However, for electronics’ embedded software, the trend has been away from such “homegrown” DBMSs and toward off-the-shelf database systems. Designers of electronics are choosing to go this route in order to shorten the engineering cycle (it is faster to buy a proven database system than it is to build one). In addition, compared to a homegrown database system, a third-party DBMS typically can be extended more easily by adding new indexes and tables, and naturally separates application logic from database logic, to accommodate application upgrades and new features.

Traditional DBMSs – those used by your company’s payroll and human resources applications, for example – are premised on the idea of persistent storage: while some data will be cached in memory to provide quick access, all database updates are written through cache to a hard disk, solid state drive or other permanent storage.

In-memory database systems (IMDSs) are a newer kind of DBMS that eliminates persistent storage, instead keeping the database entirely in main memory. This has several advantages for electronics’ embedded software. First, working with data in main memory is much faster, and embedded applications typically demand low latency. Second, since data is kept in main memory, IMDSs eliminate many of the “moving parts” of traditional DBMSs, including caching and file management. This enables a simpler, streamlined architecture that demands fewer CPU cycles, permitting the use of a less powerful – and less expensive – microprocessor.

McObject develops eXtremeDB, an IMDS product family designed specifically for embedded systems. Today, eXtremeDB can be found in electronics ranging from IP routers to MP3 players, set-top boxes, avionics and much more.

Wong: One of McObject’s partners is AgigA Tech, a Cypress Semiconductor subsidiary. What is their hardware, and how does it work?

Chang and Graves: AgigA Tech is a pioneer in high-speed, high-density, battery-free non-volatile RAM. As any electronics designer knows, conventional DRAM needs electrical power to do its job: pull the plug and you lose whatever is in memory. The idea of NVRAM grew from the desire for computer memory that would survive interruption of system power. The most familiar type of non-volatile RAM today is probably DRAM that incorporates a battery to maintain data in memory during a power failure. However, disadvantages of “battery-backed RAM” include batteries’ restrictive temperature requirements and the risk of leaking corrosive and toxic fluids. This solution also suffers from limited length of storage (data typically must be transferred from the chip within 72 hours of failover to battery), long re-charge cycles, finite battery shelf life, and overall high cost-of-ownership.

Related Articles

• Memory Channel Storage Puts SSD Next To CPU
• Non-Volatile DIMMs and NVMe Spice Up The Flash Memory Summit
• The Changing Face Of Non-Volatile Storage
• Moving Back To Magnetic Storage

AgigA Tech's AGIGARAM NVDIMM overcomes battery-backed RAM’s limitations. It gets rid of the battery and instead combines standard DRAM with NAND flash and an ultracapacitor power source. When a system operates normally, AGIGARAM provides all the capabilities of high speed DRAM. But in the event of power loss, the ultracapacitor provides a burst of electricity used to write main memory contents to the NAND flash chip, where it can be held virtually indefinitely. Upon system recovery, the AGIGARAM NVDIMM transfers data from NAND flash back into DRAM, restoring the in-memory state prior to the power loss event. Another key feature of this NVDIMM technology is that they are intended to plug into exisitng DIMM sockets, simplifying integration into off-the-shelf platforms.

Chang and Graves: Data is persistent when it can outlive the shutdown or interruption of the DBMS that created and/or manages it. Usually this is achieved via persistent storage using a device such as a hard disk. A similar, related concept is data durability. Database systems typically group updates into transactions, and durability guarantees that transactions that have committed will survive permanently (even in the event of power loss or other system failure). In the white paper title, the term “durability” could be swapped in for “persistence” – what we’re referring to is the database’s ability to survive/recover from failure, such as power loss or a system re-boot. In-memory databases gain their outstanding performance by eliminating persistence (by replacing hard drive or SSD with main memory storage). Unless steps are taken, data managed by an IMDS lacks durability.

For some electronics, this absence of persistence/durability does not matter. For example, a set-top box that keeps its electronic programming guide in RAM will lose that guide if power fails, but the information can be re-built quickly from the cable head-end or satellite transponder .

But other device-based software needs a database system that can recover stored data to its pre-failure state. Examples of such devices might include an IP router that requires instant recovery of its control plane database to avoid delay in forwarding packets, or a medical device that must have a record of vital signs over time to support clinical decisions.

Wong: If IMDSs store data in DRAM, that indeed sounds vulnerable. For electronics that require it, what other steps can be taken to make data stored in in-memory databases more durable?

Chang and Graves: It is true that conventional main memory (DRAM) is inherently volatile. This has driven the development of several techniques to add durability to IMDSs. One solution is battery-backed RAM, with the shortcomings mentioned above.

Another way for an IMDS to survive failure is database replication, in which one or more standby in-memory databases are created on failure-independent nodes and kept in synch with the “master” or main database. If the main node goes down, one of these replicas takes over as master via a failover process. Such a high availability (HA) database configuration lends durability.

However, keeping replica database nodes synchronized with the master imposes some system latency – and here we encounter the “performance penalty” mentioned in the white paper’s title. Managing the high availability sub-system drains off CPU cycles. Time is required for communication between nodes. The performance impact is greater when following a strategy of 2-safe or “eager” replication, in which updates are applied to all replicas as part of the original transaction. In contrast, 1-safe or “lazy” replication, in which transactions can close on the master node before they complete on replica nodes, is faster – but poses the risk of imperfect synchronization between nodes at the moment of failure, which lessens the guarantee of durability.

Transaction logging is another way that IMDSs can add durability. In this approach, the database system captures changes and writes them to a log file, which can be used to restore the database after failure. But logging itself requires writes to persistent storage, and their accompanying performance penalty.

Another reason is that widely-used b-tree database indexes can greatly improve random lookups, and retrieval of database content in sorted order, but they are also expensive for an on-disk DBMS to maintain during insert/update/delete operations, and become more burdensome as database size increases. (B-tree lookups are less costly with an IMDS because they impose no cache processing, accesses happen at in-memory speed, and trees are shallower because they contain no duplicated index data.)

However, it is undeniable that logging introduces some latency, a point that is driven home by the tests described in our report. Even when using a RAM-disk (that is, a memory-based analog of disk storage) as the “device” that stores the transaction log, using McObject’s eXtremeDB as a “pure” IMDS (no transaction logging) delivered performance that was more than two times faster for database inserts and deletes, and almost five times faster for database updates, compared to eXtremeDB with transaction logging enabled.

Wong: Which brings us to McObject’s current tests with AgigA Tech. Describe the tests. What did they seek to prove or disprove? What was the outcome?

Naturally, the tests included “pulling the plug” mid-execution, to prove or disprove the AGIGARAM product’s ability to save data persistently in the event of failure, and to facilitate recovery. A second goal was to check whether eXtremeDB is as fast using the AGIGARAM NVDIMM as main memory storage as it is with conventional DRAM. Proof of both recoverability and speed equal to conventional memory would mean that the eXtremeDB /AGIGARAM NVDIMM combination had achieved “persistence, without the performance penalty” mentioned in the report’s title.

And in fact, the tests delivered proof on both counts.

Response to system failure was tested using a simple technique: rebooting the test system mid-execution. When the system came back up, the test application re-started automatically, accessed the eXtremeDB database in its pre-failure state (upon recovery, the AGIGARAM NVDIMM had loaded it from its flash into its DRAM), checked for database consistency and resumed operation.

As for performance, the difference between using AGIGARAM NVDIMM vs. conventional DRAM as storage was negligible. The difference in performance on all the database operations tested – inserts, updates, deletes, index searches and table traversals – was within the margin of error for the measurement technique used.

The results also confirmed the speed advantage of using “pure” IMDS vs. an IMDS with transaction logging (IMDS+TL) or an on-disk DBMS. While the IMDS +TL combination outperformed the on-disk DBMS by a factor ranging from 5.6x to 12.77x (560% to 1277% faster), moving to the IMDS without logging boosted this advantage into the 26x to 28x range (2600% to 2800% faster). As mentioned above, a RAM-disk served as the storage “device” for tests of the IMDS+TL and on-disk DBMS. A RAM-disk is inherently much faster than an actual hard drive or SSD. The performance gap between the pure IMDS, and the IMDS+TL or on-disk DBMS using more conventional persistent storage, would be much larger.

Wong: Did the database system require any customization or special features to accommodate use of AGIGARAM NVDIMMs as main memory storage, or does eXtremeDB represent a “plain vanilla” IMDS in these tests – in other words, could you swap another IMDS and get the same results?

Chang and Graves: There was no customization of the database system, but test application code enabling database recovery leveraged an eXtremeDB feature that McObject originally added to enable customers in the aerospace industry to use its IMDS with battery-backed RAM as storage. This feature enables a process to re-connect to an NVRAM-hosted eXtremeDB database, initiate any needed cleanup, and resume normal operation, all after a system reboots. An application’s recovery algorithm assumes that the memory block of the database memory device assigned as MCO_MEMORY_ASSIGN_DATABASE can be re-used after an application crash or power failure by re-opening it with the additional flag MCO_DB_OPEN_EXISTING. In this way, after re-boot, eXtremeDB was able to access the database from the same AGIGARAM NVDIMM memory space that was used prior to the system restart.

We do not know of other database systems that offer a similar feature, or the difficulty they would face in adding it.

Wong: What are the likely applications of the joint McObject – AgigA Tech Solution?

Chang and Graves: The combination of the eXtremeDB In-Memory Database System using AGIGARAM NVDIMMs as main memory storage offers a powerful new data management solution for the sub-set of real-time and embedded applications that require in-memory speed and durability. Based on knowledge gained by working with customers across many high performance application categories, we expect strong interest in fields including telecom and networking equipment, aerospace, defense, industrial control, medical and real-time financial systems such as automated trading.

Wong: Are there additional use cases for NVDIMMs in electronics beyond IMDS storage?

Chang and Graves: Yes, any application that requires low latency memory access and has critical data in-flight that must persist over power interruption is a fit for NVDIMMs. Some examples of this would be write-caching for servers and storage appliances, metadata storage, message queueing and data analytics.