Integrating Non-Volatile Memory into an Existing, Enterprise-Class In-Memory DBMS

By Alexander Böhm.

The emergence of non-volatile memory (NVM, also referred to as persistent memory) provides new challenges and opportunities for database management system architects and vendors, in particular in the context of in-memory systems. On the one hand, as outlined by Pavlo et al [1] in this year’s SIGMOD conference, NVM enables reliable data storage without the necessity to write data to spinning disks or SSDs. This enriches the design space of DBMS, e.g. enabling innovative approaches such as write-behind logging [2]. On the other hand, NVM adds a significant amount of engineering challenges and difficulties, such as potential memory leaks becoming persistent, memory overwrites corrupting durable storage, or the need for undo/cleanup code to handle partial failure during data structure updates in NVM, to only name a few (Oukid et al [3] provide an excellent overview).
Looking at this current state of research, it seems clear that one cannot just replace DRAM chips with NVM and automatically benefit from data persistence and potentially reduced costs. For existing DBMS, this leads to the question whether and how they can be changed to consume and/or benefit from NVM.

Is it time for a complete rewrite?

We analyzed this question in the context of the SAP HANA system, SAP’s in-memory DBMS flagship solution [4]. Specifically, our motivation was to find a sweet spot between potential challenges of the technology (i.e. the software engineering difficulties mentioned above) and capitalizing on the main advantages like “automatic” durability, fast system restart, and increased storage capacity per DIMM.
A key factor that allows us to adopt NVM in the context of the HANA column store is the separation of each table into two separate containers, called the main and delta fragments: The main fragment is immutable and optimized for read-access, using dictionary compression with sorted dictionaries. All updates to a table are implemented as changes to the delta fragment, which also uses dictionary compression, but doesn’t keep the dictionaries sorted. Periodically, the content of the delta and main fragments are consolidated using a special “merge” operation, which is also the only source of writes to the main fragment. Usually, the merge operation is done automatically by the system to ensure that not more than 10% of a table’s data resides in the delta fragment.
In this architecture, the main is an excellent candidate for NVM adoption: It typically captures more than 90% of the overall data of a system, allowing us to make efficient use of NVM and benefiting from its higher capacity. Many software challenges are mitigated by the fact that write operations to the NVM main only happen in the context of the merge operation, reducing the code paths to be reviewed and hardened to a minimum.
While the integration is very beneficial and looks easy on a conceptual level, there are numerous design and implementation challenges when trying to retrofit an existing enterprise-class system with NVM support. We will discuss them in detail [5] at this year’s VLDB conference in Munich and are looking forward to meet you there.

[1] Joy Arulraj, Andrew Pavlo: How to Build a Non-Volatile Memory Database Management System. SIGMOD Conference 2017: 1753-1758
[2] Joy Arulraj, Matthew Perron, Andrew Pavlo: Write-Behind Logging. PVLDB 10(4): 337-348 (2016)
[3] Ismail Oukid, Wolfgang Lehner: Data Structure Engineering For Byte-Addressable Non-Volatile Memory. SIGMOD Conference 2017: 1759-1764
[4] Norman May, Alexander Böhm, Wolfgang Lehner: SAP HANA – The Evolution of an In-Memory DBMS from Pure OLAP Processing Towards Mixed Workloads. BTW 2017: 545-563
[5] Mihnea Andrei et al: SAP HANA Adoption of Non-Volatile Memory. To appear in PVLDB 2017

You may also like...