Adapting to NVRAM is going to be a lengthy process. This was pointed out by a recent paper. More on that later.
Thankfully, Intel wildly pre-announced 3D XPoint. That has spurred OS and application vendors to consider how it might affect their products.
As we saw with the adoption of SSDs, it takes time to unravel the assumptions built into products. Take databases: they spent decades optimizing for hard drives, and when SSDs came along many of those optimizations became detrimental.
On the face of it it shouldn’t be that hard. You want a durable transaction, you have persistant NVRAM. Are we good here?
In a paper published by Microsoft Research, DUDETM: Building Durable Transactions with Decoupling for Persistent Memory, the authors (Mengxing Liu, Mingxing Zhang, Kang Chen, Xuehai Qian, Yongwei Wu, Jinglei Ren) go into the issues:
While persistent memory provides non-volatility, it is challenging for an application to ensure correct recovery from the persistent data on a system crash, namely, crash consistency. A solution . . . is using crash-consistent durable transaction[s]. . . .
Most implementations of durable transactions enforce crash consistency through logging. However, the. . . dilemma between undo and redo logging is essentially a trade-off between update redirection cost and persist ordering cost.
The authors make a bold claim:
[O]ur investigation demonstrates that it is possible to make the best of both worlds while supporting both dynamic and static transactions. The key insight of our solution is decoupling a durable transaction into three fully asynchronous steps.
To create a fully decoupled transaction system for NVRAM, the researchers made three key design decisions.
- A single, shared, cross-transaction shadow memory.
- An out of the box Transaction Memory.
- A redo log as the only way to transfer updates from shadow memory to persistent memory.
These design choices enabled building an ACID transaction in three decoupled, asynchronous, steps.
- Perform: execute the transaction in a shadow memory, and produce a redo log for the transaction.
- Persist: flush the redo log of each transaction to persistent memory in an atomic manner.
- Reproduce: modify original data in persistent memory according to the persisted redo log.
The paper is lengthy and a recommended read for those professionally interested in transaction processing on NVRAM. But here’s their performance summary.
Our evaluation results show that DUDETM adds guarantees of crash consistency and durability to TinySTM by adding only 7.4% âˆ¼ 24.6% overhead, and is 1.7Ã— to 4.4Ã— faster than existing works Mnemosyne and NVML.
The StorageMojo take
As we’ve seen with the transition from hard drives to SSDs, unwinding decades of engineered-in assumptions in the rest of stack is a matter of years, not months. There’s the issue of rearchitecting basic systems, such as transaction processing, or databases, and then the hard work of stepwise enhancement of those new architectures as we gain knowledge about how they intersect with the new technology and workloads.
There are going to be many opportunities for startups that focus on NVRAM. The technology is coming quickly and with more technology diversity – there are several types of NVRAM already available, with more on the way, and each has different trade-offs – which means that the opportunities for creativity are legion.
Courteous comments welcome, of course.