面向非易失性内存缓冲区的SQLite-CC

胡耀艺 胡卉芪 周烜 周傲英

摘要：近年来非易失性存储（Non Volatile Memory，NVM）飞速发展，它具有的持久化、大容量、低延迟、按字节寻址、高密度和低能耗等优越特性，强烈冲击着目前的数据库系统架构.SQLite是一款轻量级关系型数据库，实现了无服务器、零配置、事务性的SQL数据库引擎.其为每个连接维护一个缓冲区，有着空间开销大和数据一致性检测的问题，同时由于采用了相对简单的串行化单写事务执行方式和按页记录日志等方案，带来了回滚日志模式性能低和写入放大以及WAL模式存储空间要求等问题.为了解决上述挑战，构建了一种新的基于非易失性内存的SQLite缓冲区的方案SQLite-CC（Copy Cache），充分考虑了非易失性内存的硬件特性，引入CC-manager用于维护事务原子性，加入修改页面索引来保证数据库文件与缓存的一致性.实验表明，其达到了和SQLite-WAL模式相当的并发性能，相比于回滚日志模式事务吞吐量提升了3倍，读写延迟降低了40%且有效解决了磁盘中的写放大问题.

关键词：NVM;SQLite;缓冲区优化;日志方案

中图分类号：TP392文献标志码：ADOI：10.3969/j.issn.l000-5641.2021.06.013

SQLite-CC based on non-volatile memory cache

HU Yaoyi，HU Huiqi，ZHOU Xuan，ZHOU Aoying

（School of Data Science and Engineering. East China Normal University，Shanghai 200062，China）

Abstract：In recent years，non-volatile memory （NVM）has developed rapidly. Its advantages，among others，include：persistence，large capacity，low latency，byte addressing，high density，and low energy consumption - all of which have impacted current database system architecture. SQLite is a lightweight relational database widely used in embedded fields such as mobile platforms. It operates as a serverless，zero-configuration，transactional SQL database engine. It maintains a cache for each connection，which results in problems with large space overhead and data consistency detection. At the same time，it adopts a relatively simple serialized single-write transaction execution method and page-based logging，which offers low performance and write amplification in the journal mode and a storage space requirement in the WAL mode during execution. In order to address the above challenges，a new scheme of SQLite Cache based on non­volatile memory，SQLite-CC （Copy Cache），is constructed，which fully considers the hardware characteristics of non-volatile memory and ensures the atomicity of transactions using a CC- manager and by adding an updated page index to ensure the consistency of database files and cache. Benchmarking tests show that it can achieve the same concurrency performance as SQLite- WAL mode. Compared with the rollback mode，it improves the execution performance of transactions by 3 times，reduces latency by 40%，and effectively solves the issue of writeamplification on disks.

Keywords：NVM;SQLite;cache optimization;logging solution

0引言

一直以來，关系型数据库系统都是面向磁盘的，建立了由HDD/SSD和DRAM构成的两层存储架构：高延迟、持久化、大容量的磁盘搭配低延迟、易失性、容量小的内存.然而，近年来随着以Intel's optane DIMM为代表的非易失性内存（Non Volatile Memory，NVM）的出现和飞速发展，凭借其持久化、大容量、低延迟、按字节寻址等优越特性，被认为是具有“革命性的”下一代存储设备.这种新型硬件强烈地冲击了文件系统，缓存系统等存储系统，毫无疑问也对目前的数据库系统架构与设计产生了新的影响.在传统的数据库架构不再适用于NVM的基础之上，对此学界重点讨论的领域包括三个方面：1）日志和恢复协议[1-2];2）存储和缓冲区管理[3];3）索引数据结构[4].本文聚焦于轻量级数据库系统SQLite和非易失性内存的缓冲区管理，SQLite具有小巧易用的特点，由于其开发效率高，可靠的事务支持和轻量级代码，SQLite在实际的应用中使用得非常广泛.与此同时，对轻量级代码库的妥协迫使它采用不太复杂但成本更高的方案来提供事务支持，例如串行化的事务执行方式，以页面粒度进行物理日志记录，冗余日志和强制提交策略.这些设计使得其在事务执行过程中负担了过多的I/O开销[5].同时在SQLite的缓冲区管理模块中使用了默认缓存和共享缓存两种设计，前者为每一个连接创建一个缓冲区，造成空间的浪费和需要花时间协调缓存之间不一致问题，后者则是多个连接共享一个缓冲区，减少了空间占用，却降低了并发.

针对以上问题，本文提出了一种新的缓冲区组织管理方案SQLite-CC（Copy Cache），在进行缓冲区创建和管理的同时维护一份拷贝cache，NVM的大容量使得空间代价得以被容忍.本文加入了一个额外的管理器，对事务的执行进行协调，另外在cache中的页面上分别进行了是否修改的标注，辅以一个修改页的哈希索引结构来保证数据的一致性.双版本的存在，维护了并发性，减小了读写阻塞，实现了与WAL相似的一写多读并发.同时保证事务的原子性和持久性.在对系统不做大量修改的前提下充分发挥NVM所带来的优势，综合了SQLite默认缓存和共享缓存的优势，且做到steal和no­force的缓冲区管理策略.此项工作的主要贡献点在于以下3点：

（1）发挥了非易失性内存的特性，将其作为SQLite缓存部分的存储，综合了两个缓冲区的优点，减少了内存与磁盘的交互，优化了数据库的读写性能，相比于回滚日志模式事务吞吐量提升了3倍，事务延迟降低了40%.

（2）凭借非易失性内存相对于内存的持久化的特性，以cache为载体，通过拷贝双版本的方式，变相地实现了undo日志和redo日志的功能，优化了在磁盘中的日志记录，减少了磁盘的空间开销和写放大，加速了数据库恢复.

（3）保持了与SQLite-WAL模式相当的读读并发和一写多读并发性能，并且解决了WAL模式中存在的尾部延迟问题，是NVM应用的一次有效尝试.

1相关背景

1.1非易失性内存及PMDK

非易失性内存（NVM）是一种新型的硬件存储介质，兼具磁盘和DRAM （Dynamic Random Access Memory）的特性.通常，它具有比磁盘小很多的读写延迟，并且读延迟相当接近DRAM，写延迟略高于DRAM.同时，NVM有着比DRAM高的密度，意味着相同体积，它可以提供更大的容量，预示着其作为主存替代品的潜力[6].在使用时间方面，有实验表明，其耐久性，即每个内存单元写的最大次数，有着优于闪存的耐久性[7].另外由于NVM不需要像DRAM那样周期性地刷新来维持内存中的数据库，所以它在能耗方面也是有优势的[8]，其中，字节寻址和持久性等是其与生俱来的特性[9].

PMDK（Persistent Memory Development Kit）持久化内存开发套件，是Intel开源的一个可用于持久化内存开发的多种库和工具的集合.这些都建立在Linux和Windows上均可以使用的Direct Access（DAX）功能的基础上，允许应用程序通过内存映射文件直接访问持久化内存.PMDK抽象出了各种底层操作，并将某些操作封装到事务性的API中，目前已经有了十余个针对各种持久化的用例库，为持久化内存编程提供了不同的功能，并且支持C、C++、Java和Python语言的使用.通过PMDK可以更有效地管理持久化内存.较为底层的库有libpmem，它为管理持久性内存提供了底层支持.开发人员可以通过将内存文件映射到DRAM来访问持久性内存，为防止内存泄漏，需要显式释放持久性内存. libpmemobj将持久性内存文件转换为灵活的对象存储，支持事务，内存管理，锁定，列表和许多其他功能，并且保证了事务的原子性.使用libpmem和libpmemobj，C/C++开发人员可以轻松创建和管理内存中的持久数据.

1.2数据库缓冲区管理

消除不完整或中止的事务以保持原子性的影响的过程称为undo.为了持久性而恢复已提交事务影响的过程称为redo.恢复子系统必须提供这些功能之一，执行的工作量取决于数据库缓冲区管理器如何处理正在提交的事务的更新数据.缓冲区管理器是数据库组件，它负责协调主内存（易失性存储）和磁盘（非易失性存储）之间的数据传输.可以原子写入非易失性存储的存储单元称为page.将对（易失性）缓冲池中的页面副本进行更新，并在以后将这些副本写到非易失性存储中.如果缓冲区管理器允许未提交的事务进行更新以覆盖非易失性存储器上数据项的最新提交值，则说它支持steal策略（反之称为no-steal）.如果缓冲区管理器确保在允许提交事务之前将事务所做的所有更新都反映在非易失性存储上，则可以说它支持force策略（反之则为no-force）.

支持steal策略意味着在需要回滚事务（由于事务失败或系统崩溃）的情况下，撤消事务将涉及由该事务更新的所有非易失性数据副本的值恢复为先前的已提交状态.相反，no-steal策略可确保非易失性存储上的数据值有效，因此不需要还原它们.no-force策略增加了某些已提交的数据值在系统崩溃期间丢失的可能性，因为无法保证将它们放置在非易失性存储中.这意味着可能需要大量的redo工作来保持已提交更新的持久性.相比之下，force策略可确保将提交的更新放置在非易失性存储上，以便在系统崩溃的情况下，更新仍将反映在非易失性存储上的数据库副本中.

可以明显看出，支持no-steal和force组合的缓冲区管理器对undo和redo恢复的需求最少.但是，这些策略可能会在正常操作期间（没有崩溃或回滚时）对DBMS的性能产生负面影响，因为它们限制了缓冲区管理器的适用性.no-steal要求缓冲区管理器将更新后的数据保留在内存中，直到事务提交或将数据写入非易失性存储上的临时位置（例如交换区）为止.force策略的问题在于，它可能会在提交事务的关键路径期间施加大量的磁盘写开销.由于这些原因，许多缓冲区管理器都支持steal和no-force策略.

2系统架构

本文设计并实现了一个针对SQLite在非易失性内存上应用的缓冲区管理方案，用于提升其执行和并发性能.本章将介绍其整体架构，总体架构图和特点展示在图1中.

SQLite是一个实现无服务器的事务型SQL数据库引擎的软件库.应用程序链接到SQLite库以利用其数据库管理功能，将数据库作为单独的文件存在磁盘中，并发事务可以访问同一数據库，但是在任何时候都只能有一个事务可以更新数据库，因为整个数据库文件都由写事务锁定，直到完成为止. pager模块负责管理内存缓冲区，B树模块负责处理选择和更新语句.

原始的SQLite设计有默认的缓存模式和共享缓存模式，默认缓存模式下，即使线程两次或多次打开同一个数据库文件，SQLite也会为打开的数据库连接分配单独的缓存，通过其不同的所有者的pager对象访问缓存.启用共享缓存模式后，如果一个线程打开对于一个数据库的多个连接，则这些连接共享同一个page cache，且在3.5.0版本中，修改了共享缓存模式，以便可以在整个进程中共享同一缓存，而不仅仅是在单个线程中共享.

所以在设计的过程中，本文将原始SQLite的缓冲区进行了扩展，通过记录拷贝的cache来保证数据库执行正确性和优化效果，所以将其称为SQLite-CC（Copy Cache）.这个设计与原始的SQLite有三个不同点：CC manager，拷贝的缓冲区和修改页的索引.

CC manager：用于管理缓冲区和保证事务的执行，它为每个事务分配时间戳，用于协调读写事务之间的版本，当写事务进行时，两个cache呈现出不一致的状态，完成写事务之后，同步两者的状态，进而允许提交事务.

copy cache：在每个进程所维护的缓冲区pcache中额外加入一个拷贝的cache.一方面，两个cache以一主一副的身份存在，写事务均在主cache中进行，副cache可以在主cache处于修改状态的过程中，提供数据读取操作的支持，以此增强了并发性.另一方面，由于非易失性内存的持久化特性，结合CC manager对当前缓冲区状态进行管理，可以保证事务的原子性和持久性.拷贝的副cache在主cache进行修改的时候，保证读事务并发的同时，副cache仍然保持着原有数据，其承担undo log的作用以保障事务的原子性.当出现事务abort的时候或者事务修改未完成宕机时，副cache的值为准确值，可以用于还原主cache中进行的修改.当出现事务修改已完成但是未提交的情况，即主cache已经完成修改，副cache没有同步，同样通过CC manager的状态检查，判定当前状态，主cache可以承担redo log的作用，将其修改值同步到副cache，并提交事务，以保障事务的持久性.

updated page index：记录cache中修改的页的编号，标记出与磁盘中数据库文件不同步的页.而后通过延迟同步的方式，在被换出缓冲的时刻，将更新同步到磁盘上，以此来保证非易失性内存中的緩冲区与磁盘中数据库文件的一致性.

故而，本设计做到了比默认缓存模式更小的空间占用，比共享缓存模式更高的并发性能，实现了steal和no-force的缓存区策略，而且事务的相关操作都由存储在非易失内存中的缓冲区层面进行，在保证事务的原子性和持久性的同时，减少了磁盘读写，极大地提升了执行效率.

3事务处理

3.1写入/更新流程

在进行写操作的时候，SQLite通过B+ tree模块向pager模块发出请求，然后经过page cache对数据进行修改.在原始的SQLite回滚日志模式中，写入/修改的操作，需要先进行数据库文件拷贝，将原有数据保存为回滚日志文件，并持久化到磁盘中，然后对内存中的数据页进行修改，之后才将数据同步到磁盘上进行持久化保存.在WAL模式中，则是采用了相反的方法，在进行数据库写操作之前，会先在内存中对数据进行修改，然后将修改后的数据页作为日志持久化到磁盘上，而原有的数据库文件内容保存不变，并在随后的某个时间通过检查点的方式同步到数据库文件中.

但是在SQLite-CC中，进行写操作前，首先需要经过CC manager的判定，确保当前两个cache处于同步状态，即可获得写入权限时，分配给其写时间戳.在修改过程中会在缓冲区中，短暂形成两个cache不同步的时段，如图2所示，两个cache由一个pcache句柄统一管理，主cache对应的hash table处于已修改的状态，已被修改的页，也被视为redo log page.拷贝cache对应的hash table则是保持原有的值不变，所以此处与主cache中被修改处对应的页，可以视为undo log page，即正常的修改流程为经历同步，到不同步，再到同步的流程.由于NVM的持久性，无须担心数据丢失，可以在同步之后仅记录updated page index来确保当缓冲区的页被换出之后与数据库文件的一致性，不用急切地将修改值刷新到磁盘中的数据库文件，从而减少了磁盘I/O.

3.2读取流程

在SQLite-CC中，读操作将面临着两种不同的情况.一种情况是当两个cache处于同步状态时，其读取流程跟原始的SQLite相同.另一种情况则是，当前的cache状态不同步，即此时存在正在进行当中的写入操作，根据读写事务的先后顺序，分为两种情况：当读在写事务之后，将通过新的cache进行读取，读取到修改后的值;反之则通过拷贝的cache进行读取，读取到旧值，其余流程相同.如图3所示，在时刻2有写入操作，那么当写事务开始时，将出现新旧读事务的划分，对之前已经执行完成的读操作的线程没有影响，正在进行的操作如读事务3，读事务6将被作为旧的读事务，通过拷贝cache进行旧值的读取，然后当旧事务线程全部完成之后，对两个cache进行同步，完成此次操作.在时刻2之后开始执行的线程读事务2，读事务4则会在等待执行过程中的写事务提交完成之后通过主cache读取到最新值.

3.3提交

与采用force策略的原始SQLite不同，SQLite-CC对提交操作采用了非常简单的过程.在提交时，原始SQLite将所有要修改的数据页从缓冲区刷新到数据库和回滚日志文件（在“删除日志”模式下）或WAL日志文件（在WAL日志模式下）.提交时间开销非常大，因为每个脏页在物理上被写入两次（包括在WAL日志模式下由检查点引起的写入操作），并且写入屏障操作（通过fsync调用）至少执行一次[10].相反，SQLite-CC是将修改同步到拷贝的cache中并且在updated page index中标记修改的页号.有这个简单的过程就足够了，因为每次的数据读写都要通过cache进行，只要保证了cache中为最新数据，之后采用组提交和清空更新页面索引的方式跟数据库文件进行同步.

3.4中止

当事务中止时，原始的SQLite从缓冲池中删除由事务更新的脏页.由于原始的SQLite采用了Steal缓冲区管理策略，因此中止的事务所做的某些更改可能已经写入数据库或日志文件.需要通过将undo日志中的数据复制到数据库文件中，以此来回滚之前的更改，或者通过忽略/删除WAL日志中存储的已修改的数据来保证事务的原子性.对于SQLite-CC未提交的修改则是停留在主cache中，而副cache中数据仍然未发生改变，因此当发生回滚时，可以找到副cache中对应的数据，以此作为undo日志的数据去回滚主cache中未提交的修改.

4恢复

当出现宕机时，原始的SQLite有自己的方法在重新启动时进行故障检测，当它在“删除日志”模式下运行时，若存在热日志则表示SQLite在重新启动之前处于崩溃状态，其中热日志（宕机前已经记录，但是由于事务并未提交，仍然存在的日志）可用于恢复数据库.当原始的SQLite以WAL日志模式运行时，WAL日志里没有commit记录的部分则表示崩溃时正在进行的事务，删除该部分修改即可.SQLite-CC检测故障的方式与前两者均不相同，其事务的原子性和持久性都是经由cache来进行保证的，由于NVM的持久性，任何情况下的故障恢复都能够获取到宕机前缓冲区的状态.如果存在需要恢复的数据，则SQLite-CC的缓冲区中的两个cache肯定不是同步的，由于在任何时候最多只有一个写事务在同一数据库上运行，那么两个cache必有一个是准确的，所以通过检测副cache的启用状态，可以判断所要恢复的状态点，进而做出对应的回滚或者重做操作，使数据库达到一致性状态.另外，如果宕机发生在将缓冲区中换出的页同步到数据库文件时，通过检测updated page index中是否还记录有该页和对比换出页与数据库文件里对应页的值，可以判定是否需要再次将cache中的页复制到数据库文件中，以保证数据的一致性.

5实验分析

在本章中，展示了对SQLite-CC进行实验评估的结果，实验使用YCSB（Yahoo！Cloud Serving Benchmark）的综合负载[11]，通过对不同比例的读写负载来评估其运行情况和性能.另外，为了检测运行的并发性能，本文分别对单线程、双线程、四线程、八线程的情况进行了负载测试.各组实验均加入了SQLite在Journal-Delete日志模式和WAL日志模式的对照组.

5.1实验环境

实验机器配置了两个Intel（R）Xeon（R）Gold 6240 M CPU @ 2.60 GHz，每个CPU具有18个内核.该系统配置了128 G DRAM和512 GB 3DXPoint内存，然后，我们应用PMDK将文件映射到程序的虚拟地址空间，加载和存储数据到3DXPoint[12].为了比较，我们采用了YCSB的负载生成100000条数据，每条记录的大小为100个字节，执行了10000个操作进行分析，负载分别是YCSB-A（读写比例50%/50%），YCSB-B（读写比例95%/5%），YCSB-C （读写比例100%/0%）.

5.2事务吞吐量

图4比较并展示了3种模式下的事务吞吐量，可以看到，随着写操作比例的下降，三者的吞吐量均呈现上升趋势，而在负载相同的情况下，SQLite-CC的性能略优于SQLite-WAL，SQLite-journal表现最差.在读写比例为95%/5%的负载中，SQLite-CC约为SQLite-journal吞吐量的3倍.

5.3事务延迟

接下来评估了3种模式下事务执行延迟，图5、图6分别展示了对于读取和更新事务时延迟分布，不同模式下的延迟走势大致相同，SQLite-CC延迟最低，大约是SQLite-journal模式下的60%.另外，SQLite-CC的修改操作方面的表现要优于其在读取操作方面的表现，这是由于SQLite串行化事务执行所决定的.对于平均延迟，SQLite-WAL和SQLite-CC均表现出了不错的性能，而SQLite-journal模式则与前两者有较大差距.这里是因为SQLite-journal模式下默认删除之前记录的日志文件造成的. 另外，SQLite-WAL模式尾部延迟过高是由于检查点开销所导致的，当日志页数达到阈值时首先会在WAL文件中检查数据库页，时间由检查点数据库页的数量控制，而SQLite-CC有着较大改善，如表1所示.

5.4多线程情况

为了展示并发效果，如图7—10所示，本文分别用单线程、双线程、四线程、八线程对3种模式在读写比例各不相同的四种负载上进行了运行时间测试，由于SQLite为确保线程安全，采用单写的方式进行数据修改.多线程对于SQLite并不是提升并发的好方法.同時可以看到的是在写操作占比较大的负载中，SQLite-journal模式表现较差，而SQLite-WAL模式采用redo日志，记录新值的一次刷盘，对此场景支持性较好，SQLite-CC则是做到了与SQLite-WAL模式下相当的执行时间.另外，很明显，读操作比例越高，SQLite单写的影响就会越小，三者差距也就逐渐缩小.

6相关工作

SQLite-CC通过应用实际的英特尔傲腾非易失性内存，结合硬件特性与软件相协调，以加快事务性数据库系统的性能，并减少磁盘I/O.本章将从与SQLite-CC关联的角度，回顾基于非易失性内存相关应用工作.

文献[13]司将相变存储器（Phase Change Memory，PCM）集成在SQLite数据库系统中，与SQLite-CC不同的是，它们主要聚焦于日志的记录方式，并未涉及数据库的内部组件.SQLite-PPL为了避免SQLite的写放大，将相变存储器PCM作为与各个数据页关联的日志记录设备，采用per-page log和global log结合的记录方式，利用PCM的差异写入性能来优化事务性能;SQLite-SSL[14]则是针

对移动应用设备负载大多是插入和本地更新的特性，采用在非易失内存中进行逻辑日志记录（用以记录SQL语句）结合现有的WAL模式进行检查点和恢复.

Chen等[15]最先探讨了在用非易失内存代替DRAM，及在非易失内存上进行关系数据库相关设计上的参數（cache misses、cache line write backs、words modified）和分析指标（total wear、energy、total PCM access lantency）等;其他工作考虑非易失内存对关系数据库存储的影响.文献[16]从数据库中非易失性内存管理的角度，把非易失性内存作为中间层，并且在DRAM和非易失性内存中都维护一个缓冲区，在其间将DRAM以cache-line的粒度从NVM中加载数据进行传递，并提出了一种减少内存占用的Mini page数据结构，以更好地利用NVM的随机访问快的特性，同时减小了DRAM的空间占用.

Oukid等[17]将NVM作为存储，设计并实现了SOFORT，这是为OLTP（On-Line Transaction Process）和OLAP（Online Analytical Processing）工作负载设计的混合存储引擎，该引擎采用MVCC和非易失性指针来避免记录日志.Arulraj等[18]用MVCC和非易失性指针来避免记录日志，针对NVM的特性，采用模拟退火算法调节数据迁移策略，同时提出了多存储层次结构的代价限制函数，以实现针对任意工作负载的存储层次管理策略和自适应机制.

7总结

在本文中，我们针对SQLite工作负载和设计特点结合非易失性内存的特性提出了一种缓冲区优化方案，被称为SQLite-CC，并阐述其设计和实现.它结合非易失性内存，通过CC-manager中分配的全局时间戳来保证事务的原子性，合理使用拷贝的双版本缓冲区优化了数据库的读写性能，并保留了与WAL模式相当的事务并发性能.在原始的SQLite中需要强制将所有页面刷新到磁盘，SQLite- CC则充分利用了非易失性内存的持久化的特性，减少了日志文件的写入/删除操作等磁盘I/O，并有效解决了磁盘中的写放大问题.

[参考文献]

[1]ARULRAJ J，PERRON M，PAVLO A. Write-behind logging [J]. Proceedings of the VLDB Endowment，2016，10（4）：337-348.

[2]COBURN J，BUNKER T，SCHWARZ M，et al. From ARIES to MARS：Transaction support for next-generation，solid-state drives [C]// Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. 2013：197-212.

[3]LEE H G，BAEK S，NICOPOULOS C，et al. An energy-and performance-aware DRAM cache architecture for hybrid DRAM/PCM main memory systems [C]// Proceedings of the 2011 IEEE 29th International Conference on Computer Design （ICCD）. IEEE，2011：381-387.

[4]ARULRAJ J，LEVANDOSKI J，MINHAS U F，et al. BzTree：A high-performance latch-free range index for non-volatile memory [J]. Proceedings of the VLDB Endowment，2018，11（5）：553-565.

[5]TUAN D Q，CHEON S，WON Y. On the IO characteristics of the SQLite transactions [C]// Proceedings of the International Conference on Mobile Software Engineering and Systems. 2016：214-224.

[6]HUANG Y，LIU T，XUE C J. Register allocation for write activity minimization on non-volatile main memory for embedded systems [J]. Journal of Systems Architecture，2012，58（1）：13-23.

[7]QURESHI M K，SRINIVASAN V，RIVERS J A. Scalable high performance main memory system using phase-change memory technology [C]// Proceedings of the 36th Annual International Symposium on Computer Architecture. 2009：24-33.

[8]WANG K L，ALZATE J G，AMIRI P K. Low-power non-volatile spintronic memory：STT-RAM and beyond [J]. Journal of Physics D：Applied Physics，2013，46（7）：074003.

[9]MUSTAFA N U，ARMEJACH A，OZTURK O，et al. Implications of non-volatile memory as primary storage for database management systems [C]// 2016 International Conference on Embedded Computer Systems：Architectures，Modeling and Simulation （SAMOS）. IEEE，2016：164-171.

[10]KANG W H，LEE S W，MOON B，et al. X-FTL：Transactional FTL for SQLite databases [C]// Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data. 2013：97-108.

[11]COOPER B F，SILBERSTEIN A，TAM E，et al. Benchmarking cloud serving systems with YCSB [C]// Proceedings of the 1st ACM Symposium on Cloud Computing. 2010：143-154.

[12]YANG J，KIM J，HOSEINZADEH M，et al. An empirical guide to the behavior and use of scalable persistent memory [C]// Proceedings of the 18th USENIX Conference on File and Storage Technologies. 2020：169-182.

[13]OH G，KIM S，LEE S W，et al. SQLite optimization with phase change memory for mobile applications [J]. Proceedings of the VLDB Endowment，2015，8（12）：1454-1465.

[14]PARK J H，OH G，LEE S W. SQL statement logging for making SQLite truly lite [J]. Proceedings of the VLDB Endowment，2017，11（4）：513-525.

[15]CHEN S，GIBBONS P B，NATH S. Rethinking database algorithms for phase change memory [C]// Proceedings of the 5th Biennial Conference on Innovative Data Systems Research. 2011：21-31.

[16]VAN RENEN A，LEIS V，KEMPER A，et al. Managing non-volatile memory in database systems [C]// Proceedings of the 2018 International Conference on Management of Data. 2018：1541-1555.

[17]OUKID I，BOOSS D，LEHNER W，et al. SOFORT：A hybrid SCM-DRAM storage engine for fast data recovery [C]// Proceedings of the Tenth International Workshop on Data Management on New Hardware. 2014：Article No.8.

[18]ARULRAJ J，PAVLO A，MALLADI K T. Multi-tier buffer management and storage system design for non-volatile memory [EB/OL]. （2019-01-30）[2020-05-04]. https：//arxiv.org/abs/1901.10938.

（責任编辑：陈丽贞）