CN114631089A - 用于直接映射的持久存储器数据库的持久存储器文件仓库 - Google Patents
用于直接映射的持久存储器数据库的持久存储器文件仓库 Download PDFInfo
- Publication number
- CN114631089A CN114631089A CN202080073277.0A CN202080073277A CN114631089A CN 114631089 A CN114631089 A CN 114631089A CN 202080073277 A CN202080073277 A CN 202080073277A CN 114631089 A CN114631089 A CN 114631089A
- Authority
- CN
- China
- Prior art keywords
- block
- pmem
- database
- version
- database block
- 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.)
- Pending
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/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
-
- 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/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2329—Optimistic concurrency control using versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
- G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/12—Replacement control
- G06F12/121—Replacement control using replacement algorithms
- G06F12/123—Replacement control using replacement algorithms with age lists, e.g. queue, most recently used [MRU] list or least recently used [LRU] list
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
- G06F16/164—File meta data generation
-
- 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/23—Updating
-
- 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/25—Integrating or interfacing systems involving database management systems
-
- 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
- G06F16/284—Relational databases
-
- 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/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
-
- 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/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- 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/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/524—Deadlock detection or avoidance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/16—General purpose computing application
- G06F2212/163—Server or database system
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Human Computer Interaction (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本文中的技术将数据库块(DBB)存储在字节可寻址持久存储器(PMEM)中,并在没有死锁或等待的情况下防止撕裂。在实施例中,计算机托管DBMS。DBMS的读取器进程在没有锁定的情况下从PMEM中的元数据获得用于直接访问PMEM中的DBB的当前版本的第一存储器地址,所述当前版本是特定版本。并发地且在没有锁定的情况下:a)读取器进程读取PMEM中的DBB的特定版本,和b)DBMS的写入器进程在PMEM中的元数据中,将第一存储器地址替换为用于直接访问PMEM中的DBB的新版本的第二存储器地址。在实施例中,计算机在没有锁定的情况下进行:a)将DBB存储在PMEM中,b)将DBB的图像复制到易失性存储器中,或者读取DBB的图像,和c)检测DBB的图像是否被撕裂。
Description
技术领域
本发明涉及在字节可寻址持久存储器(PMEM)中存储数据库块。在没有死锁或等待的情况下防止撕裂的块。
背景技术
原子的(atomic)、一致的、隔离的、持久的(ACID)事务为可变数据提供数据完整性。由于数据在中央处理单元(CPU)中被改变,但是保持在诸如磁盘和/或非易失性存储器之类的其他设备上,因此持久性数据突变带来了设备集成问题。设备加速技术包括诸如借助磁盘块和数据库块的批量数据传送。典型的关系数据库管理系统(RDBMS)架构在作为持久性数据的基本单元的数据库块上。然而,数据库块具有如下的额外问题。
新兴的字节可寻址持久存储器(PMEM)准备好商业化,包括数据库。这种新型的非易失性存储装置的等待时间预计略慢于动态随机存取存储器(DRAM),但在同一数量级内。PMEM芯片的存储容量一般比DRAM芯片大一个数量级。
字节可寻址性使PMEM在操作上与块可寻址的其他类型的非易失性存储器不同。诸如闪存之类的成熟的固态驱动器(SSD)技术保证了包含至少半KB字节的数据页的批量数据原子性。然而,字节可寻址PMEM没有这样的保证。例如,写入器可以在PMEM中原位更新数据块的字节的子集,这就面向块的存储设备来说不可能的。从而,字节可寻址的PMEM可能面临就面向块的存储装置来说不会发生的数据完整性风险。例如,PMEM可能如下遭受撕裂的数据块。
并行性可以加速RDBMS,比如通过并发的读取器和/或写入器(比如在独立的CPU核心上)。然而,如下所述,并发性可能会危及字节可寻址PMEM的原子性。典型的CPU核心每个时钟周期可以处理不到10个字节。然而,典型的数据库块至少包含1KB。因此,即使是数据库块的一小部分的RDBMS处理对于一个读取器来说也可能要花费几个时钟周期,而这个读取器可能会偶然地在时间上与写入器的活动重叠。进行中的读取器可能在突然写入之前从数据库块中读取一些原始数据,并在写入之后或期间从数据库块中读取更多的非原始数据的数据。因此,读取器处理的是数据库块的上一个版本和下一个版本的错误融合,这是一个撕裂的数据库块。即使在没有CPU的情况下也可能发生撕裂的数据库块,比如在直接存储器访问(DMA)的情况下,当在进行中的读取器将数据库块从PMEM复制到DRAM的时候,发生突然的PMEM写入冲突时。
除非通过附加的行为来加以防止或补偿,否则可能发生撕裂的数据库块。典型的方法需要排他写入,使得写入器等待数据库块的排他使用。等待的写入器可能导致两个问题。首先,降低RDBMS吞吐量。例如,可能不存在关于读取器可能花费在数据库块的时间的上限。其次,可能出现死锁,比如当两个进行中的读取器决定同时写入彼此的数据库块时。典型的方法可以通过总是读取数据库块的副本来避免这些隐患。然而,数据库块复制降低了RDBMS吞吐量。
记载在本节中的方法是可以执行的方法,但未必是以前构思或执行过的方法。于是,除非另有说明,否则不应认为记载在本节中的任何方法仅仅由于包含在本节中而成为现有技术。
附图说明
附图中:
图1是描述在字节可寻址持久存储器(PMEM)中隔离同一数据库块的不同版本以减轻访问冲突的示例计算机的方框图;
图2是描述用于在字节可寻址持久存储器(PMEM)中隔离同一数据库块的不同版本以减轻访问冲突的示例计算机过程的流程图;
图3是描述可能作为读取PMEM中的数据库块的版本的一部分而发生的示例计算机活动的流程图;
图4是描述示例数据库块管理活动的流程图;
图5是描述示例根目录的方框图,所述根目录可以是PMEM中的FSDirect文件系统的目录树的顶部;
图6是描述包含PMEM中的数据或元数据的块的树的示例文件的方框图;
图7是描述通过在指针块中重新赋值指针,将旧的数据块替换为新的数据块的示例块更新的方框图;
图8是描述用于PMEM中的空闲块的组织的示例列表的方框图;
图9是描述内部将数据块排列成适应增长的专用区间的示例区域文件的方框图;
图10是描述基础设施软件的示例体系结构的方框图,所述基础设施软件包含为了安全性而被分离成用户空间和内核空间的模块和层;
图11是图解说明可在其上实现本发明的实施例的计算机系统的方框图;
图12是图解说明可用于控制计算系统的操作的基本软件系统的方框图。
具体实施方式
在下面的说明中,为了便于说明,陈述了众多的具体细节以便透彻地理解本发明。然而,显然可以在没有这些具体细节的情况下实践本发明。在其他情况下,以框图形式表示公知的结构和设备,以避免不必要地模糊本发明。
总体概述
本文中说明的是在本文中被称为FsDirect文件仓库的文件仓库,它是为在字节可寻址持久存储器(PMEM)上的数据库管理系统(DBMS)中使用而设计的。按照本文中的方法,写入器不必等待同一数据库块的正在进行的读取器,无论读取器使用该数据库块多长时间。FsDirect在数据库块的写入时通过分配来进行操作。当写入块时,FsDirect首先在文件仓库中分配新的块,然后将新的内容复制到新分配的块中。
然而,在调整PMEM中的元数据之前,新块不会在逻辑上替换旧块。在该元数据中,块地址的指针从寻址该块的先前版本被原子地重新赋值成寻址该块的新版本。这里,保持在PMEM中的指针的原子重新赋值意味着,即使字节可寻址PMEM不是面向块的并且缺少块原子性,只要指针本身可以在PMEM中以原子方式被重写,直接从PMEM中的元数据检索指针就总是获得该块的最新版本的PMEM地址。存储在指针中的PMEM地址的原子开关避免数据块被写入所撕裂,从而保证数据的完整性。在块的引用计数达到零之前,块的先前版本不会被释放。因此,PMEM可以存储同一个块的多个版本,即使保持的元数据总是只指向块的当前版本。由于进行中的读取器和突然的写入器可以同时使用数据块的独立的持久版本,因此块的先前版本的读取器将不会导致块的写入器等待。当先前版本不再需要时,它最终可以被删除。
FsDirect解决了与直接映射的PMEM数据库具体相关的撕裂块问题。本文中,直接映射的PMEM数据库是使数据文件完全驻留在包含在DBMS的地址空间中的PMEM的区域中的数据库。因此,DBMS可以以与好似数据文件被完全加载到动态随机存取存储器(DRAM)或多或少相似的方式使用数据文件,包括字节寻址,以便只访问数据块的一部分。
为了支持数据块的多个版本,FsDirect可以略微过度地提供PMEM存储空间,以便对于陈旧版本的某些长时间直接PMEM读取,容纳块的额外副本。
FsDirect加速DBMS操作。当DBMS在FsDirect文件仓库之上运行时,输入/输出(I/O)通过存储器复制和/或直接访问而不是通过操作系统(OS)调用来完成。从用户空间到操作系统内核的OS调用较缓慢。本文中提出了一种符合标准化直接访问(DAX)的接口。
FsDirect在存在软件故障和电源故障的情况下提供对文件的写入的原子性。写入原子性确保文件读取操作不会读取撕裂的(即部分写入的)块。
本文中讨论的是可避免的问题,比如撕裂块的出现,这可能是写入器与同一个块的读取器或另一个写入器的竞争的结果。现有技术使用面向块的I/O和/或时间上昂贵的协调来管理这种竞争,这可能需要锁获取,这是悲观的,并且在锁不可用时发生阻塞(即等待),这会降低DBMS吞吐量。锁可以是互斥(mutex)锁或信号量锁,当被诸如临界区之类的软件同步机制封装时,它们可能在某种程度上被隐藏(尽管仍然有效)。本文中的解决方案是乐观的、非阻塞的和无锁的(即,没有锁定)。在没有锁定、等待,也没有如下讨论的死锁的情况下发生非阻塞操作。
如上所述,PMEM可以存储包括指向PMEM中的块地址的指针的元数据。由于PMEM是字节可寻址的,并且由于PMEM和DRAM驻留在同一地址空间中,因此这样的指针可以从PMEM中的元数据复制到DRAM中。这样,数据库块可以被浅复制到DRAM中,而不需要实际复制数据库块的内容。因此,DRAM可以包含指向PMEM中的指针。
诸如缓冲区高速缓冲存储器之类的数据块管理器可以如下充分利用这样的指针灵活性。例如,缓冲区高速缓冲存储器可以包含直接和间接可用的PMEM数据块的混合体。一些PMEM数据块的一些版本的内容可以被复制和高速缓存在直接可用的缓冲区高速缓冲存储器的DRAM缓冲区中,使得读取器或写入器不需要访问PMEM。相同或其他PMEM数据块的其他版本是间接可用的,当缓冲区高速缓冲存储器仅包含用于字节寻址到PMEM中的指针而不是PMEM数据块的这些版本的内容的缓冲副本时。
PMEM中的数据库文件可以由具有PMEM块地址的读取器或写入器直接访问。PMEM地址可以从来自缓冲区高速缓冲存储器的PMEM元数据中获得。当DBMS需要查询数据时,它可以直接从PMEM读取数据。例如,表扫描可以通过复制PMEM块地址使缓冲区高速缓冲存储器浅复制PMEM块,并将这些PMEM地址提供给执行查询的读取器。这可以以两种方式增大DBMS吞吐量。首先,表扫描不会引起缓冲区高速缓冲存储器抖动,这会妨碍竞争可用高速缓存缓冲区的并发查询。其次,避免了大多数或所有高速缓冲存储器管理活动,因为读取器可以对经扫描的表的所有数据块使用未缓冲的PMEM字节寻址。
如上所述,指向相同PMEM数据块的相同指针可以同时从PMEM和缓冲区高速缓冲存储器获得。在实施例中,如本文中所述,从DRAM和缓冲区高速缓冲存储器获得PMEM指针比从PMEM中的元数据获得指针更快和/或更简单。
如本文中所解释的,由于当并发的元数据写入器重复地干扰元数据读取器时需要重新遍历元数据树的重试,为了可靠地获得数据块指针,读取器从PMEM中的元数据中获得存储在元数据PMEM块树深处的数据块指针的可能需要或多或少无限的最坏情况时间。在表扫描期间,从PMEM中的元数据树中获得指向逻辑上顺序的,但是可能物理上不相邻的多个数据块的指针序列的读取器可能更有可能与元数据写入器发生冲突。因此,读取器改为从缓冲区高速缓冲存储器获得已经可用的PMEM指针可以加速表扫描或其他查询。
当读取器向缓冲区高速缓冲存储器请求数据块指针时,可以向读取器返回指向已填充内容的DRAM缓存器的指针。否则,缓冲区高速缓冲存储器可以返回用于字节寻址PMEM中的数据块的PMEM指针。在任一情况下,读取器通常可以使用指针,而不关心指针是寻址DRAM还是PMEM。例如,通过使用缓冲区高速缓冲存储器来获得数据块指针,表扫描有时可能需要指向PMEM和DRAM中的块地址的混合,比如当经扫描的表已经被部分高速缓存时。
即使没有缓冲区高速缓冲存储器,FsDirect也允许一个进程在PMEM中写入一个块,而另一个进程在PMEM中读取同一个块的先前版本。这避免直接映射的PMEM数据库中的死锁。本文中提供了死锁问题的更多细节。
FsDirect提供数据库块版本,这是比各个表行的版本更粗的粒度。在实施例中,对于多个数据库查询,聚合来自数据库查询的行级读取的数据库缓冲区高速缓冲存储器只需要将块引用计数递增一次。在实施例中,FsDirect可以缩减涉及对版本化PMEM块的挑战的数据文件,而这些挑战对于DRAM中的多行版本来说并不存在。
在实施例中,计算机托管DBMS。DBMS的读取器进程在没有锁定的情况下从PMEM中的元数据获得用于直接访问PMEM中的数据库块的当前版本的第一存储器地址,所述当前版本是特定版本。并发地且在没有锁定的情况下:a)读取器进程读取PMEM中的数据库块的特定版本,和b)DBMS的写入器进程在PMEM中的元数据中,将第一存储器地址替换为用于直接访问PMEM中的数据库块的新版本的第二存储器地址。
在实施例中,计算机在没有锁定的情况下进行:a)将数据库块存储在字节可寻址PMEM中,b)将数据库块的图像复制到DRAM中,或者读取数据库块的图像,和c)检测数据库块的图像是否被撕裂。
1.0示例计算机
图1是描述实施例中的示例计算机100的方框图。计算机100在字节可寻址持久存储器(PMEM)120中隔离同一个数据库块的版本131-132以减轻访问冲突。计算机100可以是诸如刀片服务器之类的机架服务器、个人计算机、大型机、虚拟计算机或其他计算设备。
计算机100托管数据库管理系统(DBMS)110,DBMS 110可以是关系DBM S(RDBMS)或其他表格数据库、纵列数据库或列存储、诸如JavaScript对象表示法(JSON)或可扩展标记语言(XML)之类的文档数据库、诸如资源描述框架(RDF)三元组存储之类的元组存储、或者管理批量数据存储的其他存储中间件。
数据库块是DBMS 110的批量持久化的单元,DBMS 110可以管理许多数据库块,包括每个数据库块的一个或多个版本,比如同一数据库块的版本131-132的存储。DBMS 110可以管理一个或多个数据库,每个数据库包含它自己的未在数据库之间共享的一组数据库块。
DBMS 110使用字节可寻址PMEM 120作为数据持久性的非易失性存储装置。PMEM120可以通过存储器总线连接到计算机100的中央处理器(CPU),这不同于较旧形式的非易失性随机存取存储器(NVRAM),NVRAM改为连接到计算机100的主板底板,比如外围扩展总线。因此,PMEM 120可以是还可以包括动态RAM(DRAM)的计算机100的物理存储器的一部分。例如,计算机100的虚拟存储器(VM)中的一些或全部地址空间可以映射到PMEM 120和/或DRAM。
字节可寻址性意味着对于少量的数据,比如单个未对齐字节、机器字或其他小字节序列、和/或几百或几千字节的对齐存储页面,计算机100的CPU的指令集体系结构(ISA)的存储器指令,比如加载和存储指令可以参考并直接访问PMEM 120。直接访问可以包括如下所述将一行PMEM加载到硬件高速缓冲存储器中,与CPU在DRAM中访问数据的方式相似或相同。直接存储器存取(DMA)控制器可以以与任何存储器芯片或存储体或多或少相同的方式使用PMEM 120,比如用于块传送(BLT)。
然而,PMEM 120不是块设备,也不是外围设备或其他外部设备。PMEM 120可以在没有输入/输出(I/O)设备驱动器和没有I/O系统调用的情况下使用,这将比DMA慢一个数量级。PMEM 120适合于诸如直接访问(DAX)之类的地址接口标准。在诸如关于Intel的Optane之类的实施例中,PMEM 120基于三维(3D)NAND芯片。
在实施例中,数据库的所有数据库块存储在PMEM 120中,使得数据库既持久的,又完全存储驻留在单一存储层中,而不必复制数据。因此,可以比固态驱动器(SSD)快一个数量级,比机械磁盘快几个数量级地操作数据库。由于PMEM 120是非易失性的,因此DBMS 110可以单独将PMEM 120用于原子的、一致的、隔离的、持久的(ACID)事务,或者与暂存DRAM结合用于甚至更快的ACID事务。尽管为了加速,本文中后面提出了DRAM数据库高速缓冲存储器,不过,计算机100的CPU的普通操作可以将直接来自PMEM 120的内容包含在诸如L1或L2之类的片上CPU高速缓冲存储器中,从而绕过DRAM芯片。
操作中,DBMS 110访问作为物理和/或虚拟存储器的可寻址区域保持在PMEM 120中的诸如131-132之类的数据库块的版本。尽管计算机100是单个计算机,不过DBMS 110具有并发性,比如由诸如多个CPU、多核,超线程或诸如抢占之类的单处理器上下文切换之类的基础设施支持的多线程或多处理。例如,DBMS 110可以包含许多执行线程或操作系统(OS)进程,比如可以是线程或进程的数据访问进程150和160。
尽管PMEM 120可以按诸如机器字之类的细粒度提供原子性,不过,PMEM 120不需要保证诸如数据库块之类的数据聚合的一致性。读取器进程150可能需要许多时钟周期和/或CPU指令来完全读取和处理数据库块的当前版本131。尽管未图示,不过,写入器进程160可以更新同一数据库块的同一个当前版本131。如果进程150和160进行的这些数据访问重叠,则读取器进程150可能读取撕裂的数据库块,该撕裂的数据库块不连贯地包含数据库块的多个部分,所述多个部分的内容分别反映更新之前和之后,这可能在语法或语义上是灾难性的。
因此,DBMS 110应当能够将同一数据库块的读取和写入隔离开来,这由包含指向所有保持的数据库块的最新相应版本在PMEM 120中的块地址的指针的持久元数据170来推动。在实施例中,元数据170还指示数据库块的较旧版本在PMEM 120中的地址。在写入器进程160更新数据库块之前,元数据170已经指示数据库块的最新版本驻留在指向PMEM 120中的当前版本131的存储器地址141处。
如下所示,当修改数据库块时应发生元数据170的维护。写入器进程160可以通过创建并填充同一数据库块的新版本132来更新数据库块。即,PMEM 120的各个存储器地址141-142可以同时包含数据库块的各个版本131-132。另外,元数据170的指向数据库块的最新版本的指针应当被重新赋值,以指向存储新版本132的存储器地址142,这完成数据库块的更新。下面针对图2讨论用于这种更新的示例算法,包括在所示的时间T1-T2发生的处理的解释。
2.0示例数据块版本控制过程
图2是描述用于在字节可寻址PMEM 120中隔离同一数据库块的版本131-132以减轻访问冲突的示例过程的流程图。参考图1来讨论图2。
所有步骤202和204a-b都是在没有锁定的情况下发生的,因此不需要等待获取不可用的锁。步骤202在步骤204开始之前结束。步骤204a-b可以以任何相对顺序发生,包括完全或部分重叠。
步骤202发生在时间T1期间。在步骤202中,读取器进程150在没有等待的情况下,从PMEM 120中的元数据170获得用于直接访问PMEM 120中的数据库块的最新版本的存储器地址141,所述最新版本在时间T1是当前版本131。即,在步骤202,读取器进程150获得存储器地址141作为指向当前版本131的指针。例如,读取器进程150可以直接读取元数据170以获得存储器地址141。换句话说,读取器进程150准备读取数据库块的最新版本。
步骤S202在没有软件同步的情况下从PMEM 120中的元数据170检索指针。因此,步骤202不会阻塞或等待。同样地,步骤204a-b中的每一个都不需要软件同步并且不需要等待。由于同一数据块的版本131-132相互隔离,因此步骤204a-b不会相互干扰。
步骤204a可以在时间T2之前、期间或之后开始,并且可以在时间T2之前、期间或之后结束。步骤204a可能需要与读取器进程150读取并且可选地处理数据库块的当前版本131一样长的时间。在实施例中,处理当前版本131和完成步骤204a所需的时间可能或多或少是无限制的。
例如,读取器进程150可以读取和处理当前版本131的一些字节,然后等待I/O(IOWAIT),比如被不是物理读取当前版本131的一部分而是处理所读取的内容的一部分的其他网络或盘活动所需的I/O。因此,步骤204a可以在读取当前版本131的一部分和处理当前版本131的一部分之间反复交替。即使处理当前版本131可能包括IOWAIT,诸如同步之类的其他等待,和/或其他等待时间,当前版本131的部分或全部的物理读取也是不同步的和非阻塞的。
步骤204a-b不需要在时间上重叠,并且步骤204a-b中的任何一个可以在另一个之前开始和结束。然而,计算机100被配置成容许步骤204a-b的同时性。换句话说,计算机100如下所示适应进行中的读取器和突然介入的写入器之间的竞争。
这样的竞争是通过至少暂时存储由读取器和写入器分别使用的同一数据库块的多个版本131-132来适应的。因此,读取器和写入器或多或少彼此解耦,并且不会相互干扰。尽管读取器和写入器可能在时间上重叠,不过在如下所示的例子之间,各种读取和写入活动的重叠量和相对时间顺序可能不同。
从在时间T2的步骤204b之前的任何时间开始,比如:a)在步骤204a期间,b)在步骤202和204a之间,c)在时间t1的步骤202期间,或者d)在步骤202和时间t1之前,写入器进程160在PMEM 120中分配和填充同一数据库块的新版本132。在时间T2的步骤204b期间,写入器进程160在PMEM 120中的元数据170中,将存储器地址141替换为用于直接访问PMEM 120中的同一数据库块的新版本132的存储器地址142。在实施例中,PMEM 120保证步骤204b的指针重新赋值是原子的,如本文中后面所述。在步骤204b之后,元数据170指示存储器地址142指向数据库块的最新版本,即新版本132。
这样,数据库块被修改,并且新版本132替换版本131作为数据库块的最新版本。然而,版本131可以无限期地保留在PMEM 120中。版本131是否已无用过时取决于读取器进程150的情形和/或DBMS 110的语义。
至少,版本131应当在仍被读取时保持可用。取决于示例和实施例,版本131:a)如果读取器进程150是版本131的最后剩余读取器,则在步骤204a之后立即被丢弃,b)在所有多个读取器完成读取版本131之后被丢弃,c)当版本131的引用计数的调整指示不再有读取器时被丢弃,或者d)如后面所述在解除固定(unpinned)之后立即被丢弃。在实施例中,即使在版本131符合丢弃条件之后,也可以推迟丢弃版本131。在实施例中,版本131保持可用,直到PMEM 120出于任何目的需要回收为止,所述目的可能是也可能不是为了创建同一或不同数据库块的新版本。
例如,DBMS 110可以提供ACID事务以及可以提高DBMS 110和/或读取器进程150的吞吐量的各种级别的放松的隔离一致性,包括串行化读取、可重复读取以及提交和/或未提交的数据的读取。例如,读取器进程150可以容许脏读取、不可重复读取和/或幻读取。然而,读取器进程150的乐观和/或完全隔离的事务可能期望读取器进程150继续使用版本131,而不管新版本132的可用性。
PMEM 120本身不管理数据库块的版本。正如本文中后面所述,DBMS 110具有用于数据库块的版本管理的技术,包括数据库块的全生命周期,比如存储器管理。正如本文中后面所述,DBMS 110可以将数据库块的版本高速缓存在DRAM中,使得在一些情况下,执行客户端命令的读取器和写入器不需要直接访问PMEM 120。
3.0示例数据库块访问过程
图3是描述可能作为读取PMEM中的数据库块的版本131的一部分而发生的示例活动的流程图。参考图1-2来讨论图3。
在实施例中,读取器进程150通过使用以下的某种形式来读取PMEM 120中的数据库块的版本131:存储器映射I/O、对硬件的字节可寻址直接访问(DAX)和/或用户空间文件系统(FUSE)。在最低层,比如硬件层,DBMS 110进行如本文中这里和前面所述的PMEM 120中的版本131的字节寻址读取。例如,DBMS 110可以执行:a)直接将版本131的部分或全部内容从PMEM 120复制到CPU寄存器中的存储器加载指令,和/或b)直接将版本131的部分或全部内容从PMEM 120复制到DRAM中的存储器移动指令或块传送(BLT)指令。DRAM数据库块高速缓存在本文中后面介绍。
与一些方法不同,本文中的技术具有如何从PMEM 120读取数据库块的版本131的约束。DBMS 110不使用块设备驱动程序,也不使用操作系统(OS)的面向块的I/O系统调用。不管读取PMEM 120如何可选地被封装在诸如FUSE之类的附加软件中,PMEM 120的物理读取实际上都是由CPU的指令集体系结构(ISA)的字节可寻址存储器指令完成的。
步骤306a-c检测到撕裂的或陈旧的块被读取,如果被检测到,则这是可容许的、可恢复的、或者以其他方式可管理的,如果未被检测到,则这可能是灾难性的。存在各种实现方式,特别是因为元数据170中的状态指示符可以具有语义稍微不同的不同实现,如下所示。如本文中前面所述,每个数据库块可能在元数据170中具有它自己的元数据,比如指向最新版本的指针,比如存储器地址141。另外,在元数据170中,数据库块可以具有相应的状态指示符,该状态指示符可以是布尔标志或无符号整数版本计数器。在实施例中,版本计数器可以被存储为带符号的整数,其中符号具有如本文中后面讨论的附加语义。
不管状态指示符是如何实现的,它都是在步骤306a期间从元数据170中读取的,步骤306a可以是图2的步骤202的一部分。在未图示的实施例中,步骤306a可以包括判定步骤,该判定步骤检测到状态指示符指示数据库块没有准备好被读取。例如,负版本计数器可以指示版本131当前正被新版本132替换或者版本131当前正被直接更新。在所示实施例中,状态指示符可以在步骤306a期间从元数据170中复制出来,以供稍后的步骤,比如306c,进行最终检查。
步骤306b从PMEM 120读取版本131。例如,版本131可以被复制到DRAM中。然而,即便是看似简单且紧凑的活动,比如快速地将版本131复制到DRAM中,也可能或多或少会在时间上与对同一数据库块的同一或更新的版本的写入发生冲突。
因此,DRAM中的副本可能是撕裂的或陈旧的。完整性校验和将使撕裂变得明显。然而,完整性校验和需要对数据库块中的一些或所有字节进行顺序处理,这是缓慢的,特别是因为校验和需要计算两次:a)在最初写入版本131时(它不是更新),和b)在读取版本131之后(在中间更新的情况下)。因此,对于步骤306a-c不需要校验和,尽管数据库块可以具有用于其他目的的校验和。
步骤306c通过从元数据170中重新读取数据库块的状态指示符来检测撕裂的或陈旧的副本。如果重新读取的值与在步骤306a中读取的先前值匹配,则数据库块的DRAM副本不是撕裂的,并且目前还不是陈旧的。如果这些值不匹配,则数据库块是撕裂的或陈旧的。在各个实施例中,比如用以下方式可以将撕裂或陈旧彼此区分开来。
在一个例子中,状态指示符是带符号的整数版本计数器,并且写入器直接改变PMEM 120中的版本131,而不创建新版本132。紧接在改变版本131之前,写入器在元数据170中将整数的符号设定为负号。在改变版本131之后,写入器在元数据170中恢复正号。如果步骤306c中的读取器观察到负号,则DRAM副本是撕裂的,从而应重新读取数据库块,这包括重复所有的步骤306a-c和图2的步骤202。
创建新版本132写入的实施例可以或多或少保证读取同一数据库块的任何版本不会是撕裂的。在这种情况下,在步骤306c中观察到的值的任何不匹配都指示DRAM副本是陈旧的,这可能是可容许的或者可能是可恢复的,比如通过重复所有的步骤306a-c和图2的步骤202。
尽管未图示,不过两个写入可能冲突。本文中后面介绍的更多无锁技术都足够鲁棒,可以管理并发写入并避免撕裂的写入。本文中在上面和后面介绍的无锁技术足以提供各种基本启用保证,比如:a)无撕裂、b)检测撕裂、和/或c)检测陈旧性。因此,与现有技术相比,DBMS 110减少了等待时间和/或增加了完整性。数据完整性对于如本文中后面介绍的数据库块的DRAM高速缓存可能是重要的。
4.0示例块管理活动
图4是描述示例数据库块管理活动的流程图。参考图1来讨论图4。图4的步骤可以以各种顺序和/或组合发生。
读取器可以重复读取PMEM中的数据库块的同一版本。然而,易失性存储器可能比PMEM更快,这鼓励数据库块的相同或不同版本的本地副本。数据库块的只读副本可能需要较少的生命周期管理。由于各种原因,将数据库块复制到易失性存储器中可能是重要的。
步骤401可以将数据库块的任何版本从PMEM复制到易失性存储器,只要读取器具有PMEM中的特定版本的地址即可。如果读取器不具有该地址,那么在元数据170中只有最新版本的地址可用。
PMEM和DRAM每一个都可以同时包含数据库块的相同或不同的多个版本。PMEM或DRAM中的数据库块的相同版本可能具有多个读取器,如步骤402所示,所述多个读取器可能是并发的也可能不是并发的。
不同的读取器可同时读取PMEM或DRAM中的同一数据库块的不同相应版本,如步骤403所示。由于PMEM 120中的元数据170指示数据库块的最新版本在PMEM 120中的地址,因此只要PMEM 120中的特定版本的地址是已知的,通过查阅元数据170,该数据库块的特定版本就总是可以被检测为陈旧或不陈旧,如步骤404所示。
数据库块的版本管理和副本管理可以由DBMS 110的DRAM中的数据库块高速缓冲存储器的控制器集中和实施,这可以便利共享和增加吞吐量。步骤405将数据库块的特定版本或最新版本从PMEM复制到高速缓冲存储器。高速缓冲存储器元数据可以指示哪些数据库块的哪个或哪些版本被高速缓存。高速缓冲存储器可以接受用于从高速缓冲存储器检索数据库块的版本的查找关键字,并且如果该版本还没有被高速缓存,则将数据库块的该版本从PMEM复制到高速缓冲存储器。取决于实施例,高速缓冲存储器查找关键字可以是版本号、版本别名(比如最新的或先前的)和/或块版本的PMEM地址。在实施例中,高速缓冲存储器可以保留已经从PMEM中删除的版本。
步骤406-407是数据库块的新版本可以(步骤406)或不可以(步骤407)被高速缓存的替代方式。步骤406从块高速缓冲存储器中复制、在块高速缓冲存储器中分配和/或在块高速缓冲存储器中填充同一数据库块的新版本。例如,新版本可以是高速缓存或未被高速缓存的先前版本的克隆,或者可以从头开始用新生成的内容填充,比如当写入器创建数据库块的空白版本并将其存储在块高速缓冲存储器中时。无论新版本是否(例如尚未)存储在PMEM中,块高速缓存中的新版本都可以被具有用于块高速缓冲存储器的新版本的查找关键字的任何进程读取,在该新版本被存储在PMEM 120中并由元数据170寻址以前,所述任何进程可能仅仅是创建该新版本的同一进程。换句话说,迄今为止仅仅被高速缓存和/或保持但是没有在元数据170中寻址的新版本,可能具有降低的其他进程的可见性或者其他进程不可见。
步骤407可以是跳过步骤406的结果。步骤407是状态而不是活动。在将新版本存储在PMEM 120中,并在PMEM 120中的元数据170中,将数据库块的先前PMEM地址替换为新版本的PMEM地址之后,在步骤407,块高速缓冲存储器仍然可以包含数据库块的先前版本,但不包含同一数据库块的新版本。例如,新版本可能绕过了高速缓冲存储器。因此,块高速缓冲存储器可能对于该数据库块来说是陈旧的。本文中后面介绍了防止、检测和/或从陈旧块高速缓冲存储器恢复的方法。
块高速缓冲存储器可以具有逐出策略,比如最近最少使用(LRU)或诸如本文中后面介绍的之类的变体。作为广义的组成部分,在一些情况下,逐出策略可能不是最优的。为了无限期地防止数据库块的特定版本的逐出,该特定版本可以被固定在块高速缓冲存储器中。在步骤408,特定版本可以由在块高速缓冲存储器中加载或创建该特定版本的同一或不同读取器或写入器进程进行固定。
5.0示例实施例
以下是示例性实施例,每个实施例可以是图1的计算机100的实现。这些实施例可以包括同时考虑到便利性或最优性的基于开发或操作场景的技术选择。对于上面提出的实施例来说,为以下实施例提出的特征可能是可选的或不必要的。
在实施例中,诸如机架服务器或智能电话之类的计算机主机托管包括如本文中所讨论的FsDirect的数据库管理系统(DBMS)。在实施例中,FsDirect是为在计算机的持久存储器(PMEM)上操作数据库而设计的单数据库用户级文件系统。除了文件仓库的创建和配置外,FsDirect的外部接口类似于本地文件系统。例如在Linux上,FsDirect支持以下:
·目录
·通常的Linux文件路径
·通常的文件系统命令,比如ls、cd等
·使用本地操作系统(OS)cp命令来往于FsDirect文件仓库复制文件
FsDirect文件仓库的创建不同于创建典型的文件系统。虽然典型的文件系统使用原始存储装置作为其后备仓库,但是FsDirect是从诸如Linux上的大型ext4文件之类的本地OS文件创建的。在Linux上,FsDirect后备仓库文件应当在以直接访问(DAX)模式挂载的ext4或XFS文件系统中,或者是在本地DAX设备中,以便更快和直接地访问PMEM。
在实施例中,为了使DBMS能够直接访问PMEM,FsDirect文件仓库不应被多个数据库共享。在实施例中,应当为DBMS的每个数据库创建至少一个FsDirect文件仓库。这种限制的原因是为了隔离损坏。通过为每个数据库限制一个FsDirect文件仓库,由跟随迷失指针的进程引起的一个数据库中的错误将不会破坏其他数据库。
在实施例中,FsDirect文件仓库是通过以非挂载模式启动DBMS服务器并发布结构化查询语言(SQL)命令来创建的,该SQL命令为文件仓库提供根挂载点和到ext4后备文件的路径,如本文中后面所述。
FsDirect文件仓库提供超出本地文件系统的本地直接访问(DAX)模式的以下益处。FsDirect保证了写入数据库数据的I/O原子性。换句话说,FsDirect避免了撕裂的写入。在以DAX模式挂载的本地文件系统中,撕裂的写入是可能的。本文中的DBMS需要底层文件系统来避免撕裂的写入。FsDirect使用存储器复制(memcpy)来进行I/O,避免了对文件或设备IO的应用程序接口(API)的昂贵的操作系统调用。
FsDirect使DBMS能够对于查询直接从PMEM中读取,而不论是否首先将数据复制到DRAM缓冲区高速缓冲存储器中。对数据库来说直接从PMEM中读取有三个优点:
·直接读取避免在数据库缓冲区高速缓冲存储器中复制本地数据,因为该数据已经在(即持久)存储器中。该好处节省了存储器。
·直接读取避免I/O。FsDirect能够直接从PMEM读取的原因是允许一个进程写入一个块,而另一个进程同时读取PMEM上的同一个块的先前版本。这避免了数据库死锁的风险。
·直接读取使关系DBMS(RDBMS)读取不到整个数据块。例如,直接读取可以访问作为更大的(例如8KB)块内的字节的单个表行。
FsDirect引入新的范例,以通过使用PMEM作为底层存储介质创建、管理和使用数据库文件来存储和检索数据。FsDirect提供以下特征。
·文件的分层目录树。
·从多个目录条目到同一文件的硬链接。
·通过调整底层EXT4文件的大小,文件系统可根据需要增长和缩减。
·支持通过诸如ksfd之类的现有数据库文件访问API来访问的所有Oracle文件类型。
·文件块的原子写入。
·在没有锁定的情况下经由memcpy从PMEM读取。
·支持2K、4K、8K、16K和32K的逻辑块大小。
·单个FsDirect文件系统中的所有文件具有相同的物理块大小。
·支持各个物理块上的应用引用保持。
·允许获得指向PMEM中物理块的指针以便直接访问(暗示引用保持)。
·针对Oracle文件I/O语义优化。
·维护Oracle文件类型信息。
·可以使用允许DAX的PMEM卷。
·使用户空间文件系统(FUSE)能够访问诸如DUL和DBverify之类的实用程序。FUSE协议实现为现有实用程序提供了通过OS访问数据库文件的能力。
·无配置许可。OS实现对底层PMEM文件的许可。
·文件系统内没有冗余。假定DataGuard用于高可用性。
·只有一个数据库实例可以访问给定的直接FS文件仓库。
·一个数据库实例可以挂载几个FsDirect文件仓库。
5.1示例数据库服务器中的示例缓冲区高速缓冲存储器
DBMS具有执行客户端请求的执行的内部进程或线程。每个这样的客户端进程(也称客户端)可以是数据库块的读取器或写入器。由于DRAM比PMEM快,因此客户端通过缓冲区高速缓冲存储器读取和修改数据库块以便加速。DRAM缓冲区高速缓冲存储器中的缓冲区可以表示所述块的最新版本,或者所述块的一致读取(过去某个时间点的快照)版本。
客户端调用缓冲区高速缓冲存储器应用程序接口(API)来固定数据库块。一旦包含该块的内容的缓冲区被固定,客户端就使用缓冲区的虚拟地址直接访问该块的内容。取决于缓冲区的类型,虚拟地址可以指向DRAM或PMEM中的区域。例如,代替缓冲区作为高速缓冲存储器条目,条目可以是指向DRAM或PMEM中的缓冲区/块的所谓头部。即,缓冲区高速缓冲存储器可以具有间接性。可以存在具有对块的不同版本的不同虚拟地址引用的同一数据库地址的多个缓冲区,并且所述多个缓冲区可以在缓冲区高速缓冲存储器之上的各个逻辑层之间共享。
在实施例中,缓冲区高速缓冲存储器存储各个块的版本的相应缓冲区头部。如果块的对应版本驻留在PMEM中,则每个头部可以包含PMEM地址。如果块的对应版本驻留在DRAM中,则每个头部可以包含DRAM地址。因此,缓冲区头部可以具有指向同一个块的同一版本的各个副本的一个或两个指针。在相关专利申请15/693,273中介绍了用于创建和使用缓冲区头部,使用它们的指针访问PMEM或DRAM中的块内容,以及在PMEM和DRAM之间复制内容的技术,该专利申请将这样的指针称为映射。
客户端可以将缓冲区固定任意的时间量,这最终可能取决于数据库客户端活动。可能没有可靠的机制来强制客户端解除对缓冲区的固定,或者使对该缓冲区的任何虚拟地址引用(即悬挂指针)无效。在任何情况下,当写入器在PMEM中突然创建缓冲块的新版本时,PMEM的指针树(本文中在后面所述)被更新以指向该新版本,但是缓冲区高速缓冲存储器不需要被更新以指向该新版本。
相反,缓冲区高速缓冲存储器可以继续引用DRAM中的陈旧版本。只有对于新的读取器,缓冲区高速缓冲存储器才会重新访问PMEM指针树以发现块的新版本,在这种情况下,缓冲区高速缓冲存储器还可以将新版本复制到缓冲区高速缓冲存储器中。在这种情况下,在缓冲区高速缓冲存储器中可以同时存在同一数据库块的多个版本。
在实施例中,缓冲区高速缓冲存储器引用计数高速缓存块的读取器。缓冲区高速缓冲存储器的策略比如按照最近最少使用(LRU),逐出未被引用(即零计数)的块。在实施例中,高速缓冲存储器策略在未被引用的当前块之前逐出未被引用的陈旧(即旧版本)块。
如本文中前面所述,缓冲区高速缓冲存储器可以保留数据库块的版本的内容和/或PMEM地址。在实施例中,即使在数据库块的版本从缓冲区高速缓冲存储器中被逐出之后,缓冲区高速缓冲存储器仍然保留该版本的PMEM地址。这样,数据库块的版本可以在逐出之前被高速缓存为深副本,而在逐出之后被高速缓存为浅副本。
例如,最近未被引用的陈旧块在最近较少未被引用的当前块之前被逐出。在实施例中,即使写入器不打算将新版本放入缓冲区高速缓冲存储器,并且即使旧版本不在缓冲区高速缓冲存储器中,写入器也通知缓冲区高速缓冲存储器。因此,在这样的实施例中,即使当如本文中前面所述,PMEM中的块的新版本绕过缓冲区高速缓冲存储器时,缓冲区高速缓冲存储器也可包含始终跟踪高速缓存的块是当前的还是陈旧的元数据。
在另一个实施例中,缓冲区高速缓冲存储器元数据本身可能变得陈旧,使得块的高速缓存版本只有在缓存了更新的版本时才会被高速缓冲存储器元数据指示为是陈旧的,而当更新的版本绕过高速缓冲存储器时则不会被高速缓冲存储器元数据指示为是陈旧的。例如,高速缓存策略可以通过首先逐出已知的陈旧版本,然后逐出未知状态的版本,最后逐出当前版本来划分未被引用块的逐出优先顺序。在实施例中,FsDirect通知缓冲区高速缓冲存储器存在过多的具有引用的陈旧块,这可能有耗尽PMEM空间的风险。因此,缓冲区高速缓冲存储器可以通过将最近最少使用的缓冲区从高速缓冲存储器中逐出来主动放弃旧的引用。
DBMS使用确保读取器永不阻塞写入器的一致读取事务模型。当写入器在它想要修改的缓冲区上遇到读取固定时,它通过将该缓冲区的内容复制到DRAM中的新的缓冲区来克隆该缓冲区,并修改新创建的克隆。新的缓冲区可以成为数据库块的最新版本,并且克隆操作中的源(即先前的)缓冲区被标记为读取器继续无限期地固定的快照副本。一旦写入器更新了DRAM中的数据库块的最新版本,DBMS可能需要将该版本写入PMEM。例如,出于检查点的目的,数据库可以持久地写入改变的块。
这在直接映射字节可寻址PMEM的情况下会带来问题。只要存在对于给定数据库块的读取器(通过其虚拟地址直接访问给定的PMEM字节范围),写入器就不能修改该块的内容。允许客户端通过映射的虚拟地址直接引用PMEM的文件系统实现应当:(a)维护给定文件块的多个版本,和(b)跟踪对于给定文件块是否存在未完成的直接映射引用。
写入器修改直接映射的块的内容的不是问题,因为该改变可以在该块的DRAM克隆中完成。问题可能在于检查点不能将块的新版本写入PMEM,因为一些读取器正在PMEM上直接读取该块。这就是为什么FsDirect中的版本控制有用的一个原因。数据库检查点是其间数据库将改变的块从DRAM写入持久存储装置,以确保这些改变是持久的,并且如果DBMS崩溃则不需要恢复的机制。
DBMS经由加载/存储和/或memcpy向通过FsDirect暴露的文件写入/读取数据。与在由数据库客户端拥有的DRAM缓冲区和存储子系统(比如旋转磁盘的存储子系统)之间复制数据的其他存储方案不同,FsDirect使PMEM芯片上的存储装置能够从FsDirect拥有的存储器直接访问,并映射到数据库实例的虚拟地址空间中。
本文中,数据块可以是数据库块。写入时的分配“重定位”数据块的地址。对于给定文件和其中的数据块,PMEM内的物理存储器地址被映射到进程的虚拟地址空间中。利用锚定到本文中后面介绍的索引节点(inode)的指针块树,文件的元数据维护指向包含文件的各个部分的叶块的指针。
即使块在PMEM中可能具有多个版本,文件的元数据也可以指向最新(更新的)版本或先前(陈旧的)版本。文件永远不会指向两个版本,因为文件元数据只容纳一个版本指针。在任何情况下,inode和块之间的指针作为用于字节寻址的相对偏移量存储在PMEM中。
在一个实施例中,每个客户端进程存储器将同一PMEM地址映射到同一虚拟地址,使得对于所有客户端进程,对于该PMEM地址只有一个相同的虚拟地址。PMEM地址被存储为引用PMEM块和被引用PMEM块之间的相对字节偏移量,并且这样的相对地址可以在不改变块之间的相对字节距离的情况下,适合于多个客户端进程的相同虚拟地址映射。这种块间相对寻址是自相对寻址。
在另一个实施例中,每个客户端进程可以将同一PMEM地址存储器映射到相应的不同的虚拟地址。例如,两个客户端进程可以具有映射到同一PMEM地址的两个不同的相应虚拟地址。在不改变块之间的相对字节距离的情况下,自相对地址可以适用于在不同虚拟基地址的相似虚拟地址映射。
由于相对地址取决于哪两个块是相关的,因此指向同一个第三PMEM块的两个不同的PMEM块可以包含指向所述同一第三个块的两个不同的相对地址。因此,以如在本文中后面所述的在块的每一个读取器处理时发生一次的指针树间接为代价,FsDirect提供版本化并且可重定位的PMEM寻址。因此,不同的客户端进程可以或多或少相互独立地操作,这减少了同步,从而减少了死锁并提高了并发性和吞吐量。
文件由可能非连续的PMEM块组成。因此,不管数据库块是在DRAM中还是在PMEM中,指针算术只被保证在块内有效,而不保证跨越多个块有效。例如,当表行具有固定大小时,行迭代可以通过诸如增量之类的指针算术在块内发生。当行迭代最终耗尽一个块并需要访问下一个块时,行指针应该基于下一个块的地址被重置(即,而不是递增)。
当块的新版本被存储在PMEM中时,它替换指针树中的旧的叶块,如本文中后面所述。因此,inode或指针块必须将其指针从块的旧版本重新赋值到块的新版本。指针被重新赋予新的偏移值,该偏移值是从指针块到叶块的新版本的字节距离。
偏移量(即,相对寻址)的优点是与存储器地址相比,偏移量可能需要较少的空间。这种较小的指针增加了PMEM可以原子地写入指针的可能性,这可能是FsDirect所需要的。例如,非原子指针写入可能使PMEM指针本身在读取器看来是撕裂的。
本文中后面讨论的是告知读取器发生了冲突(即,同时的写入正在进行中)的标志。读取器使用该标志来检测PMEM数据库块的撕裂DRAM副本。读取器读取PMEM标志,将数据(即,快照/图像)复制到读取器的DRAM缓冲区中,并再次读取标志,以确保它没有被突然的写入器翻转。数据库块的图像是数据库块的内容的快照或观察。图像有可能被损坏(即,撕裂),因为读取数据库块以获得图像的活动可能受到对数据库块的同时写入的干扰。如果检测到翻转的标志,则DRAM副本是撕裂的(即,损坏的),在这种情况下,读取器应当重复读取进程,包括再次复制数据。这确保块指针指向一致的数据,不论是旧数据还是新数据。
DBMS不会因为读取完成而删除数据块。读取器只是读取(将数据从PMEM复制到它自己的DRAM)并且继续处理,而不会认识到它具有已经或尚未变得陈旧的数据,从而当然不会影响任何关于删除旧数据块的决定。例如,这样的缓冲读取不会影响关于PMEM块的读取计数。当在缓冲区高速缓冲存储器或PMEM中被固定时,读取器可以无限期地或者在读取器想要最新版本以前直接寻址数据库块,而不需要指针重新赋值。对于同一个被固定的块版本的两个并发读取器,一个读取器可以切换到最新版本,而另一个读取器继续使用被固定的陈旧版本。
因此,DBMS在以下方面实现了或多或少的完全灵活性:a)对于同一个块保持多少个陈旧的版本,和b)是否将块版本保持在缓冲区高速缓冲存储器中、PMEM中和/或DRAM中的其他地方,比如一个进程的DRAM中。因此,DBMS或客户端进程可以在读取块时自由地决定是否进行复制。即,DBMS不强制读取器进行复制。如果读取器不进行复制,则读取器可以改为在缓冲区高速缓冲存储器中或者在PMEM中固定当前版本,并且即使在出现新版本之后继续直接使用所固定的版本。因此,被固定的版本:a)保证在最初被固定时是最新的版本,b)保证在继续被固定时是直接可寻址的,但是c)不保证在被固定时仍然是最新的版本。按照关于同一数据库块的该一致性模型,进行中的读取器和突然的写入器可以不受干扰地同时操作。从而,保证了数据库块的数据完整性。
读取器遵循无锁的代码路径,从不需要锁定数据库块,其中锁定和固定是不同的动作。锁定是排他的,而固定是包容的(即共享的)。读取器读取可用数据。数据的陈旧性对于底层的读取机制来说有些不重要。写入器独立地将数据更新为新版本,而读取器可能最终会使用该新版本,也可能不会使用该新版本,但是不存在维护的读取器的计数。因此,FsDirect避免了几个性能瓶颈:
1.没有读取器计数。
2.没有锁,比如使读取器和写入器串行化或者保护上面的(1)中的计数所需的锁。
3.写入器不等待进行中的读取器。
4.突然的写入不中断进行中的读取器。
5.在读取的关键路径中不会发生陈旧版本的回收。回收可以改为是自主的(即,后台和/或被推迟)。在没有压实的意义上,回收不是垃圾收集。
6.数据库块不会被撕裂。
取决于给定块是否是文件的现有块,在FsDirect块上支持两种新类型的操作。这些操作导致文件仓库块的虚拟地址(即,指针)对FsDirect客户端(即,DBMS中的读取器和写入器)可用,从而允许客户端直接读取或修改该块的内容。FsDirect数据库块操作包括如下工作的检索(retrieve)、借用(borrow)、放弃(forfeit)、返回(return)和采用(adopt)。
RetrieveRef操作允许FsDirect客户端获得先前成功写入的文件的块的虚拟地址。另一方面,块的借用是对于空闲的文件仓库块所允许的操作。一旦文件仓库块的虚拟地址对FsDirect客户端可用,该块的所有权也被转移到客户端。FsDirect将不能重用持有或借用的块的内容,直到该块的所有权经由ForfeitRef、Return或Adopt操作被转移回FsDirect为止。
RetrieveRef和ForfeitRef操作直接引用分配的文件块,而Adopt操作除了将该块的所有权授予FsDirect之外,还使该块被并入现有文件中。在完成对于借用块的Adopt操作时,所采用的块替换该文件块的先前版本。借用空闲文件仓库块,然后采用该块以将其回注在语义上与文件的现有块的重写相同。
5.2示例文件系统
FsDirect不对读取器计数。相反,读取器使用一个或多个级别的指针间接,并最终通过将内容从PMEM复制到属于读取器的DRAM来读取数据。在实施例中,每个数据库块具有包括块版本号的块头部。如果块版本号从自PMEM的数据复制之前,到读取器完成对块的处理之后一直保持不变,则读取器对读取(从PMEM复制到DRAM)的数据感到满意。如果块版本号在读取期间改变,则读取器进行另一尝试,包括所有的指针间接。
图5是描述实施例中的示例根目录500的方框图。根目录500可以是图1中的PMEM120中的FSDIRECT文件系统的目录树的顶部。在实施例中,根目录500是元数据170的一部分。
由于FsDirect实现文件系统,因此FsDirect中的每个文件或目录由分配给该文件的inode结构来描述。inode用于管理目录中的各个文件或目录条目所消耗的空间。FsDirect区间中的物理块从包含FsDirect文件系统的所有inode的单片Inode文件的块0(零)开始。inode号是该文件的索引。根目录500是FsDirect文件系统内的用户可见目录和文件层次结构的根,并且也由inode表示。
目录是只包含文件名和inode号而不包含数据库数据的文件。在实施例中,目录条目没有排序,因此文件创建需要扫描整个目录。这应当是可接受的,因为文件创建应当相对稀少,并且目录总是驻留在PMEM中。在实施例中,目录条目总是64字节,并且包含以下内容。
·描述对应文件的inode的inode号(如果该条目是空闲的,则为0)。
·目录条目的文件名。该名称不是以空字符串结尾的,而是填充以被清除(清零)的拖尾字节。
目录块仅仅是目录条目的数组。块根据需要被追加到目录中。如果删除的条目可用,则重新使用它们。目录中的前2个条目是具有通常的POSIX含义的“.”和“..”。
当创建FsDirect文件系统时,它包含inode文件和空的根目录。inode0留给inode文件本身,而inode 1留给根目录。因此,物理块0总是包含其中具有inode 0和1的inode文件的块0。根目录是空的,从而它只包含“.”和“..”的条目。它们都是根目录本身的条目,从而它们的inode号为1。由于两个文件最初都比块小,因此由inode指向的根块是数据块本身,并且指针树深度为0。最初,所有其他物理块都在本文中后面说明的空闲列表上。
图6是描述实施例中的示例文件600的方框图。文件600包含图1的PMEM 120中的数据或元数据的块的树。
大于一个块的每个文件的文件根是指针块。在实施例中,指针块和/或inode块是元数据170的一部分。
指针块只包含指向物理块(其他指针块或数据块)的自相对PMEM指针的数组。文件的指针块形成树,叶指针块指向包含文件数据的块。每一级处的最后一个指针块可以具有用于在下一级不存在的块的一些空指针。如果文件变得太大以致根指针块填满,则将新的块分配给新的根指针块,其第一个指针是指向旧的根指针块的指针。换句话说,指针块树在根处生长。深度为0意味着只有一个数据块,并且在inode中的根指针指向它。深度为1意味着存在指向文件中的所有数据块的单个指针块。缩减文件不会减少其深度。注意,指针块是使用PMEM事务就地更新的,而不是进行整个块的异地写入,然后进行指针切换来更新的。图6表示了指针树深度为2的文件的各个块是如何从文件的inode导航到的。
与磁盘存储不同,由于直接访问(DAX)感知实现的充分利用,数据库数据存在于可寻址存储器中。于是,FsDirect支持请求PMEM中的文件块的地址,它原子地递增对所指向的物理块的引用计数,并将其地址存储在调用者的指针中。重要的是将PMEM的引用计数与不会发生的读取器的计数区分开。例如,DBMS的缓冲区高速缓冲存储器中的块的副本的多个读取器仅被计数为对PMEM中的原始块的单次引用。因此,至少就PMEM引用追踪来说,缓冲区高速缓冲存储器本身可以起客户端或调用者作用。
当使用指针完成调用者(即,缓冲区高速缓冲存储器)时,需要另一个调用来递减PMEM引用计数。具有非零引用计数的物理块不能通过从当前文件系统到另一个文件系统的文件系统缩减(在PMEM中的多租户的情况下,未图示)而贡献出来,由于硬件问题而被标记为坏的,或者被重新用于其他块。引用计数不会阻止文件块由于写入请求、缩减或硬件问题而被重定位到不同的物理块。注意,写入请求预计经由DRAM缓冲区被发送到FsDirect,DRAM缓冲区通过使用PMEM中的暂存区域被复制到PMEM,并且块指针以事务方式被更新,从而释放原始文件块。
缓冲区高速缓冲存储器可以长时间保持对一些PMEM块的引用,比如在如本文中前面所述的缓冲区头部中。预计FsDirect将保留这样的块的PMEM地址。例如,频繁读取的块可以由缓冲区高速缓冲存储器中的缓冲区指向。该引用将持续到块老化退出高速缓冲存储器或者从高速缓冲存储器中被逐出。对于这样的引用,客户端进程可以提供释放请求回调,比如当文件被客户端打开时。当物理块已经移动并且不再与用于获取其地址的文件块关联时,利用文件号和文件块号来调用该回调。回调是引用应当尽早被释放的暗示。
当所引用的文件块被写入时,现有的物理块移动到本文中后面说明的空闲列表的末尾。只要存在对块的引用,被引用的物理块就永远不会被分配使用。注意保护空闲列表不会变为空,因为这样的情况将导致停滞。这可能导致所需的预留空间,该预留空间可以通过FsDirect配置设定来控制。
写入分两步进行。正常的块写入找到正确大小的空闲块,对其进行保持,将数据复制到其中,并且当释放该保持时,在指针块中用新版本原子地指针切换文件块的旧版本。FsDirect允许将其分解为对文件系统的两个调用,使得可以在知道其块号之前构建新版本。第一个调用获得对空闲块的引用。第二个调用用特定的文件块切换该空闲块并释放所述引用。这对于在PMEM中直接生成重做(redo),然后决定在记录器进行写入时块在文件中的位置,是有用的。
读取块周围的并发性是如下实现的。FsDirect具有无锁读取。试图读取块的调用者将使用该块的化身(即版本)号,并确保版本号与调用者在读取完成之前看到的版本号码保持相同。同一个块的任何并发写入器将否定该块版本的化身号,并恢复到正递增版本以指示正在进行的或已提交的写入。同样地,客户端进程预计不会部分地更新块,于是不需要使试图更新给定数据块的执行线程串行化。然而,指针块不是这样的,例如在目录指针块的情况下。如果正在创建两个文件,则可能同时添加/更新两个ionde,并且需要串行化锁。这样的更新是很少的,并且创建inode的串行化的成本是可接受的。
5.3示例块替换
图7是描述实施例中的示例块更新700的方框图。在操作中,通过对指南针块中的指针重新赋值,旧数据块可以被新数据块替换。图7的所有指针块和数据块可以驻留在图1的PMEM 120中。
空闲PMEM块驻留在空闲块池(或列表)中,在数据要被写入任何文件块时使用。这些块的可用性在下面讨论。当写入器试图写入文件块时,写入器如同读取器所做的那样读取目标块的相同“块版本号”(值N),并将负值(-N)写入可用的空闲块的头部中,这改变了空闲池中所选择的块的块版本。然后写入器继续用新数据更新空闲块(将数据复制到块中),原子地更新指向数据块的inode指针,接着用下一个正整数值(n+1)更新新数据块头部,作为其块版本号,如图所示。
这具有更新文件块的效果,从而在写入完成之后到达的任何新的读取器将看到新的块。由于PMEM 8字节指针更新是原子的,因此任何读取器将看到旧块(陈旧数据)或新块(新鲜数据),并且决不会在PMEM中看到撕裂的块。数据块永远不需要被删除。该块是持久存储器,并且连同其所有内容一起继续可用。因此,没有真正被释放或删除的存储器。旧数据块被简单地送回到空闲池以供重新使用,但是其数据可以保持完整,即使它明显是陈旧的。如果读取器在写入器之前开始,则读取器使用陈旧数据是完全可接受的。这是因为,对于触及陈旧数据的读取器,这样的触及(即间接解引用,又称指针追逐)应当在写入器交换inode中的指针之前发生。
此外,FsDirect允许读取器高速缓存,从而想要多久就多久地保留指向任何PMEM块(或其地址)的指针,并继续访问数据,即使它变得陈旧并且文件块被写入器更新。特殊请求将数据块标记为不可重用。写入器始终跟随并交换指针,并将旧块放入空闲池中。空闲块池用于提供供写入器消耗的块,但是在块被标记为不可重用的情况下,PMEM块及其数据(如果该块在空闲池中,则其数据是陈旧的)保持原样。
例如,Oracle DBMS保证每个读取器都知道自己在做什么,并且能够自己应对数据的陈旧性。Oracle DBMS还保证决不会存在将同时写入/更新数据库文件中的给定数据块,从而导致竞争条件和/或数据损坏的风险的不止一个写入器。
5.4示例空闲列表
图8是描述实施例中的用于空闲块的组织的示例列表800的方框图。包括所示列表1-N的列表800组织了图1的PMEM 120的空闲块。
跨越多个空闲列表1-N来组织FsDirect中的所有空闲块,以允许最佳的并发性。每个列表由它自己的锁保护。目的是避免对数据库中的不相关文件和/或数据块的并发写入对单个空闲列表锁的争用。
经由mkfs接口的文件系统创建将启动将可用存储器转换为如图所示,组织为空闲块列表800的物理区间中的空闲块和块状况的组织。该过程可能耗时,因此实例中的后台线程/进程将被分派任务以完成该任务,而mkfs接口立即返回。这使格式标记器在已经从可用物理块区间格式化的内容上指示高水位标记。当后台线程将存储器格式化为具有关联的块头部的FsDirect块,并将其附加到上述空闲列表800时,识别格式化的FsDirect大小的标记器前进。这种前进是以可编程的增量完成的。因此,mkfs具有两个步骤:产生文件系统和生长文件系统。任何需要格式化块可用而找不到可用的格式化块的后续数据库操作将停滞,直到后台完成一批块的格式化,并用信号通知试图创建或写入文件的停滞进程为止。
这里是关于空闲列表操作的一些场景。对于将引用该组织的各种用例有多种考虑。分配、替换和删除需要特定的细微差别。从文件操作的角度看,这三种场景定义如下。
分配:分配可以在对稀疏文件的写入期间发生。除了数据块之外,这还可以包括指针块的分配。这种场景与必须将文件扩展到比其当前分配更大的大小没有不同。
删除:当文件被全部删除时,发生一种形式的删除。在这种情况下,可以有两个选项:a)文件系统创建另一个空闲块列表,并将新的列表附加到多个列表中的该列表,或者b)文件系统工作以最终将新近可用的空闲块扩散到现有的空闲列表。任何其他的删除通常发生在截断期间。在这种情况下,类似的方法应该也会奏效。如上所述,很少观察到单个块被释放,在这种情况下,它可以被安全地添加到任何现有的空闲列表中。它包含的根结构和列表头部可以驻留在元数据170中。
替换:如上所述,写入将需要在实现写入的地方有空闲块可用,并且当提交到来的写入时,现有块被认为是空闲的。不管释放的块是否被引用,它都可以被添加到空闲列表中。这种块的状态最好被描述为即将被释放,因为在这种情况下的预期是新的写入将导致调用回调,以确保释放对旧数据块的保持。
再平衡:列表800可能随着时间的推移而变得歪斜(即,长度不平衡),使它们协调一致将需要后台线程来使它们恢复平衡。当需要时,将建议与上述完全相同的后台进程重新平衡列表800。启动和决定空闲块在可用列表之间的最终分布的智能可以容易地驻留在该后台内,并且通过定期地进行内部检查可以触发该任务。
5.5示例配置
图9是描述实施例中的示例区域文件900的方框图。区域文件900可以是本地文件,并且在内部将数据块排列成适应增长的专用区间。除了没有物理数据块的未使用空间区间以外,区域文件900的所有所示区间都包含物理数据块。即,未使用的空间区间是虚拟的。区域文件900,除所示的未使用的空间区间之外的它的所有区间,以及它们的所有数据和元数据块可以驻留在图1的PMEM 120中。
为了实现高性能,FsDirect将整个PMEM文件仓库映射到数据库进程,使得数据库进程可以直接从PMEM读取数据和向PMEM写入数据。对于实施例中的损坏隔离,不应在数据库之间共享FsDirect文件仓库。
FsDirect文件仓库可以用于存储数据库数据文件、重做日志文件、控制文件等。在实施例中,FsDirect不应用于存储某些管理文件类型,比如跟踪文件和审计文件,这些文件类型可能个别地或总体上太大。在实施例中,并且假定与FsDirect相关的配置参数可以在init.ora中指定,spfile不应当存储在FsDirect中,以避免任何自举问题。
在关于数据更新的原子性的某些事先声明的条件下,用作存储介质的PMEM提供字节可寻址存储装置。考虑到数据库中的数据被组织为文件内的逻辑块,FsDirect继承了人们熟悉的基于文件的数据的概念,它使数据库实现中的关联中断最小化,同时仍然创建了寻址与可寻址存储器相同的存储装置的方式。
在实施例中,FsDirect获取在EXT4挂载的文件系统(或任何其他DAX感知文件系统)中创建的常规文件,并将其转换为用于给定数据库的具有统一物理块大小的所有文件的容器。FsDirect实现了用于引用保持的物理块大小的概念。例如,8k物理块实现将不支持对小于8k的块的引用保持,也不支持跨大小大于8k的块获得单一的引用保持。下面的图描述了说明EXT4文件如何被格式化,以将多个数据库文件当作其内容的高级视图。如下所示,根区间包含与PMEM直接访问有关的元数据。数据库数据和FsDirect元数据存储在区间#1中的物理块中,如图所示。
物理块和介质上数据结构的整体内部分解将在本文中后面说明。其中包括由FsDirect提供给数据库客户端或缓冲区高速缓冲存储器的接口。为了为数据库创建FsDirect文件仓库,管理员可以发出SQL命令来创建FsDirect文件仓库,为文件仓库提供挂载点以及来自以DAX模式安装的本地ext4文件系统的后备文件,比如如下所示。
SQL>CREATE PMEMFS cloud_db_1MOUNTPOINT
'/scratch/db/cloud_db_1'BACKINGFILE
'/scratch/db_storage/db1'SIZE 2T BLOCK SIZE 8K;
指定的挂载点中的最终目录名应当与FsDirect文件仓库名匹配。如果使用spfile,则DBMS在数据库服务器启动期间自动添加为DBMS挂载FsDirect文件仓库所需的init.ora参数。对于上述例子,自动添加下面的init.ora参数。
PMEM_FILESTORE=('/scratch/db/cloud_db_1','/scratch/db_storage/db1')
如果不使用spfile,则DBA应当手动添加该init.ora参数,使得Oracle在实例启动期间,可以自动挂载FsDirect文件仓库。DBA还可以使用本文中后面说明的挂载FsDirect文件仓库命令手动挂载FsDirect文件仓库。
一旦创建了FsDirect文件仓库,该FsDirect文件仓库将显示在给定的挂载点下,就像它是本地文件系统一样。DBA可以在该挂载点下继续正常地创建数据库。
与本地文件系统不同,FsDirect文件仓库将只在FsDirect文件仓库被挂载之后在显示在其挂载点之下。通常,当数据库服务器至少以非挂载模式启动时,FsDirect文件仓库将自动挂载。
当DBA创建FsDirect文件仓库时,DBA应当指定块大小。该块大小通常应当与数据库数据文件的默认块大小匹配,因为该块大小是FsDirect文件仓库中的文件的最有效块大小。当DBA在FsDirect文件仓库中创建重做日志时,DBMS将默认使用FsDirect文件仓库的块大小作为重做日志文件块大小。
在关系DBMS(RDBMS)实施例中,数据库中的单个数据文件从其表空间继承块大小,并且不同的表空间可以具有不同的块大小。可以用与底层FsDirect文件仓库块大小不同的数据文件块大小来创建表空间。对于其块大小是FsDirect块大小的倍数的表空间,对这样的表空间的访问应当是高效的,尽管这样的表空间将不会获得对于数据库查询的直接PMEM读取的额外性能益处,如本文中在其他地方所述。可以用既不是FsDirect文件仓库块大小也不是FsDirect文件块大小的倍数的块大小来创建表空间。然而,对这样的表空间的访问是低效的,因为在这样的表空间中写入数据库块涉及在FsDirect层面的读取-修改-写入操作。因此,DBA可以考虑创建多个FsDirect文件仓库,使得文件仓库块大小与文件的块大小匹配。
规划重做日志文件的块大小可以如下进行。与可以在2K(千字节)和32K之间数据库块大小不同,重做日志文件默认为与磁盘的物理扇区大小相等的块大小,通常为512字节,尽管也支持4K扇区大小。
FsDirect文件仓库通常具有与数据库默认块大小(通常为8K)匹配的块大小。在这样的FsDirect文件仓库上创建的重做日志的默认块大小将是FsDirect文件仓库块大小。这是关于写入重做日志的性能最高效的配置。然而,较大的重做块大小也增加了重做浪费。
为了减少重做浪费,DBA可以在FsDirect上用较小的块大小创建重做日志。如果DBA在常规磁盘存储装置上创建具有备用数据库的主数据库,则DBA可以使用512K作为重做日志的块大小,使得备用数据库可以从主数据库接受归档的重做日志。DBA可以如下所示在创建重做日志时指定特定的块大小。
SQL>ALTER DATABASE orcl ADD LOGFILE
GROUP 4
('/u01/logs/orcl/redo04a.log','/u01/logs/orcl/redo04b.log')
SIZE 100M BLOCKSIZE 512REUSE;
当重做日志的块大小小于FsDirect文件仓库的块大小时,重做日志的写入不是最高效的。对于仅覆盖FsDirect块的一部分的任何重做写入,FsDirect可能必须执行读取-修改-写入。
对于要完全放置在FsDirect文件仓库内的数据库,建议使用spfile。然而,spfile本身不应当存储在FsDirect文件仓库内以避免自举问题。spfile允许DBMS在创建和删除FsDirect文件仓库时自动更新init.ora参数。
可插拔数据库(PDB)克隆如下进行。除了PDB快照复制以外,大多数克隆步骤与没有FsDirect的那些步骤相似。利用快照复制的PDB克隆取决于FsDirect支持稀疏文件的事实。为了与Linux文件系统(例如EXT4)上的PDB精简克隆(快照复制)的当前行为一致,如果用户决定让FsDirect稀疏文件能力来应对克隆过程,则他们应当将ClONEDB参数设置为真。如果是这样,则将不接触原始文件,只有被修改的块将被写入新文件中(写时复制)。
如果ClONEDB被设置为假,则源PDB文件的底层文件系统应当支持存储快照。这样的文件系统包括Oracle自动存储管理集群文件系统(Oracle ACFS)和直接网络文件系统(NFS)客户端存储。如果DBA决定使用存储快照,那么DBA预计将正确地配置存储,如同对于在没有FsDirect的情况下进行克隆所做的那样
5.6示例安全性
图10是描述实施例中的基础设施软件1000的示例体系结构的方框图。如图所示,基础设施软件1000包含为了安全性而被分离成用户空间和内核空间的模块和层。所示软件越少驻留在操作系统(OS)的内核空间中,基础设施软件1000就越安全。
所示组件/dev/fuse可以是驻留在比如在图1的PMEM 120中的FsDirect文件仓库中的后备文件。用户空间和内核空间,包括所示的虚拟文件系统(VFS)层,可以被加载到计算机100的易失性存储器中。
FsDirect是存储数据库文件的特制容器。因此,FsDirect是在数据库本身外部的组件。即使数据库管理员可以使用V$PMEM_FILESTORE视图来查询文件仓库属性,PMEM文件仓库在数据库的数据字典中也不是作为数据库对象来表示和管理的。
PMEM文件仓库后备文件(也称为容器文件,不要与容器数据库混淆)作为操作系统(OS)文件系统层次结构中的文件是可见的。OS级安全属性,诸如文件所有权、许可,扩展属性等只适用于后备文件本身,而不适用于存储在该文件仓库中的内容。相反,该后备文件的OS级安全属性由在该PMEM文件仓库中创建的所有单独数据库文件自动继承,并且与包含该后备文件的目录关联的OS级安全属性由该PMEM文件仓库中的所有目录继承。这意味着如果OS用户具有读取或写入PMEM后备文件的许可,那么该用户也具有读取或写入包含在该PMEM文件仓库中的各个数据库文件的许可。同样地,如果OS用户具有在包含后备文件的目录中列出、搜索或创建文件的许可,则该用户也将具有在该PMEM文件仓库内的任何目录中执行相同操作的相同许可。
在诸如Linux和Solaris之类的平台上,后备文件内的内容经由用户空间文件系统(FUSE)挂载点中的作为文件层次结构暴露给OS用户。FUSE访问旨在便利常见的操作/管理任务,比如将文件迁入和迁出PMEM文件仓库。
FsDirect并不打算独自成为完整的符合POSIX的文件系统。然而,为了支持外部工具,FsDirect将支持用于外部工具访问由数据库创建的文件的FUSE守护进程并与之交互。FUSE器实现的说明在本文件的范围之外,除了假设它将作为与FsDirect相同的实例的一部分运行之外。
上面描述了围绕FsDirect及其数据库实例的FUSE实现。FsDirect并不打算独自成为完整的符合POSIX的文件系统。然而,为了支持外部工具,FsDirect将支持用于外部工具访问由数据库创建的文件的FUSE守护进程并与之交互。
在Oracle实施例中,FsDirect支持Oracle数据库的所有安全特征。特别地,FsDirect支持表空间加密。然而,使用FsDirect的一个优点是能够实现用于Oracle PMEM数据库的直接映射的缓冲区高速缓冲存储器。当对表空间启用加密时,该表空间中的数据库块将不会获得对于查询,能够直接从PMEM读取的性能优势。
三个新的SQL命令,CREATE/ALTER/DROP PMEM FILESTORE,被添加到该项目中的可用SQL命令集中。当数据库处于非挂载模式时(或者甚至在数据库的创建之前),可以执行这些命令。因此,发出这些命令的会话的认证和授权遵循与被允许进行诸如创建、挂载和/或闪回数据库之类的相似操作的会话相同的协议和准则。当在数据库打开时执行这些命令时,这些命令(a)只有在会话以多租户模式连接到cdb$root时才被允许,以及(b)需要SYSDBA数据库特权。
6.0示例实现
FsDirect如下为PMEM块提供直接映射应用程序接口(API)。
鼓励能够直接固定FsDirect块的客户端注册回调,该回调允许FsDirect代码向客户端代码通知直接固定正在阻止FsDirect代码重定位该块。这可以发生在文件仓库缩减操作期间。
FsDirect将块的文件号、块号、文件类型和虚拟地址传递给回调。回调代码预计会尽快释放直接块固定;然而,不需要立即释放该固定。注意,除了virt_addr以外,其他参数可能不适用,这取决于导致获取对FsDirect块的引用的操作。例如,由于借用操作将引用放在空闲文件仓库块上,因此fno、bno和文件类型参数是不适用的。
回调可以在除获取块上的固定的进程/线程之外的进程/线程的上下文中被调用。
放弃空闲块并返回有效块是错误的。另外,FsDirect客户端可以注册回调,如果文件仓库需要收回块的所有权,则FsDirect将调用该回调。
对于Fsd_BlockRetrieveRef_op,客户端必须使用fob、fno和bno参数来指定目标块的身份。另外,virt_addr必须被设定为空。如果操作成功,则将virt_addr设定为目标FsDirect块的虚拟地址。
对于FsD_BlockBorrow_op,客户端必须将virt_addr设定为空。忽略所有其他的参数。该操作的成功完成将导致virt_addr被设定为借用的FsDirect块的虚拟地址。
对于FsD_BlockForfeitRef_op和Fsd_BlockReturn_op,virt_addr必须不为空。它必须是通过先前成功的Fsd_BlockRetrieveRef_op或Fsd_BlockBorrow_op操作返回的块的虚拟地址。成功的操作会将virt_addr设定为空。
对于FsD_BlockAdopt_op,客户端必须使用fob、fno和bno参数为所采用的块指定新的身份。该操作的成功完成将导致所采用的块替换文件块的先前版本(如同用write()操作文件块'bno'的内容一样)。
对于诸如RMAN之类的客户端,可能存在需要检查几个字节的块内容,以决定是否需要将完整的块内容读入用户缓冲区的用例。在这种场景下,块保持和释放操作可能效率较低和/或RDBMS实例可能甚至不在线。为了适应这种用例,FsDirect具有其中客户端提供检查回调的API。该回调判定是应当复制该块,还是应当完全跳过复制操作。
客户端提供回调函数'cbk'和上下文'cbkctx',以及要读取的文件块的身份。回调函数被传递块的虚拟地址和大小,使得可以检查FsDirect块的内容。如果块的全部内容应被复制到客户端提供的读取缓冲区中,则回调返回真。否则,它返回假,以跳过复制任何内容。回调实现应该是幂等的,因为对于同一个FsDirect块,回调可能被多次调用。
如果回调返回真,则将块的内容复制到'缓冲区',并返回复制的字节数。如果回调返回假,则不将块内容复制到'缓冲区',并返回0。在错误的情况下,返回-1,并将“oerr”设定为错误码。
odm_pmem_ioc结构的成员指定特定于目标FsDirect块的参数。API允许在单个调用中发出操作的计数。参数num_complete在条目上被设定为0。当执行每个单独的操作时,它被递增。来自API的返回代码指示与最后的不成功操作关联的错误。
odm_cond_read()API被设计成有条件地将指定FsDirect文件块的内容复制到客户端读取缓冲区中。该API调用客户端提供的回调,该回调用于快速检查FsDirect块的内容,并且如果该块的全部内容应当被复制到客户端提供的读取缓冲区中,则返回真。如果回调函数返回假,则不复制FsDirect块的内容。返回值0指示回调跳过块复制,返回值>0指示复制到用户读取缓冲区中的字节数,而返回值<0指示操作失败。
客户端提供回调函数eval_cbk和上下文cbkctx,以及要读取的文件块的身份。回调函数被传递块的虚拟地址和大小,使得可以检查FsDirect块的内容。如果块的全部内容应当被复制到客户端提供的读取缓冲区中,则回调函数应当返回真。否则,回调应返回假,以跳过复制任何内容。注意,回调实现应当是幂等的,因为对于同一个FsDirect块,回调可能被多次调用。
7.0示例方法
基于本文中前面提出的技术,以下是一种新颖的示例方法,该方法保证在不等待的情况下,就可以将数据库块从PMEM复制到易失性存储器而不被撕裂,这是现有技术无法做到的。
一种方法,包括在不等待的情况下:
将数据库块存储在字节可寻址持久存储器(PMEM)中;
将数据库块的图像复制到动态随机存取存储器(DRAM)中,或者读取数据库块的图像;
检测数据库块的图像是否被撕裂。
8.0数据库概述
本发明的实施例用于数据库管理系统(DBMS)的上下文中。于是,提供示例DBMS的说明。
通常,诸如数据库服务器之类的服务器是集成软件组件和用于执行集成软件组件的计算资源(比如存储器、节点及节点上的进程)的分配的组合,其中软件和计算资源的组合专用于代表服务器的客户端提供特定类型的功能。数据库服务器管理和便利对特定数据库的访问,处理客户端访问数据库的请求。
通过向数据库服务器提交使数据库服务器对存储在数据库中的数据进行操作的命令,用户与DBMS的数据库服务器进行交互。用户可以是在客户端计算机上运行的与数据库服务器进行交互的一个或多个应用。本文中,多个用户也可以被统称为用户。
数据库包含存储在持久性存储机构,比如一组硬盘上的数据和数据库字典。数据库由它自己的独立数据库字典定义。数据库字典包括定义包含在数据库中的数据库对象的元数据。实际上,数据库字典定义数据库的大部分。数据库对象包括表、表列和表空间。表空间是用于存储各种类型的数据库对象,比如表的数据的一组一个或多个文件。如果数据库对象的数据存储在表空间中,则数据库字典将数据库对象映射到保持数据库对象的数据的一个或多个表空间。
DBMS参考数据库字典,以确定如何执行提交给DBMS的数据库命令。数据库命令可以访问由字典定义的数据库对象。
数据库命令可以是数据库语句的形式。为了让数据库服务器处理数据库语句,数据库语句必须符合数据库服务器所支持的数据库语言。许多数据库服务器支持的数据库语言的一个非限制性例子是SQL,包括由诸如Oracle之类的数据库服务器支持的专有形式的SQL(例如Oracle Database 11g)。SQL数据定义语言(“DDL”)指令被发送到数据库服务器,以创建或配置数据库对象,比如表、视图或复杂类型。数据操纵语言(“DML”)被发送到DBMS,以管理存储在数据库结构内的数据。例如,SELECT、INSERT、UPDATE和DELETE是存在于一些SQL实现中的DML指令的常见例子。SQL/XML是当在对象关系数据库中操纵XML数据时使用的SQL的常见扩展。
多节点数据库管理系统由共享对同一数据库的访问的互连节点组成。一般,节点经由网络互连,并且程度不同地共享对共享存储装置的访问,比如共享对一组磁盘驱动器和存储在其上的数据块的访问。多节点数据库系统中的节点可以是经由网络互连的一组计算机(比如工作站和/或个人计算机)的形式。或者,节点可以是网格的节点,所述网格由采取与机架上的其他服务器刀片互连的服务器刀片形式的节点组成。
多节点数据库系统中的每个节点托管数据库服务器。诸如数据库服务器之类的服务器是集成软件组件和用于在处理器上执行集成软件组件的计算资源(比如存储器、节点及节点上的进程)的分配的组合,软件和计算资源的组合专用于代表一个或多个客户端进行特定功能。
可以分配来自多节点数据库系统中的多个节点的资源,以运行特定数据库服务器的软件。软件和来自节点的资源的分配的每种组合是本文中称为“服务器实例”或“实例”的服务器。数据库服务器可以包含多个数据库实例,其中的一些或全部运行在独立的计算机(包括独立的服务器刀片)上。
8.1查询处理
查询是当被执行时,使服务器对一组数据进行一个或多个操作的表达式、命令或一组命令。查询可以指定要从其确定结果集的源数据对象,比如表、列、视图或快照。例如,源数据对象可以出现在结构化查询语言(“SQL”)查询的FROM子句中。SQL是用于查询数据库对象的公知示例语言。本文中使用的术语“查询”用于指代表示查询的任何形式,包括数据库语句形式的查询和用于内部查询表示的任何数据结构。术语“表”指的是由查询引用或定义并表示一组行的任何源对象,比如数据库表、视图、或内联查询块,比如内联视图或子查询。
查询可以在源数据对象被加载时,逐行地对来自源数据对象的数据进行操作,或者在源数据对象被加载之后对整个源数据对象进行操作。通过某个或某些操作产生的结果集可以供其他操作使用,并且以这种方式,结果集可基于某些标准被过滤掉或缩小,和/或与其他结果集和/或其他源数据对象结合或组合。
子查询是查询的一部分或组件,所述一部分或组件与该查询的其他部分或组件不同,并且可以与该查询的其他部分或组件分开地(即,作为单独的查询)被评估。查询的其他部分或组件可以形成外部查询,该外部查询可以包括也可以不包括其他子查询。在为外部查询计算结果时,嵌套在外部查询中的子查询可以被单独地评估一次或多次。
通常,查询分析器接收查询语句并生成查询语句的内部查询表示。一般,内部查询表示是表示查询语句的各个组件和结构的一组互连的数据结构。
内部查询表示可以是节点图的形式,每个互连的数据结构对应于节点,并且对应于所表示的查询语句的组件。内部表示一般在存储器中生成,用于评估、操纵和变换。
硬件概述
按照一个实施例,本文中所述的技术由一个或多个专用计算设备实现。所述专用计算设备可被硬连线以实现所述技术,或者可包括被永久编程以实现所述技术的数字电子设备,比如一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA),或者可包括被编程为按照固件、存储器、其他存储装置或它们的组合中的程序指令实现所述技术的一个或多个通用硬件处理器。这样的专用计算设备还可以将定制的硬连线逻辑、ASIC或FPGA与定制的编程相结合,以实现所述技术。所述专用计算设备可以是桌上型计算机系统、便携式计算机系统、手持设备、连网设备、或者包含硬连线和/或程序逻辑,以实现所述技术的任何其他设备。
例如,图11是图解说明可在其上实现本发明的实施例的计算机系统1100的方框图。计算机系统1100包括总线1102或用于传送信息的其他通信机构,以及与总线1102耦接,用于处理信息的硬件处理器1104。例如,硬件处理器1104可以是通用微处理器。
计算机系统1100还包括耦接到总线1102,用于存储信息和由处理器1104执行的指令的主存储器1106,比如随机存取存储器(RAM)或其他动态存储设备。主存储器1106还可以用于在由处理器1104执行的指令的执行期间,存储临时变量或其他中间信息。当被存储在处理器1104可访问的非临时性存储介质中时,这样的指令使计算机系统1100变成为进行在指令中指定的操作而定制的专用机器。
计算机系统1100还包括耦接到总线1102,用于为处理器1104存储静态信息和指令的只读存储器(ROM)1108或其他静态存储设备。设置诸如磁盘、光盘或固态驱动器之类的存储设备1110,并耦接到总线1102,用于存储信息和指令。
计算机系统1100可经由总线1102耦接到显示器1112,比如阴极射线管(CRT),以便向计算机用户显示信息。包括字母数字键和其他键的输入设备1114耦接到总线1102,以便把信息和命令选择传送给处理器1104。另一种用户输入设备是光标控制器1116,比如鼠标、跟踪球或光标方向键,用于向处理器1104传送方向信息和命令选择,以及用于控制显示器1112上的光标移动。这种输入设备一般在两个轴,即,第一轴(例如,x)和第二轴(例如,y)上具有两个自由度,这使该设备可以指定平面中的位置。
计算机系统1100可利用与计算机系统结合,使计算机系统1100成为或者把计算机系统1100编程为专用机器的定制硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实现本文中所述的技术。按照一个实施例,响应处理器1104执行包含在主存储器1106中的一个或多个指令的一个或多个序列,计算机系统1100执行本文中的技术。这样的指令可以从其他存储介质,比如存储设备1110读入到主存储器1106中。包含在主存储器1106中的指令序列的执行使处理器1104进行本文中所述的处理步骤。在备选实施例中,代替软件指令或者与软件指令结合,可以使用硬连线电路。
本文中使用的术语“存储介质”指的是存储使机器以特定方式工作的数据和/或指令的任何非临时性介质。这样的存储介质可以包含非易失性介质和/或易失性介质。非易失性介质例如包括光盘、磁盘或固态驱动器,比如存储设备1110。易失性介质包括动态存储器,比如主存储器1106。存储介质的常见形式例如包括软盘、柔性磁盘、硬盘、固态驱动器、磁带、或者任何其他磁数据存储介质、CD-ROM、任何其他光数据存储介质、具有各种小孔图案的任何物理介质、RAM、PROM、EPROM、FLASH-EPROM、NVRAM、任何其他存储芯片或盒式存储器。
存储介质不同于传输介质,不过可以与传输介质结合使用。传输介质参与在存储介质之间传送信息。例如,传输介质包括同轴电缆、铜线和光纤,包括构成总线1102的导线。传输介质还可以采取声波或光波,比如在无线电波和红外数据通信期间生成的声波或光波的形式。
在将一个或多个指令的一个或多个序列传送到处理器1104以便执行时,可能涉及到各种形式的介质。例如,指令最初可以携带在远程计算机的磁盘或固态驱动器上。远程计算机可以将指令载入其动态存储器中,然后利用调制解调器通过电话线路发送所述指令。计算机系统1100本地的调制解调器可以在电话线路上接收所述数据,并使用红外发射器将数据转换成红外信号。红外探测器可以接收携带在红外信号中的数据,适当的电路可以将所述数据放置在总线1102上。总线1102将所述数据运送到主存储器1106,处理器1104从主存储器1106取回并执行指令。主存储器1106接收的指令可以在由处理器1104执行之前或之后,视情况存储在存储设备1110上。
计算机系统1100还包括耦接到总线1102的通信接口1118。通信接口1118提供耦接到网络链路1120的双向数据通信,网络链路1120连接到本地网络1122。例如,通信接口1118可以是综合业务数字网(ISDN)卡、线缆调制解调器、卫星调制解调器、或者提供与对应类型的电话线路的数据通信连接的调制解调器。再例如,通信接口1118可以是提供与兼容LAN的数据通信连接的局域网(LAN)卡。也可以实现无线链路。在任意这样的实现中,通信接口1118发送和接收携带表示各种信息的数字数据流的电信号、电磁信号或光信号。
网络链路1120一般提供通过一个或多个网络,到其他数据设备的数据通信。例如,网络链路1120可以提供通过本地网络1122,到主计算机1124或者到由因特网服务提供商(ISP)1126操作的数据设备的连接。ISP 1126又通过现在通常称为“因特网”1128的全球分组数据通信网络来提供数据通信服务。本地网络1122和因特网1128都使用携带数字数据流的电信号、电磁信号或光信号。通过各种网络的信号,以及在网络链路1120上并通过通信接口1118的往来于计算机系统1100运送数字数据的信号是传输介质的示例形式。
计算机系统1100可通过网络、网络链路1120和通信接口1118发送消息和接收数据,包括程序代码。在因特网例子中,服务器1130可通过因特网1128、ISP 1126、本地网络1122和通信接口1118,传送所请求的应用程序的代码。
接收的代码可在被接收时由处理器1104执行,和/或被存储在存储设备1110或者其他非易失性存储装置中供以后执行。
软件概述
图12是可用于控制计算系统1120的操作的基本软件系统1200的方框图。软件系统1200及其组件(包括它们的连接、关系和功能)仅仅是示例性的,而不是要限制示例实施例的实现。适合于实现示例实施例的其他软件系统可以具有不同的组件,包括具有不同的连接、关系和功能的组件。
软件系统1200是为指导计算系统1100的操作而提供的。可以存储在系统存储器(RAM)1106中和存储在固定存储装置(例如,硬盘或闪存)1110上的软件系统1200包括内核或操作系统(OS)1210。
OS 1210管理计算机操作的低级方面,包括管理进程的执行、存储器分配、文件输入和输出(I/O)以及设备I/O。表示为1202A、1202B、1202C...1202N的一个或多个应用可以被“加载”(例如,从固定存储装置1110转移到存储器1106中)以便由系统1200执行。打算在计算机系统1100上使用的应用或其他软件例如也可以被存储为一组可下载的计算机可执行指令,用于从因特网位置(例如,Web服务器、应用商店或其他在线服务)下载和安装。
软件系统1200包括图形用户界面(GUI)1215,用于以图形方式(例如,“点击”或“触摸手势”)接收用户命令和数据。系统1200又可以按照来自操作系统1210和/或应用1202的指令作用于这些输入。GUI 1215还用于显示来自OS 1210和应用1202的操作结果,由此用户可以提供额外的输入或终止会话(例如,注销)。
OS 1210可以直接在计算机系统1100的裸硬件1220(例如,处理器1104)上执行。或者,可以将管理程序或虚拟机监视器(VMM)1230置于裸硬件1220和OS 1210之间。在这种配置中,VMM 1230充当OS 1210和计算机系统1100的裸硬件1220之间的软件“缓冲垫”或虚拟化层。
VMM 1230实例化并运行一个或多个虚拟机实例(“访客机器”)。每个访客机器包括“访客”操作系统,比如OS 1210,以及设计成在访客操作系统上执行的一个或多个应用,比如应用1202。VMM 1230向访客操作系统呈现虚拟操作平台,并管理访客操作系统的执行。
在一些情况下,VMM 1230可以允许访客操作系统就像直接运行在计算机系统1200的裸硬件1220上一样地运行。在这些情况下,配置成直接在裸硬件1220上执行的访客操作系统的相同版本也可以在VMM 1230上执行,而无需修改或重新配置。换句话说,在一些情况下,VMM 1230可以向访客操作系统提供完整的硬件和CPU虚拟化。
在其他情况下,考虑到效率,访客操作系统可以被专门设计或配置成在VMM 1230上执行。在这些情况下,访客操作系统“知晓”它在虚拟机监视器上执行。换句话说,在一些情况下,VMM 1230可以向访客操作系统提供半虚拟化。
计算机系统进程包括硬件处理器时间的分配,以及(物理和/或虚拟)存储器的分配,存储器的分配用于存储由硬件处理器执行的指令,用于存储由执行指令的硬件处理器生成的数据,和/或用于在计算机系统进程不运行时,在硬件处理器时间的分配之间存储硬件处理器状态(例如,寄存器的内容)。计算机系统进程在操作系统的控制下运行,并且可以在正在计算机系统上执行的其他程序的控制下运行。
云计算
术语“云计算”在本文中通常用于说明计算模型,所述计算模型使得能够按需访问诸如计算机网络、服务器、软件应用和服务之类的计算资源的共享池,并且允许以最小的管理工作量或服务提供商交互来快速提供和释放资源。
云计算环境(有时称为云环境或云)可以以各种不同的方式实现,以最佳地适应不同的需求。例如,在公有云环境中,底层计算基础设施由使其他组织或公众可以获得其云服务的组织拥有。相反,私有云环境通常仅供单个组织使用或在单个组织内部使用。社区云用于由社区内的几个组织共享;而混合云包括通过数据和应用可移植性绑定在一起的两种或更多种类型的云(例如,私有云、社区云或公有云)。
通常,云计算模型使以前可能由组织自己的信息技术部门提供的那些职责中的一些职责可以改为在云环境内作为服务层来交付,以供(按照云的公有/私有性质,在组织内部或组织外部的)消费者使用。取决于具体实现,由每个云服务层或在每个云服务层内提供的组件或特征的精确定义可能有所不同,不过常见的例子包括:软件即服务(SaaS),其中消费者使用运行在云基础设施上的软件应用,而SaaS提供商管理或控制底层云基础设施和应用。平台即服务(PaaS),其中消费者可以使用PaaS提供商所支持的软件编程语言和开发工具来开发、部署和以其他方式控制他们自己的应用,而PaaS提供商管理或控制云环境的其他方面(即,运行时执行环境以下的一切)。基础设施即服务(IaaS),其中消费者可以部署和运行任意软件应用,和/或提供处理、存储、网络和其他基本计算资源,而IaaS提供商管理或控制底层物理云基础设施(即,操作系统层以下的一切)。数据库即服务(DBaaS),其中消费者使用运行在云基础设施上的数据库服务器或数据库管理系统,而DBaaS提供商管理或控制底层云基础设施和应用。
上述基本计算机硬件和软件以及云计算环境是为了举例说明可用于实现示例实施例的基本底层计算机组件而给出的。然而,示例实施例不一定局限于任何特定的计算环境或计算设备配置。相反,示例实施例可以在鉴于本公开,本领域技术人员会理解为能够支持在本文中给出的示例实施例的特征和功能的任何类型的系统体系结构或处理环境中实现。
在上面的说明书中,参考了可能因实现而异的众多具体细节说明了本发明的实施例。因而,说明书和附图应被认为是例证性的而不是限制性的。本发明范围,以及申请人拟作为本发明范围的内容的唯一且排他的指示物是从本申请提出的一组权利要求在提出这些权利要求的具体形式(包括任何后续修正)方面的字面上的等同范围。
Claims (20)
1.一种方法,包括:
在没有锁定的情况下,数据库管理系统(DBMS)的读取器进程从持久存储器(PMEM)中的元数据获得用于直接访问PMEM中的数据库块的当前版本的第一存储器地址,所述当前版本是特定版本;
在没有锁定的情况下并发地:
读取器进程读取PMEM中的数据库块的所述特定版本,和
DBMS的写入器进程:将内容写入PMEM中的数据库块的新版本中,或者在PMEM中的元数据中,将第一存储器地址替换为用于直接访问PMEM中的数据库块的新版本的第二存储器地址。
2.按照权利要求1所述的方法,其中所述在PMEM中的元数据中,将第一存储器地址替换为第二存储器地址是原子的。
3.按照权利要求1所述的方法,其中所述读取PMEM中的数据库块的所述特定版本不使用:块设备驱动程序或操作系统(OS)的面向块的输入/输出(I/O)系统调用。
4.按照权利要求1所述的方法,其中所述读取PMEM中的数据库块的所述特定版本使用:存储器映射I/O、对硬件的字节可寻址直接访问(DAX)和/或用户空间文件系统(FUSE)。
5.按照权利要求1所述的方法,其中所述读取PMEM中的数据库块的所述特定版本包括:
将数据库块的所述特定版本从PMEM复制到易失性存储器,和
所述读取器进程或不同的读取器进程读取易失性存储器中的数据库块的所述特定版本。
6.按照权利要求5所述的方法,其中所述将数据库块的所述特定版本从PMEM复制到易失性存储器包括将数据库块的所述特定版本复制到块高速缓冲存储器中。
7.按照权利要求6所述的方法,还包括下述至少之一:
在所述在PMEM中的元数据中,将第一存储器地址替换为第二存储器地址之前或之后,在块高速缓冲存储器中复制、分配和/或填充数据库块的所述新版本;
同时读取易失性存储器中的所述数据库块的多个版本;和/或
所述读取器进程或所述不同的读取器进程固定块高速缓冲存储器中的数据库块的所述特定版本。
8.按照权利要求6所述的方法,其中在所述在PMEM中的元数据中,将第一存储器地址替换为第二存储器地址之后:块高速缓冲存储器包含数据库块的所述特定版本,但是不包含数据库块的所述新版本。
9.按照权利要求5所述的方法,还包括基于所述从PMEM中的所述元数据获得用于直接访问PMEM中的数据库块的所述特定版本的第一存储器地址,来检测易失性存储器中的数据库块的先前版本是陈旧的。
10.按照权利要求1所述的方法,其中所述读取PMEM中的数据库块的所述特定版本包括检测数据库块的所述特定版本的副本是撕裂的或陈旧的。
11.一种或多种存储指令的非临时性计算机可读介质,所述指令当由一个或多个处理器执行时,导致:
在没有锁定的情况下,数据库管理系统(DBMS)的读取器进程从持久存储器(PMEM)中的元数据获得用于直接访问PMEM中的数据库块的当前版本的第一存储器地址,所述当前版本是特定版本;
在没有锁定的情况下并发地:
读取器进程读取PMEM中的数据库块的所述特定版本,和
DBMS的写入器进程:将内容写入PMEM中的数据库块的新版本中,或者在PMEM中的元数据中,将第一存储器地址替换为用于直接访问PMEM中的数据库块的新版本的第二存储器地址。
12.按照权利要求11所述的一种或多种非临时性计算机可读介质,其中所述在PMEM中的元数据中,将第一存储器地址替换为第二存储器地址是原子的。
13.按照权利要求11所述的一种或多种非临时性计算机可读介质,其中所述读取PMEM中的数据库块的所述特定版本不使用:块设备驱动程序或操作系统(OS)的面向块的输入/输出(I/O)系统调用。
14.按照权利要求11所述的一种或多种非临时性计算机可读介质,其中所述读取PMEM中的数据库块的所述特定版本使用:存储器映射I/O、对硬件的字节可寻址直接访问(DAX)和/或用户空间文件系统(FUSE)。
15.按照权利要求11所述的一种或多种非临时性计算机可读介质,其中所述读取PMEM中的数据库块的所述特定版本包括:
将数据库块的所述特定版本从PMEM复制到易失性存储器,和
所述读取器进程或不同的读取器进程读取易失性存储器中的数据库块的所述特定版本。
16.按照权利要求15所述的一种或多种非临时性计算机可读介质,其中所述将数据库块的所述特定版本从PMEM复制到易失性存储器包括将数据库块的所述特定版本复制到块高速缓冲存储器中。
17.按照权利要求16所述的一种或多种非临时性计算机可读介质,还包括下述至少之一:
在所述在PMEM中的元数据中,将第一存储器地址替换为第二存储器地址之前或之后,在块高速缓冲存储器中复制、分配和/或填充数据库块的所述新版本;
同时读取易失性存储器中的所述数据库块的多个版本;和/或
所述读取器进程或所述不同的读取器进程固定块高速缓冲存储器中的数据库块的所述特定版本。
18.按照权利要求16所述的一种或多种非临时性计算机可读介质,其中在所述在PMEM中的元数据中,将第一存储器地址替换为第二存储器地址之后:块高速缓冲存储器包含数据库块的所述特定版本,但是不包含数据库块的所述新版本。
19.按照权利要求15所述的一种或多种非临时性计算机可读介质,还包括基于所述从PMEM中的所述元数据获得用于直接访问PMEM中的数据库块的所述特定版本的第一存储器地址,来检测易失性存储器中的数据库块的先前版本是陈旧的。
20.按照权利要求11所述的一种或多种非临时性计算机可读介质,其中所述读取PMEM中的数据库块的所述特定版本包括检测数据库块的所述特定版本的副本是撕裂的或陈旧的。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201962899943P | 2019-09-13 | 2019-09-13 | |
US62/899,943 | 2019-09-13 | ||
US16/812,833 | 2020-03-09 | ||
US16/812,833 US11645241B2 (en) | 2019-09-13 | 2020-03-09 | Persistent memory file store for directly mapped persistent memory database |
PCT/US2020/048420 WO2021050292A1 (en) | 2019-09-13 | 2020-08-28 | A persistent memory file store for directly mapped persistent memory database |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114631089A true CN114631089A (zh) | 2022-06-14 |
Family
ID=72517317
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202080073277.0A Pending CN114631089A (zh) | 2019-09-13 | 2020-08-28 | 用于直接映射的持久存储器数据库的持久存储器文件仓库 |
Country Status (4)
Country | Link |
---|---|
US (1) | US11645241B2 (zh) |
EP (1) | EP4028901B1 (zh) |
CN (1) | CN114631089A (zh) |
WO (1) | WO2021050292A1 (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10949413B2 (en) * | 2017-09-29 | 2021-03-16 | Oracle International Corporation | Method and system for supporting data consistency on an active standby database after DML redirection to a primary database |
US11640371B2 (en) * | 2020-03-12 | 2023-05-02 | Western Digital Technologies, Inc. | Snapshot management in partitioned storage |
US20220035905A1 (en) * | 2020-07-31 | 2022-02-03 | Palo Alto Networks, Inc. | Malware analysis through virtual machine forking |
US11288188B1 (en) * | 2021-01-21 | 2022-03-29 | Qualcomm Incorporated | Dynamic metadata relocation in memory |
CN112463311B (zh) * | 2021-01-28 | 2021-06-08 | 腾讯科技(深圳)有限公司 | 事务处理方法、装置、计算机设备及存储介质 |
CN114201115A (zh) * | 2021-12-14 | 2022-03-18 | 北京达佳互联信息技术有限公司 | 数据存储系统、方法、计算机设备及存储介质 |
US20230342355A1 (en) * | 2022-04-25 | 2023-10-26 | Oracle International Corporation | Diskless active data guard as cache |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020103819A1 (en) * | 2000-12-12 | 2002-08-01 | Fresher Information Corporation | Technique for stabilizing data in a non-log based information storage and retrieval system |
US7739233B1 (en) * | 2003-02-14 | 2010-06-15 | Google Inc. | Systems and methods for replicating data |
US7243088B2 (en) | 2003-08-06 | 2007-07-10 | Oracle International Corporation | Database management system with efficient version control |
US7600063B2 (en) * | 2006-09-15 | 2009-10-06 | Oracle International Corporation | Techniques for improved read-write concurrency |
US7958387B2 (en) * | 2008-05-30 | 2011-06-07 | Spirent Communications, Inc. | Realtime test result promulgation from network component test device |
US8769350B1 (en) * | 2011-09-20 | 2014-07-01 | Advent Software, Inc. | Multi-writer in-memory non-copying database (MIND) system and method |
US10162716B2 (en) * | 2014-06-09 | 2018-12-25 | Sap Se | Hybrid SCM-DRAM transactional storage engine for fast data recovery |
WO2016122548A1 (en) | 2015-01-29 | 2016-08-04 | Hewlett Packard Enterprise Development Lp | Hash index |
US10599630B2 (en) | 2015-05-29 | 2020-03-24 | Oracle International Corporation | Elimination of log file synchronization delay at transaction commit time |
US10198352B2 (en) | 2016-05-31 | 2019-02-05 | Vmware, Inc. | Efficient pointer swizzling for persistent objects |
US10719479B2 (en) * | 2016-06-28 | 2020-07-21 | Netapp, Inc. | Data unit cloning in memory-based file systems |
US10445236B2 (en) * | 2016-11-14 | 2019-10-15 | Futurewei Technologies, Inc. | Method to consistently store large amounts of data at very high speed in persistent memory systems |
US10732836B2 (en) * | 2017-09-29 | 2020-08-04 | Oracle International Corporation | Remote one-sided persistent writes |
US10268610B1 (en) | 2018-08-16 | 2019-04-23 | International Business Machines Corporation | Determining whether a CPU stalling a current RCU grace period had interrupts enabled |
US11301331B2 (en) * | 2018-09-20 | 2022-04-12 | Samsung Electronics Co., Ltd. | Storage device and operating method of storage device |
US11061884B2 (en) | 2018-10-17 | 2021-07-13 | Oracle International Corporation | Method and system to accelerate transaction commit using non-volatile memory |
US10866890B2 (en) * | 2018-11-07 | 2020-12-15 | Arm Limited | Method and apparatus for implementing lock-free data structures |
CN110377531B (zh) * | 2019-07-19 | 2021-08-10 | 清华大学 | 基于日志结构的持久性内存存储引擎装置及控制方法 |
-
2020
- 2020-03-09 US US16/812,833 patent/US11645241B2/en active Active
- 2020-08-28 CN CN202080073277.0A patent/CN114631089A/zh active Pending
- 2020-08-28 WO PCT/US2020/048420 patent/WO2021050292A1/en active Search and Examination
- 2020-08-28 EP EP20772146.5A patent/EP4028901B1/en active Active
Also Published As
Publication number | Publication date |
---|---|
WO2021050292A1 (en) | 2021-03-18 |
EP4028901B1 (en) | 2024-06-05 |
US11645241B2 (en) | 2023-05-09 |
US20210081372A1 (en) | 2021-03-18 |
EP4028901A1 (en) | 2022-07-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11288252B2 (en) | Transactional key-value store | |
EP4028901B1 (en) | A persistent memory file store for directly mapped persistent memory database | |
Kimura | FOEDUS: OLTP engine for a thousand cores and NVRAM | |
US11080260B2 (en) | Concurrent reads and inserts into a data structure without latching or waiting by readers | |
JP6408568B2 (ja) | 複数のアクセスメソッドのためのラッチフリーのログ構造化ストレージ | |
US11023453B2 (en) | Hash index | |
EP3207471B1 (en) | High performance transactions in database management systems | |
US8407428B2 (en) | Structured memory coprocessor | |
US20180246807A1 (en) | Lifecycle management for data in non-volatile memory | |
US20170220777A1 (en) | Consistent snapshots and clones in an asymmetric virtual distributed file system | |
US20180011892A1 (en) | Foster twin data structure | |
US8972345B1 (en) | Modifying data structures in distributed file systems | |
US20170351543A1 (en) | Heap data structure | |
US8769350B1 (en) | Multi-writer in-memory non-copying database (MIND) system and method | |
WO2016196855A1 (en) | Controlling atomic updates of indexes using hardware transactional memory | |
US11100083B2 (en) | Read only bufferpool | |
Hu et al. | TxFS: Leveraging file-system crash consistency to provide ACID transactions | |
Sowell et al. | Minuet: A scalable distributed multiversion B-tree | |
US20190132415A1 (en) | Active data management by flexible routing system and methods of an accelerated application-oriented middleware layer | |
WO2022206398A1 (en) | Method and apparatus for reading data maintained in tree data structures | |
US11960442B2 (en) | Storing a point in time coherently for a distributed storage system | |
EP4016312B1 (en) | Data operations using a cache table in a file system | |
US20240330263A1 (en) | System and method for key-value shard creation and management in a key-value store | |
Li et al. | Leveraging NVMe SSDs for building a fast, cost-effective, LSM-tree-based KV store | |
Alvarez et al. | Main Memory Management on Relational Database Systems |
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 |