CN103026631A - 用于压缩xml文档的方法和系统 - Google Patents
用于压缩xml文档的方法和系统 Download PDFInfo
- Publication number
- CN103026631A CN103026631A CN201180035113XA CN201180035113A CN103026631A CN 103026631 A CN103026631 A CN 103026631A CN 201180035113X A CN201180035113X A CN 201180035113XA CN 201180035113 A CN201180035113 A CN 201180035113A CN 103026631 A CN103026631 A CN 103026631A
- Authority
- CN
- China
- Prior art keywords
- row
- xml document
- data
- compression unit
- storage
- 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
Images
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
- G06F16/84—Mapping; Conversion
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
提供了一种用于更有效率地存储粉碎的XML文档的方法和装置。该方法和装置利用压缩能力和存储称为列优先格式的关系数据的形式来以粉碎形式存储XML文档。针对每个XML文档单独分析为粉碎的XML文档存储的列值,以确定是否以列优先格式存储特定的列以及使用什么压缩技术(如果有的话)。
Description
优先权
本申请根据巴黎公约第4条要求享有2010年6月1日提交的、题为“Technique for Compressing XML Indexes”的美国申请No.12/791,337的优先权。本申请涉及到:(1)Vineet Marwah等人2010年4月28日提交的、题为“Compression Analyzer”、代理文档号50277-3695的美国申请No.12/769,508;(2)Vikram Kapoor等人2010年4月28日提交的、题为“Storing Compression Units InRelational Tables”,代理文档号为50277-3696的美国申请No.12/769,205;(3)Amit Ganesh等人2009年11月12日提交的、题为“Structure of Hierarchical Compressed Data Structure for TabularData”,代理文档号为50277-3672的美国申请No.12/617,669;以及(4)2009年4月30日提交的临时申请61/174,447。在这里通过引用将这段中提到的所有专利申请的内容并入本文。因此,申请人解除对母申请或其处理历史中权利要求范围的任何弃权,并告知USPTO本申请中的权利要求可以比母申请中的任何权利要求更宽。
技术领域
本发明涉及数据库系统,具体而言,涉及更有效地在数据库系统中存储XML数据。
背景技术
本节中描述的方法是可以寻求、但未必是先前已经想到或寻求的方法。因此,除非另有陈述,不应假设本节中描述的任何方法仅仅由于包括在本节中就限制为现有技术。
可扩展标签语言(XML)是用于表达数据的万维网协会(W3C)标准。很多应用被设计成以XML文档的形式输出数据。XML数据包括形成分级结构的结构化数据项。在XML中,由打开标签和关闭标签对称为元素的数据项划界。元素还可以包括在元素的打开的标签中指定的属性。元素的标签之间的文本可以表示任何种类的数据值,例如字符串、日期或整数。元素可以具有一个或多个子女。参照与用于论述系谱树的那些类似的方面论述XML格式的数据的所得分级结构。例如,子元素被说成起源于其父元素或其父元素所起源的任何元素。父元素被说成是其自己的任何子元素或其后代元素之一的祖先元素。总起来讲,元素连同其属性和后代,称为树或子树。
随着XML的增长和普及,很多关系数据库系统增加了对存储、管理和查询XML内容的支持。术语关系数据库系统是指支持数据处理的关系模型的任何数据库系统,包括可以支持其他数据处理模型,例如对象关系和各种XML标准模型(例如XQuery,XPath)的数据库系统。
存储XML文档的关系数据库系统可以在表格的分开的行中存储各个元素。这里将这样的文档称为粉碎的(shredded)文档。将XML文档分成离散元素值(或其表达)以存储在保存表达XML文档和/或其节点的数据的行中的过程,称为粉碎XML文档。
可以将XML文档完全粉碎到对象关系存储器中、部分粉碎或存储在LOB存储器中并由XML索引定位。如果完全粉碎,则可以由数据库中以关系方式存储的数据完整重建XML文档。如果部分粉碎,则以混合形式在LOB存储器中存储文档,至少一部分文档以对象关系形式,例如以XML索引存储。尽管XML索引中存储的部分可能不表示整个文档,但XML索引可用于高效率地访问被索引的文档的那些部分。可以对来自XML文档的特定字段进行索引,而在索引期间可以忽略来自XML文档的其他字段。
在粉碎XML文档并至少部分以对象关系形式存储时,可以在相同或不同列中的不同行中,或在相同或不同行中的不同列中存储XML文档的值。以对象关系方式存储的值可以包括针对文档的为索引选择的特定字段的值,并可以排除文档的没有为索引选择的其他字段的值。在一个示例中,在索引中同一行中不同列中存储文档中的给定字段的几个值。在另一个示例中,在索引中同一列中不同行中存储文档中的给定字段的几个值。
XML文档的粉碎版本可以具有比以其他形式,例如基于文本的文件存储器中存储的XML文档大得多的存储覆盖区。于是需要更有效率地存储粉碎的XML文档。
数据库和数据库服务器
通常,服务器,例如数据库服务器是集成软件部件和计算资源分配的组合,计算资源例如存储器、节点和节点上用于执行集成软件部件,其中软件和计算资源的组合专用于代表服务器的客户端提供特定类型的功能。数据库服务器支配并促进访问特定的数据库,处理客户端要访问数据库的请求。
数据库包括存储在持久性存储机构,例如一组硬盘上的数据和元数据。例如,可以根据关系型和/或对象关系型数据库构造,以逻辑方式在数据库中存储这样的数据和元数据。数据库元数据定义数据库对象,例如表格、对象表、视图或复杂类型,例如对象类型,重要的是表函数。向数据库服务器发出SQL数据定义语言(“DDL”)指令以创建或配置数据库对象。
通常,在数据库之内以逻辑方式将数据布置成一个或多个数据容器。每个容器都包含记录,并将每个记录之内的数据组织成一个或多个字段。在关系数据库系统中,通常将数据容器称为表格,将记录称为行,将字段称为列。在面向对象的数据库中,通常将数据容器称为对象类型或类,将记录称为对象,将字段称为属性。其他数据库体系结构可以使用其他术语。实施本发明的系统不限于任何特定类型的数据容器或数据库体系结构。不过,为了解释的目的,这里使用的示例和术语应当典型地与关系型或对象关系型数据库相关联。于是,这里应当使用术语“表格”、“行”和“列”分别指代数据容器、记录和字段。
数据块
尽管在数据容器中以逻辑方式布置数据库,但那些容器自身通常存储于例如硬盘上的一个或多个数据块中。因此,例如,尽管大部分用户将向数据库服务器发出通过查询表格、行和列来查询数据的指令或请求,但该数据实际存储在作为数据块的集合的数据库中。通过利用各种存储的元数据、索引和报头,数据库服务器能够将这些数据块之内的数据解释为逻辑表、行和列。
数据块是为存储用于一条或多条数据库记录(例如行)或其部分的原始数据而分配的存储空间基本单位。典型地,数据库系统被配置成从持久性存储器和易失性存储器中以不小于数据块的单位读写数据库记录。在需要检索来自数据块的记录时,将整个数据块读入数据库系统用于暂时存储数据块的存储器中缓冲器中。在很多数据库中,数据块全部是普通大小。数据库管理员基于若干考虑选择这个大小。不过,表格常常包括比能够装入在单个数据块中的数据更多的数据。于是,表格常常跨过很多数据块。
例如,图8示出了如何可以在示例数据块820和830中存储表格800。因为数据块820和830都是小于表格800的预定义大小,所以不能在单个数据块中装入表格800。于是,在两个数据块中存储表格800。
通常将数据块细分成一个或多个这里描述为“数据块行”的连续片段。在由数据库服务器解释时,每个数据块行从至少一部分表格产生数据。如名称“数据块行”所暗示的那样,单个数据块行保持与表格的单行对应的原始数据。不过,在表格行和数据块行之间并非始终有一一对应关系。
例如,表格800由组织成列811-815的行801-805构成。表格行801-805的数据存储在数据块行821-824和831-832中。具体而言,每个数据块行821-824和831-832包括多个字段890。每个字段890对应于来自表格800的单个列值。尽管数据块行821、822、823和832与表格行801、802、803和805分别具有一一对应,但在数据块行824和831之间划分表格行804的数据。在不同数据块中的多个数据块行间划分表格行的数据时,将表格行说成跨过多个数据块链接,并且可以将数据块行统一称为链。
尽管表格中的“行”和数据块中的“行”都通称为“行”,但现在应该明白,两种类型的“行”是不同的概念。为避免混淆,因此在必要时本申请将分别使用术语“表格行”和“数据块行”表示表格的“行”和数据块的“行”。
在一些数据库中,每个数据块行是由行报头划界的。每个行报头可以包含各种元数据,包括用于数据块行的标识符、数据库服务器应当期待从数据块行读出的列数和/或数据块行中每列的大小(由此指示数据库服务器关于数据块行中每个字段的边界)。例如,数据块行821-824和831-832的每个都包括数据块行报头821a-824a或831a-832a。在一些实施例中,替代地插入每列的大小(或长度)作为紧接在数据块行中每个列字段之前的预定义长度的独立字段。
在一些数据库中,(例如,因为大小或列计数的限制)在多个数据块行上链接表格行的数据时,数据库还可以存储将一个或多个数据块行与一个或多个保持同一表格行的数据的其他数据块行相关联的元数据。这种元数据可以在任何位置,例如在行报头、数据块报头中或在数据块行的结尾。例如,数据块行824中的指针829指向数据块行831,其包括表格行804的剩余数据值。
数据块还可以具有报头和/或其他数据结构,描述关于它们保持其原始数据的数据块和/或表格的信息。例如,数据块820和830分别包括报头数据825和835。数据块报头例如可以包括例如表目录的元数据,描述表格的各种质量和其数据块包括数据的表格行。数据块报头还可以例如包括例如行目录的元数据,表示数据块中每个数据块行的起始地址和/或标识符。
在一些数据库中,数据块报头中(或在等效结构中)的元数据可以定义并划界数据块的数据块行。于是,在一些数据库中,数据块行的特征可以是对其地址可以与数据块报头区分的数据块进行最低水平的细分,或者其数据块报头列出可索引标识符的数据块的任何细分。
以称为“行优先(row major)”的格式组织数据块820和830,因此可以将其描述为“行优先数据块”。该格式被称为“行优先”是因为每个数据块行821-824和831-832都包含仅来自表格单个行的数据。其他数据库可以代之以利用其他格式在数据块中存储表格,包括例如“列优先(column major)”的格式。这里描述的技术适用于任何类型的数据块,不论使用何种格式。
注意,表格800和数据块820-830的大小均较小。本申请同样考虑到使用大得多的表格和大得多的数据块。不过,为了清楚起见,这里的示例表格和数据块是相对简单的。
从数据块寻址数据
数据库可以存储各种元数据以辅助数据库服务器解释数据库的数据块中存储的数据。例如,各种索引可以包括将数据库中每个表格与一个或多个数据块相关联的映射数据。作为另一示例,各种索引可以包括将表格行与数据行块相关联的映射数据。
例如,图8的索引850包括表格800中表格行的列表851,连同包含表格行的数据的数据块行的地址852。地址852也可以描述为rowid,均由两个元素构成:由周期之前的数字构成的数据块标识符和由周期之后的数字构成的数据块行标识符。不过,也可以使用其他寻址方案。
数据库服务器可以利用这样的元数据定位存储用于表格和表格行的数据的数据块和/或数据块行。例如,数据库服务器可以要求从图8的表格行801访问数据。利用索引850,数据库服务器可以判定表格行801的数据在数据块820的第一数据块行(即数据块行821)中。数据库服务器然后可以利用数据块标识符到地址映射或算法以在盘上定位数据块820。数据库服务器然后可以利用其他映射数据(例如数据块报头中将数据块行标识符映射到块相对地址的数据)以定位数据块820中第一数据块行的起始。数据库服务器然后可以读取和解释这一行,由此产生针对表格801的数据。
对于数据跨过多个数据库行的表格行,诸如索引850的行索引可以仅指向包括针对表格行的第一部分的数据的数据块行。在判定表格行未被数据块行中的值充分表达时,数据库服务器可以利用诸如指针829之类的元数据断定包括表格行的额外数据的其他数据块行的位置。例如,在定位用于表格行804的数据时,数据库服务器可以首先指向数据块行824。数据库服务器然后可以遵循指针829指向数据块行831,其包括表格行804的剩余数据。
压缩的数据块
在一些数据库中,可以在块级别上压缩每个数据块之内的原始数据。例如,如果在数据块之内“San Jose”一词出现多次,则数据块可以用符号或更小的字符组,例如“1”替换“San Jose”的每次出现,然后存储将“1”与“San Jose”相关联的解压缩词典(也称为符号表)。在数据库服务器解释包含这种压缩值的数据块行时,数据库服务器可以利用解压缩词典解释压缩值。在一些数据库中,针对每个块定位解压缩词典,然后存储于块自身内部(例如,在数据块报头中)。在其他数据库中,在多个数据块之间共享解压缩词典,从而在与多个数据块独立的其自己的块中存储。在下文中将把这样的压缩方案称为“基于块的压缩”。
发明内容
提供了一种用于更有效率地存储粉碎的XML文档的方法和计算机系统。该方法包括向表格中的多个行中加载多个XML文档的每个XML文档,在表格中以粉碎形式存储XML文档。加载所述每个XML文档包括产生多个列的列值,所述列值要存储在表格的多个行中。加载所述每个XML文档还包括:对于所述多个列的每列,分析所述列值以确定用于存储所述列的行存储格式。所述确定包括确定以列优先还是行优先格式存储列值,以及确定是否使用压缩技术来压缩所述列值。加载所述每个XML文档还包括根据所述存储格式的确定在多个行中存储列值。该方法由一个或多个计算设备执行。在一个实施例中,一种计算机程序产品存储指令,该指令在被执行时使得一个或多个处理器执行该方法。
该计算机系统包括向表格中的多个行中加载多个XML文档的每个XML文档的装置,在表格中以粉碎形式存储XML文档。用于加载所述每个XML文档的装置包括用于产生多个列的列值的装置,所述列值要存储在表格中的多个行中。用于加载所述每个XML文档的装置还包括用于针对所述多个列的每个列分析所述列值以确定用于存储所述列的行存储格式的装置。用于分析的装置包括用于确定以列优先还是行优先格式存储列值的装置,以及用于确定是否使用压缩技术压缩所述列值的装置。用于加载所述每个XML文档的装置还包括用于根据存储格式的所述确定在多个行中存储列值的装置。
附图说明
在附图的图中以举例的方式而非限制方式例示本发明,其中类似的附图标记指示类似元件,且其中:
图1示出了根据本发明实施例的用于单独地分析针对XML文档产生的列值并确定主导格式和压缩技术的流程;
图2是压缩单元的方框图;
图3是在这里提供的示例中提到的表格的方框图;
图4是示出了两层压缩单元的方框图;
图5是示出了可以如何在图3中所示的压缩单元中存储图2所示表格的表式数据的方框图;
图6是示出了子压缩单元如何可以自己具有子压缩单元的方框图;
图7是示出了如何将压缩单元报头分成两个部分的方框图,其一是未压缩的,其一是压缩的;
图8示出了如何可以在示例数据块中存储未压缩的表格;以及
图9是可以在其上实施本发明的实施例的计算设备的方框图。
具体实施方式
在以下描述中,为了解释的目的,阐述了众多具体细节,以便提供对本发明的透彻理解。不过,将要明了的是,可以无需这些具体细节来实践本发明。在其他情况下,以方框图形式示出了公知的结构和设备以避免不必要地使本发明模糊不清。
一般概述
这里描述的是更有效率地存储粉碎的XML文档的机制。该机制利用压缩能力和存储称为列优先格式的关系数据的形式来以粉碎形式存储XML文档。针对每个XML文档单独分析为粉碎的XML文档存储的列值,以判断是否以列优先格式存储特定的列以及使用什么压缩技术(如果有的话)。
在具有一组所枚举大小(例如4k数据块,32k数据块)之一的持久存储单元中持久存储数据库中的数据。在持久存储单元中存储行有几种形式:行优先和列优先。在行优先格式中,在持久存储器的单位,例如数据块之内连续地存储单个行的列值。在列优先格式中,连续存储一列多个行的值。这里将行优先格式或列优先格式统称为优先格式。
在列优先格式中,重新布置输入数据,从而将属于一个列的数据放在一起。由于一个列中的数据非常可能相似,这减小了熵,因此实现了更好的压缩比。这类似于垂直划分或列式存储。
列优先格式具有允许更好的可压缩性的优点。列之内的值可以具有共同性质,使得在连续存储值时,可以利用各种压缩技术采用公共性质。这里将列优先的格式和使用的压缩技术(如果有的话)称为存储格式。
根据本发明的实施例,在粉碎XML文档时,分析要存储在保持粉碎XML文档的行中的列值以确定存储格式,即是否和/或如何以行优先或列优先格式存储行,以及应用什么压缩技术(如果有的话)。通过这种方式,单独分析针对列和特定XML文档的列值,以确定针对保存该XML文档的数据的行的存储格式。
在数据库系统的语境之内例示了本发明的实施例,该数据库系统支持数据的关系存储、查询和操作,并支持根据XML标准存储和查询XML数据。因此,描述这样的数据库系统是有用的。
数据库系统
数据库管理系统(“DBMS”)管理数据库。数据库管理系统可以包括一个或多个数据库服务器。数据库包括存储在持久性存储机构,例如一组硬盘上的数据和元数据。元数据定义数据库对象,例如关系表格、表格列、视图和触发器。
数据库应用和客户端通过向数据库服务器提交命令来与数据库服务器交互,命令让数据库服务器对数据库中存储的数据执行操作。数据库命令可以是符合数据库语言的数据库语句的形式。用于表达数据库请求的语言是结构化查询语言(SQL)。有很多不同版本的SQL,一些版本是标准的,一些是专有的,并且有多种扩展。向数据库服务器发出SQL数据定义语言(“DDL”)指令以创建或配置数据库对象,例如表格、视图或复杂数据类型。SQL/XML是在对象关系型数据库中操纵XML数据时使用的SQL的公共扩展。尽管基于Oracle的SQL描述示例,但这里提供的技术不限于任何特定版本的SQL。
XML存储
各种存储机制用于存储XML文档。一种存储机制将XML文档存储为文件系统中的文本文件。如前所述,另一种用于存储XML文档的机制是数据库服务器。在数据库服务器中,可以在表格的行中存储XML文档,并在行中的单独列中存储XML文档的节点。也可以在列中以lob(大对象)存储整个XML文档。可以粉碎XML文档并作为对象的分级结构存储在数据库中;每个对象都是对象类的实例并存储XML文档的一个或多个元素。这里将保持XML数据的表格和/或数据库系统的对象称为基础表格或对象。
二进制编码的XML是另一种形式,其中可以在数据库中存储XML数据。二进制编码的XML是XML的紧凑二进制表达,被设计成减小XML文档的大小。二进制编码的XML压缩数据的方式之一是利用固定值表达字符串(“令牌”)。
XML索引
存储XML数据的数据库服务器可以包括很多机构,允许用更强大和有效的方式查询XML文档的大集合。可以增强存储XML文档的数据库服务器以利用这些机构有效率地执行XML操作。数据库服务器可以维持对很多XML文档进行索引的“逻辑索引”,这里称为XML索引。
XML索引包含多种结构,协作地使用它们以访问很多XML文档。一种这样的结构是存储粉碎的文档的关系型表格。这样的关系型表格用于例示本发明的实施例。
具体而言,XML索引可以包括称为路径表格的表格。路径表格存储粉碎的文档,这里称为已索引文档。路径表格的每行包含用于已索引文档的节点的数据。并非已索引文档的所有节点都具有路径表格中的对应行。
每个路径表格行都包含多个列,行的每个列都包含与节点相关联的一条信息。一些列值可能受到列优先格式下压缩的作用。
根据实施例,路径表格的列包括用于(1)表示通往节点的PATHID的列,(2)用于在基础结构之内定位针对节点的片段数据的“位置数据”的列,以及(3)表示包含节点的XML文档的结构分级体系之内节点位置的“分级结构数据”的列。可选地,PATH表格可以包括包含针对与值相关联的那些节点的值信息的列。这些类型的信息的每个都将在下文更详细地加以描述。
路径ID
根据实施例,为已索引XML路径的每个分配唯一的路径ID。例如,如下表所示,可以为po⒈xml和po⒉xml中存在的路径分配路径ID:
路径ID | 路径 |
41 | /PurchaseOrder |
41.54 | /PurchaseOrder/Reference |
41.34 | /PurchaseOrder/Actions |
41.34.33 | /PurchaseOrder/Actions/Action |
41.34.33.77 | /PurchaseOrder/Actions/Action/User |
可以使用各种技术识别路径并向路径分配路径ID。
位置数据
与节点相关联的位置数据表示包含节点的XML文档驻留在基础结构中的哪里。于是,位置数据的性质将基于基础结构的性质在实施方式之间变化。根据如何存储实际的XML文档,位置数据还可以包括指向XML文档的定位器或逻辑指针。可以使用逻辑指针来提取与XPath识别的节点相关联的片段。
分级结构数据
用于节点的PATH表格行还包括表示节点位于包含该节点的XML文档分级结构之内的哪里的信息。这里将这样的分级信息称为节点的“OrderKey”。
根据一个实施例,利用Dewey型值表示分级次序信息。具体而言,在一个实施例中,通过向节点中间父亲的OrderKey附加值来创建节点的OrderKey,其中附加的值表示该特定子节点在父节点的子女间的位置。
根据一个实施例,将每个OrderKey表示的合成数转换成可与字节比拟的值,使得两个OrderKeys之间的数学比较表示OrderKeys对应的节点在XML文档的分级结构之内的相对位置。
值信息
已索引文档之内的一些节点可以是属性节点或对应于简单元素的节点。根据一个实施例,对于属性节点和简单元素,PATH表格行还存储属性和元素的实际值。例如,可以在路径表格的“值列”中存储这样的值。在值列上构建下文将更详细描述的辅助“值索引”。
路径表格示例
利用包括如下定义的列的路径表格示例例示本发明的实施例:
如上所述,PATHID是分配给节点的数字,唯一地表示通往该节点的完整扩展路径。ORDER_KEY是与节点相关联的DEWEY排序数字的系统表示。“值”列存储针对简单元素(即没有元素子女)节点和属性节点的有效文本值。
在下文参考以下两个例示性XML文档给出路径表格的示例:
po1.xml
po2.xml
下表是利用针对po⒈xml和po⒉xml的条目填充的路径表格示例的行的示例。具体而言,路径表格的每行对应于po⒈xml或po⒉xml的已索引节点。
填充的路径表格示例
在本示例中,行1-5存储po⒈xml的粉碎版本。行6-12存储po⒉xml的粉碎版本。在存储这些XML文档的基础表格中,两个文档都存储在同一块346中,但在块之内不同的行中。
当在数据块之内连续存储路径表格中特定列的列值时,可以利用值之间的公共性质进行压缩。例如,RID中的值可能受到游程编码(RLC)。游程编码是形式非常简单的数据压缩,其中将数据的运转(亦即,在很多连贯数据符号中出现同样数据值的序列)存储作为单个数据值和计数,而不是作为初始运转。此外,可以为不同XML文档的相同列使用不同的压缩技术。在同一路径频繁出现的XML文档中,可以使用游程编码的方案。在高度嵌套的文档中,由众多节点共享同一路径前缀,基于前缀的压缩方案可能更有效率。通过仅存储前缀一次来压缩具有相同前缀的所有路径ID。
压缩单元
如前所述,在具有一组枚举大小之一的持久存储单元(例如数据块)中持久存储数据库中的数据。根据本发明的实施例,这里将存储单元称为压缩单元。压缩单元是高度灵活的结构,用于物理地存储表格式数据,例如表格的行。
根据实施例,每个压缩单元存储针对对应表格所有列的数据。例如,如果表格具有二十个列,那么针对该表格的每个压缩单元将存储针对不同行的数据,但那些行的每个将具有针对全部二十个列的数据。在压缩单元之内,可以按照列优先格式或行优先格式存储数据。
不过,对于表格中的一组行,可以基于列在压缩单元之间划分针对行的数据。于是,一些压缩单元可以通过列优先格式存储针对表格第一列的数据,一些可以通过列优先格式存储表格第二列的数据,而其他压缩单元以行优先格式存储针对表格第三和第四列的数据。在这样的实施例中,可以在几个压缩单元之间扩展表格的单个行。重要的是,存储数据第一列的压缩单元可以使用与用于压缩保存第二列的压缩单元中的数据的压缩算法不同的压缩算法。可以在Structure ofHierarchical Compressed Data Structure for Tabular Data中找到压缩单元的更多详情。
根据本发明的实施例,在粉碎要存储在路径表格中的XML文档时,研究并分析要存储在特定列中的值以确定使用什么优先格式,以及要使用什么压缩技术(如果有的话)。研究表格中每列的所有列值。通过这种方式,单独分析各个XML文档以确定特定于XML文档的存储格式。
图1是示出了粉碎XML文档并确定存储格式的这种流程的图示。根据实施例,可以由已被增强以处理XML存储的数据库服务器执行步骤。在于路径表格中加载XML文档的语境中例示步骤。
参考图1,在105,数据库服务器接收XML文档,从而以粉碎形式存储。
在110,数据库服务器粉碎XML文档以产生要存储在XML索引中的值。对于每个要在其中存储的节点,产生针对行的列值。这些包括针对列PATHID、RID、ORDER_KEY、定位符、值的值。
在115,数据库服务器分析列值以确定用于行的行存储格式,亦即,为一个或多个或全部列使用行优先格式,是否为一个或多个列使用列优先格式,以及使用什么压缩技术。例如,对于基础表格中存储的大文档,有大量节点要存储在路径表格中,它们全都具有针对RID列相同的值。因此,使用利用游程压缩的列优先格式。对于PATH ID列,可能有大的具有节点的子树,其节点的路径通过同一根和紧接着的后代节点上升。如前所述,可以利用例如游程或基于压缩前缀的压缩以列优先格式存储针对PATH ID的列。在单个数字表示整条路径的情况下,可以应用任何标准的数字压缩方案(数字、二进制值等的游程编码)。
在120,数据库服务器根据在步骤115中确定的存储格式在数据库中存储列值。在实施例中,利用行批量插入功能或流程存储行,调用该功能或流程以向同一组压缩单元中存储一批行。压缩单元是数据库中数据块的一种形式。仅利用批中的行填充数据块。行批量插入功能接受用于控制特定列的优先格式的参数以及要使用的压缩技术。
利用这里所述的技术进行特定于文档的存储格式化,路径表格中存储的不同XML文档的存储格式可能不同。一个XML文档的行可以全部以行优先格式存储。对于第二个XML文档,行可以具有均处在列优先格式的列。对于存储第三XML文档的行,以列优先格式存储对于第二文档而言相同的列,但利用至少一种不同的压缩技术压缩。
在压缩单元中存储表式数据——更多细节
使用计算机存储和管理很多类型的数据。表式数据是计算机用于管理的一种通常形式的数据。表式数据是指逻辑地组织成行和列的任何数据。例如,字处理文档常常包括表格。存在于这种表格中的数据为表式数据。任何电子数据表或电子数据表那样的结构中包含的所有数据也是表式数据。此外,关系型表格或类似数据库结构中存储的所有数据都是表式数据。
从逻辑上讲,表式数据存在于像表格那样的结构中,例如电子数据表或关系型表格。不过,表式数据的实际物理存储可以采取多种形式。例如,来自电子数据表的表式数据可以存储于电子数据表文件中,电子数据表文件又存储于由操作系统管理的一组盘存储块中。作为另一示例,属于关系型数据库表格的表式数据可以存储于由数据库服务器管理的一组盘存储块中。
如何物理地存储表式数据可能对(1)表式数据消耗多少存储空间以及(2)可以以多高效率访问和操作表式数据有显著影响。如果以低效式物理存储,则表式数据可能比期望的消耗更多存储空间,导致检索、存储和/或更新时间缓慢。
表式数据的物理存储常常涉及大小和速度之间的折衷。例如,可以存储压缩或未压缩的电子数据表文件。如果是压缩的,则电子数据表文件将更小,但在检索时通常必须要解压整个文件,在再次存储时重新压缩。这样的解压和压缩操作耗费时间,导致性能更慢。
在表式数据包括各种不同类型的数据项时,特别难以实现最佳压缩/性能的平衡。例如,电子数据表可以包括一些含字符串的列,一些含图像的列,其他包含二进制的是/否指示的列。可以利用特定的压缩技术高度压缩字符串,但向电子数据表中其他类型的数据应用同一压缩技术可能没有益处。另一方面,可以利用在用于字符串时不产生益处的压缩技术高度压缩电子数据表中所含的图像。在诸如这些环境下,无论用户是否选择利用技术之一压缩电子数据表文件或根本不压缩,结果都必然是欠佳的。
提供高度灵活和可扩展的结构以物理地存储表式数据。这里称为“压缩单元”的结构可用于物理地存储逻辑上位于任何类型的表格样结构中的表式数据。例如,可以使用压缩单元存储来自电子数据表、关系型数据库表格或嵌入字处理文档中的表格的表式数据。对于存储于压缩单元中的表式数据所属的逻辑结构的性质没有限制。
根据一个实施例,压缩单元是递归的。于是,压缩单元可以具有其所属的“父”压缩单元,可以具有一个或多个属于它的“子”压缩单元。对可用于存储表式数据的压缩单元的递归层级数没有限制。出于解释的目的,这里将没有父压缩单元的压缩单元称为“顶层”递归单元,而这里将没有子压缩单元的压缩单元称为“底层”压缩单元。
根据实施例,每个顶层压缩单元存储针对对应表格的所有列的数据。例如,如果表格具有二十个列,那么针对该表格的每个顶层压缩单元将存储针对不同行的数据,但那些行的每个将具有针对全部二十个列的数据。不过,在替代实施例中,即使在顶层,也可以基于列在压缩单元之间划分来自表格的数据。于是,一些顶层压缩单元可以存储针对表格的前十个列的数据,而其他顶层压缩单元存储针对表格的随后十个列的数据。在这样的实施例中,可以在几个顶层压缩单元之间扩展表格的单个行。
在一个实施例中,压缩单元包括表示如何在它们之内存储表式数据的元数据。用于压缩单元的元数据可以表示,例如,以行优先还是列优先格式(或其某种组合)存储压缩单元之内的数据,压缩单元之内列的次序(可以与它们的逻辑容器的定义指定的列的逻辑次序不同),用于压缩单元的压缩技术,子压缩单元(如果有的话)等。
下面还描述了用于向压缩单元中存储表式数据、从压缩单元检索数据以及更新压缩单元中表式数据的技术。根据一个实施例,采用技术避免改变现有压缩单元之内的表式数据。例如,仅仅通过跟踪删除请求而不实际删除数据来避免删除压缩单元之内的表式数据。作为另一示例,通过在压缩单元外部存储新数据避免了向现有压缩单元中插入新的表式数据。如果删除的数目超过阈值,和/或新插入的数目超过阈值,则可以产生新的压缩单元。在产生新的压缩单元时,可以丢弃先前存在的压缩单元以回收存储器,或保持其以允许重建表式数据的在先状态。
压缩和未压缩部分
图2是根据一个实施例的压缩单元200的方框图。在图2所示的实施例中,压缩单元200具有两个主要部分:未压缩部分202和压缩部分204。通常,未压缩部分202包括关于压缩部分204的内容和格式的元数据。未压缩部分202例如可以指示使用什么压缩技术(如果有的话)压缩压缩部分204的内容以及如何组织未压缩部分202的内容。
例如,假设使用压缩单元200存储来自图3所示表格300的表式数据。表格300具有三个列A、B、C和十行R1-R10。为了解释的目的,假设来自表格300的所有数据都存储在压缩单元200中,且压缩单元200既是顶层压缩单元(没有父压缩单元)又是底层压缩单元(没有子压缩单元)。在这些情况下,压缩单元200的未压缩部分202可以简单地包括:
·用于压缩压缩部分204的内容的压缩技术(如果有的话)的指示;以及
·压缩单元200是底层压缩单元(因此没有子压缩单元)的指示。
尽管这两条信息足以允许使用压缩单元200,但替代实施例包括额外几条元数据以提供更大的灵活性和可扩展性。例如,在一个实施例中,在任何压缩单元之内,可以按照列优先格式或行优先格式存储表式数据。在以行优先格式存储时,表式数据会以序列IMAGE1A、IMAGE1、IMAGE1C、IMAGE2A、NAME2、IMAGE2C等存储于压缩部分204之内。另一方面,在以列优先格式存储时,表式数据会以序列IMAGE1A、IMAGE2A、IMAGE3A……NAME1、NAME2、NAME3……IMAGE1C、IMAGE2C、IMAGE3C等存储于压缩部分204之内。在允许基于逐个压缩单元做出列优先/行优先选择的实施例中,未压缩部分202还可以包括压缩部分204中包含的表式数据以行优先还是列优先格式存储的指示。在一个实施例中,为了节省空间,压缩单元不包括其数据包含于压缩单元中的列的名称。此外,压缩单元可以存储或不存储其数据包含于压缩单元中的行的rowid(行id)。
递归结构
如上所述,这里将描述压缩单元是递归结构的实施例。于是,压缩单元可以具有父压缩单元和任意数量的子压缩单元。在上文给出的示例中,压缩单元200没有任何子压缩单元。不过,在压缩单元200具有子压缩单元的情况下,压缩单元200可以包括报头,报头具有关于子压缩单元的信息。用于压缩单元200的报头可以在未压缩部分202中存储,或在未压缩部分202和压缩部分104之间划分。
在图4所示的情况下,压缩单元200具有两个子压缩单元400和410。如图所示,子压缩单元400和410与其父压缩单元200具有相同的通用结构。亦即,类似于压缩单元200,子压缩单元400和410包括未压缩部分和压缩部分。此外,压缩单元400和410完全处于其父压缩单元200的压缩部分204之内。因此,在压缩单元200的级别上向压缩部分204应用的任何压缩都适用于压缩单元400和410的整体。
因为父压缩单元的压缩适用于其子压缩单元的整体,所以实际上即使是子压缩单元的未压缩部分402和412也可以压缩。于是,压缩单元的“未压缩”部分仅仅相对于该部分所在的级别是未压缩的(但基于应用于较高级别压缩单元的压缩可以是压缩的)。相反,压缩单元的压缩部分相对于该部分所在的级别是压缩的(除了应用于更高级别的压缩单元的任何压缩之外)。
根据一个实施例,在压缩单元200是一个或多个子压缩单元的父压缩单元时,压缩单元200的报头包括额外信息。例如,在一个实施例中,压缩单元200的报头指示(a)每个子压缩单元开始的偏移,以及(b)每个子压缩单元中包含的数据。
例如,假设特定的压缩技术CT1在压缩图像方面特别好。在这种情况下,可能希望利用压缩技术CT1将图像压缩在表格300的列A和C中,同时利用不同的压缩技术CT2压缩列B的字符串。为了利用两个子压缩单元400和410实现这种压缩组合,可以使用压缩单元400存储来自列A和C的图像,同时使用压缩单元410存储来自列B的字符串。图5中示出了这种数据分布。
根据一个实施例,为了指示图5中所示数据的分布,父压缩单元200的报头会指示以列优先格式存储压缩部分204之内的数据,而在压缩单元400中存储列A和C,在压缩单元410中存储列B。压缩单元400的未压缩部分402又会指示压缩技术CT1应用于压缩部分404。类似地,压缩单元410的未压缩部分412会指示压缩技术CT2应用于压缩部分414。
因为压缩单元具有递归性质,所以压缩单元400和410自己可以是一个或多个子压缩单元的父压缩单元。例如,在图6中,压缩单元400被示为具有两个子压缩单元600和610。压缩单元600存储来自针对行R1到R5的列A到C的图像,而压缩单元610存储来自针对行R6到R10的列A到C的图像。因为压缩部分404之内的数据基于行而分布于压缩单元600和610之间,所以压缩单元400的未压缩部分402表示在压缩单元400的级别上,表式数据被组织成行优先格式。
在本示例中,压缩单元600和610是顶层压缩单元200以下两层的底层压缩单元。另一方面,压缩单元410是位于顶层压缩单元200以下一层的底层压缩单元。于是,在一个实施例中,根据表式数据如何分布于压缩单元之间,存储针对同一表格的表式数据的底层压缩单元可以在不同的深度。
描述压缩单元的内部组织的元数据
因为可以通过几乎无穷大数量的方式组织压缩单元之内的信息,所以维护元数据以指示如何组织每个压缩单元。根据实施方式,可以在压缩单元外部或压缩单元之内存储关于压缩单元之内表式数据的组织的元数据。在存储于压缩单元之内时,元数据可以在未压缩部分、压缩部分中存储或在两者之间划分。存储元数据的实际方式可以在实施方式之间有变化。
根据一个实施例,在压缩单元之内的报头中存储描述压缩单元之内表式数据的组织的元数据,元数据包括未压缩报头部分700和压缩报头部分730,如图7所示。在一个实施例中,根据以下结构组织报头:
在根据这种报头结构在压缩单元之内存储元数据的实施例中,初始“长度”字段702存储表示压缩单元的压缩大小的元数据。在当前语境中,“压缩大小”表示在所含有的任何数据被解压缩之前由压缩单元占据的存储量。不过,一些压缩单元可能未实际压缩数据。在这种情况下,“压缩大小”会与未压缩大小相同。
在图7所示的实施例中,长度字段702之后是一系列标志704。标志704表示报头是否包含特定字段。在与字段相关联的标志表示不存在字段时,那么该字段与特定压缩单元不相关,或为该字段采用某个“默认”值。在下文将更详细地论述标志704及其对应字段。
版本标志和字段
“flag_version_number”(版本号)标志表示报头中是否存在版本号字段706。在管理表式结构的应用(例如数据表程序、文字处理器或关系数据库系统)支持版本化的情况下,可以使用版本号字段706。在支持版本化的系统中,使用版本号字段706存储表示压缩单元之内包含的表式数据的版本的值。根据一个实施例,假设子压缩单元与和其父压缩单元相同的版本相关联,因此仅需要在顶层压缩单元中使用版本号字段706。
DATA_OR_UNITS标志和字段
“flag_data_or_units”(数据或单元)标志表示压缩单元是否包括与子压缩单元相关的字段。在图7所示的实施例中,这样的字段包括压缩报头部分730之内存储的“所含单元信息”。如果压缩单元是底层压缩单元,那么压缩单元将没有任何子压缩单元,因此将没有也不需要任何与子压缩单元相关的报头字段。
COL_ORDER标志和字段
“flag_col_order”(列次序)标志表示报头是否包含列次序矢量712。如果flag_col_order标志为假,那么假设按照与“父列次序”相同的列次序在压缩单元之内组织列。对于子压缩单元,父列次序是由其父压缩单元指定的列次序。对于顶层压缩单元,列次序是由表式结构自身定义的列次序。
例如,为表格300定义的列次序是A、B、C。因此,对于压缩单元100,即顶层压缩单元的父列次序是A、B、C。如果针对压缩单元100的flag_col_order标志为假,那么将假设压缩单元100之内的列次序为A、B、C。不过,如图4所示,在压缩单元100之内,列被排序为A、C、B(其中列A和C存储在子压缩单元300中)。于是,对于压缩单元100,flag_col_order将为真,压缩单元100会具有列次序矢量612以指示父列次序A、B、C和新列次序A、C、B之间的映射。
列次序矢量712可以通过各种方式指示列次序之间的映射。根据一个实施例,列次序矢量712中的位置对应于父列次序中的列。于是,列次序矢量712之内的第一、第二和第三位置分别对应于列A、B和C。不过,在列次序矢量712中的那些位置存储的值表示列的新次序。例如,在由压缩单元200规定的新列次序(A、C、B)中,列A仍然是第一个列。于是,列次序矢量的第一位置会存储“1”。
另一方面,在压缩单元200规定的新的列次序(A、C、B)中,列B现在是序列中的第三个。因此,列次序矢量712中的第二位置会存储值“3”。
最后,在压缩单元200规定的新的列次序(A、C、B)中,列C现在是序列中的第二个。因此,列次序矢量712中的第三位置会存储值“2”。
于是,压缩单元200之内的列次序矢量“1,3,2”会表示压缩单元200将来自父列次序的列的次序A、B、C改变为新的列次序A、C、B。
通过这种方式重新映射父列次序的元数据仅仅是可用于表示压缩单元之内使用的列序列的元数据的一个示例。可以使用很多替代方案。例如,报头可以简单地存储列标识符的序列,其中列标识符唯一地标识列,标识符的序列表示压缩单元之内列数据的序列。
未压缩标志和字段
“flag_uncompressed”(未压缩)标志表示单元压缩还是未压缩的。如果未压缩标志为真,那么压缩单元的“压缩部分”在当前级别上实际不是压缩的。不过,如上所述,如果“未压缩的”压缩单元是未应用压缩的任何压缩单元的后代,则它仍然可以是压缩的。类似地,“未压缩的”压缩单元可以在应用压缩的子压缩单元中存储数据。于是,未压缩标志仅表示相对于标志所属的压缩单元的级别是否发生压缩。
如果未压缩标志为真,那么压缩单元的报头将没有压缩算法字段714。另一方面,如果未压缩标志为假,那么压缩单元的报头将包括压缩算法字段714。在有压缩算法字段时,压缩算法字段714指示用于压缩压缩单元的压缩部分的压缩算法。
用于压缩压缩单元的压缩部分的压缩算法与可由任何父压缩单元应用的任何压缩不同,并与可由任何子压缩单元应用的任何压缩不同。例如,压缩单元200的报头可以指示使用压缩技术X压缩压缩单元200的压缩部分204。压缩单元400的报头可以指示使用压缩技术Y压缩压缩单元400的压缩部分404。最后,压缩单元410的报头可以指示压缩单元410的压缩部分414实际未压缩。在这些条件下,压缩部分404之内的数据将实际被双倍压缩,首先利用压缩技术Y压缩为压缩部分404的一部分,然后利用压缩技术X压缩为压缩部分204的一部分。
NUM_COL_LESS_THAN_256标志和字段
“flag_num_col_less_than_256”(列数目小于256)标志表示列的数目是否小于256。如果这个标志为真,将一个字节用于列数,而不是两个。在这种情况下仅使用一个字节表示列数是减小压缩单元总大小的另一种方式。
NUM_COLS标志和字段
“flag_num_cols”(列数目)标志表示单元是否包含关于单元中所含的列的数目的信息。Flag_num_cols标志可以为假,例如,如果压缩单元与其父压缩单元具有恰好相同的列数。对于顶层压缩单元,如果压缩单元包含压缩单元为其存储表式数据的电子数据表和/或表格的所有列,则flag_num_cols可以为假。
在图5中所示的示例中,压缩单元200的flag_num_cols将为假,因为压缩单元200具有表格300的所有列。不过,压缩单元400和410的flag_num_cols将都为真,因为它们不具有与其父压缩单元200相同的列数。
NUM_ROWS标志和字段
“flag_num_rows”(行数)标志表示单元是否包含关于压缩单元中所含的行的数目的信息。类似于“flag_num_cols”标志,如果(a)压缩单元存储其父压缩单元的所有行,或(b)压缩单元是存储压缩单元为其存储表式数据的电子数据表和/或表格的所有行的顶层压缩单元,flag_num_rows标志可以为假。
在图5中所示的示例中,压缩单元200、400和410的flag_num_rows标志将为假,因为它们全都具有表格300的所有行。不过,在图6的压缩单元600和610中,flag_num_rows标志将为真,因为压缩单元600和610具有其父压缩单元400的行的子集。
DELVEC标志和字段
Flag_delvec(删除向量)标志表示报头中是否有删除向量字段718。下文将更详细地描述,删除矢量字段718可用于存储删除矢量,删除矢量表示已经从压缩单元删除该信息而实际未删除对应的数据。
校验和标志和字段
Flag_checksum(校验和)标志表示压缩单元中是否有行校验和。行校验和可用于判断数据是否被破坏。不过,行校验和消耗空间,因此在一些情况下或实施方式中可以省略。
MORE_FLAG_BYTES标志
Flag_more_flag_bytes(更多标志字节)标志表示报头中是否存在更多的标志字节。当前报头将来支持额外标志的能力提高了压缩单元结构的可扩展性。例如,如果将来判定向压缩单元的报头增加五个新标志可能显著改善性能,那么可以向新的压缩单元增加那些新标志而不带来与现有压缩单元的兼容性问题。
具体而言,新扩展的压缩单元会将flag_more_flag_bytes设置为真,向现有应用表示存在更多标志。因此,这们的新标志的存在不应使设计成与较老压缩单元格式一起工作的应用被干扰。另一方面,设计成利用新标志的应用不会受到没有新标志的压缩单元干扰,因为那些压缩单元将把flag_more_flag_bytes设置为假。
如果flag_more_flag_bytes为真,那么在一个实施例中,新的标志字节紧随前两个标志字节。新一组标志字节中的最后一个标志可以是又一个flag_more_flag_bytes标志。通过在每组标志字节的结尾包括这样的标志,可以无限期地扩展报头中使用的标志字节的数量,以允许在将来需要支持任意数量的标志时能够扩展报头。
包含的单元信息
如果压缩单元不包含更小的单元,那么用于该单元的(压缩)数据处于该单元的压缩部分的开始,紧随压缩单元报头700。另一方面,如果压缩单元不包含更低级别的单元,那么代替以数据开始,单元的压缩部分以具有关于所包含单元的信息的(压缩的)数据结构开始。图7中将这种所包含单元结构的一个实施例例示为所包含单元信息730。
在图示的实施例中,所包含单元信息730以标志722开始。在一个实施例中,第一个标志表示是基于行还是列划分单元。第二个标志表示是否每个单元有一个列。于是,如果所包含单元信息730是用于包含三个列A、B和C的压缩单元,且每个列都处于不同的子压缩单元中,那么标志722的第一个标志表示基于列划分数据,标志722的第二个标志表示每个子压缩单元有一个列。
另一方面,如果所包含单元信息730是用于包含三个列A、B和C的压缩单元,但列A和C处于相同的子压缩单元中,那么标志722的第一个标志表示基于列划分数据,标志722的第二个标志表示每个子压缩单元没有一个列。
在图示的实施例中,标志722之后是若干单元字段724。单元字段724的数目表示子压缩单元的数目,并且根据子压缩单元的数目,可以是一个字节或两个字节长。
根据数据是以行还是列划分,单元字段724的数目之后是从行到单元或从列到单元的映射726。例如,图5所示的用于压缩单元200的映射726表示列A和C存储在子压缩单元400中,列B存储在子压缩单元410中。另一方面,图6所示的用于压缩单元400的映射726表示行R1-R5存储于子压缩单元600中,行R6-R10存储于子压缩单元610中。
在列优先和行优先的情况下,映射726可以是一个或两个字节的矢量,长度等于所包含单元的数目。在一个实施例中,矢量中的每一条目都是对应子压缩单元中行或列的数目。于是,如果列映射具有条目2、5和3,那么第一单元包含以报头中预先指定的次序的前两个列,然后第二单元包含接下来五个列,第三单元包含接下来三个列。如果每个单元有一个列,那么可以消除单元数目和列映射。
所包含单元信息730以指针728结束,指针728指向每个所包含压缩单元的报头。根据一个实施例,这些指针相对于未压缩单元的开始。指针相对于未压缩单元的开始是因为,为了利用包括指针728的所包含单元信息730,压缩单元的压缩部分将已经是未压缩的。
获得压缩单元中存储的表式数据
压缩单元的递归性质允许在很多级别的每个上压缩表式数据。例如,在底层压缩单元之内,可以利用游程编码压缩数据。该底层压缩单元可以是利用LZO压缩来压缩底层压缩单元(以及其压缩部分中任何其他内容)的中间级压缩单元的子压缩单元。该中间级压缩单元可以是利用BZIP2压缩来压缩中间级压缩单元(以及其压缩部分中任何其他内容)的顶层压缩单元的子压缩单元。
为了获得表式数据,必须要按照相反的时间次序取消各种压缩操作。在上文给出的示例中,必须要利用BZIP2解压缩来对数据解压缩,然后利用LZO解压缩来解压缩,然后利用游程解码来解压缩。因为每次解压缩操作都消耗资源,所以希望仅执行任何特定操作必需的解压缩操作。
例如,假设为与表格300的行R1到R10相关联的名称做出请求。如图5所示,那些名称在列B中,其存储于子压缩单元410中。于是,为了获得名称,将对压缩部分204解压缩。一旦解压缩,就可以读取压缩部分204之内的所包含单元信息以判定列B存储于压缩单元410中。接下来是指向压缩单元410的指针以找到用于压缩单元410的报头。存储于未压缩部分412中的报头包含表示压缩部分414如何被压缩的元数据。然后可以对压缩部分414解压缩以获得名称。
显著地,在从列B获得名称的过程期间,压缩单元400的压缩部分404不是未压缩的,因为压缩部分404没有要从行R1到R10获得名称必需的任何数据或元数据。相反,如果请求的是图像而不是名称,就不得不对压缩单元400的压缩部分404解压缩,而压缩单元410的压缩部分414将不会被解压缩。
删除压缩单元中存储的表式数据
根据一个实施例,响应于对对应表格执行的操作,向压缩单元中删除、插入并直接更新表式数据。不过,通过对数据自身执行这样的操作,由于需要在做出变化之前对数据解压缩,然后在做出变化后对数据重新压缩,导致出现开销。
在一个实施例中,使用删除矢量字段718中的删除矢量(图7中所示)从表格删除行,而不从压缩单元实际删除该行包含的数据。例如,假设特定的压缩单元存储用于1000行的数据。对应的删除矢量可以包括1000比特,其中比特的位置表示该比特对应的行。如果接收到从压缩单元删除第10行的请求,那么设置删除矢量的第10个比特以表示删除了对应行。不过,未从压缩单元的压缩部分实际删除针对第10行的实际数据。
通过这种方式处理删除获得了多种益处。例如,通过利用删除矢量,删除不会导致与压缩单元(以及其中包含的任何更低分级的压缩单元)的压缩部分的解压缩相关联的开销,因为删除矢量处于压缩单元的未压缩部分中。
此外,解压缩开销不是利用删除矢量避免的唯一开销。具体而言,如果对压缩部分解压缩以消除删除矢量,那么在消除行数据之后必须要对压缩部分重新压缩,由此导致更多开销。此外,在一些情况下,从压缩的数据集删除数据可能实际上增大数据的压缩大小。
在一个实施例中,并不是在所有压缩单元的报头中包括删除矢量,删除矢量仅包括在顶层压缩单元中。检查顶层删除矢量指示已经删除了哪些行,而无需访问任何低层压缩单元的报头。
根据一个实施例,如果删除的行数超过特定阈值,那么重新写入整个压缩单元。例如,如果比特矢量指示压缩单元之内超过一半的行已被删除,则可以对压缩单元解压缩,可以对尚未删除的行重新压缩并存储在新的压缩单元中。在这个过程期间,可以将来自很多压缩单元的数据组合成新的更小的压缩单元集合。
插入表式数据
向压缩单元中添加数据可能招致显著的开销代价,因为那将需要解压缩和重新压缩。此外,所得的压缩单元可能比期望的更大。因此,根据一个实施例,不向现有压缩单元中插入新增加的表式数据。相反,新增加的表式数据或者以单独的格式存储,或者存储于新形成的压缩单元中。例如,如果正向表格300中插入单个行,则可以在压缩单元200外部存储该行。可以在常规的行优先盘块中或基于行的压缩技术存储行。当在压缩单元中存储用于表格的一些表式数据并在压缩单元外部存储用于同一表格的其他表式数据时,这里将压缩单元外部存储的数据位置称为“溢出区”。
在一个实施例中,在要插入表格300中的数据量超过阈值时,不在溢出区中存储数据。相反,在新的压缩单元中存储新数据。例如,如果执行大量加载操作以向表格300增加数千行时,那么可以生成一个或多个新的压缩单元以存储用于新行的表式数据。根据一个实施例,新的顶层压缩单元会自动继承与压缩单元200相同的内部结构,包括从压缩单元200遗传的压缩单元结构和组织。
在一个实施例中,响应于表格300的溢出区中的数据超过特定阈值,自动将溢出的数据移入一个或多个新的压缩单元中。例如,若干更小的加载操作可能导致溢出区具有几千行。响应于检测到溢出区中的数据大小超过某个阈值,可以将来自溢出的数据重新封装到针对表格300的一个或多个新压缩单元中。类似于大量加载的情况,为了存储来自表格300到溢出区的数据而创建的新顶层压缩单元可以具有与压缩单元200相同的内部结构。
更新表式数据
根据一个实施例,更新被作为删除结合插入来处理。于是,当在表格300的行中更新值时,更新压缩单元200中的删除矢量以表示该行被删除,并在溢出区中存储具有更新值的行。
经常有更新行的一些列未被更新操作改变。因此,在溢出区中存储更新的行之前,可能必须对压缩单元(和任何子压缩单元)的压缩部分解压缩以恢复该行的更新前的值。溢出区中存储的新行包括未改变的行的列的更新前的值,以及改变的行的列的新值。
读取表式数据
在使用溢出区的实施例中,表格扫描必须读取溢出区中存储的数据和压缩单元中存储的数据。于是,单次表格扫描可能涉及到组合来自几个不同方式组织的压缩单元、来自溢出区中的压缩数据以及来自溢出区中的未压缩数据的数据。
硬件概要
根据一个实施例,这里描述的技术是由一个或多个专用计算设备实施的。可以对专用计算设备进行硬连线以执行技术,或者可以包括被持久编程以执行技术的数字电子设备,例如一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA),或者可以包括被编程以根据固件、存储器、其他存储器或组合中的程序指令执行技术的一个或多个通用硬件处理器。这样的专用计算设备也可以组合定制的硬连线逻辑、ASIC、或具有定制编程以完成技术的FPGA。专用计算设备可以是台式计算机系统、便携式计算机系统、手持式设备、联网设备或结合了硬连线和/或程序逻辑以实施技术的任何其他设备。
例如,图9是方框图,示出了计算机系统900,在其上可以实施本发明的实施例。计算机系统900包括总线902或用于通信信息的其他通信机构,以及与总线902耦接的用于处理信息的硬件处理器904。硬件处理器904例如可以是通用微处理器。
计算机系统900还包括主存储器906,例如随机存取存储器(RAM)或其他动态存储装置,其耦合到总线902以存储要由处理器904执行的信息和指令。主存储器906还可用于在执行要由处理器904执行的指令期间存储临时变量或其他中间信息。在存储在处理器904可访问的存储介质中时,这样的指令使计算机系统900成为被定制以执行指令中指定的操作的专用机器。
计算机系统900还包括耦接到总线902的只读存储器(ROM)908或其他静态存储装置,用于存储用于处理器904的静态信息和指令。提供存储装置910,例如磁盘或光盘,并耦接到总线902,以存储信息和指令。
计算机系统900可以经由总线902耦接到显示器912,例如阴极射线管(CRT),用于向计算机用户显示信息。输入装置914,包括字母数字和其他按键,耦接到总线902,用于向处理器904通信信息和命令选择。另一种用户输入装置是光标控制器916,例如鼠标、跟踪球、或光标方向键,用于向处理器904发送方向信息和命令选择并在显示器912上控制光标移动。这种输入装置通常在两个轴,即第一轴(例如x)和第二轴(例如y)上具有两个自由度,允许装置在平面中指定位置。
计算机系统900可以利用结合计算机系统以使得或程控计算机系统900以成为专用机器的定制的硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实施这里所述的技术。根据一个实施例,由计算机系统900响应于处理器904执行主存储器906中包含的一条或多条指令的一个或多个序列而执行这里的技术。可以将这样的指令从另一存储介质,例如存储装置910,读入主存储器906中。执行主存储器906中包含的指令序列使得处理器904执行这里所述的过程步骤。在替代实施例中,可以使用硬连线电路取代或结合软件指令。
这里使用的术语“存储介质”是指存储使得机器在特定方式下工作的数据和/或指令的任何介质。这样的存储介质可以包括非易失性介质和/或易失性介质。非易失性介质例如包括光盘或磁盘,例如存储装置910。易失性介质包括动态存储器,例如主存储器906。常见形式的存储介质包括,例如软盘、软磁盘、硬盘、固态驱动器、磁带或任何其他磁性数据存储介质、CD-ROM、任何其他光学数据存储介质、任何具有孔图案的物理介质、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其他存储器芯片或盒。
存储介质与传输介质不同,但可以结合使用。传输介质参与存储介质之间的信息传输。例如,传输介质包括同轴电缆、铜线和光纤,包括导线,其包括总线902。传输介质也可以采取诸如在无线电波和红外数据通信期间产生的声波或光波的形式。
在向处理器904传送一个或多个指令的一个或多个序列以执行时可能涉及到各种形式的介质。例如,最初可以在远程计算机的磁盘或固态驱动器上承载指令。远程计算机能够向其动态存储器中加载指令并利用调制调解器通过电话线发送指令。计算机系统900本地的调制调解器能够在电话线上接收数据,并利用红外发射机将数据转换成红外信号。红外探测器能够接收红外信号中承载的数据,适当的电路能够将数据置于总线902上。总线902向主存储器906传送数据,处理器904从其检索并执行指令。主存储器906接收的指令可以在由处理器904执行前或执行后任选地存储于存储装置910上。
计算机系统900还包括耦接到总线902的通信接口918。通信接口918提供耦接到网络链路920的双向数据通信,网络链路连接到局部网络922。例如,通信接口918可以是综合业务数字网络(ISDN)卡、电缆调制解调器、卫星调制调解器或提供到对应类型的电话线的数据通信连接的调制调解器。作为另一示例,通信接口918可以是局域网(LAN)卡,以提供到兼容LAN的数据通信连接。也可以实施无线链路。在任何这样的实施中,通信接口918发送和接收承载表式各种信息的数字数据流的电、电磁或光信号。
网络链路920通常通过一个或多个网络向其他数据设备提供数据通信。例如,网络链路920可以通过局部网络922提供到主计算机924或到由因特网服务提供商(ISP)926操作的数据设备的连接。ISP926接着通过全球分组数据通信网络,现在通常称为“因特网”928,提供数据通信业务。局部网络922和因特网928都使用承载数字数据流的电、电磁或光信号。通过各种网络的信号以及网络链路920上并通过通信接口918的信号在计算机系统900之间往返传输数字数据,它们是传输介质的示例形式。
计算机系统900能够通过网络、网络链路920和通信接口918发送消息和接收包括程序代码的数据。在因特网示例中,服务器930可能通过因特网928、ISP926、局部网络922和通信接口918发送为应用程序请求的代码。
接收的代码可以由处理器904按照接收的样子执行和/或存储在存储装置910中或其他非易失性存储器中以供以后执行。
在前面的说明书中,已经参考众多具体细节描述了本发明的实施例,在实施方式之间具体细节可能有变化。因此,应当以例示而非限制性的意义考虑说明书和附图。
Claims (15)
1.一种由一个或多个计算设备执行的用于存储XML文档的方法,所述方法包括:
向表格中的多个行中加载多个XML文档的每个XML文档,在所述表格中以粉碎形式存储XML文档,其中加载所述每个XML文档包括:
产生多个列的列值,所述列值要存储在所述表格中的多个行中;
对于所述多个列的每个列,分析所述列值以确定用于存储所述列的行存储格式,所述确定包括:
确定是以列优先还是以行优先格式存储列值,以及
确定是否使用压缩技术来压缩所述列值;以及
根据所述存储格式的确定在所述多个行中存储所述列值。
2.根据权利要求1所述的方法,其中:
所述多个XML文档包括第一XML文档和第二XML文档;
其中对于所述第一XML文档并且对于所述多个列的特定列,所述行存储格式的确定包括以行优先格式存储所述特定列;并且
其中对于所述第二XML文档并且对于所述多个列的所述特定列,所述行存储格式的确定包括以列优先格式存储所述特定列。
3.根据权利要求1所述的方法,其中:
所述多个XML文档包括第一XML文档和第二XML文档;
其中对于所述多个列的特定列,针对所述第一XML文档和所述第二XML文档进行的所述行存储格式的确定包括:
以列优先格式存储所述特定列;
对于所述第一XML文档的所述特定列使用第一压缩技术;以及
对于所述第二XML文档使用第二压缩技术;
其中所述第一压缩技术与所述第二压缩技术不同。
4.根据权利要求1所述的方法,
其中数据库服务器管理对所述表格的访问,其中所述步骤还包括在第二表格中存储所述多个XML文档;
其中所述表格的所述多个列包括:
存储所述多个XML文档中的节点的节点值的第一列,以及
存储指示所述第二表格中的存储所述多个XML文档的一个XML文档的行的值的第二列。
5.根据权利要求1所述的方法,其中在压缩单元中存储所述表格的所述数据。
6.根据权利要求1-5中的任一项所述的方法,其中对于所述表格的给定行,所述多个列的每个列存储针对所述多个XML文档的相应XML文档的节点的列值;其中所述多个文档包括第一XML文档和第二XML文档;其中所述表格的第一多个行存储针对所述第一XML文档的数据;其中所述表格的第二多个行存储针对所述第二XML文档的数据;其中对于所述第一多个行和所述第二多个行,以列优先格式存储所述多个列的特定列;其中对于所述表格的所述第一多个行,利用第一压缩技术压缩所述特定列中的所述值;以及其中对于所述表格的所述第二多个行,利用第二压缩技术压缩所述特定列中的所述值。
7.根据权利要求6所述的方法,
其中所述表格的第三多个行存储针对第三XML文档的数据;并且
其中对于所述第三多个行,不以列优先格式存储所述特定列。
8.一种计算机系统,包括:
用于向表格中的多个行中加载多个XML文档的每个XML文档的装置,在所述表格中以粉碎形式存储XML文档,其中用于加载所述每个XML文档的装置包括:
用于产生多个列的列值的装置,所述列值要存储在所述表格中的多个行中;
用于对于所述多个列的每个列,分析所述列值以确定用于存储所述列的行存储格式的装置,用于分析的装置包括:
用于确定是以列优先还是以行优先格式存储列值的装置,以及
用于确定是否使用压缩技术来压缩所述列值的装置;以及
用于根据所述存储格式的确定在所述多个行中存储列值的装置。
9.根据权利要求8所述的计算机系统,其中:
所述多个XML文档包括第一XML文档和第二XML文档;
其中对于所述第一XML文档并且对于所述多个列的特定列,所述行存储格式的确定包括以行优先格式存储所述特定列;以及
其中对于所述第二XML文档并且对于所述多个列的所述特定列,所述行存储格式的确定包括以列优先格式存储所述特定列。
10.根据权利要求8所述的计算机系统,其中:
所述多个XML文档包括第一XML文档和第二XML文档;
其中对于所述多个列的特定列,针对所述第一XML文档和所述第二XML文档进行的所述行存储格式的确定包括:
以列优先格式存储所述特定列;
对于所述第一XML文档的所述特定列使用第一压缩技术;以及
对于所述第二XML文档使用第二压缩技术;
其中所述第一压缩技术与所述第二压缩技术不同。
11.根据权利要求8所述的计算机系统,
其中数据库服务器管理对所述表格的访问,其中所述计算机系统还包括用于在第二表格中存储所述多个XML文档的装置;
其中所述表格的所述多个列包括:
存储所述多个XML文档中的节点的节点值的第一列,以及
存储表示所述第二表格中的存储所述多个XML文档的一个XML文档的行的值的第二列。
12.根据权利要求8所述的计算机系统,其中在压缩单元中存储用于所述表格的所述数据。
13.根据权利要求8-12的任一项所述的计算机系统,其中对于所述表格的给定行,所述多个列的每个列存储针对所述多个XML文档的相应XML文档的节点的列值;其中所述多个文档包括第一XML文档和第二XML文档;其中所述表格的第一多个行存储针对所述第一XML文档的数据;其中所述表格的第二多个行存储针对所述第二XML文档的数据;其中对于所述第一多个行和所述第二多个行,以列优先格式存储所述多个列的特定列;其中对于所述表格的所述第一多个行,利用第一压缩技术压缩所述特定列中的所述值;以及其中对于所述表格的所述第二多个行,利用第二压缩技术压缩所述特定列中的所述值。
14.根据权利要求13所述的计算机系统,
其中所述表格的第三多个行存储针对第三XML文档的数据;以及
其中对于所述第三多个行,不以列优先格式存储所述特定列。
15.一种存储指令的计算机程序产品,所述指令在被执行时使得一个或多个处理器执行权利要求1-7中的任一项所述的方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/791,337 US9667269B2 (en) | 2009-04-30 | 2010-06-01 | Technique for compressing XML indexes |
US12/791,337 | 2010-06-01 | ||
PCT/US2011/038762 WO2011153241A1 (en) | 2010-06-01 | 2011-06-01 | A method and system for compressing xml documents |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103026631A true CN103026631A (zh) | 2013-04-03 |
CN103026631B CN103026631B (zh) | 2017-07-04 |
Family
ID=44276014
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201180035113.XA Active CN103026631B (zh) | 2010-06-01 | 2011-06-01 | 用于压缩xml文档的方法和系统 |
Country Status (4)
Country | Link |
---|---|
US (1) | US9667269B2 (zh) |
EP (1) | EP2577873B1 (zh) |
CN (1) | CN103026631B (zh) |
WO (1) | WO2011153241A1 (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104239391A (zh) * | 2013-06-14 | 2014-12-24 | 国际商业机器公司 | 用于数据编码及处理列数据的系统和方法 |
CN107341697A (zh) * | 2017-07-18 | 2017-11-10 | 江苏仲博敬陈信息科技有限公司 | 一种基于大数据的需求与供给预测方法 |
US10642841B2 (en) * | 2016-11-17 | 2020-05-05 | Sap Se | Document store utilizing partial object compression |
TWI768982B (zh) * | 2021-06-23 | 2022-06-21 | 鼎新電腦股份有限公司 | 表格佈署系統和其方法 |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8356060B2 (en) * | 2009-04-30 | 2013-01-15 | Oracle International Corporation | Compression analyzer |
US8645337B2 (en) * | 2009-04-30 | 2014-02-04 | Oracle International Corporation | Storing compression units in relational tables |
US8935223B2 (en) * | 2009-04-30 | 2015-01-13 | Oracle International Corporation | Structure of hierarchical compressed data structure for tabular data |
US8583692B2 (en) * | 2009-04-30 | 2013-11-12 | Oracle International Corporation | DDL and DML support for hybrid columnar compressed tables |
US9667269B2 (en) | 2009-04-30 | 2017-05-30 | Oracle International Corporation | Technique for compressing XML indexes |
US8296517B2 (en) | 2009-08-19 | 2012-10-23 | Oracle International Corporation | Database operation-aware striping technique |
US9876507B2 (en) * | 2013-02-22 | 2018-01-23 | Sap Se | Semantic compression of structured data |
US11269829B2 (en) * | 2013-03-12 | 2022-03-08 | Oracle International Corporation | Row level locking for columnar data |
US9659050B2 (en) * | 2013-08-06 | 2017-05-23 | Sybase, Inc. | Delta store giving row-level versioning semantics to a non-row-level versioning underlying store |
US9489409B2 (en) | 2013-10-17 | 2016-11-08 | Sybase, Inc. | Rollover strategies in a N-bit dictionary compressed column store |
US20160254824A1 (en) * | 2013-11-26 | 2016-09-01 | Longsand Limited | Determining compression techniques to apply to documents |
US9990308B2 (en) | 2015-08-31 | 2018-06-05 | Oracle International Corporation | Selective data compression for in-memory databases |
JP6344486B2 (ja) | 2015-12-29 | 2018-06-20 | 華為技術有限公司Huawei Technologies Co.,Ltd. | サーバおよびデバイスによりデータを圧縮するための方法 |
US11328000B1 (en) | 2017-07-05 | 2022-05-10 | Liberty Mutual Insurance Company | Method, apparatus and computer program product for transforming structured hierarchical data into flattened lineage and attribute tables |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6643633B2 (en) * | 1999-12-02 | 2003-11-04 | International Business Machines Corporation | Storing fragmented XML data into a relational database by decomposing XML documents with application specific mappings |
US7496589B1 (en) * | 2005-07-09 | 2009-02-24 | Google Inc. | Highly compressed randomly accessed storage of large tables with arbitrary columns |
US20100042587A1 (en) * | 2008-08-15 | 2010-02-18 | International Business Machines Corporation | Method for Laying Out Fields in a Database in a Hybrid of Row-Wise and Column-Wise Ordering |
Family Cites Families (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5263145A (en) | 1990-05-24 | 1993-11-16 | International Business Machines Corporation | Method and means for accessing DASD arrays with tuned data transfer rate and concurrency |
US5506979A (en) | 1991-04-02 | 1996-04-09 | International Business Machines Corporation | Method and means for execution of commands accessing variable length records stored on fixed block formatted DASDS of an N+2 DASD synchronous array |
WO1993019434A1 (en) | 1992-03-17 | 1993-09-30 | Zoran Corporation | Image compression coder having improved bit rate control and block allocation |
US5404510A (en) | 1992-05-21 | 1995-04-04 | Oracle Corporation | Database index design based upon request importance and the reuse and modification of similar existing indexes |
US5581778A (en) | 1992-08-05 | 1996-12-03 | David Sarnoff Researach Center | Advanced massively parallel computer using a field of the instruction to selectively enable the profiling counter to increase its value in response to the system clock |
US5794228A (en) | 1993-04-16 | 1998-08-11 | Sybase, Inc. | Database system with buffer manager providing per page native data compression and decompression |
US5794229A (en) | 1993-04-16 | 1998-08-11 | Sybase, Inc. | Database system with methodology for storing a database table by vertically partitioning all columns of the table |
US5546575A (en) | 1994-05-23 | 1996-08-13 | Basil E. Potter & Associates, Inc. | Encoding method for compressing a tabular database by selecting effective compression routines for each field and structure of partitions of equal sized records |
US5995080A (en) | 1996-06-21 | 1999-11-30 | Digital Equipment Corporation | Method and apparatus for interleaving and de-interleaving YUV pixel data |
US6216125B1 (en) | 1998-07-02 | 2001-04-10 | At&T Corp. | Coarse indexes for a data warehouse |
US6959300B1 (en) | 1998-12-10 | 2005-10-25 | At&T Corp. | Data compression method and apparatus |
US6624761B2 (en) | 1998-12-11 | 2003-09-23 | Realtime Data, Llc | Content independent data compression method and system |
US7024414B2 (en) | 2001-08-06 | 2006-04-04 | Sensage, Inc. | Storage of row-column data |
US7031994B2 (en) | 2001-08-13 | 2006-04-18 | Sun Microsystems, Inc. | Matrix transposition in a computer system |
US8868544B2 (en) | 2002-04-26 | 2014-10-21 | Oracle International Corporation | Using relational structures to create and support a cube within a relational database system |
US7103608B1 (en) | 2002-05-10 | 2006-09-05 | Oracle International Corporation | Method and mechanism for storing and accessing data |
JP4188912B2 (ja) | 2002-06-07 | 2008-12-03 | ノキア コーポレイション | 通信システムにおける移動装置に関する情報要求のサポート |
US7079056B2 (en) | 2003-01-15 | 2006-07-18 | Delphi Technologies, Inc. | Method of encoding and storing in a machine control computer a compressed data lookup table |
DK1629406T3 (en) | 2003-05-19 | 2016-11-07 | Huawei Tech Co Ltd | LIMITATION OF scans SOLVED SUBSIDIARY AND / OR GROUP READY RELATIONS BY APPROXIMATE SUBSIDIARY PICTURES |
CN100547583C (zh) | 2003-08-14 | 2009-10-07 | 甲骨文国际公司 | 数据库的自动和动态提供的方法 |
US7469266B2 (en) | 2003-09-29 | 2008-12-23 | International Business Machines Corporation | Method and structure for producing high performance linear algebra routines using register block data format routines |
US7693325B2 (en) | 2004-01-14 | 2010-04-06 | Hexagon Metrology, Inc. | Transprojection of geometry data |
US20050210054A1 (en) | 2004-03-22 | 2005-09-22 | Michael Harris | Information management system |
US7707194B2 (en) | 2004-06-08 | 2010-04-27 | Sap Ag | Interface to lock a database row through a logical locking interface |
US7590641B1 (en) | 2005-04-04 | 2009-09-15 | Qd Technology, Llc | Selecting various algorithms to compress columns of analytic data in a read-only relational database in a manner that allows decompression of the compressed data using minimal system resources |
US7428524B2 (en) | 2005-08-05 | 2008-09-23 | Google Inc. | Large scale data storage in sparse tables |
US7447865B2 (en) | 2005-09-13 | 2008-11-04 | Yahoo ! Inc. | System and method for compression in a distributed column chunk data store |
US7558290B1 (en) | 2005-12-16 | 2009-07-07 | Narus, Inc. | Method and apparatus of data compression for computer networks |
US7877373B2 (en) | 2006-06-30 | 2011-01-25 | Oracle International Corporation | Executing alternative plans for a SQL statement |
US7961959B2 (en) | 2006-08-24 | 2011-06-14 | Dell Products L.P. | Methods and apparatus for reducing storage size |
US8266147B2 (en) | 2006-09-18 | 2012-09-11 | Infobright, Inc. | Methods and systems for database organization |
WO2008034213A1 (en) | 2006-09-18 | 2008-03-27 | Infobright Inc. | A method and system for data compression in a relational database |
US7552130B2 (en) | 2006-10-17 | 2009-06-23 | International Business Machines Corporation | Optimal data storage and access for clustered data in a relational database |
US7634512B2 (en) | 2006-10-20 | 2009-12-15 | Oracle International Corporation | Migrating temporary data of a session |
US7730106B2 (en) | 2006-12-28 | 2010-06-01 | Teradata Us, Inc. | Compression of encrypted data in database management systems |
US8386444B2 (en) | 2006-12-29 | 2013-02-26 | Teradata Us, Inc. | Techniques for selective compression of database information |
US7769729B2 (en) | 2007-05-21 | 2010-08-03 | Sap Ag | Block compression of tables with repeated values |
US8032499B2 (en) | 2007-05-21 | 2011-10-04 | Sap Ag | Compression of tables based on occurrence of values |
US20090006399A1 (en) * | 2007-06-29 | 2009-01-01 | International Business Machines Corporation | Compression method for relational tables based on combined column and row coding |
US20090019029A1 (en) | 2007-07-11 | 2009-01-15 | James Joseph Tommaney | Method and system for performing a scan operation on a table of a column-oriented database |
US8862625B2 (en) | 2008-04-07 | 2014-10-14 | Teradata Us, Inc. | Accessing data in a column store database based on hardware compatible indexing and replicated reordered columns |
US8392382B2 (en) | 2007-10-19 | 2013-03-05 | Oracle International Corporation | On-line transaction processing (OLTP) compression and re-compression of database data |
US20090287737A1 (en) | 2007-10-31 | 2009-11-19 | Wayne Hammerly | Architecture for enabling rapid database and application development |
US20110040771A1 (en) | 2008-06-18 | 2011-02-17 | Petascan Ltd. | Distributed hardware-based data querying |
US8060476B1 (en) | 2008-07-14 | 2011-11-15 | Quest Software, Inc. | Backup systems and methods for a virtual computing environment |
WO2010028279A1 (en) | 2008-09-05 | 2010-03-11 | Arcsight, Inc. | Storing log data efficiently while supporting querying |
US8478775B2 (en) | 2008-10-05 | 2013-07-02 | Microsoft Corporation | Efficient large-scale filtering and/or sorting for querying of column based data encoded structures |
US9507811B2 (en) | 2008-12-22 | 2016-11-29 | Oracle International Corporation | Compressed data page with uncompressed data fields |
US9667269B2 (en) | 2009-04-30 | 2017-05-30 | Oracle International Corporation | Technique for compressing XML indexes |
US8356060B2 (en) | 2009-04-30 | 2013-01-15 | Oracle International Corporation | Compression analyzer |
US8935223B2 (en) | 2009-04-30 | 2015-01-13 | Oracle International Corporation | Structure of hierarchical compressed data structure for tabular data |
US8645337B2 (en) | 2009-04-30 | 2014-02-04 | Oracle International Corporation | Storing compression units in relational tables |
US8583692B2 (en) | 2009-04-30 | 2013-11-12 | Oracle International Corporation | DDL and DML support for hybrid columnar compressed tables |
US8296517B2 (en) | 2009-08-19 | 2012-10-23 | Oracle International Corporation | Database operation-aware striping technique |
US8832142B2 (en) | 2010-08-30 | 2014-09-09 | Oracle International Corporation | Query and exadata support for hybrid columnar compressed data |
-
2010
- 2010-06-01 US US12/791,337 patent/US9667269B2/en active Active
-
2011
- 2011-06-01 EP EP11727018.1A patent/EP2577873B1/en active Active
- 2011-06-01 CN CN201180035113.XA patent/CN103026631B/zh active Active
- 2011-06-01 WO PCT/US2011/038762 patent/WO2011153241A1/en active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6643633B2 (en) * | 1999-12-02 | 2003-11-04 | International Business Machines Corporation | Storing fragmented XML data into a relational database by decomposing XML documents with application specific mappings |
US7496589B1 (en) * | 2005-07-09 | 2009-02-24 | Google Inc. | Highly compressed randomly accessed storage of large tables with arbitrary columns |
US20100042587A1 (en) * | 2008-08-15 | 2010-02-18 | International Business Machines Corporation | Method for Laying Out Fields in a Database in a Hybrid of Row-Wise and Column-Wise Ordering |
Non-Patent Citations (1)
Title |
---|
DANIELJ.ABADI: "《Query Execution in Column-Oriented Database Systems》", 《QUERY EXECUTION IN COLUMN-ORIENTED DATABASE SYSTEMS》 * |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104239391A (zh) * | 2013-06-14 | 2014-12-24 | 国际商业机器公司 | 用于数据编码及处理列数据的系统和方法 |
CN104239391B (zh) * | 2013-06-14 | 2018-03-27 | 国际商业机器公司 | 用于数据编码及处理列数据的系统和方法 |
US10042873B2 (en) | 2013-06-14 | 2018-08-07 | International Business Machines Corporation | Data encoding and processing columnar data |
US10642841B2 (en) * | 2016-11-17 | 2020-05-05 | Sap Se | Document store utilizing partial object compression |
CN107341697A (zh) * | 2017-07-18 | 2017-11-10 | 江苏仲博敬陈信息科技有限公司 | 一种基于大数据的需求与供给预测方法 |
TWI768982B (zh) * | 2021-06-23 | 2022-06-21 | 鼎新電腦股份有限公司 | 表格佈署系統和其方法 |
Also Published As
Publication number | Publication date |
---|---|
EP2577873A1 (en) | 2013-04-10 |
US20110295817A1 (en) | 2011-12-01 |
CN103026631B (zh) | 2017-07-04 |
US9667269B2 (en) | 2017-05-30 |
EP2577873B1 (en) | 2016-03-09 |
WO2011153241A1 (en) | 2011-12-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103026631A (zh) | 用于压缩xml文档的方法和系统 | |
US11080277B2 (en) | Data set compression within a database system | |
CN1264107C (zh) | 集成具有不同块大小的表空间 | |
US9710517B2 (en) | Data record compression with progressive and/or selective decomposition | |
US9805080B2 (en) | Data driven relational algorithm formation for execution against big data | |
EP2021957B1 (en) | Efficient piece-wise updates of binary encoded xml data | |
US8738667B2 (en) | Mapping of data from XML to SQL | |
CN101154239B (zh) | 将表状数据变换成结构化文档的系统及方法 | |
CN103003813B (zh) | 记录的列状存储表示 | |
CN102804168A (zh) | 在数据库系统中减少存储需求的数据压缩 | |
CN103493043A (zh) | 用于有效的xml处理的混合二进制xml存储模型 | |
CN102362273A (zh) | 用于关系数据库系统中高效数据存取的动态散列表 | |
CN108140046A (zh) | 对于任何半结构化数据格式的高效存储器中db查询处理 | |
US8214403B2 (en) | Structured document management device and method | |
CN100449545C (zh) | 访问扇区数据的方法和系统 | |
CN105144157A (zh) | 用于压缩数据库中的数据的系统和方法 | |
US20210326320A1 (en) | Data segment storing in a database system | |
US8694546B2 (en) | Optimized fetching for customization object attributes | |
CN101566948B (zh) | 一种表单系统数据源数据绑定方法 | |
JP2007310845A (ja) | データ処理システム | |
Gleim et al. | Representing and maintaining large corpora | |
Li et al. | Optimal Representation of Large‐Scale Graph Data Based on Grid Clustering and K2‐Tree | |
Nicola et al. | DB2 pureXML cookbook: master the power of the IBM hybrid data server | |
Silva-Coira et al. | Space-efficient representations of raster time series | |
Boukraa et al. | Efficient compression and storage of XML OLAP cubes |
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 |