NVM作为主存上对数据库管理系统的影响

implications of non-volatile memory as primary storage for database managementsystems

摘要

传统的数据库管理系统使用磁盘存储关系型数据。硬盘的特点：廉价、持久性、大容量。然而，从磁盘进行读取数据代价非常高。为了消除这个延迟，需要DRAM作为中间媒介。DRAM的特点：比磁盘速度快，但容量小且不具备持久性。NVM是一个新兴的存储技术，具有容量大、字节寻址、堪比DRAM的存储速度、非易失兴。

本文，我们综述了NVM作为主存对关系型数据库管理系统的影响。即，研究了如何修改传统的关系型数据库管理系统以充分利用NVM的特性。修改了PostgreSQL的存储引擎，使之适配NVM，并详细描述了如何修改以及修改的挑战。最后通过一个全面的仿真平台对其进行测试评估。结果显示，数据存储在磁盘：修改后的PG查询时间比原生PG减少40%；数据存储在NVM，可以减少14.4%。平均分别减少20.5%和4.5%。

引言

一般数据库管理系统都是内存加磁盘的架构，数据集最终会持久化到磁盘。磁盘具有廉价、非易失的特性，适合存储大规模数据。然而，当从磁盘读取数据时，时间比较长。为了减少数据访问的延迟，在CPU和磁盘直接添加了DRAM作为中间存储媒介。DRAM的访问速度比磁盘快几个数量级。另外，随着DRAM芯片的密度增加以及内存价格的降低，具有大内存的系统变得越来越常见。

基于这些原因，传统的基于内存的关系数据库变得越来越流行。关系型数据库的重要部分，例如索引结构、恢复机制、提交处理过程等都是针对主存作为存储介质而定制的。但是关系型数据库在处理关键数据或者非冗余数据时仍然需要持久化存储介质，例如大量磁盘。

DRAM是影响数据库服务效率的重要因素。数据库在执行查询时，59%的电量耗费在主存上。此外，还有与漏电和电压相关的内置物质限制DRAM的进一步扩展。因此，DRAM作为主要内存介质，不可能跟上当前以及未来数据集的增长。

NVM是一种新型的硬件存储介质，同时具备磁盘和DRAM的一些特性。突出的NVM技术产品有：PC-RAM、STT-RAM和R-RAM。因为NVM具有设备层次上的持久性，所以不需要向DRAM一样的刷新周期以维持数据状态。因此NVM和DRAM相比，每bit耗费的能量更少。另外，NVM比硬盘有更小的延迟，读延迟甚至和DRAM相当；字节寻址；比DRAM密度更大。

DBMS设计时需要充分考虑NVM的特性以释放其硬件红利。最简单的设计方法是将NVM替代磁盘，利用其低延迟以获取性能提升。然而，使DBMS适配NVM的特性，远远不止其低延迟的特点。

本文，研究了如何在设计DBMS时部署NVM。首先，讨论了如何将NVM包含到当前系统的内存结构中；然后通过修改PostgreSQL的存储引擎最大化NVM的红利。我们旨在绕过缓慢的磁盘接口的同时保证DBMS的健壮性。

我们通过使用仿真平台和TPC-H基准测试用例来评估PG的两种修改后的存储引擎。同时，测试了未修改的PG在SSD和NVM上的场景。结果显示，修改后的存储引擎能够减少内核执行时间（文件IO发生的位置）：平均从10%到2.6%。修改后的PG性能在硬盘上能够提升20.5%，NVM上可以提升4.5%。另外，证明了修改后的PG性能瓶颈：由于直接访问NVM以获取数据，所以当查询需要该数据时，改数据不靠近CPU。当用户层次的cache没有该数据时，造成很长的延迟，就体现不出新硬件带来的好处了。

 

背景

本小节详细介绍了NVM技术的特性以及对DBMS涉及的影响。然后介绍了管理NVM的系统软件。

1、NVM特性

数据访问延迟：NVM的读延迟比磁盘小很多。由于NVM仍处于开发阶段，来源不同延迟不同。STT-RAM的延迟1-20ns。尽管如此，他的延迟也已经非常接近DRAM了。

PC_RAM 和R-RAM的写延迟比DRAM高。但是写延迟不是很重要，因为可以通过buffer来缓解。

密度：NVM的密度比DRAM高，可以作为主存的替代品，尤其是在嵌入式系统中。例如，相对于DRAM，PC-RAM提供2到4倍的容量，便于扩展。

耐久性：即每个内存单元写的最大次数。最具竞争性的是PC-RAM和STT-RAM，提供接近DRAM的耐久性。更精确的说，NVM的耐久性是10¹⁵而DRAM是10¹⁶。另外，NVM比闪存技术的耐久性更大。

能量消耗：NVM不需要像DRAM一样周期性刷写以维护内存中数据，所以消耗的能量更少。PC-RAM比DRAM消耗能量显著的少，其他比较接近。

此外，还有字节寻址、持久性。Interl和Micron已经发起了3D XPoint技术，同时Interl开发了新的指令以支持持久内存的使用。

2、NVM的系统软件

使用NVM作为主存时，不仅需要更改应用软件还要修改系统软件，才能充分发挥出NVM的优势。传统的文件系统通过block层访问存储介质。如果仅仅只是将磁盘替换成NVM，而不作任何修改，那么NVM存储也需要通过block层才能读写数据。因此NVM字节寻址的特性不能充分发挥出其优势。

因此，文件系统支持持久内存上已经有了一些进展。PMFS是一个由Interl开发并开源的POSIX文件系统。它提供2个关键特性以方便使用NVM。

首先，PMFS不为NVM维护独立的地址空间。换句话说，NVM和内存统一寻址。这意味着不需要将数据从NVM拷贝到DRAM以便应用访问。进程可以以字节的粒度直接访问NVM中的数据。

其次，传统数据库以两种方式访问blocks：文件IO；内存mapped IO。PMFS以类似传统FS的方式实现文件IO。然而，内存mapped IO的实现方式不同。传统文件系统中内存mapped IO先将pages拷贝到DRAM。PMFS则不用这个步骤，它直接将pages直接映射到进程的地址空间。图1为传统文件系统与PMFS对比。

 

设计的选择

本小节，讨论了系统包含NVM时存在的内存分层设计方案以及为充分利用NVM，对面向磁盘的DBMS如何修改。

1、基于NVM的DBMS内存分层设计

 

有各种方法将NVM放在当前DBMS的内存层次结构中。图2展示了几种使用NVM的三种常见。其中a图为传统的方式，当前使用的中间状态包括日志、数据缓存、部分查询状态，存放在DRAM中，主要数据存放于磁盘。

基于NVM的特性，可以将其替换DRAM和磁盘。如b图所示。然而，这样的改动需要重新设计当前的操作系统和应用软件。另外，作为DRAM的替代品，NVM技术在耐久性方面并不成熟。因此，我们主张平台中仍然包含DRAM内存，磁盘全部或部分被替换成NVM。如图c（NVM-Disk）所示。

这种方案中，仍在当前系统中保留DRAM层，从而利用DRAM快速读写临时数据结构和应用代码。另外，允许应用通过PMFS文件系统访问数据库系统的数据，利用NVM字节寻址的特性避免当前传统文件系统的API开销。这样的部署方式不需要大量的DRAM，因为临时数据量比较小。我们认为这种部署场景是为了集成NVM的合理使用方式：将NVM放置DRAM旁以存储临时数据结构或者使用传统磁盘存放冷数据。

2、传统DBMS的改动点

将传统面向磁盘的数据库系统直接部署在NVM上时，不能充分发挥出NVM新硬件带来的红利。当使用NVM作为主要存储介质时，DBMS的重要部件需要更改或移除。

避免块级别的访问：传统的DBMS使用磁盘作为主要存储介质。由于磁盘顺序访问速度较快，所以以数据块的形式读取来平衡磁盘访问延迟。

不幸的是，以块的形式访问数据会造成额外的数据移动成本。例如，如果一个事务更新了一个记录的一个字节，仍然需要将整个块刷写到磁盘。换句话说，块级访问提供了较好的数据预读。由于NVM是字节寻址，可以字节的形式访问数据。然而，这样将数据粒度降低到字节级别，没有了数据预热性。一个较好的方法需要平衡这两方面的优点。

移除DBMS的内部buffer cache：DBMS通常维护一个内部的buffer cache。当访问一个记录时，首先计算出他的磁盘地址。如果数据对应的block不在buffer cache，就需要从磁盘读取到buffer cache。

基于NVM的数据库就不需要这样的方法了。如果NVM的地址空间可以被其他进程可见，那么久不需要再做block拷贝的动作。直接访问NVM中的记录会更高效。然而，这就需要一个支持NVM的操作系统，例如PMFS，可以直接将NVM地址空间暴露给进程。

移除redo日志：为了保证数据库的ACID属性，DBMS需要两种日志：undo和redo。Undo log用来回滚未提交的事务，redo用来回放已提交但未写到磁盘的数据。基于NVM的DBMS中，如果不部署内部的buffer cache，所有写直接写到NVM时，就不需要redo log了，但是undo log仍旧需要。

案例：POSTGRESQL

Postgresql是一个开源关系型数据库，支持完成的ACID，并能够运行在所有主流的操作系统上，包括Linux环境。本小节我们研究了postgresql的存储引擎和做一些修改使之适配NVM。先介绍了PG的读写架构，然后解释做了哪些修改。

1、PG的读写架构

 

图3a展示了原始PG的读写文件操作的架构。左边一列的图显示了PG软件层执行的操作，右边一列展示了对应的数据移动。注意，使用的操作系统是PMFS。图3a中使用NVM替代磁盘以存储数据。

PG读写数据的性能严重依赖于文件IO。由于PMFS的文件IO的API和传统文件系统的一样，所以使用特定的文件系统对于PG来说不用做任何修改。

PG server调用Buffer Layer的服务，用于维护内部的buffer cache。Buffer cache中维护这PG即将被访问的页。如果buffer cache没有空闲slot以供磁盘读取一个页进来，就会执行替换策略，即选择一个数据页从buffer cache的管理链表中驱逐供之使用，如果该数据页是脏页，则需先将其刷写到磁盘。

PG一旦接收到一个从磁盘读取数据页的请求，Buffer Layer就会在buffer cache中找一个空闲slot并得到他的指针。图3a中pg Buffer和PgBufPtr分别是空闲的buffer slot和对应的指针。Buffer Layer将这个指针传输给File Layer。最终PG的File Layer唤醒文件读和写，读和写依赖于文件系统来完成。

对于读操作，PMFS将数据块从NMV拷贝到内核的buffer，然后内核将之拷贝到PgBufPtr指向的空闲buffer cache slot。写操作的话也是两次拷贝，只不过方向相反。

因此，当未命中buffer cache时，原生PG的存储引擎会引发两次拷贝动作。当数据集非常大时，这将是一个很大的开销。由于PMFS能够将NVM地址直接map到内存，可以通过修改存储引擎，避免拷贝的开销。下面介绍如何改动。

2、SE1：使用内存map的IO方式

利用NVM特性的第一步：将PG的File Layer替换掉，命名为MemMapped Layer。如图3b所示，这一层仍然接收Buffer Layer传来的空闲 buffer slot的指针。但是，通过使用PMFS的内存映射输入输出接口，不再产生文件IO。将这样的存储方式称之为SE1。

读操作：当访问文件进行读时，首先需要调用open()将文件打开，然后需要使用mmap()将文件映射到内存。由于使用PMFS，mmap()会返回NVM中文件的映射指针。这就可以是应用直接访问NVM上的文件。

因此，不需要将请求的数据页拷贝到内核buffer中。如图3b所示，可以调用memcpy()将请求的数据页直接拷贝到PG的buffer中。当请求完成，不再需要访问该文件时，可以将文件关闭。之后，就可以调用munmap()函数取消映射。

写操作：和读操作类似。首先需要将即将更改的文件打开，然后mmap映射。使用memcpy()直接将脏数据从PG buffer中拷贝到NVM。

SE1，不必将数据拷贝到内核buffer，减少了一次数据拷贝。

3、SE2：直接访问映射文件

第二种修改方法是，将SE1的MemMapped Layer替换为图3c的PtrRedirection Layer。和MemMapped Layer不同，他接收到的是指向PgBufPtr的指针（ P2PgBufPtr）。

读操作：当访问文件进行读操作时，调用open()打开文件，然后使用mmap()映射到内存。原来的PgBufPtr指针指向内部buffer cache的空闲slot。因为mmap可以将NVM映射到内存，即进程可以看到这个地址，PtrRedirection Layer将PgBufPtr指向NVM上文件的地址。读操作的指针重定向如图3c的“Read”标签所示。

因此读操作时不再需要数据拷贝。在大数据查询中，这种方法对性能有很大提升。

写操作：PMFS可以使应用直接访问NVM上的文件。由于PG是个多进程系统，直接更改NVM上文件非常危险，可能使数据库处于不一致的状态。为了避免这个问题，SE2在修改数据页并标记为脏页前还需2步：如果页在NVM中，那么将数据页拷贝到内部buffer cache，即Pg-Buffer；然后解除PgBufPtr重定向指针，重新指向buffer cache的空闲slot。如图3c的“Write”流程。通过这种方法，SE2就能保证每个进程只更改其本地的数据页副本。

相关工作

之前的工作主要分为两类：用NVM将整个数据库存储介质替换掉；部署NVM存储日志。《Nvram-aware logging in transaction systems》和《High performance database logging using storage class memory》减少磁盘IO对事物吞吐量的影响，以及将日志直接写入NVM而不是刷到磁盘以减少相应时间。多核多socket的硬件上使用NVM写分布式日志，当系统负载增加时减少集中式日志记录的竞争：《Scalable logging through emerging nonvolatile memory》。DRAM和NVM两层存储，研究不同的恢复方法

结论

研究了在设计DBMS时，部署NVM对其影响。谈论了将NVM加入DBMS内存层次中的几种情形。将NVM完全或者替代部分磁盘是一种典型的应用场景。这种方法下，原理系统不用修改，并允许直接访问NVM上的数据集。介绍了PG存储引擎的两种变种：SE1和SE2。

实验结果表明，对于原生PG，将数据库部署在NVM比磁盘上性能最高提升40%，平均提升16%。SE1和SE2相对于磁盘下能减少执行时间近20.5%。然而，当前数据库系统的设计最大障碍在于将性能提升最大化。比较我们基准和SE2，能够最大提升读性能14.4%，平均4.5%。

限制因素在于数据离CPU比较远，这是直接访问NVM上数据的负面影响。这会使NVM带来的优势减弱。因此开发适配NVM的库非常必要。