1.本发明属于数据库
技术领域：
：，更具体地说，是一种用于非易失性内存的高吞吐量无日志在线事务处理方法。
背景技术：
：：2.新兴的非易失性内存(nvm)具有可字节寻址、几乎和dram一样快、比dram容量更大等特性，为oltp数据库带来了巨大的性能潜力，但是由于具有写带宽低于读带宽、缓存线刷新和内存屏障指令等特殊持久化操作比普通写操作开销高、写操作次数有限等特性要求设计nvmoltp系统必须满足3个设计原则：将频繁访问的数据结构放在dram中、尽可能减少nvm写操作、尽可能减少持久性操作。3.具有nvm的mmdb系统与现有的mmdb设计一样，系统将元组和索引存储在易失性内存中，将wal(write-aheadlog)和检查点放在nvm中。系统崩溃后，易失性内存中的元组和索引被认为丢失了，恢复基于nvm中的日志和检查点。这种设计将修改后的元组写入wal和检查点，导致对元组进行两次额外的nvm写操作。最近的研究提出了几种基于nvm的日志改进方案，包括wbl和foedus等，其中wbl显著减少了日志大小，并且不维护检查点，显著减少了nvm写入的次数，foedus完全在dram中处理事务，从而避免了在nvm中写入元数据。然而，这些设计存在三个重要问题：首先，在mmdb和wbl中，元组元数据与nvm中的元组一起存储，元组元数据修改会导致频繁的nvm写操作，其次，在mmdb和foedus中，修改后的元组被写入nvm的元组堆、日志、检查点中，存在nvm写冗余问题，最后是粗粒度的nvm空间管理，可能会产生很大的nvm持久化开销。技术实现要素：4.本发明的目的在于提供一种用于非易失性内存的高吞吐量无日志在线事务处理方法。5.本发明一种用于非易失性内存的高吞吐量无日志在线事务处理方法，包括以下步骤：6.步骤一、构建引擎架构；引擎架构中包含nvm元数据、索引和多个基表。每个基表均包括存储在nvm中的元组堆、存储在dram中的met-cache，以及各线程在该基表中的nvm元组管理器。7.所述的nvm元组由元组头和元组数据组成。元组头包括最后持久化位lp、事务提交时间戳、元组id和删除位。元组id和事务提交时间戳用于对不同元组版本进行唯一标识。删除位用于显示逻辑元组是否已被删除；最后持久化位lp用于显示逻辑元组是否是提交事务中持久化的最后一个元组。8.所述的met-cache由多个条目组成；一个条目包含元组数据和7个元数据字段：第一个元数据字段为指向nvm元组的指针，第二个元数据字段为元组id，第三个元数据字段为脏位，第四个元数据字段为活动位，五个元数据字段为时钟位，第六个元数据字段为复制位，第七个元数据字段为cc-meta字段。9.步骤二、通过步骤一构建的引擎架构在接收到事务请求时进行无日志事务处理过程。10.2-1.执行阶段，在dram中针对事务请求进行执行事务处理11.2-2.持久化阶段，具体过程如下：12.2-2-1.将事务执行过程中写入的除最后一个元组外的其他所有元组持久化到nvm中；13.2-2-2.将事务执行过程中写入的最后一个元组除了元组头外的所有数据持久化到nvm；14.2-2-3.执行sfence写屏障指令，保证在对最后持久化位lp进行持久化前持久化所有元组。15.2-2-4.将事务执行过程中写入的最后一个元组的最后持久化位lp标记为持久化，并使用nvm原子写操作，将其元组头持久化到nvm。16.在步骤二中，若数据库发生崩溃，则执行事务崩溃恢复过程，具体如下：17.(1)引擎架构运行多个线程，每个线程负责扫描一个nvm元组堆区域，初始化时间戳ts-commit和列表pending-list。ts-commit表示目前为止出现的最大事务提交时间戳。pending-list表示未确定是否已经提交的元组集合。18.(2)进行第一次扫描，第一次扫描的区域为整个nvm元组堆，针对每一个nvm元组，若最后持久化位lp已被设置，则更新时间戳ts-commit；若删除位或者事务提交时间戳等于0，则将该nvm元组放入垃圾队列中。19.若nvm元组的事务提交时间戳≤时间戳ts-commit，则用该nvm元组更新主索引，否则将该nvm元组放入挂起列表pending-list中；20.(3)进行第二次扫描，第二次扫描的区域为挂起列表pending-list中的各nvm元组；此时，时间戳ts-commit是第一次扫描中被扫描区域的最大事务提交时间戳；针对每一个nvm元组，如果一个nvm元组的事务提交时间戳≤时间戳ts-commit，则用该nvm元组更新主索引；否则表明该nvm元组关联的事务在持久化时发生崩溃，通过将该nvm元组对应的元组头标记为空并通过nvm原子写操作将该nvm元组持久化到nvm中，使得该nvm元组被标记为已丢弃；同时，将该nvm元组放入垃圾队列中。21.(4)执行sfence写屏障指令，保证所有崩溃事务的nvm元组均被标记为已丢弃。22.作为优选，步骤二中执行阶段的具体过程如下：23.2-1-1.以接收到客户端的事务请求的时刻作为事务开始时刻，获得事务开始时刻对应的时间戳。24.2-1-2.在主索引中查找是否存在请求元组；若不存在，则进入步骤2-1-3；否则，直接进入步骤2-1-4；25.2-1-3.读取nvm元组，并使用并发控制方法的cc-meta字段增强该nvm元组，来构建met-cache的条目，并使用基于请求元组的met-cache条目的位置更新索引。26.2-1-4.引擎架构根据请求元组的met-cache条目并发执行事务；如果没有冲突并且事务成功提交，直接进入步骤2-2的持久化阶段；如果事务中止，进入到步骤2-1-5；27.2-1-5.检查事务访问的所有met-cache条目的脏位是否已被设置。对于脏位已被设置的met-cache条目，分别从对应的nvm元组指针指向的nvm元组中恢复该条目。28.作为优选，步骤二中，在持久化阶段后进入维护阶段。维护阶段的具体过程为：当线程发现新的版本存在时，将旧版本的nvm元组放入到垃圾队列中。29.作为优选，对于垃圾队列，引擎架构周期性地提取所有线程最后一个提交事务的事务提交时间戳，取得到的各事务提交时间戳的最小值作为全局最小时间戳。将垃圾队列中事务提交时间戳小于全局最小时间戳的nvm元组从垃圾队列移动到分配器空闲列表中。30.作为优选，所述的引擎架构还包括事务私有数据。事务私有数据和索引存储在dram中。31.作为优选，所述的nvm元数据中存储有表模式和粗粒度分配结构；32.作为优选，所述的元组堆由固定大小的页面组成。每个页面均包含固定数量的nvm元组插槽；33.作为优选，nvm元组堆包含一个逻辑元组的多个元组版本；34.作为优选，所述的met-cache在dram中为相应的nvm元组堆管理元组缓存。35.作为优选，所述的索引中的主索引包含键和值；键是元组的主键，值指向met-cache中的缓存条目或nvm元组堆中的最新版本。36.作为优选，所述的引擎架构支持多线程并发处理事务，每个线程均在dram中拥有私有空间37.本发明具有的有益效果是：38.1、本发明提供的引擎架构采用元数据增强的元组缓存(met-cache)、无日志的持久化事务和轻量级的nvm空间管理三种新技术解决了“nvm写操作频繁”、“nvm写冗余”和“nvm持久化开销大”的问题。39.2、本发明通过在nvm元组中设定最后持久化位，从而在不记录日志的情况下，依然能够实现崩溃恢复。40.3、本发明提出了一种改进的崩溃恢复扫描算法，使用目前为止出现的最大事务提交时间戳(ts-commit)来标识尽可能多的已提交元组，第二次扫描无需扫描整个nvm元组堆，只需要扫描挂起列表(pending-list)中的各nvm元组，提升了崩溃恢复的效率。附图说明41.图1为本发明构建的引擎架构的架构图。具体实施方式42.以下结合附图对本发明作进一步说明。43.如图1所示，一种用于非易失性内存的高吞吐量无日志在线事务处理方法，包括以下步骤：44.步骤一、构建引擎架构；引擎架构包括nvm元数据、索引、事务私有数据和多个基表(即htable)。每个基表均包括存储在nvm(非易失性内存)中的元组堆、存储在dram(易失性内存)中的met-cache(元数据增强的元组缓存)，以及各线程在该基表中的nvm元组管理器；一个线程能够通过各基表中对应的nvm元组管理器访问各基表。45.nvm元数据中存储有表模式和粗粒度分配结构；事务私有数据和索引存储在dram中。46.引擎架构将基表中的所有元组作为nvm元组堆中的nvm元组存储；元组堆由固定大小(本实施例为2mb)的页面组成。每个页面均包含固定数量的nvm元组插槽；nvm元组由元组头和元组数据组成。nvm元组堆包含一个逻辑元组的多个元组版本；元组头包括最后持久化位(lp)、事务提交时间戳(tx-cts)、元组id和删除位。元组id和事务提交时间戳(tx-cts)用于对不同元组版本进行唯一标识。删除位用于显示逻辑元组是否已被删除；最后持久化位(lp)用于显示逻辑元组是否是提交事务中持久化的最后一个元组。47.met-cache在dram中为相应的nvm元组堆管理元组缓存。引擎架构通过met-cache完全在dram中执行并发控制。48.met-cache由多个条目组成；一个条目包含元组数据和7个元数据字段：第一个元数据字段指向nvm元组的指针，第二个元数据字段为元组id，第三个元数据字段为脏位，第四个元数据字段为活动位(指示该条目是否被活动事务使用)，第五个元数据字段为时钟位(支持缓存替换算法)，第六个元数据字段为复制位(指示该条目是否已被复制)，第七个元数据字段为cc-meta字段(与正在使用的并发控制方法相关的元数据)。49.引擎架构在dram中为每个基表维护索引，在崩溃恢复时重建索引。主索引是必需的，次要索引是可选的。主索引包含键和值；键是元组的主键，值指向met-cache中的缓存条目或nvm元组堆中的最新版本。引擎架构支持多线程并发处理事务，每个线程均在dram中拥有一块私有空间，用于记录事务的读、写和插入活动等事务私有数据。50.步骤二、通过步骤一构建的引擎架构在接收到客户端的事务请求时进行无日志事务处理过程，具体包括三个阶段分别为执行、持久化和维护。51.2-1.执行：在dram中执行事务处理。52.2-1-1.以接收到客户端的事务请求的时刻作为事务开始时刻，获得事务开始时刻对应的时间戳(tx-cts)。53.2-1-2.在主索引中查找是否存在请求元组；若不存在，则进入步骤2-1-3，否则，直接进入步骤2-1-4；54.2-1-3.读取nvm元组并使用当前使用的并发控制方法独有的cc-meta字段增强该nvm元组，来构建met-cache的条目，并使用基于请求元组的met-cache条目的位置更新索引；55.2-1-4.引擎架构根据请求元组的met-cache条目完全在dram中并发执行事务；如果没有冲突并且事务能够成功提交，直接进入步骤2-2的持久化阶段处理；如果事务中止，进入到步骤2-1-5；56.2-1-5.检查事务访问的所有met-cache条目的脏位是否已被设置。对于脏位已被设置的met-cache条目，分别从对应的nvm元组指针指向的nvm元组中恢复该条目。57.2-2.持久化：将新写入的元组持久化到nvm。58.2-2-1.将事务执行过程中写入的除最后一个元组外的其他所有元组持久化到nvm中；59.2-2-2.将事务执行过程中写入的最后一个元组除了元组头外的所有数据持久化到nvm；60.2-2-3.执行sfence写屏障指令，保证在对最后持久化位(lp)进行持久化前持久化所有元组。61.2-2-4.将事务执行过程中写入的最后一个元组的最后持久化位(lp)标记为持久化，并使用nvm原子写操作，将其元组头持久化到nvm。通过这种方式，最后持久化位(lp)能够达到与提交日志记录相同的作用；在崩溃恢复期间，如果最后持久化位(lp)存在，则事务已经提交；否则，表明在持久化事务的过程中发生崩溃，必须丢弃事务写入的任何nvm元组。62.2-3.维护：收集过期的元组。63.为了减少争用，每个线程都有私有的nvm堆分配器和垃圾队列。当线程发现一个较新的版本存在时，将旧版本的nvm元组放入到垃圾队列中。垃圾队列中的条目不能直接释放，因为相关的nvm元组版本可能仍然被其他事务使用。引擎架构周期性地提取所有线程最后一个提交事务的事务提交时间戳(tx-cts)，取得到的各事务提交时间戳(tx-cts)的最小值作为全局最小时间戳tx-cts。将垃圾队列中事务提交时间戳小于全局最小时间戳tx-cts的nvm元组从垃圾队列移动到分配器空闲列表中。该方式能够避免当前事务正在访问的nvm元组版本被错误移除到空闲列表。64.在步骤二中，若数据库发生崩溃，则执行事务崩溃恢复过程，具体如下：65.(1)引擎架构运行多个线程，每个线程负责扫描一个nvm元组堆区域，初始化时间戳ts-commit和列表pending-list。ts-commit表示目前为止出现的最大事务提交时间戳，pending-list表示未确定是否已经提交的元组集合。66.(2)进行第一次扫描，第一次扫描的区域为线程负责的整个nvm元组堆，针对每一个nvm元组，若设置最后持久化位(lp)已被设置，则更新时间戳ts-commit；若删除位或者事务提交时间戳等于0，则将该nvm元组放入垃圾队列中。67.若nvm元组的事务提交时间戳≤时间戳ts-commit，则用该nvm元组更新主索引，否则将该nvm元组放入挂起列表pending-list中；68.(3)进行第二次扫描，第二次扫描的区域为挂起列表pending-list中的各nvm元组；此时，时间戳ts-commit是第一次扫描中被扫描区域的最大事务提交时间戳；针对每一个nvm元组，如果一个nvm元组的事务提交时间戳≤时间戳ts-commit，则用该nvm元组更新主索引；否则表明该nvm元组关联的事务在持久化时发生崩溃，通过将该nvm元组对应的元组头标记为空(tx-cts＝0)并通过nvm原子写操作将该nvm元组持久化到nvm中，从而使得该nvm元组被标记为已丢弃；同时，将该nvm元组放入垃圾队列中。69.(4)执行sfence写屏障指令，保证所有崩溃事务的nvm元组均被标记为已丢弃。当前第1页12当前第1页12