CN112597254B - 面向混合dram-nvm主存的联机事务型数据库系统 - Google Patents
面向混合dram-nvm主存的联机事务型数据库系统 Download PDFInfo
- Publication number
- CN112597254B CN112597254B CN202011439569.XA CN202011439569A CN112597254B CN 112597254 B CN112597254 B CN 112597254B CN 202011439569 A CN202011439569 A CN 202011439569A CN 112597254 B CN112597254 B CN 112597254B
- Authority
- CN
- China
- Prior art keywords
- data
- nvm
- transaction
- version
- dram
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/219—Managing data history or versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2282—Tablespace storage structures; Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5022—Mechanisms to release resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5018—Thread allocation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提出一种面向混合DRAM‑NVM主存的联机事务型数据库系统,包括:用于缓存数据的DRAM和用于持久存储数据的NVM;NVM通过第一数据表记录NVM中存储的多个数据元组,用于事务处理并发控制的元信息仅保存在DRAM中,即NVM中该数据元组不保存并发控制的元信息,根据访问任务将该数据元组以元组为粒度缓存至DRAM,且在数据元组缓存至DRAM时为每个数据元组增加并发控制元信息,DRAM通过第二数据表记录数据元组及其对应的并发控制元信息;该联机事务型数据库系统还包括混合数据表,该混合数据表包括该第一数据表、该第二数据表,以及用于管理该第一数据表和第二数据表的管理模块。
Description
技术领域
本发明涉及数据库处理技术领域,并特别涉及一种面向混合DRAM-NVM主存的联机事务型数据库系统。
背景技术
新一代非易失性存储器(NVM)是一种新型存储技术,是对现有DRAM(动态随机存储器)主存技术的替代或补充。当前的集成电路特征尺寸已经达到5nm,DRAM技术继续向下扩展至更小的特征尺寸存在巨大的挑战。新一代NVM技术通过改变存储介质的电阻来存储0/1,可以支持更小的特征尺寸,为上述问题提供了一种可行的解决方案。新一代NVM技术包括相变存储器(PCM),自旋转移扭矩磁性随机存取存储器(STT-MRAM)和忆阻器(Memristor),3DXPoint等。
与DRAM技术相比,NVM技术具有下述特点。(1)NVM的读写性能与DRAM相近,但是比DRAM慢。(2)NVM的写比读性能差,功耗高,而且写有次数的限制,即同一个存储单元写的次数超过某个阈值,存储单元就会损坏。(3)写入NVM的数据在掉电后不消失,而掉电后DRAM和CPU Cache中的数据将会消失。(4)为了保证CPU Cache中的内容写回NVM,需要执行clwb/clflush/clflushopt等cache line flush指令和sfence/mfence等内存操作排序指令,这些特殊指令的性能代价比普通写高(例如10倍)。(5)CPU访问NVM的基本单元是一个Cacheline(例如64B)。(6)NVM模块内部的访问基本单元可能比Cache line大(例如Intel OptaneDC Persistent Memory内部的访问单元是256B)。
与闪存相比,NVM技术的性能高至少2个数量级,而且NVM允许在原位置写,而不需要类似闪存的擦除等操作。因此,NVM技术的使用特征更加接近于DRAM,被视作对DRAM主存技术的一种替代或补充。
基于DRAM的内存数据库技术已经成为数据库领域的主流技术,在Oracle,MS SQLServer,SAP HANA主流商用数据库产品中,都包括了内存数据库引擎。例如,Hekaton是MSSQL Server中的事务处理内存数据库引擎,SAP HANA内存数据库支持事务处理。
相比传统磁盘数据库使用两段锁协议(2PL),支持联机事务处理的内存数据库倾向使用乐观并发控制(OCC)和多版本并发控制(MVCC)以获得高吞吐量。这两种方法预期事务间冲突较少,允许事务激进的运行并在事务提交时检测冲突。其中联机事务为一个或者多个客户端向服务端发出请求,服务端响应和处理所有请求并返回结果。Silo使用时间分片为基础的时间戳生成机制和组提交改进OCC。MOCC基于OCC,并结合锁机制处理热数据事务冲突。Tictoc将中心化的时间戳分配机制移除,并在事务提交时计算事务时间戳。Hekaton在MVCC中应用无锁数据结构。Hyper通过直接修改数据和将提交前的数据存储在Undo缓冲中,以优化基于列式存储的内存数据库的读性能。Cicada使用多个松散同步的时钟来减少MVCC的开销和冲突,尽最大努力内联数据版本以提高CPU Cache的命中率,并优化事务验证方法。这些方法都需要给每个数据添加元数据,比如读写时间戳,指向不同版本的时间戳,锁位等。这些方法在不考虑数据库持久性的前提下,实现了每秒百万级的事务吞吐量。
和传统数据库类似,内存数据库可以使用日志和检查点技术实现持久性。不同的是内存数据库完整存储于内存,因此只有提交事务的Redo日志需要写入持久存储设备。内存数据库通过加载最近的检查点到内存并读取Redo日志重做已提交的事务来恢复数据库。
相比支持联机事务处理的内存数据库,支持联机事务处理的NVM数据库需要重新考虑并发控制和崩溃恢复以完整支持数据库的原子性、一致性、隔离性和持久性(ACID特性)。
面向NVM的联机事务型数据库同时有DRAM和NVM两种主存,其中NVM是持久的而且容量显著大于DRAM,因此联机事务型数据库可以把数据完整存储到NVM,而避免了外存I/O操作。
NVM容量大小的联机事务型内存数据库(MMDB):在MMDB中,索引和数据存储于传统的易失主存,事务仅使用普通的CPU Load和Store指令访问主存中的数据结构。但是,原本的实现受限于DRAM容量。当数据量大于DRAM时,将无法支持。如图1(a)所示,本发明可以扩展联机事务型内存数据库,将部分NVM视为易失主存,从而可以利用更大的主存支持超过DRAM容量的数据量。此外,我们将写前日志(WAL)和检查点放入NVM,从而消除外存访问,支持数据库的持久性。数据库崩溃后,数据库根据NVM中存储的持久化的检查点和写前日志恢复易失主存中的数据表和索引等数据结构。其中NVM的特性是可以持久存储数据和字节粒度的存储访问。CPU将数据持久性存储在NVM上,使用和访问内存一样的方式访问NVM,实现和原来一样的功能并且比原来更快,但是不需要磁盘和SSD这样的块设备。消除了磁盘和SSD,即消除了外存访问。
基于写后日志(WBL)的联机事务型内存数据库:如图1(b)所示,此技术在DRAM中存储索引和维护数据记录粒度的缓存。数据被提取到DRAM中进行事务处理。通过给数据增加事务标志、提交时间戳和上次提交版本的索引等元数据,WBL支持在NVM中存储逻辑数据记录的多个版本。在事务提交时,WBL在NVM上创建新版本的数据记录,并将DRAM中记录内容的修改持久化到新创建的记录版本中。当崩溃发生时,已提交的新版本可用于崩溃恢复。因此,WBL不需要像写前日志那样在日志中存储数据的修改,并在事务提交后写到NVM。一条写后日志包括两个时间戳:时间戳Cp标记此时间前的事务均被完整持久化到NVM,时间戳Cd标记Cp到Cd之间可能存在未完全提交事务的。崩溃发生后,系统检查最后一条写后日志,并回收时间戳处于Cp到Cd之间的数据记录版本。
FOEDUS:如图1(c)所示,FOEDUS将数据记录存储在NVM中的快照数据页中,并在DRAM中缓存部分数据页。DRAM中维护数据页的索引,对于每个数据页维护两个指针,一个指向NVM中最新的快照数据页,另一个指向在DRAM缓冲中的数据页(如果存在)。FOEDUS在DRAM中运行事务。如果事务需要访问的数据在NVM中,FOEDUS将此数据页加载入DRAM并更新数据页索引。在事务提交时,FOEDUS将Redo日志写到NVM。FOEDUS在后台运行一个Log Gleaner线程,周期性扫描并回收日志,以Map-Reduce方式使用Redo日志产生新的快照数据页。
NVM容量大小的联机事务型内存数据库(MMDB)存在两个问题:第一,数据的修改需要写WAL日志和检查点,这会带来额外的2倍NVM写。当数据库容量大于DRAM,对于存储在作为易失主存的NVM上的数据,修改操作需要再写一次NVM,因此最大有3次NVM写。第二,当数据逐渐变大,越来越多的数据将存储在NVM中,由于MVCC等并发控制机制在读数据记录时也需要修改记录头部的元数据,所以即使是读事务也会引发大量的NVM写。
基于写后日志(WBL)的联机事务型内存数据库:相比MMDB,基于写后日志的联机事务型内存数据库显著减少日志并且不需要检查点。因此对数据的修改只会引发一次NVM写。由于该技术在每个数据上都维护了元数据并且这些元数据因为并发控制而经常被修改,因此,此方法仍然有频繁写NVM的问题。
FOEDUS在内存中运行事务,因此可以避免NVM上的元数据的频繁修改。但是,该方法有3个明显不足:第一,数据页粒度的缓存会引起NVM的读放大,读取一个数据记录可能导致读取一整个数据页到DRAM。第二,FOEDUS采用Map-Reduce方式处理日志生成新的数据页快照,而复杂的Map-Reduce计算过程在NVM中进行,会带来大量的NVM写。第三,FOEDUS使用IO接口来访问NVM,这种方法没有充分利用NVM的字节寻址特性。
上述3种现有技术,存在以下三点共性问题:
第一,数据记录的元数据修改,MMDB和WBL将每条数据记录的元数据存储在NVM中,由于并发控制的需要,这些元数据被经常修改。
第二,数据记录的多次冗余写,MMDB和FOEDUS对一次数据记录的写,会额外带来对日志、检查点或快照数据页的NVM写。
第三,NVM空间管理,MMDB和FOEDUS只需要粗粒度的给日志、检查点和数据页分配存储空间,而WBL需要细粒度的为每个数据记录分配空间。由于WBL技术论文未提及空间管控,一个基本的方法是将NVM空间的分配操作以元数据形式持久化到NVM,这个空间管理方法可能带来显著的NVM持久化开销。
本发明提出的面向NVM的联机事务型数据库在上述研究的基础上,针对上述3个现有技术的共性问题,分别提出技术解决方案,实验表明Zen显著优于上述现有技术。
发明内容
本发明的目的是解决面向NVM的联机事务型数据库:(1)频繁写NVM上的元数据;(2)冗余写NVM上的数据记录;(3)NVM空间管理;这三方面的现有技术共性问题。针对前述共性问题,本发明提出了一种面向NVM的联机事务型数据库(Zen),Zen提出(1)元数据增强的数据记录缓存(Metadata Enhanced Tuple Cache,MetCache);(2)无日志持久事务框架(Log-Free Persistent Transactions);(3)轻量级NVM空间管理机制(Lightweight NVMSpace Management)。与现有方案相比,Zen充分利用NVM的字节寻址特性,减少NVM上的元数据写和数据冗余写,在NVM数据库规模条件下,实现了面向NVM的数据库高吞吐零日志的联机事务处理和高效崩溃恢复。
针对现有技术的不足,本发明提出一种面向混合DRAM-NVM主存的联机事务型数据库系统,其中包括:
用于缓存数据的DRAM和用于持久存储数据的NVM;
NVM通过第一数据表记录NVM中存储的多个数据元组,用于事务处理并发控制的元信息仅保存在DRAM中,即NVM中该数据元组不保存并发控制的元信息,根据访问任务将该数据元组以元组为粒度缓存至DRAM,且在数据元组缓存至DRAM时为每个数据元组增加并发控制元信息,DRAM通过第二数据表记录数据元组及其对应的并发控制元信息;
该联机事务型数据库系统还包括混合数据表,该混合数据表包括该第一数据表、该第二数据表,以及用于管理该第一数据表和第二数据表的管理模块。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中该并发控制元信息为以元组为粒度且具有并发控制相关的元信息,该第二数据表缓存按照线程数目划分为多个缓存区域,各线程仅在其对应的缓存区域内修改数据;该第二数据表内的缓存项包括数据元组的存储空间和第二元数据,第二元数据包括活跃位、并发控制字段、元组标识字段、指向NVM版本的指针和缓存替换字段;通过该活跃位判断该缓存项是否被占用通过该活跃位控制该缓存项不被替换,若占用,则当前该缓存项不能被修改替换;事务运行中,根据通过读取和写入该并发控制字段,执行并发控制算法,并根据读取和写入该缓存替换字段,以执行缓存替换策略。
所述的混合DRAM-NVM主存的联机事务型数据库系统,其中该第一数据表中部分数据元组存在多个数据版本,每个数据元组包括其占用的存储空间和第一元数据,第一元数据包括:事务提交时间戳、元组标识字段、删除位和事务提交确认位;通过该事务提交时间戳和该元组标识字段唯一确定事务提交版本,通过该删除位标记逻辑数据的删除;
同一事务提交的所有数据元组修改具有相同的事务提交时间戳,且同一事务提交的所有数据元组修改对应的数据版本中,任意一个数据版本事务提交确认位被设置,即可确认事务已被正确提交,数据修改均已持久化。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中
事务在执行阶段访问该混合数据表,判断该事务访问的目标数据是否位于DRAM中,若是则直接访问DRAM中缓存的该目标数据,否则将NVM中存储的该目标数据缓存到执行当前事务的线程对应的数据缓存区域并填写与之对应的第二元信息;
在DRAM中通过并发执行且成功提交的事务进入持久阶段,将该事务修改的所有数据版本均写到NVM上进行持久存储;
事务维护阶段,回收NVM上的因新提交版本而无效的数据版本。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中该持久阶段包括:事务在该持久阶段从所有数据修改所对应的多个数据版本选择最后修改完的数据进行持久化,并只设置最后修改完的数据版本的事务提交确认位为已提交;事务先持久化除最后一个版本的事务提交确认位所在的CacheLine的所有版本数据;等待上述持久化操作完成后,原子性持久化最后一个版本的事务提交确认位所在的CacheLine。
所有要持久化的数据版本都需要按照CPU CacheLine粒度进行划分,然后,按照CacheLine的粒度大小持久化数据。最后一项持久化的数据也同上需要按照CacheLine划分,只需要保证包含LP(事务提交确认位)的那个CacheLine最后持久化。这里“最后”指的是前面的所有持久化均已完成,在现有CPU技术中使用Sfence保证前面的持久化均已完成。需要按照CacheLine划分的原因是在现有CPU技术中,CacheLine是具有原子性的。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中该混合数据表配备一个主索引,该主索引的存储位置为DRAM或NVM,该主索引的值为同一逻辑数据最新版本的存储位置。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中当存储于DRAM中的该主索引因掉电失去时,执行以下步骤:
步骤1、初始化已确认提交事务时间戳为0,初始化待判定NVM版本指针集合为空;
步骤2、选择NVM中一个元数据版本作为当前元数据版本,根据当前元数据版本的最后持久标记位判断其是否为最新修改版本,若是则将当前元数据的版本和其最新的已确认提交事务时间戳加入该已提交事务时间戳,否则执行步骤3;
步骤3、判断当前元数据版本是否为已回收版本或新分配的数据页上的还未被使用过版本,若是则跳过当前元数据版本执行该步骤2,否则执行步骤4;
步骤4、判断当前元数据版本的Tx-CTS是否小于等于当前该已提交事务时间戳,若是则通过该垃圾回收队列回收当前元数据版本,否则将当前元数据版本存入该待判定NVM版本指针集,再次执行步骤步骤2,直到遍历NVM中所有元数据版本执行步骤5;
步骤5、对于处于该待判定NVM版本指针集中的元数据版本,判断其Tx-CTS是否小于等于当前该已提交事务时间戳,若是则通过该垃圾回收队列回收当前元数据版本,否则当前元数据版本未提交,直接回收此版本。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中NVM空间管理分为两层,第一层是数据页粒度的空间管理,通过给NVM上的全局数据结构分配线程,每个线程在数据版本存储空间不够时,向图1中的NVM Page Manager提出请求。NVM Page Manager找到一个NVM数据页,得知其地址,并在NVM上管理数据页属于那个线程的持久空间上记录该地址归属于哪个数据表和哪个线程。最后将此地址告诉提出请求的线程;第二层是数据版本粒度的空间管理,数据版本粒度的NVM空间的分配和释放由DRAM中的数据结构通过指向NVM地址的指针进行管理。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中数据版本粒度的NVM空间分配和释放采用特定线程合作机制:
线程内部使用该管理模块管理NVM空间,线程之间同步当前正在运行的事务最小时间戳,事务在该事务维护阶段根据当前正在运行事务的最小时间戳Tx-Min,回收NVM中相同逻辑数据但事务提交时间戳小于Tx-Min的数据版本。
任意时刻,所有线程正在执行事务。这些事务在开始时获得一个唯一的时间戳,这个唯一时间戳的大小记录了事务的先后次序。同一线程内后一个事务的时间戳大于前一个事务的时间戳。因此后一个事务提交的时间戳大于前一个提交的事务时间戳。线程间通过同步机制,保证不同线程的后一个提交的事务时间戳大于前一个提交的事务。任意时刻所有正在运行的事务所具有的时间戳中最小的那个即为事务最小时间戳。如果一个NVM版本的时间戳小于上述时间戳,那么这个NVM版本一定不被任何正在运行的事务所需要和访问。
由以上方案可知,本发明的优点在于:
本发明所提出的Zen系统充分利用NVM的特性,消除面向NVM的事务型数据库在NVM上的数据冗余写和元数据读写,实现了NVM容量大小的高性能无日志联机事务型数据库,并实现快速崩溃恢复。
附图说明
图1为面向NVM的联机事务数据库;
图2为Zen面向NVM的联机事务型数据库;
图3为基于时钟的LRU Cache替换算法;
图4为无日志持久事务框架;
图5为事务修改持久化算法;
图6为NVM-Tuple Heap区域崩溃后状态;
图7为基于扫描的崩溃恢复算法;
图8为YCSB性能实验效果对比图;
图9为TPCC-NP性能实验效果对比图;
图10为TPCC-NP扩展性实验效果对比图;
图11为崩溃恢复实验效果对比图;
图12为并发控制支持效果对比图。
具体实施方式
发明人在深入理解相关数据库系统的前沿研究工作和深刻理解NVM新硬件特性的基础上,重新思考联机事务型数据库的系统结构,发现现有技术的共性问题:元数据修改,数据多写冗余和NVM空间管理。因此,发明人提出一种新的面向NVM的联机事务型数据库系统设计Zen,解决了现有技术存在的共性问题。实验表明,Zen相比现有技术有显著的性能提升。
本发明申请包括以下关键点:
关键点1:一种面向混合DRAM-NVM主存的联机事务型数据库系统,其特征在于(1)数据表存储在NVM中,一条数据记录可能在NVM中有多个数据记录版本;(2)使用DRAM作为数据记录缓存,当一个活跃事务需要访问一条数据记录时,系统首先在DRAM数据记录缓存中搜索该记录,如果缓存缺失,那么系统就从NVM中将最新版本的记录读入DRAM数据记录缓存;(3)细粒度并发控制所需要的记录级元信息,在NVM记录版本中不保存,当记录被读入DRAM数据记录缓存时,系统为读入记录添加细粒度并发控制元信息,元信息仅在DRAM中被访问和使用;(4)无日志的持久化事务,事务处理不记录日志,提交事务所修改的记录直接写入NVM成为新的记录版本;(5)轻量级的NVM空间管理,对于单条记录空间的分配和释放,不在NVM上记录元信息,在崩溃恢复时,通过扫描判断数据记录版本来确定空间是否被占用。
技术效果:系统可以利用NVM的大容量,来存储比DRAM大得多的数据量,而又避免了外存访问的开销。利用DRAM数据记录缓存,减少活跃事务对于NVM的访问,完全避免在NVM上读写细粒度并发控制元信息,对于所需的记录最多读取一次。无日志的持久化事务避免了在NVM上写事务日志的开销。轻量级的NVM空间管理避免了记录版本分配释放时NVM元信息的修改。整个设计极大减少了NVM的写开销和读开销,降低了事务处理的代价,提高了并发事务处理的吞吐率,同时保证了崩溃恢复的效率。
关键点2:DRAM数据记录缓存,其主要特征是:(1)每个记录在读入DRAM数据记录缓存时增加细粒度并发控制所需的元信息;(2)具体的细粒度并发控制元信息根据采用的并发控制机制来确定,可以支持包括2PL、OCC、MVCC等在内的主流内存事务处理并发控制机制。
技术效果:元数据增强的DRAM数据记录缓存使得NVM中数据记录不需要存储这些并发控制相关的元数据,从而减少NVM上元数据的频繁读写。
关键点3:DRAM数据记录缓存划分为多个Region,每个事务处理线程负责一个Region的缓存替换和缓存空间管理,一个线程可以读所有Region,但是一个线程只能将NVM记录加载放入所属的Region。
技术效果:减少了多线程缓存访问的冲突,可以在此基础上实现无锁缓存管理,发挥并发线程的效率。
关键点4:NVM数据版本堆(NVM-Tuple Heap)存储一个数据表的数据,其主要特征是:同一逻辑数据记录可能有多个版本,每个版本包含产生该版本的事务的时间戳和该数据记录的ID;NVM数据版本堆不存储细粒度并发控制相关的元数据。
技术效果:完全消除了事务因为细粒度并发控制元数据对NVM的修改。
关键点5:无日志持久化事务,其主要特征是:事务处理划分为3个阶段,分别是运行(Perform)、持久(Persist)和维护(Maintenance)阶段。在运行(Perform)阶段,事务读取NVM或DRAM数据记录缓存中的数据,数据修改仅在DRAM中进行,系统根据所采用的并发控制机制判断事务是否可以提交。如果事务可以提交,事务进入持久(Persist)阶段,否则事务直接回滚,丢弃DRAM中的数据修改。在持久阶段,事务产生的每条新记录和每个对现有记录的修改,都写回NVM数据版本堆,成为一个新版本。NVM数据版本上除了时间戳和数据记录ID外,还包括一个LP标志位。一个事务的写回NVM数据版本堆的新记录版本中,除了最后一个写出的记录版本外,其他记录版本LP标志位为0。对于最后一个写出的记录版本,LP标志位为1,并且要求LP标志位所在的8B是在该记录中最后写入NVM的。在维护(Maintenance)阶段,对旧版本的记录进行回收。
技术效果:每个事务提交时产生新版本的记录,并不立即覆盖旧版本的记录,在崩溃恢复时,可以根据需要保留新版本或者保留旧版本的记录,从而可以避免写Undo/Redo事务日志记录。LP标志位避免了事务提交日志记录,可以在崩溃恢复时,通过LP标志位判断一个事务是否完整提交。上述两个方法结合在一起,完全避免了事务日志,从而减少了事务日志可能引入的NVM写开销。
关键点6:无日志的崩溃恢复算法,其主要特征是通过扫描NVM数据版本堆,恢复DRAM中的数据结构,根据LP标志位,判断事务是否完整提交,同时确定NVM中可以回收的记录版本位置。
技术效果:崩溃恢复不需要事务日志,可以正确地恢复系统状态,所有提交事务的数据被保留,所有未提交事务的数据被丢弃。
关键点7:轻量级NVM空间管理方法,其主要特征是对NVM空间进行二级管理。第一级是页粒度的空间管理,页的大小可以设置,NVM数据页的分配和释放需要在NVM中记录元数据。第二级是数据记录粒度的空间管理,记录粒度的NVM空间分配和释放完全在DRAM中管理,不需要在NVM中写元信息。分配的记录来源包括两个,一是从新分配的NVM数据页中分配,二是重新利用已回收的NVM记录版本。
技术效果:NVM记录版本的分配和释放不需要在NVM中写元信息,因此减少了大量NVM写操作。
关键点8:第二级的NVM空间管理是每个线程本地进行的,其主要特征是每个线程NVM堆数据版本的分配和回收是独立的,每个线程都在DRAM中维护自己的分配队列,把回收的版本地址放入队列,并在需要时从队列中分配数据版本,仅当分配队列为空时,才需要通过第一级的NVM空间管理获取新的NVM页。
技术效果:NVM空间的分配和回收基本无竞争,减少多线程冲突对NVM空间管理开销。
为让本发明的上述特征和效果能阐述的更明确易懂,下文特举实施例,并配合说明书附图作详细说明如下。
本发明提出一种面向非易失主存的联机事务型数据库,主要描述如下:
如图2所示,面向NVM的联机事务型数据库总体结构:
NVM-Tuple Heap是在NVM上持久存储数据表的数据结构,具体是一个堆。每个数据表的NVM-Tuple Heap由2MB的NVM数据页组成,每个NVM数据页可以根据单条数据记录的大小存储若干条NVM-Tuple记录。每个NVM-Tuple包含16B的元数据和16字节对齐的数据域。同一NVM-Tuple Heap中可能包含同一逻辑数据记录的多个版本,即数据元组指:存储在NVM上的一条数据,这一条数据由Tx-CTS和Tuple-ID唯一确定。逻辑数据指:Tuple-ID相同的数据。同一逻辑数据可能在NVM上有多个版本。这多个版本的Tuple-ID相同而Tx-CTS不同。事务提交时间戳Tx-CTS和TupleID可以唯一确定一个NVM版本。删除位(Deleted)标记一个数据记录的删除被持久化。事务提交标志位(LP)用于识别最后一个被持久化的数据版本,并对并发控制至关重要。每个数据记录元数据16B小于CPU Cache(64B),因此可以被原子性的持久化。
MetCache是DRAM中数据记录粒度的缓存,每个数据表都有自己的NVM-Tuple Heap和MetCache。每个MetCache entry包含数据记录本身和7个元数据域:一个指向NVM-Tuple的指针NVM-Pointer、TupleID、脏位Dirty、活跃位Active、支持Clock Cache替换算法的锁位、一个拷贝位和支持并发控制的CC-Meta域。通过MetCache,Zen完全将并发控制放入内存。
一致内存索引是每个HTable均配备的数据结构,包含一个主索引和若干可选次级索引。索引可以是Hash或者基于树的索引。主索引的键是数据的逻辑主键,值标记MetCacheentry位置,或者是NVM-Tuple的地址。Zen选择用地址保留位来区分这两种情况。由于DRAM访问频繁,Zen选择使用“0”来标记数据在DRAM的MetCache中,以使得Zen可以直接使用该值索引MetCache数据。对于次级索引,键是用户指定的,值是数据记录的主键。
事务运行私有数据:Zen支持多线程并发执行事务。每个线程拥有私有内存空间,并在私有空间记录事务的读写、插入等活动。OCC和MVCC在单独的数据结构中记录这些操作,两段锁协议(2PL)以日志的形式记录这些修改。
NVM空间管理:Zen使用两层机制管理NVM空间。第一,NVM数据页粒度的管理,Zen分配2MB数据页给每个HTable,并在NVM上记录每个2MB页与数据表之间的分配关系。第二,每个HTable配备的线程本地的NVM-Tuple Manager在内存中管理Tuple粒度的NVM空间。每个NVM-Tuple Manager由一个NVM-Tuple分配器和回收器组成。分配器包含不连续的NVM-Tuple可用地址。可用地址的来源有2个,一个是新分配的NVM数据页,另一个是被回收的NVM-Tuple地址。Zen在分配NVM数据页时将该页数据初始化为0以用Tx-CTS=0来标记此页所有地址可用。回收器回收无效NVM-Tuple版本并将其放入分配器。一个数据表所有NVM-Tuple Manager中的回收器以线程合作方式回收无效数据版本。
元数据增强的内存数据记录缓存:
对于每个HTable,Zen将MetCache划分为多个容量相等的区域(Region)。每个线程拥有一个这样的区域。NVM-Tuple Heap也同样被划分为每个线程的区域。每个线程负责管理其自身的Met-Cache Region和NVM-Tuple Region。任一线程可以读取其它线程的Region,但是只能写自己拥有的Region。当MetCache缓存需要修改另一个Region里的数据记录,需要将该数据记录拷贝到自己的Region中同时将原数据记录的Copy位设置为1。当有Cache Miss的时候,线程从NVM-Tuple Heap将数据加载到MetCache。Zen通过LRU时钟算法从本地Region中选择被替换的MetCache Entry。这样的涉及消除了MetCache之间的竞争,并且绑定MetCache和NVM-Tuple Heap地址空间到CPU核心,也就是说每个CPU可以无竞争的获取这些DRAM和NVM空间。
Zen使用时钟算法来做MetCache Entry的替换。如图3所示,该算法在线程本地Region选择第一个Active和Clock位都为0的缓存项。如果Active位被设置,该缓存项正在被活跃事务访问,算法跳过这样的缓存项以保证正在被访问的数据项不会被替换出。如果Clock位被设置,该数据项最近被使用过,根据LRU Cache策略,Zen优先保留这样的数据项在MetCache中。Active和Clock位的修改均使用原子操作。
Zen根据在DRAM的容量有限条件下,根据数据表的大小和每个事务对数据表元组的平均访问数量,来确定MetCache的数量。Zen根据每个数据表,事务平均访问次数除以数据表的大小,这个参数的大小采用贪心策略来分配每个表的MetCache数量。
由于Zen在NVM上的数据版本不包含并发控制相关的元信息,当一个数据元组从NVM中缓存到MetCache时,CC-Meta这个字段会填充并发控制相关的信息,这个信息和不同的并发控制算法相关。之后Zen完全在内存运行并发控制因为所有被活跃事务访问的元组都已经在内存。这个涉及有5点好处:(1)细粒度的并发控制相关的元数据读写从NVM迁移到内存;(2)元组的读不会引起NVM写;(3)中止的事务不会带来NVM写开销;(4)内存并发控制降低了事务处于临界状态的时间,因此事务的中止率可能会降低。
无日志持久事务框架:
正常事务执行:
事务执行分为3个阶段:(1)执行阶段,Zen在DRAM中处理事务;(2)持久化,Zen将最新修改或插入的元组写到NVM;(3)维护阶段:Zen回收NVM上的冗余无效版本。
图4展示了一个事务的生命周期。数据表维护消费者的账户。初始时,X有$500,Y和Z分别有$100。运行的事务是X向Y和Z各转账$100。此图的上半部分展示的是事务运行前的状态。NVM-Tuple Heap有5个元组,其中R:d已经被删除和垃圾回收。Q:300被缓存在Met-Cache中。索引记录有效版本的位置信息,指向Met-Cache中缓存的元组(如有,比如Q:d)或者NVM-Tuple Heap中的元组。NVM-Tuple Manager中的分配器记录着3个可用分配地址。
执行阶段:
对于事务请求访问的每一个元组,Zen在主索引中寻找其位置。如果此元组在NVM中,Zen使用图3所示的算法找到一个Met-Cache项换出(如果MetCache无空闲项)然后将需要访问的元组读到Met-Cache并使之增强具有并发控制相关的元信息,并更新主索引指向Met-Cache,否则直接访问Met-Cache中的数据。在执行阶段的访问数据和验证事务间的冲突时会用到并发控制相关的元信息,事务提交后能否回收此版本(DRAM和NVM版本)均需要此相关的元信息。更新主索引指向Met-Cache的原因是最新的数据在Met-Cache entry,而不在NVM-Tuple Heap,该数据即将发生改变或者即使只是被读取进行并发控制,该项Met-Cache entry都是逻辑数据的最新数据。
Zen不需要将被换出的元组写回NVM,因为以下原因:(1)如果此元组只是被当前事务之前的事务读取,此版本未发生改变,索引指向NVM中的相同数据,因此该缓存元组直接丢弃。(2)如果该缓存项被当前事务之前提交的事务修改,该Met-Cache缓存项必定在前述事务的持久化阶段写回NVM。(3)如果这个事务被中止事务修改,该缓存项无效并且应该被舍弃。
图3所示的算法的输入为运行事务的线程号,输出为找到的被替换的Met-CacheEntry的位置。第一步,根据线程号找到该线程具有写权限的一组连续Met-Cache entries区域。第二部,循环访问此区域中的每项Met-Cache entry,如果此项entry的Active标志位被设置,则跳过此项entry,否则继续判断此项。如果此项entry的Clock位为1,则将Clock位设置为0,并跳过此项,否则继续判断此项。如果上述两项均未跳过此项entry,则此项entry满足条件,可以被替换。其中Clock的意义在于以LRU(Least Recent Used)策略选择换出项以最大化利用Cache性能。每次数据访问Met-Cache enrty均会将Clock位设置为1。
Zen因为Met-Cache这个设计能在完全在DRAM做并发控制。如果没有冲突事务可以提交,Zen进入持久化阶段。如果事务必须中止,Zen检查被该事务访问的Met-Cache项是否是脏数据。对于脏数据,Zen使用Met-Cache的NVM-Pointer指向的NVM-Tuple来恢复该Met-Cache项中的数据以使得重试的事务找到正确的数据。
图4下半部分展示事务运行后的系统状态。在执行阶段,Zen将X、Y、Z加载到Met-Cache。索引也对应修改了。事务在Met-Cache中将X、Y、Z分别修改为300、200和200.事务的私有数据空间记录事务的读写集合。
持久化阶段:
Zen将事务修改所产生的新元组无日志的持久化到NVM上。这里的挑战是将多个元组原子性的持久化到NVM上并且不写Redo日志和提交日志。主要思路是:(1)Zen将元组持久化到NVM-Tuple Heap中的空闲NVM槽位,这样旧版本是完好无损的。Zen可以在崩溃恢复时回退到旧版本。并且这个方法已经在WBL中被证明可用。(2)Zen使用原子操作标记事务的最后一个修改版本的最后持久标记位(LP)。这个LP位和提交日志有同样的功能。在崩溃恢复时,如果LP位被标记,那么这个事务提交成功,并且所有的修改均已持久化到NVM。否则说明系统崩溃在事务的持久化阶段出现了。因此Zen丢弃该事务所有修改。
图5展示了1个事务将其对元组的修改持久化到NVM的过程。该事务并发的持久化除了最后一个包含LP位的CPU Cache-line。CPU Cache-line是64B对齐的。该算法使用循环每64B使用Clwb指令按照CPU Cache-line写出。前面这些CPU Cache-line持久化过程的顺序是不影响正确性的。但是这些写回必须先于最后一个修改的LP写回,Zen通过Sfence指令来保证这一点。包含最后一项修改的元数据能原子性的写回是因为NVM-Tuple是16B对齐的并且元数据的大小是16B。
该算法可以只用1个Sfence,而不需要在最后一个Clwb之后再使用1个Sfence。这是正确的因为恢复过程无论LP是否被写到NVM都可以正确的处理该事务。并且任何之后事务的Sfence都可以保证最后1个Clwb指令完成。举个例子,1个用户交互线程可以在将事务结果返回客户端之前执行1个Sfence指令。
如图4右下部分所示,Zen在空闲NVM槽位f、g、h将X’,Y’和Z’写回,其中Z’是最后一项。因此,Zen在把LP位设置在Z’的元数据中。
维护阶段:
为了减小竞争,每个线程都有自己的私有NVM-Tuple分配器和垃圾回收队列。一个线程当发现有新版版本时就可以回收旧版本。垃圾回收的时机有2个:(1)当事务提交要重写一个新的逻辑版本时,当前线程回收旧的NVM-Tuple版本,除非当前版本是从其它线程的Region中拷贝过来的。(2)在Met-Cache替换出该版本时,当前线程回收Met-Cache中已被复制的NVM-Pointer所指向的NVM-Tuple版本。这里要注意,当前Met-Cache项必定已经被另一个提交事务拷贝,并且该事务已写到NVM上一个更新的版本。这样,线程可以在本地回收旧版本。
在Garbage队列中的回收项不能立即被使用因为相关的旧版本可能正在被其它运行着的事务访问(比如,MVCC并发控制)。每个垃圾回收项包含NVM-Tuple指针和事务时间戳。Zen通过计算每个线程的最后一次提交时间戳,来维护一个全局最小已提交事务的时间戳,保证运行时的事务时间戳高于该全局时间戳。Garbage队列中小于全局最小提交时间戳的回收项可以被放入分配器安全复用。
如图4左下方所示,Zen将X、Y和Z的旧版本放入垃圾回收队列。Zen将R:d从垃圾回收队列放入分配器,因为该垃圾回收项的时间戳小于全局最小提交时间戳。
灵活支持多种并发控制算法
上述事务处理设计提供了一个灵活支持多种并发控制方法的框架。Zen通过实验证明至少支持10种典型的并发控制算法,包括两段锁、OCC、MVCC和基于划分的并发控制。
为了支持不同并发控制方法,Met-Cache的CC-Meat使用和并发控制相关元数据。对于两段锁,CC-Meta的元数据是锁位。对于OCC,CC-Meta包括元组的写时间戳,读时间戳写锁位和标记最新版本的位。对于MVCC,CC-Meta包括多个时间戳和版本指针。这些并发控制方法均通过Met-Cache完全在内存中执行。
考虑支持版本的并发控制这个特征,并发控制方法分为单版本方法和多版本方法。Met-Cache是否支持版本是由并发控制方法确定的。NVM-Tuple Heap支持多版本是为了移除Redo日志,和Met-Cache是否支持多版本无关。队医单版本并发控制方法,Met-Cache为每个元组维护单一版本,被并发控制保护的元组修改直接修改Met-Cache中的元组。当在NVM-Tuple Heap存在多个已提交的数据版本,只有最新的版本被缓存入Met-Cache。对于多版本并发控制方法,Met-Cache中有被事务直接访问的多版本,事务会给每次修改创建一个新的版本。缓存替换算法不会替换这些缓存项Active位被设置。相关已提交的NVM-Tuple版本也必须存在于NVM。只有最新版本在Garbage队列中进行记录。同一逻辑元组的多版本不能直接放到分配器的原因是这些元组可能被正在运行的事务访问。多版本并发控制方法通常为同一逻辑元组的多个版本维护为版本链表。主索引一致指向最新版本。旧版本总可以通过版本链表找到。
无日志崩溃恢复:
崩溃发生后,DRAM中的数据结构丢失,这些数据包括索引、NVM-Tuple管理器、Met-Cache和事务私有信息。Zen需要重建索引和元组粒度的NVM空间管理器。Met-Cache和事务私有数据不需要被恢复。在NVM中持久化的数据包括NVM元数据(数据表结构、页粒度的页面分配信息)和NVM上的数据表的元组。
图6是一个崩溃后的例子。例子中有时间戳分别为1000、1003、1015和1016的4个事务,其中时间戳为1000和1003的两个事务有LP标记,是提交成功的事务。但是另外两个事务未能成功提交。
在崩溃恢复时,Zen运行多个线程。每个线程扫描一个NVM-Tuple Heap区域。一个朴素的方法是扫描两次。第一次扫描通过统计LP计算事务提交的全局最大时间戳。第二次扫描通过将元组时间戳和全局最大提交时间比较来识别出所有提交的版本。
Zen提出一个如图7所示的改进算法来避免扫描两次。算法的主要思想是尽可能用目前的最大提交时间戳识别出更多的提交版本,只有无法确定的版本才需要被在此访问。需要被再次访问的平均元组数目是O(log(n)),这里n是NVM-Tuple中版本的数量。
算法描述如图7所示。该算法用ts-commit来维护当前最大提交时间戳。Zen在扫描的过程中不断通过有LP标记的版本更新为更大的值。Zen认为所有小于或等于该时间戳的版本均被提交。Zen通过比较时间戳来更新索引,使之指向最新的版本,同时将旧版本回收。如果版本时间戳大于ts-commit,Zen暂时不能分辨当前版本是否提交,因此将其放入待定数组。
在第一次扫描区域数据之后,ts-commit成为本区域的最大时间戳。之后,Zen处理第一次扫描不确定的版本。如果被再次访问的版本时间戳小于等于ts-commit,Zen更新索引并回收旧版本。如果被再次访问的版本时间戳大于ts-commit,崩溃一定发生在持久这个版本相关事务的过程中。由于一个线程只能写本地区域,所有同一事务的写在同一个区域。这说明扫描过程识别了此事务的所有版本,但是由于没有LP标记,因此事务未完成提交。Zen丢弃这些改变并回收这些版本。
正确性:图7所示算法识别了区域内所有的提交版本。第一,如果版本的时间戳小于等于ts-commit,那么该事务一定已提交完成。这是因为区域内的元组由同一个线程写出,并且同一线程的事务时间戳是单调递增的(尽管不同线程之间的时间戳在某些并发控制算法中不是全序关系)。第二,该算法在主扫描循环中执行检查,之后再检查不确定的版本。因此所有的NVM版本都被识别(为提交或者未提交)。
该算法正确的重建了索引。该算法对未删除的提交版本调用updateIndexGC,这使得最新版本被索引指向。该算法也回收了无用版本槽(比如,旧版本,删除的版本,NVM数据页中的未用版本)。
更进一步,该算法是幂等的。该算法不改变提交的元组,将提交时崩溃的事务要修改的版本标记为空槽。因此,当恢复时发生了系统崩溃,Zen可以重新运行该算法得到相同的ts-commit并再次恢复索引,得到相同的数据库恢复状态。
最后,考虑崩溃发生时,系统运行恢复一段时间了,第二次崩溃发生了。第二次恢复后的数据库不会看到第一次崩溃恢复失败造成的任何未提交版本因为Zen在第一次崩溃恢复已将那些版本标记为空槽。
恢复效率:在无法确定数组中的元组被访问了两次。因此,无法确定元组的个数决定改进算法相比于简单算法的收益。
定理:无法确定数组中的元组数量是平均O(log(n)),这里n是NVM-Tuple Heap中版本的的数量(通常n是很大的)。
证明:假设有不同时间戳的版本随机均匀分布在所有NVM-Tuple Heap中。设k为有LP标记的版本数量,同样假设这些版本是随机均匀分布在NVM-Tuple Heap区域中,并且在时间顺序上也是随机均匀分布的。
在典型的联机事务系统(OLTP)中,同一事务访问元组的数量是有上界的小数常量。因此k和n同数量级。因此这k个具有LP标记的版本将NVM-Tuple Heap区域划分为k+1个子域,每个子域平均长度为n/(k+1)。
如果版本的时间戳大于ts-commit,则被放入待定数组。初始的ts-commit等于0。所以第一个子域的所有元组都被放入了待定数组。考虑第i个子域,由于前面已访问过i-1个具有LP的版本,ts-commit是前i-1个提交版本时间戳最大的,因此第i个子域的提交时间戳有1/i的概率大于之前的ts-commit。因此:
L为待定版本的长度,H为欧拉数列。因此L的上界是O(ln(n))。
算法输入为NVM上的数据分区和初始索引,输出是完成了的索引。算法会访问全局定义的索引结构。该索引初始为空,算法结束后,该索引被恢复。
第一步,定义当前确认的已提交事务时间戳(时间戳小于等于此时间戳的版本一定已提交),初始化为0,和当前无法判定的NVM版本指针集合,初始化为空集合。
第二步,对于扫描区域内的任一版本
如果该NVM版本的LP位被设置,则选择该NVM版本和已确认提交事务时间戳之中大者作为当前已确认提交事务时间戳。
如果该NVM版本的Deleted标记被设置或者TX-CTS为0(为已回收版本或新分配的数据页上的还未被使用过版本),开始处理下一个NVM版本。
如果该NVM版本的Tx-CTS小于或者等于当前已确认提交事务时间戳,则调用程序,更新索引和回收垃圾NVM版本(updateIndexGC);否则(NVM版本的Tx-CTS大于当前确认已提交时间戳)此NVM暂时不发确认是否提交,将其放入待定NVM版本集合。(经过第二步完整扫描已确定全局提交事务时间戳)
第三步,对于处于未决NVM版本集合中的NVM版本,如果NVM版本Tx-CTS小于已确认全局提交时间戳,则调用程序,更细索引和回收垃圾版本。否则当前NVM版本未提交,直接回收此版本。
更新索引和回收垃圾算法输入为NVM版本,无输出。
以下为与上述方法实施例对应的系统实施例,本实施方式可与上述实施方式互相配合实施。上述实施方式中提到的相关技术细节在本实施方式中依然有效,为了减少重复,这里不再赘述。相应地,本实施方式中提到的相关技术细节也可应用在上述实施方式中。
本发明还提供了一种面向混合DRAM-NVM主存的联机事务型数据库系统,其中包括:
用于缓存数据的该DRAM和用于持久存储数据的该NVM;
NVM通过第一数据表记录NVM中存储的多个数据元组,用于事务处理并发控制的元信息仅保存在DRAM中,即NVM中该数据元组不保存并发控制的元信息,根据访问任务将该数据元组以元组为粒度缓存至DRAM,且在数据元组缓存至DRAM时为每个数据元组增加并发控制元信息,DRAM通过第二数据表记录数据元组及其对应的并发控制元信息;
该联机事务型数据库系统还包括混合数据表,该混合数据表包括该第一数据表、该第二数据表,以及用于管理该第一数据表和第二数据表的管理模块。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中该并发控制元信息为以元组为粒度且具有并发控制相关的元信息,该第二数据表缓存按照线程数目划分为多个缓存区域,各线程仅在其对应的缓存区域内修改数据;该第二数据表内的缓存项包括数据元组的存储空间和第二元数据,第二元数据包括活跃位、并发控制字段、元组标识字段、指向NVM版本的指针和缓存替换字段;通过该活跃位判断该缓存项是否被占用通过该活跃位控制该缓存项不被替换;事务运行中,根据通过读取和写入该并发控制字段,执行并发控制算法,并根据读取和写入该缓存替换字段,以执行缓存替换策略。
所述的混合DRAM-NVM主存的联机事务型数据库系统,其中该第一数据表中部分数据元组存在多个数据版本,每个数据元组包括其占用的存储空间和第一元数据,第一元数据包括:事务提交时间戳、元组标识字段、删除位和事务提交确认位;通过该事务提交时间戳和该元组标识字段唯一确定事务提交版本,通过该删除位标记逻辑数据的删除;
同一事务提交的所有数据元组修改具有相同的事务提交时间戳,且同一事务提交的所有数据元组修改对应的数据版本中,任意一个数据版本事务提交确认位被设置,即可确认事务已被正确提交,数据修改均已持久化。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中
事务在执行阶段访问该混合数据表,判断该事务访问的目标数据是否位于DRAM中,若是则直接访问DRAM中缓存的该目标数据,否则将NVM中存储的该目标数据缓存到执行当前事务的线程对应的数据缓存区域并填写与之对应的第二元信息;
在DRAM中通过并发执行且成功提交的事务进入持久阶段,将该事务修改的所有数据版本均写到NVM上进行持久存储;
事务维护阶段,回收NVM上的因新提交版本而无效的数据版本。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中该持久阶段包括:事务在该持久阶段从所有数据修改所对应的多个数据版本选择最后修改完的数据进行持久化,并只设置最后修改完的数据版本的事务提交确认位为已提交;事务先持久化除最后一个版本的事务提交确认位所在的CacheLine的所有版本数据,之后原子性持久化最后一个版本的事务提交确认位所在的CacheLine。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中该混合数据表配备一个主索引,该主索引的存储位置为DRAM和/或NVM,该主索引的值为同一逻辑数据最新版本的存储位置。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中当存储于DRAM中的该主索引因掉电失去时,执行以下步骤:
步骤1、初始化已确认提交事务时间戳为0,初始化待判定NVM版本指针集合为空;
步骤2、选择NVM中一个数据版本作为当前数据版本,根据当前数据版本的最后持久标记位判断其是否为最新修改版本,若是则选择当前数据版本的事务提交时间戳其和已确认提交事务时间戳中最大者作为已确认提交事务时间戳,否则执行步骤3;
步骤3、判断当前数据版本是否为已删除版本或新分配的数据页上的还未被使用过版本,若是则回收该当前数据版本并执行步骤2,否则执行步骤4;
步骤4、判断当前数据版本的事务提交时间戳是否小于等于当前该已提交事务时间戳,若是则更新索引指向该数据的最新版本并回收该数据的旧版本,否则将当前数据版本存入该待判定NVM版本指针集,再次执行步骤步骤2,直到遍历NVM中所有数据版本执行步骤5;
步骤5、对于处于该待判定NVM版本指针集中的数据版本,判断其事务提交时间戳是否小于等于当前该已提交事务时间戳,若是则更新索引指向该数据的最新版本并回收该数据的旧版本,否则当前数据版本未提交,直接回收此版本。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中NVM空间管理分为两层,第一层是数据页粒度的空间管理,通过给NVM上的全局数据结构分配线程;第二层是数据版本粒度的空间管理,数据版本粒度的NVM空间的分配和释放由DRAM中的数据结构通过指向NVM地址的指针进行管理。
所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其中数据版本粒度的NVM空间分配和释放采用特定线程合作机制:
线程内部使用该管理模块管理NVM空间,线程之间同步当前正在运行的事务最小时间戳,事务在该事务维护阶段根据当前正在运行事务的最小时间戳Tx-Min,回收NVM中相同逻辑数据但事务提交时间戳小于Tx-Min的数据版本。
Claims (9)
1.一种面向混合DRAM-NVM主存的联机事务型数据库系统,其特征在于,包括:
用于缓存数据的该DRAM和用于持久存储数据的该NVM;
NVM通过第一数据表记录NVM中存储的多个数据元组,用于事务处理并发控制的元信息仅保存在DRAM中,即NVM中该数据元组不保存并发控制的元信息,根据访问任务将该数据元组以元组为粒度缓存至DRAM,且在数据元组缓存至DRAM时为每个数据元组增加并发控制元信息,DRAM通过第二数据表记录数据元组及其对应的并发控制元信息;
该联机事务型数据库系统还包括混合数据表,该混合数据表包括该第一数据表、该第二数据表,以及用于管理该第一数据表和第二数据表的管理模块。
2.如权利要求1所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其特征在于,该并发控制元信息为以元组为粒度且具有并发控制相关的元信息,该第二数据表缓存按照线程数目划分为多个缓存区域,各线程仅在其对应的缓存区域内修改数据;该第二数据表内的缓存项包括数据元组的存储空间和第二元数据,第二元数据包括活跃位、并发控制字段、元组标识字段、指向NVM版本的指针和缓存替换字段;通过该活跃位判断该缓存项是否被占用,通过该活跃位控制该缓存项不被替换;事务运行中,根据通过读取和写入该并发控制字段,执行并发控制算法,并根据读取和写入该缓存替换字段,以执行缓存替换策略。
3.如权利要求1或2所述的混合DRAM-NVM主存的联机事务型数据库系统,其特征在于,该第一数据表中部分数据元组存在多个数据版本,每个数据元组包括其占用的存储空间和第一元数据,第一元数据包括:事务提交时间戳、元组标识字段、删除位和事务提交确认位;通过该事务提交时间戳和该元组标识字段唯一确定事务提交版本,通过该删除位标记逻辑数据的删除;
同一事务提交的所有数据元组修改具有相同的事务提交时间戳,且同一事务提交的所有数据元组修改对应的数据版本中,任意一个数据版本事务提交确认位被设置,即可确认事务已被正确提交,数据修改均已持久化。
4.如权利要求2所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其特征在于,
事务在执行阶段访问该混合数据表,判断该事务访问的目标数据是否位于DRAM中,若是则直接访问DRAM中缓存的该目标数据,否则将NVM中存储的该目标数据缓存到执行当前事务的线程对应的数据缓存区域并填写与之对应的第二元信息;
在DRAM中通过并发执行且成功提交的事务进入持久阶段,将该事务修改的所有数据版本均写到NVM上进行持久存储;
事务维护阶段,回收NVM上的因新提交版本而无效的数据版本。
5.如权利要求4所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其特征在于,该持久阶段包括:事务在该持久阶段从所有数据修改所对应的多个数据版本选择最后修改完的数据进行持久化,并只设置最后修改完的数据版本的事务提交确认位为已提交;事务先持久化除最后一个版本的事务提交确认位所在的CacheLine的所有版本数据,之后原子性持久化最后一个版本的事务提交确认位所在的CacheLine。
6.如权利要求1所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其特征在于,该混合数据表配备一个主索引,该主索引的存储位置为DRAM和/或NVM,该主索引的值为同一逻辑数据最新版本的存储位置。
7.如权利要求6所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其特征在于,当存储于DRAM中的该主索引因掉电失去时,执行以下步骤:
步骤1、初始化已确认提交事务时间戳为0,初始化待判定NVM版本指针集合为空;
步骤2、选择NVM中一个数据版本作为当前数据版本,根据当前数据版本的最后持久标记位判断其是否为最新修改版本,若是则选择当前数据版本的事务提交时间戳,其和已确认提交事务时间戳中最大者作为已确认提交事务时间戳,否则执行步骤3;
步骤3、判断当前数据版本是否为已删除版本或新分配的数据页上的还未被使用过版本,若是则回收该当前数据版本并执行步骤2,否则执行步骤4;
步骤4、判断当前数据版本的事务提交时间戳是否小于等于当前该已确认提交事务时间戳,若是则更新索引指向该数据的最新版本并回收该数据的旧版本,否则将当前数据版本存入该待判定NVM版本指针集,再次执行步骤2,直到遍历NVM中所有数据版本执行步骤5;
步骤5、对于处于该待判定NVM版本指针集中的数据版本,判断其事务提交时间戳是否小于等于当前该已确认提交事务时间戳,若是则更新索引指向该数据的最新版本并回收该数据的旧版本,否则当前数据版本未提交,直接回收此版本。
8.如权利要求4所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其特征在于,NVM空间管理分为两层,第一层是数据页粒度的空间管理,通过给NVM上的全局数据结构分配线程;第二层是数据版本粒度的空间管理,数据版本粒度的NVM空间的分配和释放由DRAM中的数据结构通过指向NVM地址的指针进行管理。
9.如权利要求8所述的面向混合DRAM-NVM主存的联机事务型数据库系统,其特征在于,数据版本粒度的NVM空间分配和释放采用线程合作机制:
线程内部使用该管理模块管理NVM空间,线程之间同步当前正在运行的事务最小时间戳,事务在该事务维护阶段根据当前正在运行事务的最小时间戳Tx-Min,回收NVM中相同逻辑数据但事务提交时间戳小于Tx-Min的数据版本。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011439569.XA CN112597254B (zh) | 2020-12-07 | 2020-12-07 | 面向混合dram-nvm主存的联机事务型数据库系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011439569.XA CN112597254B (zh) | 2020-12-07 | 2020-12-07 | 面向混合dram-nvm主存的联机事务型数据库系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112597254A CN112597254A (zh) | 2021-04-02 |
CN112597254B true CN112597254B (zh) | 2023-02-03 |
Family
ID=75191783
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011439569.XA Active CN112597254B (zh) | 2020-12-07 | 2020-12-07 | 面向混合dram-nvm主存的联机事务型数据库系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112597254B (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113032292B (zh) * | 2021-05-19 | 2021-09-03 | 北京金山云网络技术有限公司 | 存储空间回收方法、数据读取方法及装置 |
CN113515502B (zh) * | 2021-07-14 | 2023-11-21 | 重庆度小满优扬科技有限公司 | 数据迁移方法、装置、设备以及存储介质 |
CN115576494B (zh) * | 2022-10-31 | 2023-11-03 | 超聚变数字技术有限公司 | 数据存储方法和计算设备 |
CN115587883B (zh) * | 2022-11-22 | 2024-03-08 | 荣耀终端有限公司 | 一种成本计价方法和装置 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104881371A (zh) * | 2015-05-29 | 2015-09-02 | 清华大学 | 持久性内存事务处理缓存管理方法与装置 |
CN110515705A (zh) * | 2019-08-07 | 2019-11-29 | 上海交通大学 | 可扩展的持久性事务内存及其工作方法 |
CN111459920A (zh) * | 2020-05-15 | 2020-07-28 | 北京谷数科技股份有限公司 | 基于虚拟全局时钟同步的多版本并发控制方法及系统 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11204926B2 (en) * | 2018-10-31 | 2021-12-21 | International Business Machines Corporation | Storing partial tuples from a streaming application in a database system |
-
2020
- 2020-12-07 CN CN202011439569.XA patent/CN112597254B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104881371A (zh) * | 2015-05-29 | 2015-09-02 | 清华大学 | 持久性内存事务处理缓存管理方法与装置 |
CN110515705A (zh) * | 2019-08-07 | 2019-11-29 | 上海交通大学 | 可扩展的持久性事务内存及其工作方法 |
CN111459920A (zh) * | 2020-05-15 | 2020-07-28 | 北京谷数科技股份有限公司 | 基于虚拟全局时钟同步的多版本并发控制方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN112597254A (zh) | 2021-04-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112597254B (zh) | 面向混合dram-nvm主存的联机事务型数据库系统 | |
US11288252B2 (en) | Transactional key-value store | |
US10289545B2 (en) | Hybrid checkpointed memory | |
US11023453B2 (en) | Hash index | |
CN111309270B (zh) | 一种持久性内存键值存储系统 | |
CN109407979B (zh) | 多线程持久性b+树数据结构设计与实现方法 | |
Levandoski et al. | High performance transactions in deuteronomy | |
US7266669B2 (en) | File system with file management function and file management method | |
US8868624B2 (en) | Blob manipulation in an integrated structured storage system | |
US20180011892A1 (en) | Foster twin data structure | |
Levandoski et al. | LLAMA: A cache/storage subsystem for modern hardware | |
US8620884B2 (en) | Scalable blob storage integrated with scalable structured storage | |
US20170351543A1 (en) | Heap data structure | |
CN109407978B (zh) | 高并发索引b+链表数据结构的设计与实现方法 | |
Graefe | A survey of B-tree logging and recovery techniques | |
US11755427B2 (en) | Fast recovery and replication of key-value stores | |
JPH04337850A (ja) | データベース・トランザクション及び照会処理システム | |
US20180004798A1 (en) | Read only bufferpool | |
Kim et al. | {ListDB}: Union of {Write-Ahead} logs and persistent {SkipLists} for incremental checkpointing on persistent memory | |
CN110515705B (zh) | 可扩展的持久性事务内存及其工作方法 | |
CN113495692A (zh) | 数据存储的方法和键值存储设备 | |
Iwabuchi et al. | Metall: A persistent memory allocator enabling graph processing | |
US11829291B2 (en) | Garbage collection of tree structure with page mappings | |
CN112214171B (zh) | 一种面向SQLite数据库的非易失性内存缓冲区设计方法 | |
US11593352B2 (en) | Cloud-native object storage for page-based relational database |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |