CN105556519A - 对oracle存储器中数据库的存储器中快照存储的多版本并行控制 - Google Patents
对oracle存储器中数据库的存储器中快照存储的多版本并行控制 Download PDFInfo
- Publication number
- CN105556519A CN105556519A CN201480051441.2A CN201480051441A CN105556519A CN 105556519 A CN105556519 A CN 105556519A CN 201480051441 A CN201480051441 A CN 201480051441A CN 105556519 A CN105556519 A CN 105556519A
- Authority
- CN
- China
- Prior art keywords
- data
- row
- data acquisition
- imcu
- data item
- 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.)
- Granted
Links
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/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/273—Asynchronous replication or reconciliation
-
- 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/2228—Indexing structures
- G06F16/2237—Vectors, bitmaps or matrices
-
- 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
- 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/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24564—Applying rules; Deductive queries
-
- 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/275—Synchronous replication
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Computing Systems (AREA)
- Computational Linguistics (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Quality & Reliability (AREA)
Abstract
提供了用于以一种格式持久性地维护数据,但是使该数据以多于一种的格式让数据库服务器可用的技术。例如,其中使数据可用于查询处理的格式之一是基于盘上格式,而其中使数据可用于查询处理的另一种格式独立于盘上格式。处于独立于盘格式的格式的数据可以专门在易失性存储器中进行维护,以减少使数据与数据的盘上格式拷贝保持同步相关联的开销。
Description
技术领域
本发明涉及数据库系统,并且更具体地,涉及在存储器中以一种格式镜像以另一种格式驻留在盘上的数据。
背景技术
鉴于主存储器变得越来越便宜和越来越大,当数据被存储在存储器中时,需要新的数据格式来加快查询处理。现有的格式是为盘而设计的,并且当存储在存储器中(例如,在缓冲区高速缓存中)时,这些格式对于查询不是最优的。例如,对于数据库系统来说,将数据持久性地存储在“盘块”中是常见的。通常,在每个盘块内,数据以行为主的格式进行布置。即,一行中的所有列的值后面跟着用于下一行的所有列的值。
为了提高性能,一些盘块可以在易失性存储器内的“缓冲区高速缓存”中进行高速缓存。从易失性存储器访问数据比从盘访问数据明显更快。但是,即使在易失性存储器内,数据仍然是以行为主的盘块格式,这对于某些类型的数据库操作不是最优的。
与行为主的盘块相比,列状格式对于存储器中的查询处理具有许多吸引人的优点,诸如高速缓存局部性和压缩性。因此,一些数据库服务器现在采用新的表类型,用于以列为主的格式持久性地存储数据。在列为主的格式中,数据可以被读入到易失性存储器中,其中与数据以行为主的盘块存储时相比,它可以被用来更高效地处理某些查询。
不幸的是,将以行为主的盘块持久性地存储数据的现有数据库迁移到使用新的列为主的表类型的任务不是简单的任务。此外,在执行这种迁移之后,对于可以在以行为主的盘块中存储的数据上更高效执行的查询类别来说,查询处理将变得较为低效。
作为替代,一些数据库系统将数据保持在行为主的盘块中,但是采用列存储索引。列存储索引不取代现有的表,并且因此不需要将整个数据库迁移到新的表结构。相反,列存储索引更像作为传统的二级索引。例如,这种列存储索引仍然被持久保存到盘中。不幸的是,随着对通过其进行索引的数据执行更新,可能需要大量的开销来维护这种索引。
作为还有的另一种替代,数据库可以被复制,其中数据库的第一副本用常规的行为主的盘块存储数据,而第二副本以列为主的格式存储数据。当数据库以这种方式进行复制时,利用行为主的数据最高效处理的查询可以被路由到第一副本,而利用列为主的数据最高效处理的查询可以被路由到第二副本。
不幸的是,由于在被复制的系统之间发生的滞后,这种技术并不能很好地工作。具体而言,在任何给定的时间点,在其中一个副本处做出的一些改变将还没有被应用到另一个副本。因此,在复制机制中固有的滞后会导致不可预测的假像,并且有可能地,导致不正确的结果。
此外,每个事务通常需要看见其自己的改变,甚至在那些改变已被提交之前。但是,数据库的改变通常直到改变已被提交时才被复制。因此,即使在另一个副本处的数据的格式可能对于一些操作是更高效的,事务也可能被限制为利用其中做出事务未提交的改变的副本。
本节中描述的方法是可以实行的方法,但不一定是先前已被构思或实行的方法。因此,除非另外指出,否则不应当假定在本节中描述的任何方法仅仅凭其包括在本节中就有资格作为现有技术。
附图说明
在附图中:
图1是根据实施例的、同时维护在易失性存储器中的镜像格式数据和在持久性存储装置上的持久性格式数据的数据库系统的框图;
图2a是用于例子的表的框图;
图2b是根据实施例的、用于表的数据项如何可以被同时以两种格式维护的框图,其中一种格式是存储器中(in-memory)格式;
图3是示出根据实施例的、存储在易失性存储器中的与镜像格式数据结合的日志的框图;
图4是示出根据实施例的、来自单个表的数据如何可以基于行的范围在IMCU之间进行划分的框图;
图5a是示出可以如何分配不同的数据库服务器实例来管理不同MF数据集合的框图,其中所述集合基于行的范围;
图5b是示出可以如何分配不同的数据库服务器实例来管理不同MF数据集合的框图,其中所述集合基于列;
图6是示出根据实施例的、存储改变行的位图和位改变的记录的SMU的框图;
图7是示出根据实施例的、用于执行扫描操作的步骤的流程图;
图8是示出根据实施例的、用于实现改变行的位图的结构的框图;及
图9是示出可用来实现本文所述的技术的计算机系统的框图。
具体实施方式
在以下描述中,出于解释的目的,阐述了许多具体细节,以便提供对本发明的透彻理解。但是,很显然,本发明可以在没有这些具体细节的情况下进行实践。在其它情况下,众所周知的结构和设备以框图的形式示出,以避免不必要地模糊本发明。
总体概述
不同数据格式具有不同的好处。因此,本文所描述的技术用于以一种格式持久性地维护数据,但是使该数据以多于一种的格式对数据库服务器可用。在一种实施例中,其中使数据可用于查询处理的格式中之一是基于盘上(on-disk)格式,而其中使数据可用于查询处理的另一种格式独立于该盘上格式。
对应于盘上格式的格式在本文被称为“持久性格式”或“PF”。处于持久性格式的数据在本文被称为PF数据。独立于盘上格式的存储器中格式被称为“镜像格式”或“MF”。处于镜像格式的数据在本文被称为MF数据。例如,在一种实施例中,持久性格式是行为主的盘块,而镜像格式是列为主的格式。
根据一种实施例,镜像格式完全独立于持久性格式。但是,MF数据初始地基于持久存储的PF数据,而不基于任何持久性MF结构在存储器中构建。由于不需要持久性MF结构,因此现有数据库的用户不需要将其现有数据库中的数据或结构迁移到另一种格式。因此,使用行为主的盘块的常规数据库系统可以继续使用那些盘块来持久存储其数据,而无需执行任何数据迁移,同时仍然获得由于具有在易失性存储器中可用的数据的列为主的表示而产生的性能益处。
存储器中MF数据被维护为在事务上与PF数据一致。MF数据在事务上是一致的,因为从MF数据提供给事务的任何数据项将是如果数据项从PF数据提供的话将会被提供的同一版本。此外,那一版本反映了在事务的快照时间之前提交的所有改变,并且不反映在事务的快照时间之后提交的改变。因此,当提交对在MF数据中被镜像的数据项做出改变的事务时,使得该改变相对于PF数据和MF数据两者都可见。另一方面,如果做出改变的事务被中止或回滚,则该改变相对于PF数据和MF数据两者被回滚。
在一种实施例中,确保PF数据的读和写之间的一致性的同一事务管理器也被用于确保MF数据的读和写之间的一致性。因为MF数据以在事务上一致的方式保持最新,因此,如果存储器中MF数据包括由数据库操作所需的数据,则数据库操作可以或者从存储器中MF数据或者从PF数据中被满足。
MF数据镜像已经在PF数据中存在的数据。但是,虽然在MF数据中的所有项都是在PF数据中的对应项的镜像版本(尽管以不同的格式被组织),但是不是所有在PF数据中的项都需要在MF数据中被镜像。因此,MF数据可以是PF数据的子集。
由于不是所有的PF数据都必须在MF数据中镜像,因此,在一些情况下,查询可能需要只能被PF数据满足的数据。例如,如果表具有列A、B和C,并且只有列A在MF数据中被镜像,则需要来自列B的值的查询必须从PF数据中获得那些值。
但是,即使在那些情况下,MF数据仍然可以用于(a)满足查询的一部分,和/或(b)加快从PF数据中所需数据的检索。例如,MF数据可以用来识别必须从PF数据中检索的特定行。
根据一种实施例,为了减少开销,不维护MF数据的盘上拷贝。在一种可替代的实施例中,MF的拷贝可以被存储,但不试图使MF数据的盘上拷贝与正在PF数据上执行的更新保持同步。因此,在失败之后,存储器中MF数据必须基于PF数据的持久性拷贝进行重建。
在一些实施例中,MF数据被压缩。压缩可以在由用户指定的或基于访问模式的各种压缩级别下执行。
虽然下文将给出其中镜像格式是列状的实施例,但是镜像格式可以是与持久性格式不同的、对运行存储器中查询有用的任何格式。例如,在可替代的实施例中,PF格式是列为主的,而MF格式是行为主的。无论使用何种特定镜像格式,镜像格式数据都基于现有的PF结构(例如表和索引)在存储器中进行创建,而不会引起对那些结构的格式的改变。
通用体系架构
图1是根据一种实施例的数据库系统的框图。参考图1,数据库系统100包括易失性存储器102和持久性存储装置110。易失性存储器102一般表示由数据库系统使用的随机存取存储器,并且可以通过任何数量的存储器设备来实现。通常,当发生故障时,在易失性存储器102存储的数据丢失。
持久性存储装置110一般表示任何数量的持久性存储设备,诸如磁盘、闪存存储器和/或固态驱动器。与易失性存储器102不同,存储在持久性存储装置110上的数据在发生故障时不会丢失。相应地,在发生故障之后,持久性存储装置110上的数据可用来重建在易失性存储器102中丢失的数据。
在易失性存储器102中,数据库服务器120正在执行由一个或多个数据库应用(未示出)提交给数据库服务器的数据库命令。被这些应用使用的数据被示为PF数据112。PF数据112以PF数据结构108驻留在持久性存储设备110中。PF结构108可以是,例如,行为主的盘块。虽然行为主的盘块被用于说明的目的,但是PF结构可以采取任何形式,诸如列为主的盘块、混合压缩单元,等等。
易失性存储器102还包括PF数据的高速缓存106。在高速缓存106内,数据以基于其中数据驻留在PF数据结构108内的格式的格式被存储。例如,如果持久性格式是行为主的盘块,则高速缓存106可以包含行为主的盘块的高速缓存拷贝。
在另一方面,MF数据104处于与持久性格式无关的格式。例如,在其中持久性格式是行为主的盘块的情况下,镜像格式可以是列为主的压缩单元。由于镜像格式与持久性格式不同,因此MF数据104通过对PF数据执行变换来产生。这些变换既在易失性存储器102被初始地用MF数据104填充时发生(无论在启动时或根据需要时),又在易失性存储器102在发生故障之后用MF数据104重新填充时发生。
重要的是,MF数据104的存在可以对向数据库服务器提交数据库命令、利用MF数据104的数据库应用是透明的。例如,被设计为与在PF数据112上独自操作的数据库系统交互的那些相同的应用除了PF数据112之外还可以不加修改地与维护MF数据104的数据库服务器交互。此外,对那些应用透明,该数据库服务器可以使用MF数据104来更高效地处理那些数据库命令中的一些或全部。
镜像格式数据
MF数据104可以镜像所有PF数据112或其子集。在一种实施例中,用户可以指定PF数据112的哪一部分是“启用存储器中(in-memoryenabled)”。可以在任何粒度级别做出该指定。例如,什么启用存储器中的指定可以至少在以下粒度级别做出:
·整个数据库
·指定的表
·指定的列
·指定的行范围
·指定的分区
·指定的段
·指定的扩展区(extent)
·或其任意组合(例如指定的列和分区)
如将在下文中进行描述的,启用存储器中的数据被转换成镜像格式并且在易失性存储器中存储为MF数据104。因此,当查询需要启用存储器中的数据时,数据库服务器具有从PF数据112或者从MF数据104中任一个提供数据的选项。转换和加载可以在数据库启动的时间发生,或者以懒惰或按需的方式发生。没有处于启用存储器中的数据没有在MF数据104中被镜像。因此,当查询需要这种数据时,数据库服务器不具有从MF数据104中获取该数据的选项。
为了解释的目的,将假定PF数据结构108包括在图2A中所示的表200。表200包括三个列c1-c3和六个行r1-r6。虽然在图2A中示出的表200描绘了数据逻辑上如何被组织在持久性存储装置110中,但是其中数据被物理上存储的实际格式可能是完全不同的。
具体而言,参考图2B,它示出了驻留在表200中的数据如何可以被物理上组织在持久性存储装置110中。在本例子中,用于表200的数据被存储在三个行为主的盘块202、204和206中。块202存储用于行r1的所有列的值,接着用于行r2的所有列的值。块204存储用于行r3的所有列的值,接着行r4的所有列的值。最后,块206存储行r5的所有列的值,接着行r6的所有列的值。
那些盘块中的一些盘块的拷贝可以被临时存储在高速缓存106中。在图2B所示的例子中,块204的高速缓存拷贝212驻留在高速缓存106中。高速缓存106可以利用各种高速缓存管理技术中的任何一种技术来管理,并且本文描述的实施例不限于任何特定的高速缓存管理技术。一般而言,这些技术试图在易失性存储器102中保留最有可能在不久的将来被请求的盘块的拷贝。因此,当高速缓存106用完空间时,较不可能被请求的盘块的高速缓存拷贝被更可能被请求的块的拷贝替换。
与高速缓存106中的数据相比,镜像格式数据104没有以基于持久性格式的方式被格式化。在图示的例子中,镜像格式数据104包括两个列向量220和222。每个列向量存储来自表200的单个列的连续的一系列值。在本例子中,列向量220存储来自表200的列1的值,并且列向量222存储来自表300的列3的值。在这个例子中,MF数据104镜像PF数据的子集,因为MF数据104不包括用于表200的列2的列向量。
MF数据的组织
根据一种实施例,即使MF数据使用与PF数据不同的格式,MF数据也以对应于PF数据组织的方式进行组织。例如,在持久性存储装置110中,PF数据可以被存储在驻留在扩展区中的块中,其中扩展区又被组织成段。在这些情况下,在易失性存储器102内,MF数据104可以基于数据所属的扩展区和/或段进行组织。因此,列向量220可以被划分成向量部分,其中每个部分对应于扩展区和/或段的特定范围。
在扩展区内,数据通常按rowid进行排序。类似地,在一种实施例中,MF数据104基于rowid进行排序。例如,在列向量220中的值基于用来排序块202、204和206中的PF数据的同一rowid进行排序。具体而言,rowidr1紧挨着在rowidr2之前,因此r1c1在列向量220中紧挨着在r2c1之前,并且r1c1至r1c3在块202中紧挨着在r2c1至r2c3之前。
在可替代实施例中,MF数据104中的数据项的一些或全部没有在MF数据104内按rowid排序。以不同的顺序存储数据项会是有用的,例如,如果不同的排序产生显著更好的压缩。作为另一个例子,列向量可以最初按rowid进行排序。但是,当新的更新被“合并到”列向量中时(如将在后面更详细讨论的),更新的值可以附加到现有列向量的尾部,以避免必须解压缩和重新压缩现有的列向量。
当列向量内的数据项不按rowid排序时,存储器中索引可以建立在rowid上,以在MF数据104内快速定位与任何给定rowid相关联的数据项。
无论列行向量内的数据项是否基于rowid排序,都可以通过维护与列向量结合的rowid的向量建立rowid到数据项(rowid-to-item)的映射。例如,图3示出了除了列向量220和222之外还被维护的rowid向量330。在rowid的向量中的第一个值(R1)是在每个列向量中的第一个数据项的rowid。类似地,在rowid的向量中的第二个值(R2)是每个列向量中的第二数据项的rowid。
在其中MF数据的组织对应于PF数据的组织的实施例中,对于数据库服务器而言,分离MF数据和PF数据之间的数据库操作更容易。例如,数据库服务器可以确定要使用MF数据来满足相对于扩展区(例如扩展区1至扩展区10)的一个范围的查询,而要使用PF数据来满足相对于扩展区(例如扩展区11至扩展区20)的另一个范围的查询。
利用MF数据来满足查询
常规的数据库系统可以通常通过响应于每个查询首先在高速缓存106中搜索请求的数据来操作。如果数据在高速缓存106中,则数据从高速缓存106中访问。否则,所需的数据从PF数据结构108加载到高速缓存106中,并且然后从高速缓存106中访问。但是,由于在高速缓存106和PF数据结构108两者中的数据处于持久性格式,因此只基于PF数据执行操作并不总能提供最好的性能。
因此,根据一种实施例,数据库服务器使用MF数据104来提供由至少一些请求的数据库操作所需的数据项。例如,如果数据库查询请求来自所有行的列1的值,则数据库服务器可以从列向量220中获取那些值,而无需访问持久性存储装置110。当不存在MF数据104时,数据库将在不访问持久性存储装置110的情况下只能获得R3C1和R4C1(因为当前只有块204是在高速缓存106中)。为了获得R1C1和R2C1,块202必须被加载到高速缓存106中,并且为了获得R5C1和R6C1,块206必须被加载到高速缓存106在。将块202和206加载到高速缓存所花费的时间将比直接从列向量220获取值所需的时间明显更长。
利用MF数据来评估谓词
即使在由数据库操作所需的数据不包括在镜像格式数据104中的情况下,镜像格式数据104也可以用来评估谓词,并且从而以与常规索引相同的方式加快数据库操作。例如,假定表200具有数千行,并在那些行中只有三行的列c1确实具有值“joe”。在这些情况下,数据库服务器可以接收请求来自所有行的列c2的值的数据库命令,其中c1=“joe”。
在这个例子中,需要由数据库命令返回的数据是来自列c2,其不在MF数据104中。但是,可以使用用于列1的列向量220来快速识别其中c1=“joe”的三个行。因为评价谓词(来自c1的值)所需的数据项被连续地存储在易失性存储器中,因此这一操作可以被高效地执行。一旦这些行已利用列向量220被识别,数据库服务器就可以只从盘中检索从那三行获取数据所需的那些块。
在不利用MF数据的情况下,可以使用在列c1上建立的常规索引来评估谓词“wherec1=joe”。但是,一些盘I/O可能是必要的,以利用常规索引来执行这一评估,但不需要盘I/O来利用列向量220评估谓词。此外,维护这种索引会导致显著的开销。
在不利用镜像格式数据104或常规索引的情况下,数据库服务器将必须从持久性存储装置110中加载(a)尚未在高速缓存106中,和(b)为表200存储数据的每个盘块。这些块将不得不被加载,以仅仅为了将列c1的值与“joe”进行比较,以识别其中c2由数据库命令所需的三个行。
由于MF数据104可以用于与常规索引相同的功能(即,高效地识别哪些行满足在数据库命令中指定的标准),因此使用MF数据104的数据库系统不必具有与否则将对于高效谓词评估所需的那么多的常规索引。例如,如果MF数据104包括用于c1的列向量和用于c3的列向量,则数据库服务器不必维护对列c1或c3的常规索引。通过减少需要被数据库服务器维护的常规索引的数量,与进行更新相关联的开销可以被显著降低。
存储器中索引
如上所述,当谓词引用列时,可以使用用于那个列的列向量来评估谓词。以这种方式,可以使用列向量而不是常规的索引。为了提供甚至更快的谓语评估,可以使用存储器中索引。存储器中索引是完全存储在易失性存储器内的索引。存储器中索引的性质可以基于被索引的数据的特点而不同。例如,如果低基数(cardinality)关键字被索引,则存储器中索引可以是二元索引。如果高基数关键字被索引,则存储器中索引可以是B树(B-tree)。无论存储器中索引的性质如何,在索引中的条目指向有关数据项的存储器中的位置,而不是盘上的位置。
压缩
如上所述,MF数据可以被压缩。但是,根据一种实施例,并不是所有的MF数据都需要以相同的方式被压缩,或者被压缩到相同的程度。例如,如果确定来自表200的列c1的数据被频繁使用,并且来自列c3的数据不经常被使用,则在列向量220中的数据可以被轻微压缩,或无压缩,而在列向量222中的数据被高度压缩。
压缩算法,以及用来压缩MF数据的每一部分的、由算法使用的压缩级别可以由用户来指定,或者可以由数据库服务器基于各种因素自动地确定。可能的压缩算法包括,但不限于,基于字典的压缩、行程长度编码(run-lengthencoding,RLE)、Ozip压缩,等等。Ozip压缩在于2014年3月19日提交的美国临时专利No.61/955,574中被描述,其内容通过引用被结合于此。
由数据库服务器使用的确定MF数据的每一部分如何被压缩的因素可以包括,例如,每一部分被访问的频率、和在该部分有多少数据、以及有多少易失性存储器可用。一般而言,MF数据的一部分越频繁地被访问,数据就越少被压缩。作为另一个一般性规则,可用于存储MF数据的易失性存储器越少和/或MF数据的这部分的尺寸越大,压缩就越高。
即使数据项可以在MF数据内被压缩,但是也可能不一定要解压缩MF数据来使用它。例如,向量处理操作可以直接在压缩的值上执行,如在于2012年12月7日提交的美国专利申请No.13/708,054中所描述的,其全部内容通过引用被结合于此。如也在那个申请中描述的,在压缩的列向量值已被转移到CPU之后,解压缩也可能在芯片上执行。
存储器中压缩单元(IMCU)
在其中MF数据被压缩的实施例中,MF数据可以在易失性存储器102内被组织到“存储器中压缩单元”(IMCU)中。每个IMCU存储一组不同的MF数据。例如,如在图4中所示,IMCU402存储列向量220和222的一半,并且IMCU404存储列向量220和222的另一半。具体而言,IMCU402包括存储来自列c1中的值的一半的向量部分420,和存储来自列c3的值的一半的向量部分422。类似地,IMCU404包括存储来自列c1的值的另一半的向量部分424,和存储来自列c3的值的另一半的向量部分426。
在这个例子中,IMCU基于数据所属的行划分MF数据,其中IMCU402对应于表200的行r1至r3,并且IMCU404对应于行表200的行r4-r6。但是,这只是MF数据可以在IMCU之间分布的许多不同方式中的一种。例如,不同的IMCU可以存储用于不同的表、表的不同分区、表的不同列、不同段、不同扩展区等的MF数据。
用于MF数据的元数据
为了确定MF数据是否具有处理查询所需的数据,并且如果是,则找到处理查询所需的MF数据,数据库服务器需要知道哪些PF数据在MF数据中被镜像,并且具体地,哪些特定的PF数据被每个IMCU镜像。因此,根据一种实施例,用于MF数据的元数据430被维护在易失性存储器102中,如在图4中所示。
在一种实施例中,元数据430包括数据到IMCU(data-to-IMCU)的映射。数据到IMCU的映射指示哪些数据被包含在每个IMCU中。这个指示可以以各种方式做出,包括存储为每个IMCU指示以下中的一个或多个的数据:
·其数据被存储在IMCU中的(一个或多个)表
·其数据被存储在IMCU中的(一个或多个)列
·存储在IMCU中的行的范围
·其数据被存储在IMCU中的盘块的范围
·其数据被存储在IMCU中的段
·其数据被存储在IMCU中的表分区
·其数据被存储在IMCU中的扩展区
·其中在IMCU内的数据已被压缩的方式
·用于解压缩存储在IMCU中的数据的字典(当已使用字典类型的编码来压缩PF数据时)
在图4中所示的情况下,数据到IMCU映射可以指示,例如,表200的列c1和c3的行r1-r3被存储在IMCU402中,并且表200的列c1和c3的行r4-r6被存储在IMCU404中。
多实例环境
在一些环境中,同一PF数据被多个数据库服务器实例访问。这种环境在本文中被称为多实例环境。在多实例环境中,每个数据库服务器实例可以访问其它数据库服务器实例不能直接访问的易失性存储器。在这种情况下,可以利用同一MF数据填充数据库服务器实例中每个实例的易失性存储器,或者可以使MF数据的不同部分存储在不同数据库服务器实例的易失性存储器中。在其中MF数据的不同部分被存储在不同数据库服务器实例的易失性存储器中的情况下,元数据430也可以包括IMCU到实例(IMCU-to-instance)的映射。
例如,参考图5a,它示出了其中IMCU402被存储在一个数据库服务器实例(实例1)的易失性存储器502中,并且IMCU404被存储在另一个数据库服务器实例(实例2)的易失性存储器504中的实施例。为了让数据库服务器知道MF数据的特定部分驻留在哪里,每一个都维护元数据(530和532),以指示(a)IMCU402和404驻留在哪里,和(b)它们包含什么数据。
在图5a中,来自相同两列(c1和c3)的MF数据被分布在两个数据库实例之间。但是,也可能基于其它在数据库服务器之间分布MF数据。例如,不同的实例可以具有用于不同的表、不同的列、不同的分区、不同的段、不同的扩展区等的MF数据。
图5b是其中MF数据基于列在数据库实例之间分布的情形的框图。具体而言,在图5b中,存储在实例1的易失性存储器502中的IMCU402包括用于列c1的整个列向量220,而存储在实例2的易失性存储器504中的IMCU404包括用于列c3的整个列向量222。
因为访问本地数据比从远程实例获取数据更高效,因此MF数据的位置可以是确定是从MF数据还是从PF数据获取特定数据项的因素。例如,在图5b所示的情景中,如果被实例1的数据库服务器执行的查询需要来自列c1的数据,则数据库服务器可以决定从列向量220而不是从PF数据中获取数据。另一方面,如果被同一数据库服务器执行的同一查询需要来自列c3的数据,则数据库服务器可以决定从PF数据中获取数据。
当数据库服务器确定利用驻留在远程实例中的MF数据比使用PF数据执行操作更高效时,数据库服务器请求远程实例来执行该操作。例如,在图5b所示的情景中,如果实例1的数据库服务器正在执行具有谓词“wherec3=X”的查询,则实例1的数据库服务器将请求实例2的数据库服务器利用列向量222来评估“wherec3=X”。响应于评估谓词,实例2的数据库服务器将向实例1的数据库服务器返回指示哪些行满足谓词的数据。
使镜像格式数据保持同步
MF数据104只在如果MF数据104保持与对PF数据做出的所有改变最新时才有用。例如,如果查询需要来自列c1的当前值,则列向量220只在如果其值是当前值时才能被使用。类似地,如果查询需要来自其中c1=“joe”的行的c2的当前值,则列向量220只在如果列向量220中的值是当前值时才能被用来识别其中c1=“joe”的行。
因此,提供了当在PF数据上执行更新、插入和删除时用于使镜像格式数据104与PF数据保持同步的机制。具体而言,在一种实施例中,常规地被设计为通过事务更新PF数据的关系数据库服务器的事务管理器被修改为并行地通过事务更新MF数据。例如,当事务管理器作为事务的一部分更新PF数据中的特定项时,事务管理器作为同一事务的一部分也更新在MF数据中的特定项(如果该特定项在MF数据中)。
通过维护MF数据104和PF数据在事务上同步,查询的结果集合将是相同的,无论查询是利用只从MF数据104中获取的数据项,还是只从PF数据中获取的数据项进行处理。如果查询利用来自MF数据104中的一些数据项和来自PF数据中的其它数据项进行处理,结果集合也将是相同的。
对MF数据的就地(IN-PLACE)更新
为了使MF数据与PF数据保持事务上一致,对MF数据做出永久性改变的同时对PF数据做出永久性改变。例如,当将r1c1从X改变到Y的事务提交时,r1c1必须在PF数据和MF数据两者中从X改变为Y。
在一些情况下,有可能直接更新MF数据,以反映当事务提交时由事务作出的改变。例如,如果列向量220是未压缩的,或者是以产生固定宽度的值的方式被压缩的,则当事务提交时,可以在列向量220中直接将r1c1的值从X改变为Y,而无需以其它方式影响列向量220或导致显著开销。
但是,在其它情况下,可能有必要隐式地更新MF数据。当隐式地更新时,MF数据本身不一定改变,但是元数据被存储,以指示其中包含的值已被更新。如将在后面更详细描述的,用来记录对MF数据的隐式更新的元数据可以包括日志和改变行的位图。
日志
在一些实施例中,使PF数据保持与对MF数据的更新同步是复杂的,这是由于MF数据可能处于压缩格式的事实。例如,如果列向量220是压缩的,则直接更新列向量220内的值可能需要整个列向量要被解压缩、执行更新、并且然后整个列向量再次被压缩。响应于在PF数据上执行的每个更新来执行这些操作将是低效的。
为了减少使MF数据保持同步所需的解压缩和压缩操作的量,一种实施例利用日志来对MF数据进行隐式更新。一般而言,日志存储关于(a)对PF数据做出的,和(b)还没有直接对MF数据做出的更新的信息。
参考图3,它示出了其中日志304结合列向量220和222被维护的实施例。在图3示出的实施例中,列向量220和222存储压缩的MF数据302。由于列向量220和222内的数据被压缩,因此将需要相当量的开销来直接更新列向量220和222内的数据。
虽然日志304也在易失性存储器102中,但是日志304通常包含指示尚未反映在列向量220和222中的对PF数据做出的改变的未压缩数据302。例如,如果表200的R3C1的值从X更新到Y,则不是在列向量220中改变R3C1的值,而是在其中一个日志304中存储条目来指示R3C1已被改变,并且记录用于R3C1的新的值。
日志310包括全局日志310和许多私有日志。一般而言,全局日志310只记录那些已被提交的事务做出的改变。在事务提交之前,由事务做出的改变被存储在私有日志中,如下文更详细解释的。
日志310可以包括用于不在MF数据中存在的行的条目。例如,假定用于表200的MF数据在时间T1被创建,并且在时间T2新的行被插入到表200中。在这些情况下,用于新的行的条目将初始地被添加到插入该行的事务的私有日志,并且当那个事务提交时,用于新行的条目将被转移到用于表200的全局日志。
根据一种实施例,所有日志都支持完整的事务语义(例如,查询、DML、回滚到保存点、回滚/中止、并行查询/DML、以及分布式事务)。此外,日志可以与盘上的数据库系统互操作。例如,当数据已从存储器中的日志中清除时,如果查询需要它们,则所需的改变可以从盘上的PF数据中获得。
私有日志
如上所述,使用日志304来存储指示(a)对PF数据做出的改变(b)尚未反映在IMCU中存储的MF数据中的数据。这些改变通常由数据库服务器作为事务的一部分做出。根据一种实施例,除了具有诸如日志310的单个“全局”日志之外,对于所有此类改变,还为每个事务维护单独的“私有”日志。
例如,图3示出了其中三个事务TX1、TX2和TX3对在压缩MF数据302中被镜像的PF数据做出改变的情况。除了对PF数据进行改变之外,这些事务还通过在其各自的私有日志中存储指示这些改变是什么的数据对MF数据做出同样的改变。
类似于对PF数据做出的改变,反映在事务的私有日志中的那些改变直到事务提交才认为是永久性的。因此,反映在任何给定事务的私有日志中的改变直到给定事务提交才将对其它事务可见。在图3所示的例子中,日志312的内容将被事务TX2和TX3忽略。日志314的内容将被事务TX1和TX3忽略。日志316的内容将被事务TX1和TX2忽略。
当提交时移动日志条目
全局日志在系统范围是可见的,因为其中反映的所有改变已被提交。因此,响应于事务TX1提交,反映在TX1的私有日志312中的改变被移动到全局日志130。类似地,响应于事务TX2提交,反映在TX2的私有日志314中的改变被移动到全局日志130。同样,响应于事务TX3提交,反映在TX6的私有日志316中的改变被移动到全局日志130。
如上所述,当事务提交时,事务的私有日志中的内容被移动到适当的全局日志。在其中全局日志基于每IMCU被维护并且私有日志基于每事务被维护的实施例中,移动被提交事务的私有日志条目会涉及将条目中的一些条目移动到一个IMCU的全局日志,并且另一些条目移动到另一个IMCU的全局日志。
例如,假定事务修改映射到第一IMCU的第一组数据,并且修改映射到第二IMCU的第二组数据。在提交之前,用于这两组修改的条目被存储在事务的私有日志中。但是,当事务提交时,用于对第一组数据的修改的条目被移动到用于第一IMCU的全局日志,并且用于对第二组数据的修改的条目被移动到用于第二IMCU的全局日志。
在事务的改变被持久性地提交到PF数据之后,事务被分配提交时间。响应于被分配提交时间,事务的日志条目被更新以反映提交时间。一旦事务的日志条目被转移到适当的全局日志并且利用事务的提交时间被更新,那么反映在那些条目中的改变变得对其它事务可见。
如以上所提到的,IMCU内的数据不需要以rowid次序排列。当不以rowid次序时,可以使用rowid的列向量(例如向量330)来基于rowid定位IMCU内的数据。具体而言,rowid在向量330内的位置是用于在其它向量220和222内的相应行的值的位置。根据一种实施例,即使当IMCU内的数据没有以rowid次序排列时,在对应的私有和全局日志中的条目也基于rowid进行组织。因此,当IMCU中的数据由于对对应的PF数据做出的更新而无效时,无效数据的rowid被记录下来,而不是那个数据在IMCU内的位置。
日志条目内容
一般而言,每个日志条目包含确定(a)什么数据项在条目中,以及(b)该条目反映了那些数据项的什么版本所需的所有信息。在一种实施例中,每个日志条目包括:
·与条目相关联的行的rowid
·指示何时在行中包含的数据是“当前”的时间戳
·用于对应行的一个或多个列的值
对于列值,在一种实施例中,每个日志条目包括由所有数据操纵语言(DML)操作产生的整行图像。在这种实施例中,日志最初是行为主的数据存储库。但是,在某些情况下(诸如当日志变得太大时),日志的内容可以被转换为列为主的行存储库。在日志中的列为主的信息将只需要包括用于那些在MF数据中被镜像的列的值。
在一种实施例中,为日志在行为主的格式中可以具有多少行建立阈值。一旦超过阈值,转换操作就被触发,用于将日志的行为主的数据中的一些或全部转换为列为主的格式。阈值可以是,例如,日志可以具有不超过1000行的行为主的数据。
日志索引
根据一种实施例,在易失性存储器102中维护的索引建立在每个私有日志的rowid列上。除了rowid列之外,索引还可以建立在将提高整体查询处理效率的私有日志的任何其它列上。这些日志索引可以,例如,在查询处理期间使用,以执行日志的查找或基于范围的扫描。
日志结构
根据实施例,日志在易失性存储器102内被组织为一系列按时间排序的扩展区。例如,假定用于MF数据104的版本时间是T1,并且当前的系统时间是时间T10。在这些情况下,日志310可以被组织为三个扩展区,其中第一个包括用于在时间T1和时间T3之间做出的改变的日志条目,其中第二个包括用于在时间T3和时间T6之间做出的改变的日志条目,并且其中第三个包括用于在时间T6和当前系统时间之间做出的改变的日志条目。
当以这种方式构造时,可以使用扩展区修剪来减少在表扫描期间被处理的扩展区的数量。例如,对于为具有T2快照时间的事务执行的表扫描,只有日志310的第一扩展区将需要被扫描。其它日志只包含不允许事务看到的改变。
在另一方面,对于为具有T7快照时间的事务执行的表扫描,日志310的所有三个扩展区将不得不被扫描,因为所有这三个都可能包含用于必须被事务看到的改变的日志条目。
将全局日志合并到MF数据中
如以上所提到的,使用日志是因为每次数据库操作对对应PF数据做出改变时直接更新MF数据是低效的。当MF数据被压缩时,尤其是这样。但是,允许日志无限地增长也是低效的,这既因为日志最终将需要太多的易失性存储器,又因为日志增长得越大,使用MF数据来满足查询就变得越低效。
因此,根据一种实施例,全局日志的内容被定期性地合并到MF数据中。当MF数据被压缩时,这种合并操作通常涉及解压缩MF数据、更新MF数据以反映包含在其中的项目的最新提交版本、并且然后压缩MF数据。
在数据已被合并到包含在特定IMCU中的MF数据之后,与IMCU相关联的元数据被更新,以指示用于该IMCU的新版本时间戳。例如,如果在IMCU中的MF数据反映直到时间T1所做的所有改变,那么在合并之前,用于IMCU的版本时间戳将是T1。如果更新涉及将直到时间T3做出的所有改变合并到IMCU的MF数据中,则在合并之后,用于该IMCU的版本时间戳将被更新为T3。
全局日志条目的合并后保留
如将在下文更详细描述的,在一些实施例中,可以使用改变行的位图来指示MF数据中的哪些数据项已变得陈旧。当改变(没有反映在MF数据中)被提交到数据项时,在MF数据中的数据项变得陈旧。一旦全局日志的内容已被合并到对应的MF数据中,日志中旧的条目可以被清除并且改变行的位图被更新,以重置所有的位(从而指示在新合并的MF数据中没有数据项是陈旧的)。但是,在一些实施例中,不是响应于将改变合并到MF数据中而清除所有旧的日志条目,而是旧数据中的一些可以被保留,以便继续使用MF数据用于其快照时间是在合并时间之前的事务。
例如,如果用于IMCU的合并后版本时间戳是T3,则具有T2快照时间的事务不能使用IMCU中的MF数据,因为那个数据包含不允许该事务看到的改变。但是,如果直到时间T1的所有日志条目都已被保留,则可能使用那些日志条目与IMCU结合来获取直到时间T2的一些数据项目。具体而言,对于其日志条目已被保留的数据项,具有T2快照时间的事务将使用来自在该事务的快照时间T2之前的最近日志条目的数据项的版本。
例如,假定日志只具有单个条目,并且该条目指示r5c1在时间T3从X改变为Y。因此,合并后的IMCU将对r5c1具有值Y。但是,为了向事务提供正确的值,数据库服务器检查日志来查看r5c1的行在IMCU的快照时间T2和版本时间T3之间被改变。基于该信息,数据库服务器知道r5c1的值Y对于该事务太近而看不到,并且该事务必须相反查看r5c1的值X。因此,在为该事务获取的数据中,数据库服务器将r5c1的值Y改变为X。
不幸的是,不可能永久地保留旧的日志条目。因此,根据一种实施例,提供了配置参数用于指定与IMCU或它们所对应的数据库对象相关联的保留策略。例如,保留策略可以是,对于表200,日志条目被保留至少一个小时。因此,对于包含用于表200的数据的IMCU,当在合并之后清除日志条目时,只有与小于一个小时旧的快照时间相关联的那些日志条目被保留。以这种方式保留已被合并的日志条目确保了具有小于一个小时旧的快照时间的事务将总能从MF数据中获得数据项的正确版本。
根据一种实施例,旧日志条目将保留到直到数据库服务器确定没有当前执行的查询将需要旧的日志条目。例如,如果改变在时间T10被合并到IMCU中,那么在该IMCU的全局日志中的、与在时间T10之前做出的改变相关联的日志条目可以在不再有具有在T10之前的快照时间的当前运行的事务时被数据库服务器自动地清理。
在一些实施例中,日志条目可以只存储哪个行被改变以及何时被改变的指示,而无需存储所涉及的实际值。在这种实施例中,合并前日志条目对于指示来自合并后IMCU的哪些值不能被事务使用仍然有用。在以上给出的例子中,在合并后IMCU中的r5c1的版本不能用于具有T2快照时间的事务,因为该日志将指示r5c1在快照时间T2和合并后IMCU的版本时间T3之间被改变。在这些情况下,如果日志不具有r5c1的实际更新前的值(即X),则数据库服务器可以从PF数据中获取那个值,并且从MF数据中获取它需要的其它的值。
全局日志和存储器约束
如以上所解释的,全局和私有日志两者都被维护在易失性存储器中。私有日志用来记录由尚未提交的事务做出的改变。在另一方面,全局日志一般记录由已提交的事务做出的改变。
全局日志具有的条目越多,消耗的易失性存储器就越多。在一些情况下,可能就是没有足够的易失性存储器来存储过大的全局日志。处理这些情况的一种方式是清除较旧的日志扩展区。
例如,假定IMCU的全局日志具有三个扩展区E1、E2和E3。还假定E1包含用于在时间T1和时间T5之间提交的事务的条目、E2包含用于在时间T5和时间T9之间提交的事务的条目、并且E3具有用于在时间T9和当前系统时间之间提交的事务的日志条目。
还假定IMCU的版本时间是T5。在这些情况下,可以使用在E1中的条目来“回滚”IMCU中用于具有在T1和T5之间的快照时间的事务的值。另一方面,可以使用在E2和E3中的条目来“前滚”IMCU中用于具有在T5之后的快照时间的事务的值。
当遇到存储器约束时,取决于需要多少存储器,数据库服务器可以只清除扩展区E1、清除E1和E3、或者清除E1、E2和E3。清除扩展区对某些事务的性能有影响。例如,假定E1被清除。在E1被清除之后,具有T3快照时间的事务可能需要映射到IMCU的数据项。事务可以从IMCU中获取在T3和T5之间没有改变的数据项。在T3和T5之间确实改变的数据项从PF数据中获得,因为那些项被记录在已清除的E1中。
即使在IMCU的日志清除之后,IMCU也可以用来提供在(a)该IMCU的版本时间和(b)请求数据的事务的快照时间之间没有改变的数据。例如,如果IMCU版本时间是T1,具有T5快照时间的事务可以从在T1和T5之间没有被改变的IMCU中获得数据项。如将在后面更详细描述的,那些改变的数据项可以利用为事务产生的删除向量来识别。
快照元数据单元
如以上所提到的,为每个IMCU维护元数据。在一种实施例中,快照元数据单元(SMU)负责维护至少一些那种元数据。参考图6,IMCU600被示出具有其对应的SMU604。在示出的实施例中,SMU604存储IMCU版本时间和改变行的位图606。IMCU版本时间是其中在IMCU600中的值是当前值的时间。改变行的位图将在后面更详细地描述。
在其它方面,用于IMCU的SMU捕获影响包含在IMCU中的MF数据的所有更新。因此,用于IMCU的SMU可以指示,例如,对应的IMCU是否具有用于给定rowid/快照时间组合的有效值。作为另一个例子,SMU可以产生用于其中对应的IMCU相对于给定快照时间具有无效值的所有行的rowid的列表。该列表然后可以与rowid列向量结合使用,以识别对于其,值必须从其它来源获得(例如从日志或者从PF数据获得)的行。
改变行的位图
在一种实施例中,由SMU捕获的更新由在SMU内维护的“改变行的位图”来指示。再次参考图6,用于IMCU600的改变行的位图606在SMU604中进行维护。改变行的位图是指示这样的行的位图:(a)其中对应的IMCU具有值,和(b)自从IMCU的版本时间戳以来已被被提交的事务改变。
例如,当事务执行对表200的行r1、r3和r5的更新时,由于那些行是落在IMCU600的MF数据内的更新的行,因此用于IMCU600的SMU604通过设置对应于行r1、r3和r5的位更新IMCU600的改变行的位图。
根据一种实施例,当对在IMCU600中被镜像的数据做出改变时,SMU604存储改变行的位图606的哪些位被设置以及何时被设置的记录。这些记录在图6中被统一表示为位改变的记录608。例如,如果在时间T1做出的更新修改行r1,则用于行r1的位将被设置,并且记录被存储,以指示用于r1的位在时间T1被设置。
根据一种实施例,改变行的位图按需进行创建。例如,如果改变行的位图是反映是否对一百万行已发生改变,则不是主动地初始化一百万位的数据结构。相反,只为具有至少一个位被设置的行范围存储数据。对于没有数据被存储的任何范围,所有的位被认为是“0”。
参考图8,它示出了根据一种实施例的、用于表示改变行的位图的分层结构800。在图示的实施例中,分层结构800具有对应于扩展区、块和行的层。扩展区层信息802包括用于其中存在任何被设置位的每个扩展区的记录。扩展区层记录链接到其它扩展区层记录(未示出),从而为具有一个或多个设置位的扩展区形成记录的链表。
此外,扩展区记录包括指向驻留在扩展区中的块的块级别信息804的链表的指针。在图示的例子中,扩展区E1的记录指向块B1、B2、B3和B4的记录。块级别记录可以是属于扩展区E1的块的块级别记录的链表中的第一条记录。
块级别记录又指向以位图片段形式存储的行级别信息806。具体而言,在图示的实施例中,用于块B1的记录指向位图片段850。
在位图片段850中的每个位置对应于其数据项存储在块B1中的行。在图示的实施例中,位图片段850具有六个位的位置,其对应于存储在B1中的六个行。对于每个位位置,位图片段850包括两个位,其中一个是行改变(row-changed)位820并且另一个是日志中(in-journal)位830。对于任何给定的行,行改变位指示自从用于该行的数据项被存储在IMCU中之后该行被改变。用于行的日志中位指示用于该行的更新的值是否被存储在IMCU的日志中。
基于在数据结构800中的信息,数据库服务器可以确定数据项的当前版本是否驻留在IMCU中、在IMCU的日志中、或者两者都没有。具体而言,如果结构800对于给定行没有信息,则IMCU具有来自该行的数据项的当前版本。如果结构800具有用于该行的信息并且用于该行的行改变位是“0”,则IMCU也具有来自该行的数据项的当前版本。如果结构800具有用于该行的信息,行改变位被设置并且日志中位被设置,则IMCU不具有该项的当前版本,但是用于IMCU的日志确实具有该项的当前版本。最后,如果结构800具有用于该行的信息、行改变位被设置、并且日志中位没有被设置,则IMCU和日志两者都不具有数据项的当前版本,并且当前版本必须从PF数据中检索。
结构800的记录按需进行创建。因此,如果IMCU对于在特定扩展区中的所有数据项是当前的,则结构800可能不具有用于该扩展区的任何记录。类似地,如果IMCU对于特定块中的所有数据项是当前的,则结构800可能不具有用于那个块的任何块级别信息804。通过只存储用于自从IMCU的版本时间之后已被改变或添加的扩展区/块的改变的行的信息,结构800会比否则如果为每一行预先分配位的情况明显小。
利用位改变的记录
对于需要数据项的最近版本的事务,在改变行的位图606中设置的位指示MF数据具有用于那行的陈旧数据,并且因此IMCU600不能用来从那行提供数据。但是,并非所有的事务都需要数据项的最近版本。
例如,在许多数据库系统中,事务被分配快照时间,并且返回反映直到那个快照时间的数据库的状态的数据。具体而言,如果事务被分配T3快照时间,则该事务必须被提供包括在T3之前被提交的所有改变,并且没有直到T3尚未提交的改变(除了事务自己所做的改变)的数据项的版本。对于这种事务,在改变行的位图606中设置的位不一定指示该IMCU600不能用来作为用于对应行的项的来源。具体而言,如果位在事务的快照时间之后被首先设置,则即使用于特定行的位在改变行的位图606中被设置,这种事务仍然可以使用IMCU600来获取用于该特定行的数据。
例如,假定列向量220和222包含如在时间T1时存在的数据,如由存储在SMU604中的IMCU版本时间所指示的。在后来的时间T5,更新操作改变行r1。具体而言,更新将r1c1的值从X改变为Y。响应于这个更新,IMCU600的改变行的位图606将从000000改变为100000,将对应于行r1的位设置为“1”。此外,在SMU604内存储指示用于r1的位在T5被改变的记录。
在另一个后面时间T9,另一个更新操作改变行r3。具体而言,第二更新将r2c3的值从A改变到B。响应于这个更新,IMCU600的改变行的位图606将从100000改变到101000,将对应于行r3的位设置为“1”。此外,在SMU604内存储指示用于行r3的位在时间T9被设置的记录。
在这些更新发生之后,数据库服务器可以执行读取列c1和c3的值的事务。如果该事务的快照时间比T5早,则该事务可以从列向量220和222中读取所有的值。这可以由数据库通过将该事务的快照时间与在位改变的记录608中指示的时间进行比较来确定。如果事务的快照时间在IMCU版本时间之后,但是在位改变的记录608中的任何时间之前,则在IMCU600中的所有值相对于那个事务都是有效的。
如果事务的快照时间是在T5之后但是在T9之前,则除了必须从别处(例如从日志中或者从PF数据中)获得的行r1的值之外,事务可以从列向量220和222中读取所有的值。如果事务的快照时间是在T9之后,则除了必须从别处获得的行r1和r3的值之外,事务可以从列向量220和222中读取所有的值。
删除向量
在一种实施例中,为了考虑读取在IMCU600中被镜像的值的事务的快照时间,改变行的位图606与位改变的记录608结合使用来创建用于寻求从IMCU600中读取数据的每个事务的删除向量。删除向量特定于快照时间,因为在删除向量中的位只为在与该删除向量为其构造的事务相关联的快照时间之前被修改的行设置。换句话说,每个删除向量反映直到快照时间是当前的改变行的位图的版本。因此,与删除向量相关联的快照时间越旧,该删除向量反映的改变行的位图的版本越旧,并且因此,将在删除向量中设置的位的数量越少。
对于具有在IMCU的版本时间之后的快照时间的事务,通过“回滚”在事务的快照时间之后对改变行的位图606发生的改变为事务产生删除向量。例如,如果事务具有T5的快照时间,则数据库服务器搜索位改变的记录608,以识别在时间T5之后发生的改变。改变行的位图606的拷贝被产生,并且在那个拷贝中,对应于在时间T5之后发生的改变的位被重置为“0”。对于具有在IMCU的版本时间之前的快照时间的事务,删除向量可以通过生成改变行的位图606的拷贝来产生,并且在那个拷贝中,将在查询的快照时间和IMCU的版本时间之间被改变的行的位设置为“1”。
由于删除向量是特定于事务的,因此在任何给定时间,任何数量的不同事务可以执行映射到特定IMCU的行的扫描。每个那些事务都可以被分配不同的快照时间。因此,虽然每个那些事务将具有不同的删除向量,但是所有那些删除向量都是基于对应于IMCU的SMU的同一改变行的位图产生的。
合并前改变行的位图的合并后保留
如以上所提到的,当改变被合并到IMCU中时,在IMCU的改变行的位图中的所有值被重置为“0”,以指示自从IMCU的新版本时间(其将是IMCU被刷新/合并的时间)开始,没有行被改变。但是,不是简单地丢弃或重写现有改变行的位图,而是合并前改变行的位图的拷贝可以被保存。合并前改变行的位图的保存拷贝在本文被称为“保留位图”。如将在后面更详细描述的,这种保留位图允许使用合并后的IMCU来向具有在合并之前的快照时间的事务提供数据项。
例如,假定IMCU在时间T1被构建。从时间T1到时间T10,对IMCU中的数据项做出的改变被记录在其全局日志中,而不是直接对IMCU内的数据项本身做出。虽然那些改变被记录在日志内,但是这些改变也使得对应的位在IMCU的改变行的位图中被设置。在时间T10,改变被合并到IMCU中,使得IMCU的版本时间从T1改变到T10。
在这些情况下,紧挨着合并之前的改变行的位图的状态反映IMCU内的哪些行在时间T1和时间T10之间改变。通过指示哪些行在时间T1和时间T10之间改变,改变行的位图同样指示哪些行在时间T1和时间T10之间没有改变。在合并后的IMCU内,在时间T1和时间T10之间没有改变的那些行可以被提供给具有在T1和T10之间的快照时间的事务。
具体而言,改变行的位图的合并前版本的拷贝在合并之后被保留。与被保留的位图一起,合并前IMCU的版本时间戳也被存储。在以上给出的例子中,被保留的位图将与T1的版本时间戳相关联。
当事务(a)需要映射到IMCU的数据项,和(b)具有落在被保留的位图时间和当前IMCU时间之间的快照时间时,被保留的位图被用来识别在在被保留的位图时间和当前IMCU时间之间没有改变的行。用于所识别的行的值可以被提供给来自当前IMCU的事务。用于剩余行的值从别处获得。具体而言,如果相关的日志条目还未被清除,则用于剩余行的值可以从IMCU的全局日志中获得,或者,否则从PF数据中获得。
IMCU刷新撤销
不是响应于最近的合并而存储单个保留位图,而是响应于每个合并可以存储独立的保留位图。用于给定IMCU的保留位图可以按时间次序被链接。用于IMCU的保留位图的链接集合构成用于IMCU的“IMCU刷新撤销”。
例如,假定IMCU在时间T1被创建,并且然后在时间T10、T15和T30被刷新/合并。在这些情况下,对IMCU的IMCU刷新撤销将包含三个保留位图RB1、RB2和RB3。这三个保留位图将分别与时间T1、T10和T15相关联。
在本例子中,RB1的“0”位指示在时间T1和T10之间没有改变的行。RB2的“0”位指示在时间T10和T15之间没有改变的行。RB3的“0”位指示在时间T15和T30之间没有改变的行。
给定任何快照时间,可以使用IMCU刷新撤销来识别当前IMCU内的哪些行可以被提供给具有那个快照时间的事务。例如,对于具有快照时间T18的事务,在RB3中的“0”位将指示哪些行可以从当前IMCU中被提供给事务。作为另一个例子,对于具有T12的快照时间的事务,RB2和RB3可以利用逻辑或运算来合并,以产生指示哪些行可以从当前IMCU中被提供给事务的位图。作为还有的另一个例子,对于具有T5的快照时间的事务,RB1、RB2和RB3可以利用逻辑或运算来合并,以产生指示哪些行可以从当前IMCU中被提供给事务的位图。
因此,给定具有TX的快照时间的事务,具有低于TX的最高时间戳的保留位图利用逻辑或运算与同一IMCU的所有最近的保留位图进行合并。逻辑“或”操作产生其中“0”对应于自从TX和当前IMCU的版本时间开始没有改变行的位图。因此,用于那些行的数据项可以通过IMCU来提供。
基于存储器约束的事务降级
如上所述,对IMCU中的项做出的改变被记录在日志中,而不是直接对IMCU中的项做出。日志被维护在易失性存储器中。不幸的是,对大数量的项进行改变的长时间运行的事务会导致产生太多日志条目,使得没有足够的空间在易失性存储器中存储条目。
在这些情况下,日志条目可以被冲刷到持久性存储装置中,以释放在易失性存储器中的空间。但是,冲刷日志条目到持久性存储装置并且之后从持久性存储装置读取条目导致明显的性能损失。因此,根据一种实施例,产生足够数量日志条目从而引起存储器问题的事务被“降级”。
根据一种实施例,通过将这些事务的现有私有日志条目推入到IMCU的全局日志中,并且停止产生进一步的私有日志条目来降级这些事务。尽管在IMCU的全局日志中,由于这些日志条目是用于未提交事务的,并且因此初始地与“不确定的”时间戳相关联,因此这些日志条目对其它事务不可见。当降级的事务提交时,在全局日志中事务的条目的时间戳从不确定的改变为事务的提交时间。
不是当在降级模式时停止日志条目的产生,而是事务可以继续产生日志条目,直到它们的私有日志的大小再次达到指定的阈值。在那一点时,私有日志条目可以再次被移动到全局日志,其中由于条目的不确定时间戳,因此条目将对其它事务不可见。填充私有日志至阈值,并且然后将条目转移到全局日志的这一过程可以被重复任意次,直到事务或者提交或者被回滚。
无论在降级模式下操作的事务是否继续产生更多的私有日志条目来记录其改变,这些改变仍然被记录在与IMCU相关联的位改变的记录中。一旦事务提交,那些位改变就被生成到改变行的位图中。
通过利用改变行的位图来记录发生了改变的事实,未来的事务将避免从IMCU中读取陈旧的数据项。当改变行的位图指示与特定行相关联的数据项无效时,需要那行数据项的事务必须从除IMCU之外的其它来源获得数据项。在改变由停止产生日志条目的降级事务做出的情况下,改变将不在全局日志中出现,因此数据项从PF数据中检索。
在一种实施例中,不是所有利用IMCU的事务都被立即降级。相反,降级基于每个事务来执行,其中只有如果事务满足某些标准它们才被降级。标准可以是,例如,它们已产生的日志条目的数量超过了特定阈值。
一般而言,事务必须看到它们自己做出的未提交的改变。因此,已停止产生日志条目的降级事务可能必须从PF数据中获取该事务先前改变的一些数据项的值,因为对于那些改变,没有日志条目存在。
在没有日志的情况下保持同步
在以上当部分中,解释了MF数据可以通过在日志中记录改变来与PF数据保持同步,同时使压缩的MF数据完好,直到日志被合并到压缩的MF数据中。但是,在可替代的实施例中,对于IMCU中的一个或多个,MF数据可以仅仅通过响应于对对应PF数据做出的改变使数据无效而不使用日志记录这些改变来保持同步。
在这种实施例中,如上所述,可以为事务产生删除向量。对于没有被设置的那些位,数据可以从适当的IMCU中获得。对于被设置的那些位,数据必须从PF数据中检索,因为当没有维护这种日志时,从存储器中的日志获得数据不是一个选项。
使MF数据无效而不用在日志中记录改变的好处是避免了处理开销和维持日志的存储器消耗。但是,当在IMCU中的数据项太陈旧而不能被用于处理事务时,从PF数据中访问数据项的适当版本通常将导致比要求从日志中获得数据项更多的开销。此外,在不存在存储器中的日志时刷新IMCU通常还将导致更多的开销,因为需要被合并到IMCU中的改变必须从PF数据而不是从存储器中日志获得。
在一些实施例中,可以为一些IMCU维护日志,而不为其它的IMCU维护。此外,IMCU的日志有可能被丢弃,并且仍继续使用IMCU,用于由于在IMCU版本时间和需要数据的事务的快照时间之间的改变而尚未失效的数据。
确定从何处获取数据
由于MF数据104仅仅是PF数据中的一些数据的镜像(尽管以不同的格式),因此包含在MF数据104中的所有数据项也在PF数据中。因此,对于需要访问在MF数据中被镜像的数据项的任何查询,数据库服务器具有从MF数据104、从PF数据、或者部分从MF数据104和部分从PF数据获取那个数据的选择。
通常,当所请求的数据是表的整行(或表的大多数列)时,从其最高效检索数据的位置是高速缓存106(假定持久性格式是行为主)。如果所请求的行当前不驻留在高速缓存106中,但是MF数据104具有该行的所有列,则MF数据104是从其最高效检索该行的位置。假定MF数据104是列为主,则MF数据104对于检索行要比高速缓存106低效,因为,在列为主的格式中,用于行的值必须从MF数据104内的各个地方拼凑在一起。
如果不是所有用于所请求的行的数据都在MF数据104中,则行的至少一些数据必须从持久性存储装置110中检索。通常,持久性存储装置110是从其检索数据最低效的位置,因为盘访问比在易失性存储器中存储的数据上操作明显更慢。
根据一种实施例,从哪里获得数据的决定可以在多种粒度级别中的任何一种做出。例如,从哪里获得数据的决定可以基于每个表、每列、每扩展区、每段、每个表分区等做出。因此,即使来自列c1的所有数据都在列向量220中,数据库服务器也可以决定通过从列向量220中获取列c1的一些值并且通过从持久性存储装置110上的PF数据中获得列c1的其余的值来执行扫描。
根据一种实施例,诸如表的数据库对象可以是“启用存储器中”的。已被启用存储器中的表具有其数据的至少一部分被镜像在MF数据中。例如,表200是启用存储器中的,因为来自它的两个列(c1和c3)的数据以镜像格式数据104被镜像。具体而言,来自表200的列c1的数据被镜像在列向量220中,并且来自表200的列c3的数据被镜像在列向量222中。
当表没有启用镜像时,表的扫描通过从高速缓存106和/或从持久性存储装置110中读取PF数据来执行。另一方面,当表启用镜像时,它也可以从MF数据104中得到表的数据中的一些或全部。更具体而言,有可能从任何以下位置获得启用镜像的表的数据:
·持久性存储的PF数据
·从闪存高速缓存中(在于2013年3月15日提交的美国专利No.13/840,811中描述,其全部内容通过引用被结合于此)
·本地高速缓存的PF数据
·在另一个实例的高速缓存中的PF数据
·本地存储的MF数据
·存储在另一个实例的易失性存储器中的MF数据
·利用来自日志的信息更新的本地存储的MF数据
·完全来自日志
·存储在利用来自日志的信息更新的另一个实例的易失性存储器中的MF数据
·以上的任意组合
此外,可以在不使用任何索引、使用PF数据上的常规索引和/或使用存储器内索引的情况下获得数据。此外,索引不必只与基于其建立索引的格式一起使用。因此,可以使用建立在PF数据上的常规索引来识别必须被检索的行,并且然后用于那些行的数据可以从MF数据中检索。类似地,可以使用存储器内索引来识别必须被检索的行,并且那些行中的一些或全部可以从PF数据中检索。
根据一种实施例,使用基于成本的优化器来为任何给定的数据库操作确定哪些来源(或这些来源的组合)将被用于提供由数据库操作所需的数据。由基于成本的优化器使用的附加因素包括是否存在用于快速定位想要数据的常规和/或存储器中索引。
扫描操作
根据一种实施例,当确定表扫描操作是要从MF数据104中获得所请求数据中的至少一些时,做出关于与MF数据104相关联的时间戳是否早于正在被扫描使用的快照时间戳的确定。在其中MF数据104包含在IMCU中的实施例中,该确定通过比较存储在IMCU的SMU中的IMCU版本时间和与表扫描相关联的事务的快照时间做出。
如果MF数据时间戳早于正在被扫描使用的快照时间戳,则可能在IMCU中的一些数据相对于那个快照时间陈旧。在这些情况下,可能在IMCU中陈旧的数据项的所需版本驻留在IMCU的全局日志或事务的私有日志中。在这种情况下,与IMCU相关联的日志也可以被扫描,以获得在IMCU中陈旧的数据的正确版本。
参考图6,假定列向量220具有直到时间T1来自表200的列c1的所有值的当前版本。但是,在时间T3,R3C1从X改变为Y。对于R3C1,列向量220具有旧的值X,而日志602具有新的值Y。因此,当具有T5的快照时间的表扫描使用IMCU600作为任何其数据的来源时,在IMCU600中被压缩的MF数据和IMCU600的全局日志602两者都被扫描。
除了扫描全局日志602之外,正在执行扫描的事务的私有日志也被扫描。例如,如果执行扫描的事务是TX1,则私有日志662也被扫描。
因此,任何给定的表扫描可以涉及扫描在IMCU600中压缩的MF数据、扫描全局和私有日志(例如日志602和662)、以及扫描PF数据(其中一些可能位于高速缓存106中)。这些扫描中的每个扫描可以被独立地和并行地执行。因此,响应于请求表200的列c1和c2的值的查询,数据库服务器可以并行地(a)为来自c1的值扫描列向量220,(b)为来自c1的更新的值扫描日志602,(c)为c1的更新的值扫描日志662,和(d)扫描PF数据结构108以获得用于表200的c2的值。
扫描操作例子
参考图7,它是响应于扫描表的请求而被数据库服务器执行的步骤的框图。正在被扫描的表被分成段,其中每段包括一组扩展区,并且每个扩展区包括一组块。在这种环境中,数据库服务器确定哪些块包含需要被扫描的数据,以及是否要从PF数据中扫描这些块,或者从MF数据中获得数据。
具体而言,在步骤700,数据库服务器确定扫描操作是否是“启用存储器”的。如果操作被允许从MF数据中获得它需要的数据中的一些或全部数据,则该操作是“启用存储器”的。例如,如果正在被扫描的表(“目标表”)被指定为启用存储器,则扫描操作可以自动地被视为启用存储器的。如果来自表中的数据要在MF数据中进行镜像,则表是“启用存储器”的。如别处所述,来自启用存储器的表的数据项可以被主动地加载到IMCU中,或者可以按需被加载到IMCU中。即使目标表被指定为启用存储器,也可以提供开关来指定扫描操作为或者启用存储器或者不启用存储器。扫描操作可以被指定为不启用存储器,以迫使扫描仅针对PF数据执行。
根据一种实施例,启用存储器的指定可以在多种粒度级别中的任何一种做出。例如,指定可以基于每个表、每分区、每段、或每扩展区做出。为了说明的目的,将假定启用存储器的指定是基于每扩展区做出。
再次参考图7,如果扫描是不启用存储器的,则控制传递到步骤780,并且扫描只针对PF数据执行。在已使用PF数据来执行扫描之后,扫描操作完成(步骤782)。
在另一方面,如果扫描操作是启用存储器的,则控制前进到步骤702。在步骤702,数据库服务器确定包含由扫描所需的数据的块的范围。一旦范围被确定,控制就传递到步骤704。为了说明的目的,将假定块B1至B500包含由扫描操作所需的数据。
步骤704是迭代通过在步骤704中所识别的范围中的每一块的循环的开始。如果在步骤704确定没有更多的块要扫描,则控制传递到步骤782并且扫描操作完成。如果某些块还未被扫描,则控制从步骤704传递到步骤706。
在步骤706,数据库服务器从在步骤702中所识别的范围内确定下一块来扫描。在步骤708,确定在步骤706中选择的块的地址是否映射到IMCU。如果该地址映射到IMCU,则IMCU存储来自该段的至少一些数据项的MF版本。如果IMCU存储来自该段的数据项的MF版本,则控制传递到步骤710。否则,控制传递到步骤712,在那里包括该块的段从PF数据中获得。
在一种实施例中,当获得被映射到IMCU的段的PF版本时,数据库服务器将该段转换成存储器中格式,并且将如此产生的MF数据存储在IMCU中。这种实施例采用按需加载,按需加载将在下文更详细地描述。将数据转换和加载到IMCU中会花费一些时间。因此,在步骤714,数据库服务器确定是否等待来自段的数据被转换和加载。如果数据库确定等待,则数据库服务器等待,并且当来自段的数据已被转换并加载到IMCU中时,控制传递到步骤708。如果数据库服务器确定不等待,则数据项从PF数据中获得(步骤720),并且控制返回到步骤704。
如上所述,当确定块的地址映射到IMCU时,控制传递到步骤710。当块的地址映射到IMCU时,IMCU在块中包含数据项的至少一些的MF版本。但是,包含在IMCU中的数据项的版本相对于扫描的快照时间不一定有效。因此,在步骤710,确定在IMCU中的那些数据项的版本对于正在执行扫描的事务是否有效。在一种实施例中,确定在IMCU中的数据是否有效涉及基于与扫描操作相关联的快照时间、IMCU的改变行的位图、以及用于IMCU的位改变的记录为扫描操作生成删除向量。如上所述,删除向量是特定于快照的位图,其中每个被设置的位指示对应于该位的行相对于快照时间是无效的。
如果在步骤710确定在IMCU中没有用于当前块的有效的数据项,则控制传递到步骤716,其中数据项从PF数据中获得,直到当前扩展区的结尾。然后控制传递回步骤704。在一些情况下,即使在IMCU中没有用于当前块的有效的数据项,数据库服务器也可以不立即试图从盘中获取PF数据。相反,数据库服务器可以试图只在到达当前扩展区的结尾之后才检索PF数据。
如果IMCU具有用于至少一些项的有效版本,则控制传递到步骤722。在步骤722,IMCU具有其有效版本的数据项从IMCU中取得。IMCU没有其有效版本的数据项或者从IMCU的全局日志中的条目中取得,或者从PF数据中取得。如别处所解释的,各种因素可能影响从其获得数据项的来源的选择。这些因素可以包括,例如,存储数据项的正确版本的PF盘块是否当前驻留在高速缓存中。有可能只是段中的数据的子集被映射到IMCU。例如,有可能只是表的列的子集被映射到IMCU。在这些情况下,由扫描所需的但没有映射到IMCU的段中的任何数据项必须从PF数据中获得。
如果执行扫描的事务的私有日志具有从IMCU或全局日志中获得的任何数据的更新版本,则提供那些更新版本代替以其它方式获取的任何版本。这确保了扫描事务看到其自己的改变,尽管这些改变还没有被提交。
即使当删除向量指示IMCU具有用于所有行的有效数据时,全局日志也被检查,以识别在IMCU创建之后被插入的行。如果日志不包含用于那些行的实际数据项,则这些行从PF数据中进行检索。类似地,为由事务新插入的行,以及为已被事务改变的数据项检查事务的私有日志。
在取得所有必要的数据项之后,控制从步骤722传递回到步骤704。在步骤704,循环被重复,直到由扫描所需的数据项已从IMCU、从日志条目、或者从PF数据被获得。
何时创建MF数据
在可以使用MF数据来满足查询或者提高其结果最终从PF数据中获得的查询的性能之前,MF数据必须存在于易失性存储器中。不像高速缓存106,镜像格式数据不是简单地被存储在持久性存储装置110上的数据的拷贝。相反,因为镜像格式不是基于持久性格式,因此易失性存储器102初始地通过(a)从持久性存储装置110中读取PF数据和(b)将如此获得的PF数据转换为MF格式进行填充。
执行PF到MF转换所需的开销量将基于镜像格式与持久性格式如何不同视情况而异。例如,如果持久性格式是已经以一种方式被压缩的行为主的盘块,并且镜像格式是以另一种方式被压缩的列向量,则执行转换所需要的开销量可能很大。
关于何时创建MF数据的决定可以基于各种因素。例如,如果在系统启动时有足够的时间可用,则已被选择用于镜像的所有PF数据可以在启动时被预加载到易失性存储器102中。如以上所提的的,加载MF数据涉及从持久性存储装置110中读取相应的PF数据并且然后将该PF数据转换为镜像格式。
预加载MF数据
在一种实施例中,MF数据在数据库系统启动时被预加载到易失性存储器中。预加载可以在针对包含将被MF数据镜像的数据项的启用存储器的数据结构执行任何数据库操作之前例如由后台进程执行。
MF数据可以一次被创建一个IMCU。在多实例的环境中,可以使用持久存储的元数据来确定哪些MF数据被预加载到哪个数据库实例中。这种元数据可以包括,例如,MF数据到IMCU(MF-data-to-IMCU)的映射和IMCU到实例(IMCU-to-instance)的映射。
在一个简单的例子中,MF数据到IMCU映射可以指示IMCU402用于存储用于c1的列向量220,并且IMCU404用于存储列c3的列向量222。IMCU到实例映射可以指示IMCU402要被加载到实例1的易失性存储器502中,而IMCU404要被加载到实例2的易失性存储器504。基于这些映射,MF数据将以图5b中所示的方式被预加载到易失性存储器中。
MF数据的按需加载
不是简单地预加载MF数据,而是MF数据中的一些或全部可以在对应的PF数据被数据库操作访问的时间产生。例如,假定数据库实例1被分配来托管用于表200的列c1和c3的列向量。不是在启动时构造和加载那些列向量,而是数据库实例1可以初始地不产生MF数据。相反,数据库实例1可以等待,直到数据库命令需要表200的扫描。因为还没有MF数据被创建,因此扫描完全基于PF数据来执行。在那个扫描期间,构建用于c1和c2的列向量所需的值将被访问。因此,用于c1和c2的列向量可以在那时进行创建,而不导致任何附加的盘访问。
MF数据的按需加载可以与预加载结合使用。例如,要在实例1上托管的MF数据中的一些可以在实例1启动时被创建。MF数据的其它部分可以在数据被查询访问的时间来构建。
在一种实施例中,用户可以设置配置选项来指示哪些MF数据要预加载,以及哪些MF数据按需加载。在可替代的实施例中,数据库服务器自动确定MF数据的哪些部分是预加载和哪些部分是按需加载。一般而言,数据项被使用得越频繁,数据库服务器将越可能自动地将该数据项预加载到MF数据中,使得即使需要该数据项的第一个数据库操作也具有从MF数据获得数据的选项。
IMCU图像的持久性存储
如以上所提的的,MF数据可以在启动时、按需、或以其任何组合被创建。在一种实施例中,IMCU的图像可以被定期地存储到盘中。这种持久存储的图像可以用来在崩溃之后利用MF数据重新填充易失性存储器102。任何给定IMCU的图像将是直到“检查点时间”为止是当前的,检查点时间可以是当IMCU图像被持久存储时。但是,检查点时间可能在发生崩溃的时间之前。因此,在IMCU图像的检查点时间和崩溃时间之间,可能已对IMCU做出了其它改变。由于这些改变没有反映在存储的图像中,因此IMCU图像可能是陈旧的。
为了使用否则陈旧的IMCU图像,IMCU图像可以首先被加载到易失性存储器中。如此加载的IMCU数据与持久存储的撤销信息结合可能对于具有在与IMCU图像相关联的检查点时间之前的快照时间的数据库命令是可用的。为了对具有在检查点时间之后的快照时间的数据库命令可用,在崩溃之前为相关联的PF数据持久存储的重做信息可以用来利用用于在IMCU的检查点时间之后发生的改变的日志条目填充IMCU图像的陈旧日志。
取决于在检查点时间之后和在崩溃之前做出多少改变,利用IMCU的过时的持久性存储的图像重构IMCU会比完全从PF数据重新生成IMCU数据消耗显著更少的开销。
选择哪些PF数据要镜像
哪些PF数据要镜像,以及何时加载它的决定可以基于各种因素。例如,如果系统具有大约巨大的易失性存储器102和相对小的数据库,则可能期望镜像整个数据库。因此,所有的PF数据也将被镜像在MF数据中。另一方面,如果存在相对于数据库的大小相对小量的易失性存储器102,则只镜像数据库的非常小的部分可能是最优的。
通常,当不是所有的数据库都要被镜像时,被选择来镜像的部分是基于哪个部分将最提高系统的整体性能。通常,镜像频繁被使用的数据将比镜像较不频繁被使用的数据提供更多的益处。因此,如果一个表、表的一列、或表的一个分区比数据库中的其它数据更频繁地被访问,则那个表、列或分区可以被选择在易失性存储器102中镜像。选择数据库的哪些部分要镜像可以在任何粒度级别做出。例如,选择可以基于每个表、每列、每扩展区、每段、每个表分区,等等。
自我验证
在除了PF数据之外还维护MF数据的系统中,同一数据的多个来源对处理一些查询可用。在前述部分中,已经解释当同一数据的多个来源可用时,数据库服务器可以基于哪个来源将产生所请求数据库操作的最高效处理从可能的来源中选择。
但是,不是选择可能的来源之一,而是数据库服务器可以可替代地针对两个或更多个来源中的每一个平行地执行数据库操作。例如,从表200的列c1中选择数据的查询可以利用来自列向量220的MF数据来回答,或者利用来自PF数据结构108的PF数据来回答。不是选择一个或另一个,而是数据库服务器可以针对两个来源单独地和独立地执行操作。一旦完成,由各种来源产生的结果可以相互比较。如果结果集合不匹配,则在至少一个操作的处理期间发生了错误。
当检测到错误时,数据库服务器可以采取任意数量的可能的行动。例如,在一种实施例中,产生警报,以指示错误的发生。该警告可以指示在两个结果集合之间的差异是什么。作为产生警报的替代或附加,数据库服务器可以执行附加的调试操作,包括但不限于,重新执行关闭或打开不同数据库特征的操作,以确定其的使用导致产生错误的特征。
当结果集合匹配时,用户对于操作的结果是准确的会具有更大程度的信心。因此,通过同一数据库实例针对相同数据(MF数据和PF数据)的多个来源并行执行相同操作提供了即时的“双重检查”来验证操作的结果结合。
典型地,针对两个来源执行数据库操作可以被并行进行,使得执行自我验证相对于只在PF数据上执行操作具有对操作较小的性能影响。根据一种实施例,自我验证可以在高粒度级别被启用。例如,自我验证可以基于每会话被启用。因此,通过自我验证导致的附加开销会只在那些用户希望“测试”准确性的会话中产生。
自我验证操作也可以由系统自身发起。例如,不是从应用接收执行数据库命令的请求,而是数据库系统可以被配置为从那些已被数据库系统执行的数据库命令中识别并选择“关键”数据库命令。在低使用时间段期间,数据库服务器可以在后台执行那些选定的数据库命令中的一个或多个。选定的数据库命令在自我验证模式下执行,以并行地生成结果集合的多个拷贝,一个基于MF数据和一个基于PF数据。结果集合被比较,以确保结果集合是完全相同的。如果不完全相同,则错误消息可以发送给用户和/或记录在日志中。如果完全相同,则数据可以被存储,以指示选定的数据库命令通过了自我验证测试。在通过阈值数量的测试之后(其中阈值可以是1),数据库服务器可以被配置为停止选择用于自动后台自我验证的数据库命令。
在一种实施例中,当自我验证测试失败时,不是简单地产生警报,而是该数据库命令在不同条件下被反复重新测试。为了确保操作的重复尽可能与产生自我验证错误的原始操作相似,同一数据库操作可以利用与在遇到错误的会话期间使用的快照时间相同的快照时间被执行。
在许多数据库系统中,许多高级查询处理特征可以具有虚拟的“打开-关闭”开关,其中,默认状态是“打开”。在重复先前失败的自我验证测试期间,那些特征可以被选择性地打开和关闭。如果当特定特征被关闭时自我验证通过,并且当同一特征被打开时失败,则存在错误与那个特征有关的可能性。
在已确定使用特定的特征导致与特定数据库操作的自我验证问题之后,可以强制执行隔离。隔离的范围可以不同。例如,数据库服务器可以自动地为所有将来的数据库命令、为针对与遇到错误的数据库操作相同数据的所有将来的数据库命令、或者只为遇到错误的特定数据库命令的将来执行关闭特定特征。
硬件概述
根据一种实施例,本文所描述的技术由一个或多个专用计算设备实现。专用计算设备可以是硬连线的以执行所述技术,或者可以包括诸如被永久性地编程以执行所述技术的一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)的数字电子设备,或者可以包括编程为按照固件、存储器、其它存储装置或者其组合中的程序指令执行所述技术的一个或多个通用硬件处理器。这种专用计算设备还可以合并定制的硬连线逻辑、ASIC或FPGA与定制的编程来实现所述技术。专用计算设备可以是台式计算机系统、便携式计算机系统、手持式设备、联网设备或者结合硬连线和/或程序逻辑来实现所述技术的任何其它设备。
例如,图9是说明本发明的实施例可以在其上实现的计算机系统900的框图。计算机系统900包括总线902或者用于传送信息的其它通信机制,以及与总线902耦合用于处理信息的硬件处理器904。硬件处理器904可以是例如通用微处理器。
计算机系统900还包括耦合到总线902用于存储信息和要由处理器904执行的指令的主存储器906,诸如随机存取存储器(RAM)或其它动态存储设备。主存储器906还可以用于在要由处理器904执行的指令执行期间存储临时变量或其它中间信息。当存储在处理器904可访问的非暂时性存储介质中时,这种指令使计算机系统900变成为执行指令中所规定的操作而定制的专用机器。
计算机系统900还包括只读存储器(ROM)908或者耦合到总线902的其它静态存储设备,用于为处理器904存储静态信息和指令。提供了存储设备910,诸如磁盘、光盘或固态驱动器,并且耦合到总线902,用于存储信息和指令。
计算机系统900可以经总线902耦合到显示器912,诸如阴极射线管(CRT),用于向计算机用户显示信息。输入设备914,包括字母数字和其它键,耦合到总线902,用于向处理器904传送信息和命令选择。另一种类型的用户输入设备是游标控制916,诸如鼠标、轨迹球或者游标方向键,用于向处理器904传送方向信息和命令选择并且用于控制显示器912上的游标运动。这种输入设备通常具有在两个轴,第一个轴(例如,x)和第二个轴(例如,y),中的两个自由度,以允许设备在平面内规定位置。
计算机系统900可以利用定制的硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实现本文所述的技术,这些与计算机系统相结合,使计算机系统900或者把计算机系统900编程为专用机器。根据一种实施例,本文的技术由计算机系统900响应于执行包含在主存储器906中的一条或多条指令的一个或多个序列的处理器904而执行。这种指令可以从另一存储介质,诸如存储设备910,读到主存储器906中。包含在主存储器906中的指令序列的执行使处理器904执行本文所述的过程步骤。在备选实施例中,硬连线的电路系统可以代替软件指令或者与其结合使用。
如在本文所使用的,术语“存储介质”指存储使机器以特定方式操作的数据和/或指令的任何非暂时性介质。这种存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如光盘、磁盘,或固态驱动器,诸如存储设备910。易失性介质包括动态存储器,诸如主存储器906。存储介质的常见形式包括,例如,软盘、柔性盘、硬盘、固态驱动器、磁带,或者任何其它磁性数据存储介质,CD-ROM,任何其它光学数据存储介质,任何具有孔模式的物理介质,RAM、PROM和EPROM、FLASH-EPROM、NVRAM,任何其它存储器芯片或盒式磁带。
存储介质与传输介质截然不同但是可以与其结合使用。传输介质参与在存储介质之间传送信息。例如,传输介质包括同轴电缆、铜线和光纤,包括包含总线902的配线。传输介质还可以采取声或光波的形式,诸如在无线电波和红外线数据通信中产生的那些。
各种形式的介质可以参与把一条或多条指令的一个或多个序列携带到处理器904供执行。例如,指令最初可以在远端计算机的磁盘或固态驱动器上携带。远端计算机可以把指令加载到其动态存储器中并且利用调制解调器经电话线发送指令。位于计算机系统900本地的调制解调器可以在电话线上接收数据并且使用红外线发送器把数据转换成红外线信号。红外线检测器可以接收在红外线信号中携带的数据并且适当的电路系统可以把数据放在总线902上。总线902把数据携带到主存储器906,处理器904从该主存储器906检索并执行指令。由主存储器906接收的指令可以可选地在被处理器904执行之前或之后存储在存储设备910上。
计算机系统900还包括耦合到总线902的通信接口918。通信接口918提供耦合到网络链路920的双向数据通信,其中网络链路920连接到本地网络922。例如,通信接口918可以是综合业务数字网络(ISDN)卡、电缆调制解调器、卫星调制解调器,或者提供到对应类型的电话线的数据通信连接的调制解调器。作为另一个例子,通信接口918可以是提供到兼容的局域网(LAN)的数据通信连接的LAN卡。无线链路也可以实现。在任何此类实现中,通信接口918都发送和接收携带表示各种类型信息的数字信号流的电、电磁或光信号。
网络链路920通常通过一个或多个网络向其它数据设备提供数据通信。例如。网络链路920可以通过本地网络922提供到主计算机924或者到由因特网服务提供商(ISP)926操作的数据设备的连接。ISP926又通过现在通常称为“因特网”928的全局分组数据通信网络提供数据通信服务。本地网络922和因特网928都使用携带数字数据流的电、电磁或光信号。通过各种网络的信号以及在网络链路920上并通过通信接口918的信号是传输介质的示例形式,其中信号把数字数据带到计算机系统900或者携带来自计算机系统900的数字数据。
计算机系统900可以通过网络、网络链路920和通信接口918发送消息和接收数据,包括程序代码。在因特网例子中,服务器930可以通过因特网928、ISP926、本地网络922和通信接口918发送对应于程序的所请求代码。
所接收的代码可以在其被接收时由处理器904执行,和/或存储在存储设备910或其它非易失性存储装置中,供随后执行。
在前面的说明书中,本发明的实施例已经参考众多的具体细节进行了描述,这些细节可以从一种实现到另一种实现不同。因此,说明书和附图应当在说明性而不是限制性的意义上考虑。本发明范围的唯一且排他指示,以及申请人预期作为本发明范围的内容,是由本申请产生的权利要求集合的字面和等效范围,以这种权利要求产生的具体形式,包括任何后续的校正。
Claims (11)
1.一种方法,包括:
在持久性存储装置中维护数据库服务器可访问的数据库;
其中数据库包括第一数据集合;
在数据库服务器可访问的易失性存储器中维护第二数据集合;
其中在第二数据集合中的每个数据项是在第一数据集合中的对应数据项的拷贝;
其中第一数据集合和第二数据集合二者都具有特定数据项的拷贝;
维护指示第二数据集合中的哪些数据项不再有效的位图;
其中维护位图包括通过以下步骤对所述特定数据项的更新做出响应:
更新所述特定数据项在所述第一数据集合中的拷贝;
在不更新所述特定数据项在所述第二数据集合中的拷贝的情况下,在所述位图中设置与所述特定数据项对应的特定位,以指示所述特定数据项在所述第二数据集合中的拷贝无效。
2.如权利要求1所述的方法,其中:
第一数据集合是持久性格式的;
第二数据集合是镜像格式的;
所述镜像格式不同于持久性格式并且独立于持久性格式以及;
第二数据集合是通过将第一数据集合转换成镜像格式而生成的。
3.如权利要求1所述的方法,还包括:通过生成指示所述特定位在特定时间被改变的记录来对所述特定数据项的更新做出响应。
4.如权利要求1所述的方法,其中:
所述特定数据项的更新是由在特定时间提交的事务做出的;
所述方法还包括:
在所述特定数据项的更新之后,通过确定特定事务的快照时间来确定与所述特定事务相关联的特定查询是否被允许使用所述特定数据项在第二数据集合中的拷贝;
响应于所述快照时间在所述特定时间之前,允许所述特定事务使用所述特定数据项在第二数据集合中的拷贝;以及
响应于所述快照时间在所述特定时间之后,不允许所述特定事务使用所述特定数据项在第二数据集合中的拷贝,并且从除了所述第二数据集合之外的源获取所述特定数据项的拷贝。
5.如权利要求4所述的方法,其中除了所述第二数据集合之外的所述源是所述第一数据集合。
6.如权利要求4所述的方法,其中除了所述第二数据集合之外的所述源是存储器中日志中的具有所述特定数据项的更新的拷贝的条目。
7.如权利要求4所述的方法,还包括:
基于所述位图和指示所述位图的位何时被改变的一组记录来为所述特定查询生成删除向量;
其中为所述特定查询生成的所述删除向量指示所述第二数据集合中的哪些数据项截止到所述特定事务的快照时间是无效的;以及
使用所述删除向量来确定所述特定查询被允许访问所述第二数据集合中的哪些数据项。
8.如权利要求7所述的方法,还包括通过以下步骤来生成所述删除向量:
做出所述位图的拷贝;
在所述位图的拷贝内重置在所述特定事务的快照时间之后被设置的所有位。
9.如权利要求1所述的方法,其中:
所述第二数据集合截止到第一时间点是当前的;
所述位图是指示所述第二数据集合中的哪些数据项在所述第一时间点之后并且在第二时间点之前被更新的第一位图;
所述方法还包括:
在所述第二时间点时,通过将在所述第一时间点和所述第二时间点之间对所述第二数据集合中的数据项做出的那些更新合并到所述第二数据集合中,来产生更新的第二数据集合;
维护指示自所述第二时间点起所述第二数据集合中的哪些数据项已被更新的第二位图。
10.如权利要求9所述的方法,还包括:在产生所述更新的第二数据集合之后,确定第二特定查询是否被允许使用所述特定数据项在所述更新的第二数据集合中的拷贝;
其中所述第二特定查询与在所述第一时间点之后且在所述第二时间点之前的第二快照时间相关联;
其中确定第二特定查询是否被允许使用所述特定数据项在所述更新的第二数据集合中的拷贝包括:
使用所述第一位图的改变的记录来识别在所述第二快照时间和所述第二时间点之间哪些数据项没有改变;以及
允许所述第二特定查询访问在所述更新的第二数据集合内的、在所述第二快照时间和所述第二时间点之间没有改变的那些数据项。
11.一种或多种非暂态计算机可读介质,其存储用于执行如权利要求1-10中任何一项所述的方法的指令。
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361880852P | 2013-09-21 | 2013-09-21 | |
US61/880,852 | 2013-09-21 | ||
US201461955574P | 2014-03-19 | 2014-03-19 | |
US61/955,574 | 2014-03-19 | ||
US14/337,183 | 2014-07-21 | ||
US14/337,183 US9128972B2 (en) | 2013-09-21 | 2014-07-21 | Multi-version concurrency control on in-memory snapshot store of oracle in-memory database |
PCT/US2014/055571 WO2015041968A1 (en) | 2013-09-21 | 2014-09-15 | Multi-version concurrency control on in-memory snapshot store of oracle in-memory database |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105556519A true CN105556519A (zh) | 2016-05-04 |
CN105556519B CN105556519B (zh) | 2019-06-25 |
Family
ID=51743544
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201480051441.2A Active CN105556519B (zh) | 2013-09-21 | 2014-09-15 | 对oracle存储器中数据库的存储器中快照存储的多版本并行控制 |
Country Status (4)
Country | Link |
---|---|
US (2) | US9128972B2 (zh) |
EP (1) | EP3047400B1 (zh) |
CN (1) | CN105556519B (zh) |
WO (1) | WO2015041968A1 (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107908718A (zh) * | 2017-11-13 | 2018-04-13 | 山东浪潮通软信息科技有限公司 | 一种数据表管理方法及装置 |
CN109478183A (zh) * | 2016-05-31 | 2019-03-15 | 甲骨文国际公司 | 数据库中的存储器中单元的版本化和非破坏性服务 |
CN109716280A (zh) * | 2016-09-30 | 2019-05-03 | 甲骨文国际公司 | 灵活的内存列存储布置 |
CN110399372A (zh) * | 2019-06-05 | 2019-11-01 | 上海英方软件股份有限公司 | 一种rowid对应关系数据的压缩和解压方法 |
US11621894B2 (en) | 2020-11-18 | 2023-04-04 | Coupang Corp. | Computerized systems and methods for processing high-volume log files from virtual servers |
Families Citing this family (64)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2021161104A1 (en) * | 2020-02-12 | 2021-08-19 | Monday.Com | Enhanced display features in collaborative network systems, methods, and devices |
US10592416B2 (en) | 2011-09-30 | 2020-03-17 | Oracle International Corporation | Write-back storage cache based on fast persistent memory |
US10380021B2 (en) | 2013-03-13 | 2019-08-13 | Oracle International Corporation | Rapid recovery from downtime of mirrored storage device |
US10152500B2 (en) | 2013-03-14 | 2018-12-11 | Oracle International Corporation | Read mostly instances |
US10642837B2 (en) | 2013-03-15 | 2020-05-05 | Oracle International Corporation | Relocating derived cache during data rebalance to maintain application performance |
US9292564B2 (en) | 2013-09-21 | 2016-03-22 | Oracle International Corporation | Mirroring, in memory, data from disk to improve query performance |
US9323799B2 (en) | 2013-09-21 | 2016-04-26 | Oracle International Corporation | Mechanism to run OLTP workload on in-memory database under memory pressure |
US10303682B2 (en) | 2013-09-21 | 2019-05-28 | Oracle International Corporation | Automatic verification and triage of query results |
US9128972B2 (en) | 2013-09-21 | 2015-09-08 | Oracle International Corporation | Multi-version concurrency control on in-memory snapshot store of oracle in-memory database |
US9378232B2 (en) | 2013-09-21 | 2016-06-28 | Oracle International Corporation | Framework for numa affinitized parallel query on in-memory objects within the RDBMS |
US9767178B2 (en) | 2013-10-30 | 2017-09-19 | Oracle International Corporation | Multi-instance redo apply |
US10261950B2 (en) * | 2013-11-26 | 2019-04-16 | Sap Se | Table as query language parameter |
US9697221B2 (en) | 2014-03-19 | 2017-07-04 | Oracle International Corporation | OZIP compression and decompression |
CA2854022C (en) | 2014-06-11 | 2023-05-23 | Ibm Canada Limited - Ibm Canada Limitee | Artifact correlation between domains |
US10002148B2 (en) | 2014-07-22 | 2018-06-19 | Oracle International Corporation | Memory-aware joins based in a database cluster |
US10275184B2 (en) | 2014-07-22 | 2019-04-30 | Oracle International Corporation | Framework for volatile memory query execution in a multi node cluster |
US10229128B2 (en) * | 2014-11-19 | 2019-03-12 | Rubrik, Inc. | Method and apparatus for the generation, organization, storage and retrieval of time stamped blocks of data |
US9442837B2 (en) * | 2015-02-17 | 2016-09-13 | International Business Machines Corporation | Accelerating multiversion concurrency control using hardware transactional memory |
CN107111552B (zh) * | 2015-04-03 | 2021-01-08 | 慧与发展有限责任合伙企业 | 用于版本控制的方法、版本控制器以及机器可读介质 |
US11829349B2 (en) | 2015-05-11 | 2023-11-28 | Oracle International Corporation | Direct-connect functionality in a distributed database grid |
US10216781B2 (en) | 2015-05-29 | 2019-02-26 | Oracle International Corporation | Maintaining cross-node coherence of an in-memory database object in a multi-node database cluster |
US10067974B2 (en) | 2015-05-29 | 2018-09-04 | Oracle International Corporation | Loading and reloading an in-memory copy of a database object without blocking concurrent updates to the database object |
US10025822B2 (en) | 2015-05-29 | 2018-07-17 | Oracle International Corporation | Optimizing execution plans for in-memory-aware joins |
US9990308B2 (en) | 2015-08-31 | 2018-06-05 | Oracle International Corporation | Selective data compression for in-memory databases |
US10706019B2 (en) * | 2015-09-22 | 2020-07-07 | Sap Se | Database processing after a lock condition |
US11403318B2 (en) * | 2015-10-01 | 2022-08-02 | Futurewei Technologies, Inc. | Apparatus and method for managing storage of a primary database and a replica database |
US10984043B2 (en) | 2015-10-02 | 2021-04-20 | Oracle International Corporation | Method for faceted visualization of a SPARQL query result set |
US10678788B2 (en) | 2015-10-22 | 2020-06-09 | Oracle International Corporation | Columnar caching in tiered storage |
US11657037B2 (en) * | 2015-10-23 | 2023-05-23 | Oracle International Corporation | Query execution against an in-memory standby database |
US10747752B2 (en) | 2015-10-23 | 2020-08-18 | Oracle International Corporation | Space management for transactional consistency of in-memory objects on a standby database |
US10565059B2 (en) * | 2015-10-26 | 2020-02-18 | International Business Machines Corporation | Adaptive optimization of a computer database journal |
WO2017086983A1 (en) * | 2015-11-19 | 2017-05-26 | Hewlett Packard Enterprise Development Lp | Prediction models for concurrency control types |
US10102046B2 (en) | 2016-03-24 | 2018-10-16 | Oracle International Corporation | In-memory data analytic system that provides an integrated tracking mechanism for explicit memory resources |
WO2017168483A1 (ja) * | 2016-03-28 | 2017-10-05 | 株式会社日立製作所 | 計算機及びデータベースの処理方法 |
US10140190B1 (en) * | 2016-03-29 | 2018-11-27 | EMC IP Holding Company LLC | Efficient transaction log flushing |
US10061708B2 (en) * | 2016-05-12 | 2018-08-28 | SK Hynix Inc. | Mapped region table |
US10997175B2 (en) * | 2016-06-24 | 2021-05-04 | Teradata Us, Inc. | Method for predicate evaluation in relational database systems |
US10262002B2 (en) | 2016-08-11 | 2019-04-16 | International Business Machines Corporation | Consistent execution of partial queries in hybrid DBMS |
US10133667B2 (en) * | 2016-09-06 | 2018-11-20 | Orcle International Corporation | Efficient data storage and retrieval using a heterogeneous main memory |
US10372699B2 (en) | 2016-09-14 | 2019-08-06 | Oracle International Corporation | Patch-up operations on invalidity data |
US10698771B2 (en) | 2016-09-15 | 2020-06-30 | Oracle International Corporation | Zero-data-loss with asynchronous redo shipping to a standby database |
US10268636B2 (en) | 2016-09-16 | 2019-04-23 | Oracle International Corporation | Column level invalidation for in-memory database |
US10437688B2 (en) * | 2016-09-22 | 2019-10-08 | Oracle International Corporation | Enhancing consistent read performance for in-memory databases |
US10891291B2 (en) | 2016-10-31 | 2021-01-12 | Oracle International Corporation | Facilitating operations on pluggable databases using separate logical timestamp services |
US11475006B2 (en) | 2016-12-02 | 2022-10-18 | Oracle International Corporation | Query and change propagation scheduling for heterogeneous database systems |
US10691722B2 (en) * | 2017-05-31 | 2020-06-23 | Oracle International Corporation | Consistent query execution for big data analytics in a hybrid database |
US10719446B2 (en) | 2017-08-31 | 2020-07-21 | Oracle International Corporation | Directly mapped buffer cache on non-volatile memory |
US10732836B2 (en) | 2017-09-29 | 2020-08-04 | Oracle International Corporation | Remote one-sided persistent writes |
US11086876B2 (en) | 2017-09-29 | 2021-08-10 | Oracle International Corporation | Storing derived summaries on persistent memory of a storage device |
US10956335B2 (en) | 2017-09-29 | 2021-03-23 | Oracle International Corporation | Non-volatile cache access using RDMA |
CN108363772A (zh) * | 2018-02-08 | 2018-08-03 | 竞技世界(北京)网络技术有限公司 | 一种基于缓存的签到数据存储方法及装置 |
US11379433B2 (en) * | 2018-05-25 | 2022-07-05 | Microsoft Technology Licensing, Llc | Persistent version storage for relational database management system |
US11226955B2 (en) | 2018-06-28 | 2022-01-18 | Oracle International Corporation | Techniques for enabling and integrating in-memory semi-structured data and text document searches with in-memory columnar query processing |
US11514055B2 (en) | 2019-09-13 | 2022-11-29 | Oracle International Corporation | Querying on hybrid formats and storages |
CN110968646B (zh) * | 2019-12-20 | 2023-06-06 | 广东睿住智能科技有限公司 | 一种嵌入式系统数据库同步方法、装置及存储介质 |
US11501255B2 (en) | 2020-05-01 | 2022-11-15 | Monday.com Ltd. | Digital processing systems and methods for virtual file-based electronic white board in collaborative work systems |
US20240184989A1 (en) | 2020-05-01 | 2024-06-06 | Monday.com Ltd. | Digital processing systems and methods for virtualfile-based electronic white board in collaborative work systems systems |
US20220221966A1 (en) | 2021-01-14 | 2022-07-14 | Monday.com Ltd. | Digital processing systems and methods for dual mode editing in collaborative documents enabling private changes in collaborative work systems |
CN113626137B (zh) * | 2021-06-30 | 2023-12-29 | 济南浪潮数据技术有限公司 | 一种支持多格式镜像的实现方法、装置、设备和介质 |
US12056664B2 (en) | 2021-08-17 | 2024-08-06 | Monday.com Ltd. | Digital processing systems and methods for external events trigger automatic text-based document alterations in collaborative work systems |
US11741071B1 (en) | 2022-12-28 | 2023-08-29 | Monday.com Ltd. | Digital processing systems and methods for navigating and viewing displayed content |
US11886683B1 (en) | 2022-12-30 | 2024-01-30 | Monday.com Ltd | Digital processing systems and methods for presenting board graphics |
US11893381B1 (en) | 2023-02-21 | 2024-02-06 | Monday.com Ltd | Digital processing systems and methods for reducing file bundle sizes |
US12056255B1 (en) | 2023-11-28 | 2024-08-06 | Monday.com Ltd. | Digital processing systems and methods for facilitating the development and implementation of applications in conjunction with a serverless environment |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1647047A (zh) * | 2002-04-03 | 2005-07-27 | 鲍尔凯斯特公司 | 为计算机和存储资源的管理使用分离的映像 |
WO2007078444A1 (en) * | 2005-12-30 | 2007-07-12 | Microsoft Corporation | Managing states with delta pager |
US20080281784A1 (en) * | 2007-05-08 | 2008-11-13 | Zane Barry M | Query handling in databases with replicated data |
CN102498476A (zh) * | 2009-09-14 | 2012-06-13 | 甲骨文国际公司 | 在数据库服务器和存储系统之间高速缓存数据 |
CN102929750A (zh) * | 2011-09-12 | 2013-02-13 | 微软公司 | 非易失性介质肮脏区段跟踪 |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5544347A (en) * | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
US5778430A (en) | 1996-04-19 | 1998-07-07 | Eccs, Inc. | Method and apparatus for computer disk cache management |
US6009432A (en) | 1998-07-08 | 1999-12-28 | Required Technologies, Inc. | Value-instance-connectivity computer-implemented database |
US7149769B2 (en) | 2002-03-26 | 2006-12-12 | Hewlett-Packard Development Company, L.P. | System and method for multi-destination merge in a storage area network |
US7555497B2 (en) | 2003-08-21 | 2009-06-30 | Microsoft Corporation | Systems and methods for separating units of information manageable by a hardware/software interface system from their physical organization |
US20080059492A1 (en) | 2006-08-31 | 2008-03-06 | Tarin Stephen A | Systems, methods, and storage structures for cached databases |
US7664866B2 (en) | 2007-04-10 | 2010-02-16 | Apertio Limited | Sub-tree access control in network architectures |
US8671076B2 (en) | 2007-05-08 | 2014-03-11 | Bmc Software, Inc. | Database recovery using logs applied to consistent copies |
US10152504B2 (en) | 2009-03-11 | 2018-12-11 | Actian Netherlands B.V. | Column-store database architecture utilizing positional delta tree update system and methods |
US8401996B2 (en) * | 2009-03-30 | 2013-03-19 | Commvault Systems, Inc. | Storing a variable number of instances of data objects |
US8583692B2 (en) | 2009-04-30 | 2013-11-12 | Oracle International Corporation | DDL and DML support for hybrid columnar compressed tables |
US8868510B2 (en) | 2009-12-03 | 2014-10-21 | Sybase, Inc. | Managing data storage as an in-memory database in a database management system |
US8433684B2 (en) | 2010-03-30 | 2013-04-30 | Sybase, Inc. | Managing data backup of an in-memory database in a database management system |
US8880508B2 (en) | 2010-12-30 | 2014-11-04 | Sap Se | Processing database queries using format conversion |
US20120323971A1 (en) | 2011-06-14 | 2012-12-20 | Sybase, Inc. | Optimizing data storage and access of an in-memory database |
US8918436B2 (en) | 2011-12-22 | 2014-12-23 | Sap Ag | Hybrid database table stored as both row and column store |
US20140040218A1 (en) | 2012-07-31 | 2014-02-06 | Hideaki Kimura | Methods and systems for an intent lock engine |
US8856484B2 (en) | 2012-08-14 | 2014-10-07 | Infinidat Ltd. | Mass storage system and methods of controlling resources thereof |
US20140075493A1 (en) | 2012-09-12 | 2014-03-13 | Avaya, Inc. | System and method for location-based protection of mobile data |
US9378232B2 (en) | 2013-09-21 | 2016-06-28 | Oracle International Corporation | Framework for numa affinitized parallel query on in-memory objects within the RDBMS |
US9292564B2 (en) | 2013-09-21 | 2016-03-22 | Oracle International Corporation | Mirroring, in memory, data from disk to improve query performance |
US9128972B2 (en) | 2013-09-21 | 2015-09-08 | Oracle International Corporation | Multi-version concurrency control on in-memory snapshot store of oracle in-memory database |
US9323799B2 (en) | 2013-09-21 | 2016-04-26 | Oracle International Corporation | Mechanism to run OLTP workload on in-memory database under memory pressure |
-
2014
- 2014-07-21 US US14/337,183 patent/US9128972B2/en active Active
- 2014-09-15 CN CN201480051441.2A patent/CN105556519B/zh active Active
- 2014-09-15 WO PCT/US2014/055571 patent/WO2015041968A1/en active Application Filing
- 2014-09-15 EP EP14786387.2A patent/EP3047400B1/en active Active
-
2015
- 2015-08-05 US US14/819,016 patent/US9483517B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1647047A (zh) * | 2002-04-03 | 2005-07-27 | 鲍尔凯斯特公司 | 为计算机和存储资源的管理使用分离的映像 |
WO2007078444A1 (en) * | 2005-12-30 | 2007-07-12 | Microsoft Corporation | Managing states with delta pager |
US20080281784A1 (en) * | 2007-05-08 | 2008-11-13 | Zane Barry M | Query handling in databases with replicated data |
CN102498476A (zh) * | 2009-09-14 | 2012-06-13 | 甲骨文国际公司 | 在数据库服务器和存储系统之间高速缓存数据 |
CN102929750A (zh) * | 2011-09-12 | 2013-02-13 | 微软公司 | 非易失性介质肮脏区段跟踪 |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109478183A (zh) * | 2016-05-31 | 2019-03-15 | 甲骨文国际公司 | 数据库中的存储器中单元的版本化和非破坏性服务 |
CN109478183B (zh) * | 2016-05-31 | 2023-08-08 | 甲骨文国际公司 | 用于数据库中的存储器中单元的非破坏性版本化的方法和设备 |
CN109716280A (zh) * | 2016-09-30 | 2019-05-03 | 甲骨文国际公司 | 灵活的内存列存储布置 |
CN109716280B (zh) * | 2016-09-30 | 2021-05-11 | 甲骨文国际公司 | 灵活的内存列存储布置 |
CN107908718A (zh) * | 2017-11-13 | 2018-04-13 | 山东浪潮通软信息科技有限公司 | 一种数据表管理方法及装置 |
CN110399372A (zh) * | 2019-06-05 | 2019-11-01 | 上海英方软件股份有限公司 | 一种rowid对应关系数据的压缩和解压方法 |
CN110399372B (zh) * | 2019-06-05 | 2020-03-27 | 上海英方软件股份有限公司 | 一种rowid对应关系数据的压缩和解压方法 |
US11621894B2 (en) | 2020-11-18 | 2023-04-04 | Coupang Corp. | Computerized systems and methods for processing high-volume log files from virtual servers |
Also Published As
Publication number | Publication date |
---|---|
WO2015041968A1 (en) | 2015-03-26 |
EP3047400B1 (en) | 2018-12-12 |
US9483517B2 (en) | 2016-11-01 |
EP3047400A1 (en) | 2016-07-27 |
CN105556519B (zh) | 2019-06-25 |
US20150339343A1 (en) | 2015-11-26 |
US20150088822A1 (en) | 2015-03-26 |
US9128972B2 (en) | 2015-09-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105556519A (zh) | 对oracle存储器中数据库的存储器中快照存储的多版本并行控制 | |
CN105556520A (zh) | 在存储器中镜像盘中的数据以提高查询性能 | |
US10268746B2 (en) | Mechanism to run OLTP workload on in-memory database under memory pressure | |
US11126620B2 (en) | Automatic verification and triage of query results | |
US9606921B2 (en) | Granular creation and refresh of columnar data | |
US11119997B2 (en) | Lock-free hash indexing | |
CN109478183B (zh) | 用于数据库中的存储器中单元的非破坏性版本化的方法和设备 | |
US9922086B1 (en) | Consistent query of local indexes | |
Petrov | Database Internals: A deep dive into how distributed data systems work | |
US9811560B2 (en) | Version control based on a dual-range validity model | |
Richardson | Disambiguating databases | |
CN111694847B (zh) | 一种特大lob数据高并发低延迟的更新访问方法 | |
CN113778632B (zh) | 一种基于cassandra数据库的分布式事务管理方法 | |
JP2024514672A (ja) | アペンド専用データ構造を用いるリスト・ベースのデータ検索 | |
Richardson | Disambiguating Databases: Use the database built for your access model. | |
Chen | Google big table |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |