CN111291041B - 列数据的非统一分页 - Google Patents
列数据的非统一分页 Download PDFInfo
- Publication number
- CN111291041B CN111291041B CN201911252406.8A CN201911252406A CN111291041B CN 111291041 B CN111291041 B CN 111291041B CN 201911252406 A CN201911252406 A CN 201911252406A CN 111291041 B CN111291041 B CN 111291041B
- Authority
- CN
- China
- Prior art keywords
- page
- block
- blocks
- data
- compression
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0804—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with main memory updating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2282—Tablespace storage structures; Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- 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
-
- 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/221—Column-oriented storage; Management thereof
-
- 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/2246—Trees, e.g. B+trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/258—Data format conversion from or to a database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/10—Providing a specific technical effect
- G06F2212/1041—Resource optimization
- G06F2212/1044—Space efficiency improvement
Abstract
一种计算机实现的存储器内数据库的存储器管理的系统和方法。系统使用其块的非统一压缩来实现分页数据向量。以这种方式,系统实现比使用统一压缩的系统更大的压缩。
Description
技术领域
本发明涉及存储器内(in-memory)数据库系统,尤其涉及存储器内数据库系统的存储器管理。
背景技术
除非本文另外指出,否则本节中描述的方法对于本申请中的权利要求不是现有技术,并且不是通过包含在本节中而承认是现有技术。
数据库是有组织的数据集合,以电子方式存储和访问。数据库设计人员通常以支持需要信息的处理的方式组织数据以对现实的各个方面进行建模。
数据库管理系统(DBMS)是与最终用户、应用和数据库本身进行交互以捕获和分析数据的软件。通用DBMS允许定义、创建、查询、更新和管理数据库。数据库、DBMS及其相关应用的总和可以被称为“数据库系统”。通常,术语“数据库”用于泛指DBMS、数据库系统或与数据库相关联的应用中的任何一个。
存储器内数据库系统(IMDBS或IMDB,也称为主存储器数据库系统(MMDBS)或存储器驻留数据库(MRDB))是一种数据库管理系统,主要依靠主存储器来存储计算机数据。它与依靠盘存储机制的数据库管理系统形成对比。存储器内数据库比盘优化的数据库快,这是因为盘访问比存储器访问慢,并且内部优化算法更简单并且执行的CPU指令更少。访问存储器中的数据消除了查询数据时的寻道时间(seek time),从而提供了比盘更快、更可预测的性能。IMDB的存储器可以是易失性的(例如,随机存取存储器)或非易失性的(例如,闪存)。尽管对于“主要依靠主存储器”的方面而言,IMDB是值得注意的,但是IMDB也可以包括盘或其他永久性存储(例如,出于备份目的)。(当然,非IMDB系统和IMDB系统二者具有存储器,但是数据库领域的普通技术人员会意识到,由于内部优化算法不同,因此将为非IMDB系统开发的特征应用于IMDB系统并不是一件容易的事)。示例IMDB在美国申请公开第2009/0240663号中有所描述。商业上可用的IMDB的示例是SAP SE的SAP存储器内数据平台。
对于当数据的大小超过存储器的大小的IMDB,IMDB可以包括存储器管理系统,以管理在给定时间存在于主存储器中的数据的一部分。通常,存储器管理系统协调主存储器和另一组件(诸如盘系统)之间的数据存储。存储器管理系统可以使用多种策略来管理该协调。一种策略是将数据划分为多个单元(例如,页),在需要时将特定单元加载到主存储器中,并当需要时在主存储器中用其他页替换这些单元。在美国申请公开第2016/0012089号中描述了用于IMDB的示例存储器管理系统。
发明内容
鉴于上述情况,提出了许多问题。一个问题是,当数据已被划分为多个单元时,与空间效率相比,通常通过存储器管理系统易于访问更优选。由于存储器管理系统必须准确确定哪个单元包含特定数据记录,因此,在将数据划分为每个单元时,通常会对数据应用相同的压缩(称为统一压缩)。结果,即使不同类型的压缩可以导致对特定单元的更好压缩,但是优选统一压缩,因为统一压缩可以整体应用于数据。统一压缩系统的示例在美国专利申请公开第2016/0012089号中描述,通过将其压缩(字典压缩和n位压缩)整体应用于值标识符集合来实现统一压缩。需要一种能够实现非统一压缩的技术解决方案,以使得每个单元可以根据其自身的适当压缩来被压缩,同时仍使得存储器管理系统易于访问。
实施例旨在解决以上问题以及其他问题,如下面更详细地讨论的。结果,与仅实现统一压缩的许多现有系统相比,实施例使用非统一压缩来实现更有效的数据存储,同时仍然具有易于访问的特性。
在一个实施例中,一种方法执行存储器内数据库的存储器管理。所述方法包括:在辅存储器中存储分页数据向量。分页数据向量包括多个块,使用非统一压缩来压缩多个块,并且多个块被逻辑地排列在分页数据向量中作为多个页。所述方法还包括接收数据请求。所述方法还包括识别与数据请求相关的多个页的子集。所述方法还包括从辅存储器向主存储器加载已被识别为与数据请求相关的多个页的子集中的至少一个页。所述方法还包括使用主存储器中的多个页的子集中的至少一个页来执行数据请求。
对于非统一压缩,可以使用第一压缩类型压缩至少第一块,并且可以使用第二压缩类型压缩至少第二块。(第一块与第二块不同,并且第一压缩类型与第二压缩类型不同。)
分页数据向量可以是通过以下方法生成,所述方法包括:计算数据向量的块大小;以及根据块大小对数据向量进行编码,以形成与分页数据向量相对应的分页统一分区树数据结构。
计算块大小可以包括选择初始块大小,并且将数据向量划分为多个初步块。计算块大小还可以包括使用相应选择的压缩类型压缩多个初步块中的每一个,并计算多个压缩率。计算块大小还可以包括基于比较压缩率和误差容限来设置目标压缩率。计算块大小还可以包括基于压缩率计算目标空间量,并基于适合目标空间量的最小适合页计算页大小。计算块大小最低限度以目标压缩率为目标。
编码数据向量可以包括将根节点构造为页链,根据块大小对数据向量进行划分以形成多个块,并使用相应选择的压缩类型将多个块中的每个块编码为瞬态数据结构,其中,页链最初是空页链。编码数据向量还可以包括将具有常规大小的多个块中的每一个从瞬态数据结构移动到最小适合页中,并将每个最小适合页附加到页链。
编码数据向量还可以包括:参考子节点将超大尺寸的多个块中的每一个的空页附加到页链上;以及递归地将超大尺寸的多个块中的每一个存储到相应的子节点中。
识别与数据请求相关的多个页的子集可以包括从根节点开始,遍历页数据结构中的多个块,一次一个块。
分页数据向量可以具有根节点和至少一个子节点。根节点可以对应于多个块的逻辑表示,并且子节点对应于根节点的多个块中的单个块。至少一个子节点对应于至少一个超大尺寸块,其中特定子节点可以对应于特定超大尺寸块。至少一个子节点可以对应于包括第一子节点和第二子节点的多个子节点,其中第二子节点是第一子节点的子节点。
分页数据向量可以具有根节点,该根节点是包含多个块的单个节点。
计算机可读介质可以存储用于控制计算机实现上述方法的一个或多个步骤的计算机程序。
系统可以使用计算机(例如,服务器计算机、数据库系统、客户端计算机等)实现一个或多个步骤,以执行用于存储器内部数据库的存储器管理的上述方法。系统可以包括至少一个处理器、主存储器、辅存储器、解码器组件和页加载器组件。系统还可以包括组块大小计算器组件和编码器组件。
以下详细描述和附图提供了对本发明的本质和优点的更好的理解。
附图说明
图1是实现存储器内数据库系统(IMDBS)100的计算机系统的框图。
图2是用于存储器内数据库的存储器管理的方法200的流程图。
图3是统一分区树(UPT)300的逻辑表示的框图。
图4是用于存储器内数据库的存储器管理的方法400的流程图。
图5是生成分页数据向量的方法500的流程图。
图6是代码列表600。
图7是代码列表700。
图8是用于实现上述各种实施例的示例计算机系统800的框图。
图9是用于实现上述各种实施例的云计算系统900的框图。
具体实施方式
本文描述了用于存储器内部数据库系统中的存储器管理的技术。在下面的描述中,出于解释的目的,阐述了许多示例和具体细节,以便提供对本文描述的系统和方法的透彻理解。然而,对于本领域的技术人员显而易见的是,由权利要求书限定的本发明可以单独地或与下面描述的其他特征组合地包括这些示例中的一些或全部特征,并且可以进一步包括本文所述的特征和概念的修改和等同物。
在本文档中,详细介绍了各种方法、处理和程序。尽管可以以特定顺序描述特定步骤,但是这种顺序主要是为了方便和清楚。特定步骤可以重复执行一次以上,可以在其他步骤之前或之后发生(即使这些步骤以其他顺序描述),并且可以与其他步骤并行发生。仅在必须在第二步开始之前完成第一步的情况下,才需要第二步跟随第一步。当从上下文中不清楚时,将具体指出这种情况。
在本文中,使用术语“和”,“或”和“和/或”。这样的术语应被理解为具有包含性含义。例如,“A和B”可以至少表示以下含义:“A和B两者”、“至少A和B两者”。作为另一示例,“A或B”可以至少表示以下含义:“至少A”、“至少B”、“A和B两者”、“至少A和B两者”。作为另一示例,“A和/或B”可以至少表示以下含义:“A和B”,“A或B”。当打算使用异或时,将特别指出(例如,“A或B”,“A和B中至多一个”)。
在本文档中,使用术语“服务器”。通常,服务器是硬件设备,并且在硬件服务器的讨论中可以省略描述符“硬件”。服务器可以实现或执行控制服务器功能的计算机程序。这样的计算机程序在功能上也可以被称为服务器,或者被描述为实现服务器功能;然而,应当理解,将实现服务器功能或控制硬件服务器的计算机程序更精确地称为“软件服务器”、“服务器组件”或“服务器计算机程序”。
在本文档中,使用了术语“数据库”。通常,数据库是一种易于组织,存储和检索大量数据的数据结构。数据库也可以称为数据存储。术语数据库通常用于表示关系数据库,其中数据以表的形式存储,并且数据之间的关系也以表的形式存储。数据库管理系统(DBMS)通常是指实现数据库的硬件计算机系统(例如,诸如磁盘驱动器或闪存驱动器的持久性存储器、诸如随机存取存储器的易失性存储器、处理器等)。
在本文档中,使用了“要存储”,“已存储”和“存储”一词。通常,这些术语可以用于指代主动动词(例如,存储或从未存储状态变为存储状态的处理),存在状态(例如,正在存储的状态),或两者。例如,“存储数据记录”可以用于描述存储处理(例如,数据记录从未存储状态转变为存储状态)。作为另一示例,“存储数据记录”可以用于描述数据记录的当前状态(例如,由于先前被存储,因此数据记录当前以存储的状态存在)。当仅意味着单个解释时,这种含义从上下文中将显而易见。
图1是实现存储器内数据库系统(IMDBS)100的计算机系统的框图。计算机系统可以包括一个或多个硬件组件,其细节在随后的附图中讨论。IMDBS 100可以由计算机系统通过执行一个或多个计算机程序来实现。IMDBS 100包括主存储器110、辅存储器120、存储器管理系统130和数据处理系统140。IMDBS 100还可以包括(为了简洁)没有详述的其他组件(例如,持久层等)。
主存储器110通常以与上述其他主存储器数据库系统类似的方式用作IMDBS 100的主存储器。主存储器110可以用易失性存储器组件或非易失性存储器组件来实现。合适的易失性存储器组件包括随机存取存储器(RAM),诸如静态RAM(SRAM)或动态RAM(DRAM)。合适的非易失性存储器组件包括闪存。
辅存储器120通常与主存储器110协同操作,以存储其大小超过主存储器110的容量的数据。这允许主存储器110的尺寸减小,但仍可对大数据集操作。通常,辅存储器120比主存储器110更慢并且成本更低(按数据大小单位)。例如,如果主存储器110由SRAM实现,则辅存储器120可以由DRAM、闪存或硬盘系统实现。
存储器管理系统130通常协调主存储器110和辅存储器120之间的数据存储。例如,当IMDBS 100需要特定数据记录时,存储器管理系统130将特定数据记录从辅存储器120加载到主存储器110。存储器管理系统130包括块(chunk)大小计算器132、编码器组件134、解码器组件136和页加载器138。
块大小计算器132计算由IMDBS 100存储和处理的数据的块大小。如下面更详细地讨论的,将数据块存储在被称为页的数据结构中。通常,数据以块的形式从辅存储器120加载到主存储器110,并且块大小计算器132计算块大小,作为为此目的布置数据的一部分。在随后的部分中将更详细地讨论块大小和块大小计算器132。
编码器组件134对由IMDBS 100存储和处理的数据执行压缩。例如,IMDBS 100可以对列数据进行操作,并且特定列中的数据值可以(使用各种技术)被压缩以减小需要存储在存储器中的数据的大小。编码器组件134还生成IMDBS 100使用的其他数据结构,诸如下面更详细讨论的统一分区树(uniform partition tree,UPT)。通常,编码器组件134可以以每个块为基础执行压缩。这允许编码器组件134将不同的压缩类型应用于不同的块(例如,非统一压缩)。(这种操作可以与统一压缩进行对比,统一压缩将相同的压缩应用于整个数据列。)压缩和编码器组件134将在后续章节中详细讨论。
解码器组件136识别包含给定数据记录的特定块(页)。由于块可能已经使用不同的压缩类型被进行了压缩,因此识别特定块是非平凡(non-trivial)处理。如果识别的页已经在主存储器110中,则IMDBS 100可以对该块执行其处理。如果否,则解码器组件136将识别的页的信息提供给页加载器138。在随后的部分中将更详细地讨论该解码处理以及解码器组件136。
页加载器138将由解码器组件136识别的页从辅存储器120加载到主存储器110。以这种方式,页加载器138协调数据从辅存储器120到主存储器110的存储。在随后的部分中将更详细地讨论页加载和页加载器138。
数据处理系统140通常对加载到主存储器110中的数据执行数据处理。数据处理可以是事务性数据处理,例如以添加、删除、复制、修改或更新数据记录。数据处理可以是分析性数据处理,例如对一个或多个数据记录执行查询。
IMDBS 100通常如下操作。IMDBS提供使用页可加载列类型作为完全驻留存储器列类型的替代来存储表数据的选项。前者允许将表加载单元从整个列减少到固定大小的连续数据块(被称为页)。这通常会减少存储器使用,尤其是在较大的工作负载下。这是通过与每一列相关联的关键数据结构的可分页版本来实现的,即可编码的列内容、其字典以及可能的其反向索引。主列内容(被称为数据向量)对应于列的数据记录,并构成列的大部分存储器使用。
如以上关于许多现有系统所讨论的,数据向量在被转换成其可分页副本时可能遭受严重的空间开销。这是因为与空间效率相比,优选值可访问性(即行到页的转换)的易用性,并且在这些现有系统中,页可加载列(page loadablecolumn)仅允许统一压缩。为了使识别包含编码值的页变得容易,即使页上的所有值都相同,或者每页的值压缩得很好,所有数据页也具有相同的大小。这增加了分页数据向量的存储器占用量。
为了解决上述问题,IMDBS 100利用分页数据向量的无损压缩来实现新颖的持久性布局,其对数据向量的相等大小的段使用非统一分页。这种方法被称为分页统一分区树编码(paged uniform-partition tree encoding,PUPTE)。PUPTE涉及由编码器组件134和解码器组件136实现的新的编码和解码处理,以执行非统一压缩。与许多现有系统相比,IMDBS 100确实减少了空间消耗,同时仍保留了分页数据向量的所希望的有效随机分页访问属性。这意味着识别与行位置相对应的页非常接近统一压缩,而存储器消耗可以被大大降低,尤其是在数据向量压缩良好的情况下。
总览
IMDBS 100支持存储数据库表列的三种方法:(1)完全驻留存储器列,(2)页可加载列,以及(3)分页统一分区树编码(PUPTE)。
1.完全驻留存储器列(Fully Memory-Resient Column)
当使用完全驻留存储器列时,整个列被加载到主存储器110中以进行处理。IMDBS可以在整个列上使用字典压缩和n位编码来压缩列,以减少存储器占用量。
2.页可加载列(Page Loadable Column)
与使用完全驻留存储器列相比,页可加载列通常可以使得能够更少地使用存储器。通过从辅存储器120到主存储器110一次仅从列中加载和卸载固定大小的连续数据部分(称为页)来实现页可加载列方法。通过这种策略,仅活动需要的表的列的页将被保留在主存储器110中,从而优化了宝贵的主存储器的系统使用。尤其是当对具有低基数或低多样性的非常大的数据集寻求高性能(其中存储压力会增加)时,这可能至关重要。将整个表装入主存储器110可能是不必要地昂贵的,甚至有时甚至是不可能的。可以通过向用于通过字典压缩对存储器内容列进行编码的主数据和辅助数据结构提供可分页副本来实现页可加载列。问题是,尽管数据结构的所有分页版本都具有其他缺点,但是被称为数据向量的一个可能会特别受影响。数据向量本质上是有界整数的数组。
对于列的只读部分,IMDBS 100支持多种高级压缩方法,但是对于可页加载列,仅应用统一压缩。只读分页数据向量的使用方法不比字典压缩和n位编码更好,后者仅使用存储最大值所需的位数来实际存储每个值。出于讨论目的,字典压缩和n位编码数据向量的组合是统一压缩。这是导致分页数据向量性能下降的原因。虽然它们通常会主动使用较少的存储器,但是如果还要考虑磁盘空间,则总空间使用量可能明显大于压缩的存储器内数据向量的总空间使用量。分页数据向量当前不支持任何进一步压缩的原因是由于访问值的简单性与空间效率之间的固有权衡。
实际上,IMDBS 100支持的高级压缩方法也是如此。由于可以使用可变数量的位对每个值进行编码,因此许多现有系统无法再确定任何编码值的精确位置。因此,当使用可变长度值时,将失去有效的随机访问的能力。从压缩数据解码值通常涉及顺序遍历。然而,这不是分页数据向量的选项。为了最大程度地减少存储器压力,我们希望能够在不加载整个表或整个列的情况下能够访问任何值,仅加载存储页。但是如果我们无法确定数据存储在哪个页,则最糟糕的情况是,我们最终可能会加载列中的所有页。相反,统一压缩的n位数据向量支持随机访问,因此我们可以轻松确定任何值位于哪个页中。这是通过将所希望的行位置除以适合每个页的值数来完成的,以识别页码。然而,没有必要完全随机访问;我们不需要知道存储值的确切位置,而只需要知道存储值的页即可。具有我们所谓的随机页访问就足够了,这是一种以页为单位的半随机访问形式。
3.分页统一分区树编码(PUPTE)
第三种方法PUPTE旨在在压缩数据的同时仍支持随机页访问之间为分页数据向量找到良好平衡。这提供了具有固定到可变编码的灵活性。PUPTE将数据向量统一地划分成固定大小的块,并使用IMDBS 100支持的压缩方法将每个块编码成它自己的页。结果,可以用最适合于特定块的压缩类型来压缩块。这被称为非统一压缩。(相反,对于页可加载列,对整个列执行统一压缩。)请注意,由于每个块包含相等数量的值,因此IMDBS 100可以轻松确定任何值位于哪个块中,并且由于每个块被存储在一个页中,因此我们可以确定每个值被存储在哪个页中。同时,IMDBS 100可以根据需要继续允许压缩值。IMDBS 100实现了编码和解码算法,使得用PUPTE(第三种方法)编码的分页数据向量的功能类似于页可加载列(第二种方法),只是具有不同的底层表示。
下面提供了由IMDBS 100实现的PUPTE的更多细节。
附加细节
IMDBS 100实现列式存储器内数据库。存储器内数据可以被连续存储在堆分配的存储器中(方法1)、页可加载列中(其中,页可加载数据存储在固定大小的存储器块(称为页)中以提高存储器分配效率)(方法2)、或者使用PUPTE(方法3)。支持的页大小范围从4KiB到1MiB,并且每个页大小比先前页大小类大两倍或四倍。每个页包含元数据的页标题,其后是用于访问实际内容的时隙。页可以组织成链接列表(称为页链)。为了保证数据的持久性,可能还存在可以持久存储页的磁盘存储,这由持久层处理。可以将页从磁盘加载到存储器,再到缓冲池(称为页缓冲区),尽管如果页缓冲区已满,但是必须先逐出页缓冲区中的几个页以腾出空间。
IMDBS 100管理数据库表的存储。表被表示为列的集合,每个列包含两个段。第一个是读取优化段,称为主要片段。第二个是写入优化段,称为增量片段。改变不会修改数据,而是将新行追加到增量片段中。稍后在称为增量合并的操作中将改变从增量片段引入到主要片段中,该操作本质上重建新的数据向量。主要片段从未被真正修改过或添加过(只能重建),因此我们说它是只读的。两个列片段都使用字典压缩来进行有效存储。这涉及为列中的每个唯一值分配唯一的整数,被称为值标识符。然后,将实际列存储为值ID的向量(我们称为数据向量或值ID数组),该列中每一行的一个值以及将值ID映射为其所参考的值的字典。还可以选择构造另一个数据结构(被称为反向索引),以允许有效查询。
列可以是完全驻留存储器(方法1)、页可加载(方法2)或PUPTE(方法3)。页可加载列被设计为使得对该列执行查询不需要主存储器中的整个列。数据被存储在磁盘上的页中,并且在查询期间仅将包含必要数据的页加载到页缓冲区中。为了实现页可加载列,列的三个辅助数据结构被设计为页可加载副本,可以以页为单位进行存储和访问。
因为主要片段通常比增量片段大得多,所以它们自然是压缩的候选者。对于完全驻留存储器列,IMDBS 100支持主要数据向量的五种高级压缩方法:(1)前缀编码,(2)游程长度编码,(3)簇编码,(4)稀疏编码以及(5)间接编码。然而,对于分页数据向量,由于压缩带来的高效随机页访问的挑战,使用这些压缩方法的组合是不可行的(除了具有字典压缩和n位编码的统一压缩之外)。这当然是PUPTE所要解决的问题。
本文档的其余部分使用以下符号:
n–数据向量中最大值的位长。
Smin–任何块应使用的最小空间量。
enc(n)–使用IMDBS 100支持的最慢压缩方法对数据进行编码的时间,其中,n是数据的长度。
dec(n)–从使用IMDBS 100支持的最慢压缩方法压缩的数据中解码值的运行时间,其中,n是数据的长度。
图2是用于存储器内数据库的存储器管理的方法200的流程图。方法200可以由IMDBS 100(参见图1)例如由存储器管理系统130执行。
在202,数据列被转换为分页数据向量。分页数据向量是根据PUPTE生成的,如上所述(下面将进一步详细介绍)。简言之,数据向量被划分为块,块被存储在称为页的数据结构中,并且页被排列以形成分页数据向量。块大小计算器132和编码器组件134(参见图1)可以实现该变换,如下文进一步详述。分页数据向量被存储在辅存储器120中。
在204,从分页数据向量(在202生成)读取数据。通常,这涉及在分页数据向量中识别适当的页(这可以由解码器组件136执行),并将识别的页从辅存储器120加载到主存储器110中(可以由页加载器组件138执行)。
步骤202可以被看作是预备步骤或设置步骤,例如在增量合并期间(在下文中更详细地讨论),或者在将数据向量转换为分页数据向量的任何其他点。步骤204可以被视为操作步骤,例如被视为IMDBS 100执行其数据处理操作(诸如交易数据处理、分析数据处理等)的一部分。
统一分区树
图3是统一分区树(UPT)300(也称为分页统一分区树(PUPT))的逻辑表示的框图。UPT 300是在PUPTE存储器管理处理中使用的数据结构。图3中所示的特定UPT 300是示例,并且节点、参考和块的具体布置可以根据数据向量的细节而变化。
通常,UPTO 300在逻辑上将数据向量表示为树。树具有根节点302,并且可以具有多个子节点(也称为副节点);在此显示的是子节点304、306、308、310、312和314。UPT的每个节点都对应于数据向量320的段,并将数据向量320所参考的数据进一步统一划分为固定大小的块。每个块具有选择的大小。例如,数据向量320的长度为16000000条记录,而节点302、304、306、308、310、312和314的块大小分别为4000000、1000000、1500000、200000、500000、500000和30000。允许节点的最后一块具有比选择的大小更少的值ID。(此处,子节点306中的最后一个块具有1000000个值ID,而子节点314中的最后一个块具有20000个值ID)。每个节点的内容是它表示的数据块的列表。在特殊情况下(如下所述),一个节点(称为父节点)的块由附加节点(子节点)表示。父节点具有到子节点的链接;此链接用实心箭头表示。例如,节点304是根节点302的子节点,并且节点310是节点304的子节点。根节点302对应于整个数据向量,并且后续节点对应于先前节点的块。然后,本质上,IMDBS 100(参见图1)将整个数据向量320统一划分为固定大小的块;如果有必要,特定块可以进一步统一划分(如下所述)。为了防止无限递归,任何子节点都使用小于其父节点的块大小,使得子节点中至少有两个块。相反,与整个数据向量相对应的根节点302可以使用与整个数据向量的大小相等的块大小,使得仅存在一个块;在这种情况下,IMDBS100可以使用上述的统一压缩(方法2)来实现可页加载列。
UPT 300的每个节点具有相关联的块大小N,并且包含相同大小的数据向量320的块,可能除了每个节点中的最后一个块以外(在此,节点306和314的最后一个块)。节点的块(在实心箭头的顶端)也共同在其对应的父节点(在相同箭头的尾部)上形成块,但是其块共同形成整个数据向量320的根节点302除外。虽然示例UPT 300中的节点没有包含许多块,但实际上,单个节点可以包含数百个(如果不是数千个)块。
为了存储每个节点,IMDBS 100为每个块分配一页。对于不对应于另一节点的块,IMDBS 100使用其最佳编码方案来单独压缩块,并将压缩后的块存储在已分配的页中。为了将整体编码方案与在块上使用的压缩方法区分开,后者可以被称为二次压缩。在每个页中,IMDBS 100存储足够的信息以解码该块中的任何值,而无需加载任何其他页。现在,不同的块通常将需要不同的空间量(由于不同的块大小和不同的压缩类型),并且由于内部分片的原因,必须一次将每个块分配给整个页,使得很难有效地容纳所有块。幸运的是,IMDBS使用多大小(multi-sized)的页来帮助减轻此问题,方法是让每个块使用最合适的页,该页的最小可用大小足以容纳压缩的内容。因此,每个节点被存储为页序列,每个块一个。为了存储整个UPT 300,IMDBS 100将所有节点的所有页序列附加到单个页链中。
IMDBS 100可以将子节点用于特定块的原因是,如果存储该特定块需要的空间甚至比容纳最大可用页大小的空间还要大。这种块被称为超大尺寸。例如,块302a、302b、304a、304b、306a和308a是超大尺寸块。其他块被称为常规或常规大小。对于超大尺寸块,IMDBS 100不是将块的数据及其所属的节点一起存储,而是为超大尺寸块创建新节点,从而将其数据递归存储在单独的页序列中。例如,为超大尺寸块302a创建子节点304。
由于UPT可能具有较大的高度(例如,多个级别的子节点),因此确定行的值ID存储在哪个节点中不应该涉及从根节点开始从父节点重复参考子节点。这是因为,大概每个此类参考都可能涉及从磁盘加载页以重定向到下一页。这是一个高成本操作,具有很大的存储器开销。相反,IMDBS 100将参考存储在根节点中的超大尺寸块的页内,从而可以从根节点访问所有非根节点。这些参考由图3中的虚线箭头指示,从根节点302到没有直接链接到根节点302的各个子节点(如实线箭头所示)。
下面讨论更多的实现细节。
再次,IMDBS 100除了根节点302之外还使用子节点,以支持超大尺寸块。仅当数据向量320的某些部分的压缩率另一部分好得多时,特别是通过比最大页大小和最小页大小之间的比率大得多的因子压缩时,这些才应该存在(这并不常见)。因此,可能在许多情况下,用于数据向量的UPT仅具有一个节点(例如,根节点302),并且数据向量仅被统一划分一次,这带来了更简单的编码和解码。包含超大尺寸块处理,因此PUPTE的实现可以处理所有特殊情况。当IMDBS 100遇到超大尺寸块时,它使用多个页来存储它,但是IMDBS 100还将继续保持良好的压缩率并同时访问少量的页。回想一下,这就是PUPTE想要在整个数据向量上解决的问题。这是使编码方案递归的动机。
总的来说,PUPTE处理为前面解释的折中做出了妥协。PUPTE处理的一个值得注意的特征是统一分区。具有固定大小的块意味着IMDBS 100可以通过简单的算法确定任何行的值ID存储在哪个块中。将每个块存储在一页中意味着IMDBS 100可以立即确定加载哪个页。同时,IMDBS 100继续使用值ID的二次压缩方法。
最后,回想一下,字典压缩可以确保每个数据向量实际上仅由整数组成,即使列具有不同的数据类型,诸如float或可变长度字符序列(varchar)。虽然PUPTE是专门为压缩数据向量(它是一个整数数组)而设计的,但是如果固定大小值具有适合在其上使用的压缩方法,则可以将其通用化为与任何固定大小值的数组一起工作。
图4是用于存储器内数据库的存储器管理的方法400的流程图。方法400可以由IMDBS 100(参见图1)执行,例如由存储器管理系统130和其他组件执行。与方法200(参见图2)相比,方法400更针对于描述操作中的IMDBS 100。
在402,分页数据向量被存储在辅存储器中。(如上所述,该措辞还包括分页数据向量处于已存储的状态;例如,当诸如在图2中的202已经预先生成分页数据向量时)。例如,IMDBS 100可以将分页数据向量存储在辅存储器120中。分页数据向量包括使用非统一压缩进行压缩的多个块。非统一压缩将在下面更详细地讨论,但是通常,使用第一压缩类型压缩至少一个块,并且使用第二压缩类型压缩至少另一个块。(第一压缩类型可以不同于第二压缩类型。)例如,可以使用前缀编码压缩一个块,并且可以使用簇编码来压缩另一个块。块在逻辑上作为多个页排列在分页数据向量中(如下文进一步详述)。分页数据向量可以对应于UPT 300数据结构(参见图3)。
在404,接收到数据请求。例如,数据处理组件140可以接收数据请求。数据请求可以是事务性请求(例如,编辑、添加、删除特定数据记录等)、分析性请求(例如,对一个或多个数据记录执行查询)等。
在406,识别与数据请求相关的多个页的子集。例如,解码组件136可以识别存储在辅存储器120中的分页数据向量中与数据请求相关的一个或多个页。如上所述并且如下面更详细地讨论的,当使用不同的压缩类型来压缩列的不同部分(例如,块)时,这导致非统一压缩。当列已经被非统一压缩时,识别包含特定数据记录的页将是非平凡处理,下面将进一步详细介绍。
在408,多个页的子集中的至少一个页(在406被识别)从辅存储器被加载到主存储器中。例如,页加载器组件138可以将页从存储在辅存储器120中的分页数据向量加载到主存储器110中。
在410,使用来自主存储器(在408加载)的至少一页来执行数据请求。例如,数据处理组件140可以访问加载到主存储器110中的页中的数据,以便执行数据请求。然后,数据处理组件140可以将数据请求的结果(例如,查询的输出等)提供给IMDBS 100或其他组件。
图5是生成分页数据向量的方法500的流程图。方法500可以被执行为202(参见图2)的步骤或子步骤。方法500可以由存储器管理系统130(参见图1)执行,例如,通过使用块大小计算器132和编码器组件134来执行。
在502,为数据向量计算块大小。数据向量通常对应于列的数据记录,并且可以被存储在辅存储器120中。每个块对应于数据向量的段(例如1000行或数据记录)。计算块大小包括子步骤502a-502e。
在502a,选择初始块大小。作为示例,初始块大小可以被设置为数据向量的总大小的10%。初始块大小可以根据IMDBS 100的组件的特性和性能根据需要进行调整。块大小计算器132可以选择初始块大小。
在502b,数据向量被划分为块(根据初始块大小)以形成被称为节点的数据结构。如果数据向量未被均匀地划分为多个块,则最后一个块可能小于块大小。编码器组件134可以将数据向量划分成块。
在502c,为每个块选择合适的压缩类型,使用选择的压缩类型对每个块进行压缩,并且对压缩的块计算各种压缩率。各种压缩率可以包括每个块的平均压缩率Ravg、最小压缩率Rmin和最大压缩率Rmax。此时选择的压缩类型是模拟整个编码处理的初始压缩(一旦当需要时将初始块大小调整为最终块大小)。通常,合适的压缩类型对应于该特定块的最合适的压缩类型(例如,得到最高压缩率)。例如,可以将一组压缩类型应用于块,并且可以选择具有最高压缩率的压缩类型。编码器组件134可以选择合适的压缩类型,压缩每个块,并且计算压缩率。
在502d,将压缩率(在502c计算)与误差容限进行比较。基于该比较,如果满足误差容限,则将目标压缩率Rtar设置为最小压缩率,否则将目标压缩率设置为1。编码器组件134可以评估误差容限并设置目标压缩率。
在502e,基于最大压缩率Rmax和压缩率R来计算目标空间量Star,并且基于适合目标空间量Star的最小适合页来计算页尺寸M。然后计算块大小以最小化目标压缩率Rtar。
在504,根据块大小(在502计算)对数据向量进行编码,以形成分页统一分区树(PUPT)数据结构(也称为UPT数据结构,参见图3)。编码组件134(参见图1)可以对数据向量进行编码。编码数据向量包括子步骤504a-504d。
在504a,将根节点构造为空页链,根据块大小(在502计算)对数据向量进行分区,并且使用选择的压缩类型将每个块编码为瞬态数据结构。
在504b,如果特定块具有规则大小(如下文进一步所述),则将编码数据从瞬态数据结构移动到最小合适页中,并将该页附加到页链中。
在504c,如果特定块是超大尺寸块(如下文进一步描述),则参考子节点将空页附加到页链上。
继续步骤504b和504c,直到所有块都已被处理。一旦所有块都已被处理,则所有常规大小的块都将从瞬态数据结构中移出(参见504b),并且只有超大尺寸块在瞬态数据结构中。
在504d,通过将每个超大尺寸块从瞬态数据结构移动到子节点中来递归存储每个超大尺寸块。如下面更详细描述的,像根节点那样生成每个子节点(在504a-504c),但是应用于每个特定超大尺寸块(而不是整个数据向量)。
这些步骤的结果是,根节点(和任何子节点)形成了与分页统一分区树(PUPT)相对应的页链,诸如图3的UPT 300。
块大小选择
本部分提供了有关确定块大小的更多细节(参见图5中的502)。影响块大小选择的因素通常分为两类:(1)幅度和(2)对准。
1.幅度
关于幅度因子,选择更小块大小的一些原因如下。首先,块大小显然不能超过节点的长度。此外,如果可能具有超大尺寸块,则IMDBS 100(参见图1)需要确保块大小严格小于节点的大小,以防止无限递归。这些是严格的上限,因为它们在任何情况下都不应被打破。
其次,更小的块大小允许IMDBS 100利用具有不一致模式的数据。如果系统使用大块,则块中的数据可能没有共同点,因此很难进行压缩。相反,最好尝试优化我们能够发现散布在整个数据向量中的任何简短的局部模式。为此,系统将需要更小的块,使得各个块更可能被关联并因此被压缩。
第三,在存储其中位置偏移或长度的编码方案中,IMDBS 100可以选择从块的开始而不是数据向量或节点的开始进行参考。使用更小的块大小将需要较少的位来存储这些值。
选择更大块大小的一些原因如下。首先,观察到更小的块大小会导致使用更多的块,从而导致使用更多的页。因此,仅在使用更小的页时使用更小的块才有好处。然而,如果块大小太小而无法使用最小的可用页大小,则进一步减小块大小将无益。这样做将导致继续使用相同大小的页,但页数量更多,从而导致不必要的空间浪费。因此,系统理想地希望确保块大小足够大,以至于没有块需要太少的空间。
其次,如果块大小太小,系统将无法为可能被很好压缩的数据集节省尽可能多的空间。例如,假设系统可以压缩每10,000个值以使用1个块的空间。如果系统使用的块大小为1,000,则为了节省相同的空间,需要仅用0.1个值存储每1000个值,我们可以假设这是不可能的。通常,使用更大的块大小会增加块的最大可压缩性。
总而言之,以下几点显而易见。首先,对于块大小有严格的上限。它必须不大于数据向量的长度,并且如果有超大尺寸块,则必须严格小于数据向量的长度。
其次,存在块大小的首选下限。它应该足够大,以使压缩最多的块不会占用太少的空间。这恰好解决了有关小块大小的两个问题。
第三,存在使用更小块大小的一般原因。具有低相关性的数据更有可能得到更好的压缩,因为单个更小的块更可能具有共同的模式。此外,当越过较大容器而参考小容器(例如,块、节点或数据向量)时,特定量(诸如位置和长度)需要存储的位数更少。
尽管可能还有许多其他因素尚未考虑在内,但是这些因素为IMDBS 100提供了一般性指导方针,并且几乎可以同时满足所有要求。系统的目标是在上下限内采用最小的块大小,如果上下限冲突,则以上限为准;这是因为当数据压缩不佳时,选择较小的块大小不会有任何好处。
2.对准
关于对准因子,根据数据向量的数据分布,IMDBS 100可以发现,尽管它确定了块大小,但是节点中的许多块需要大约相同的空间量。在这种情况下,IMDBS 100可能会略微调整其选择,以确保每个块的空间实际上填充了可用页大小之一,以最大程度地减少存储器开销。此处理称为对准。即使不同块使用的空间存在较大差异,IMDBS 100仍可以尝试对不可压缩块使用对准,因为它知道这些块的大小始终固定。注意,IMDBS 100在进行该对准时也应考虑所有块。IMDBS 100可能不一定需要要求平均空间对准的块,因为任何使用比该空间大一点的块都将使用下一个更大的页大小。
总之,按照优先顺序,要满足的标准如下。准则1:IMDBS 100应该确保块大小满足上限:不大于节点的长度,并且如果存在超大尺寸块,则严格小于节点的长度。准则2:IMDBS100应该使用对准方式,使得大多数块接近最大程度地填充分配的页。准则3:IMDBS 100应该确保即使使用最少空间量的块也将占据分配的页的相当一部分。准则4:在其他考虑因素相同的情况下,IMDBS 100应该选择更小的块大小,而不是更大的块大小。
我们使用以下定义来理解满足准则2(对准)意味着什么:
定义:与页对准。如果块几乎完美地填充了大小为M的页,则将块大小N与页大小M对准以获得压缩率R。
使用压缩率(未压缩/压缩)而不是块使用的确切空间更为方便,因为当IMDBS 100改变块大小时,使用的空间也会改变。另一方面,压缩率与块大小无关(在大多数情况下,请参见下面的“可选实施例”部分)。
现在,我们检查满足准则3(空间量)的要求。下表1总结了不同范围的所需空间的已用空间百分比范围:
所需空间 | 分配空间 | 已用空间百分比 |
(1b)到(4KiB) | 4kB | ~0%到100% |
(4KiB+1b)到(16KiB) | 16kB | ~25%到100% |
(16KiB+1b)到(64KiB) | 64kB | ~25%到100% |
(64KiB+1b)到(128KiB) | 128kB | ~50%到100% |
(128KiB+1b)到(256KiB) | 256kB | ~50%到100% |
(256KiB+1b)到(512KiB) | 512kB | ~50%到100% |
(512KiB+1b)到(1MiB) | 1MiB | ~50%到100% |
表1
从表1中注意到,仅当分配了最小页大小时,才有可能使用少于25%的页(基于可用页大小的粒度,甚至可以获得更好的结果)。因此,IMDBS 100可以确保所有块(尤其是最大可压缩块)使用的最小空间至少为最小页大小的25%。根据以下公式计算任何块的最小允许空间:
Smin=25%×4kB=1kB。
因此,我们希望未压缩的块至少使用:
Sunc=RmaxSmin。
通常,压缩率为R的块至少应使用:
定义:最小目标压缩率。给定压缩率R、Rmax和Smin,如果存在页大小M,其中块几乎完美地填充了大小M的页,则块大小N的目标为压缩率R。此外,如果它还保证了最低要求,即压缩率为Rmax的块至少要使用Smin空间,并且是此类块大小中的最小可能,则我们说N最低限度地以压缩率R为目标。为了确定该N,IMDBS 100计算大于的最小页大小M,然后取与页大小M对准的块大小。
注意,如果Rmax>>R使得仅以R为因子压缩的块使用的空间大于最大页大小,则没有这样的有效N。在这种情况下,如果IMDBS 100尝试确保按照Rmax压缩的块不要使用太少的空间,则按照R压缩的块最终会变得尺寸超大。否则,对于每个R,只有一个这样的N。
令Smin为最小空间,其中块的相应页不会浪费太多空间。Smin的合适候选值为1kB。
为了选择块大小,IMDBS 100首先确定分别在数据向量内的不同块的平均、最小和最大压缩率Ravg、Rmin和Rmax的一些测量值。为此,IMDBS 100选择一些初始块大小,并且模拟编码方案以使用最佳压缩方法来计算对每个块进行编码所需的空间。然后,IMDBS 100对这些结果进行汇总,以就所需空间确定汇总测量结果,然后计算压缩率的对应副本。
接下来,IMDBS 100通过最低限度以一些压缩率为目标来满足准则2-4,这主要涉及对准。如果块大小与平均值之间的差异太大,则IMDBS 100操作以R=1为目标以进行对准,从而使不可压缩的块受益最大。这是因为仅保证使用相同空间量的块是不可压缩的。另一方面,如果块大小的方差足够小,则IMDBS 100操作以接近Ravg的某个专门目标比率Rtar为目标。通常,系统更关心的是使用比平均空间更多的空间的块(或者等效地,压缩率比平均小),因为如果我们不能正确控制对准方式,则这些块有可能使用最大为平均块大小四倍的页。因此,IMDBS 100仅测量更低的压缩率变化率。解决变异性的一种方法是测量压缩率与平均值的最大下偏差,即Rerror=Ravg-Rmin。当Rerror足够小时,IMDBS 100取Rtar=Rmin,使得最大的块将将经历最多的对准,尽管通过Ravg压缩的平均块也不应该相差太远。现在,随着Rerror的增加,Ravg从Rmin进一步增加,因此具有Ravg可压缩性的块填充它们的页越来越少,这是不希望的。如果对准将比通常不使用对准节省更多空间,则IMDBS100可以认为对使用对准来说Rerror足够小。回想一下,我们所有页的填充量至少应为25%至100%,因此平均填充量应为62.5%。假设具有可压缩性Rmin的块填充其页,我们希望:
最终,如果存在最低限度地目标为Rtar的块大小,则IMDBS 100将N取为该块大小和节点的长度之间的最小值(准则1)。否则,按照Rtar或更小因子压缩的块必须尺寸超大,因此IMDBS 100不会打扰对准。不使用对准但仍满足最小大小要求并且应尽可能小的分区大小(准则3和4)如下:
由于块可能会尺寸超大,因此IMDBS 100通过在节点的一半长度与该值之间取最小值来实现特殊上限以防止无限递归。
图6是代码列表600。代码列表600以伪代码提供块大小选择处理的完整陈述(如上所述,并且也在图5中的502)。
根据上述处理的块大小选择涉及通过本质上直接将压缩方法直接应用于块来确定每个块将使用多少空间。汇总这些结果和其他算法的后续步骤均使用恒定时间。
由于编码至少需要一次查看数据向量的每个值,因此我们知道:
enc(n)∈Ω(n)。
因此,我们可以不太精确但更有用的说,不管N为何,存储块如下:
O(enc(L))。
由于N不大于L,因此上述建议等同于对整个数据向量进行编码的运行时间。这也是块大小选择的运行时间。
编码
本部分提供了编码处理的更多细节(参见图5中的504)。如上所述,该编码处理的结果是包含数据向量的PUPTE数据结构(参见图3)。
IMDBS 100(参见图1)从根节点(参见图3中的302)开始一次对一个节点的数据结构进行编码。IMDBS 100以空页链开始。对于每个节点,IMDBS 100首先使用上述处理(例如,图5中的502、图6中的列表600以及相关文本)为该节点选择块大小。然后,对于节点中的每个块,IMDBS 100将块编码为瞬态数据结构,该瞬态数据结构可以使用可以在其上使用的最佳压缩方法来任意地变大。(也参见图5中的504a。)然后,IMDBS 100测量该编码的块使用了多少空间(以便确定该块是常规的还是超大尺寸的),并设置指示其类型的位标记。如果块是常规的,则IMDBS 100将瞬态数据结构中的编码数据复制到最小适合页中,并将该页附加到运行页链中。(也参见图5中的504b。)否则,IMDBS 100将空白页附加到链上,并记下(例如,附加到队列中)该块是超大尺寸的,并且以后需要使用更小的块进行递归存储。(也参见图5中的504c。)如果当前节点是根节点,则最终IMDBS 100将在该页中存储对其他节点的参考。否则,因为实际数据将存储在另一页序列中,所以该空白页可能大部分未使用。使该页保持数据结构的一致性仍然很有用。这可能会浪费一些空间,但是考虑到该块过大,甚至无法容纳在最大页,则可能与使用量不成比例。IMDBS 100可以通过在该页上存储其他元数据来减轻该问题。
在节点中的所有块都已被处理之后,IMDBS 100继续前进以递归存储每个标记为返回的超大尺寸块。(也参见图5中的504d。)如果当前节点不是根节点,则IMDBS 100还需要在根节点中的正确页中对该节点附加参考。该页应该是其对应的块包含与该节点对应的(子)块的页。该参考可以是(s,e,N,p)形式的元组,其中s和e是节点的开始行和结束行,N是节点的块大小,p是节点的逻辑页号。可选方案可以用于提供用于解码的信息。在对该节点的所有子节点都进行递归编码之后,应该对该节点添加参考。这样,对子节点的参考在父节点参考之前发生。最终,由于插入顺序的原因,根节点中的节点参考列表应按以下顺序排序:e是按降序排序的主键,而s是按升序排序的辅键。此排序确保(1)按照排序顺序前面的节点出现在下一个节点之前,并且(2)子节点出现在父节点之前。
页链的元数据可以至少由Nroot、L和n组成,即根块大小、数据向量的长度和位长度。
图7是代码列表700。代码列表700以伪代码提供了编码处理的完整陈述(如上所述,并且也在图5中的504)。
编码的复杂度分析
本部分出于空间目的和时间目的,讨论了PUPTE页生成处理的复杂性(参见图5中的500,以及上面的相关文本)。
关于空间,很难给出PUPTE可以节省多少空间的精确测量,因为这很大程度上取决于数据分布和采用的压缩方案。然而,即使在最坏的情况下,预期使用PUPTE处理的IMDBS100(参见图1)的空间消耗也不超过页可加载列处理(上面讨论的方法2)的空间消耗,因为在最坏的情况下PUPTE处理可以回退到页可加载列。在最坏的情况下,不能压缩任何块,因此IMDBS 100选择对未压缩的块对准的块大小。结果是页大小相同,所有页都填充了未压缩的n位编码值。这等效于整个数据向量上的n位编码。当然,在一般情况下,因为IMDBS 100在可能的情况下(例如,通过压缩)对数据向量的块应用二次编码方案,所以PUPTE提供了比页可加载列处理更好的性能。只要压缩的块可以放入比未压缩的块小的页中,就可以节省空间。同样,所使用的确切空间量取决于数据和压缩方法,但是这可以轻松地比可页加载列(使用统一压缩,而无需二次压缩)小几个数量级。
因为在PUPTE中,数据必须一次存储在页上,所以平均节省的空间量减少了,可能导致大量内部片段,但是块大小的选择有助于减轻这种情况。让我们假设数据向量的长度足够长,使得在正确选择块大小的情况下,IMDBS 100可以满足期望的条件,即所有块在其分配的页中至少使用最小的空间阈值。在我们的情况下,我们希望所有页至少满25%。这意味着分配的空间不超过所需空间的4倍。因此,PUPTE中压缩率的有效性仍然至少是理论上如果在任何页上都没有浪费空间时可能达到的25%。例如,如果可以按照因子20压缩数据向量,则在应用PUPTE编码方案时,在最坏的情况下,我们可以希望按照至少因子5来压缩。
在大多数情况下,我们希望得到更好的结果。由于IMDBS 100使用对准,因此如果不同块的可压缩性变化不大,则大多数块应几乎填满它们的整个页。即使可压缩性不一致,因为IMDBS 100分别压缩块,所以PUPTE处理可能仍具有很好的性能,因此,如果一个块不能被很好地压缩,这不会直接影响另一块被压缩的能力。实际上,IMDBS 100甚至可以比不需要分页的页可加载列的性能更好。这是因为使用页可加载列处理的编码在整个数据向量上使用单一压缩方法,并且在可能需要对数据向量的不同部分使用不同压缩方法的情况下,可能会出现问题。另外,通常,IMDBS 100中的一些二次压缩方法依赖于存储长度或位置偏移。如果这些值参考的是更小的块而不是整个数据向量,则将需要更少的位来存储。
关于时间,数据库系统中的磁盘I/O比存储器I/O昂贵得多,因此写入磁盘是构建运行时间的瓶颈。写入磁盘的时间取决于已编码的PUPTE数据结构使用了多少页空间。这可以是使用的所有页的总大小或使用的页总数的组合。由于PUPTE编码方案最终压缩数据,从而节省空间,因此又减少了页写入时间。
至于在主存储器上工作的其余处理,对每个块进行编码涉及首先选择块大小(参见图5中的502),然后存储实际内容(参见图5中的504)。尽管块大小选择的一部分类似于存储实际内容,但是并不完全相同,因为由于这不需要逼近所需的空间而避免了递归存储的复杂性。在树结构的每个级别上(参见图3),如果某种程度上所有节点中的所有块都过大,则该级别中每个节点的块都不会比合并组成整个数据向量更糟。如上面关于时间分析所解释的,这将为每个级别增加O(enc(L))额外时间,以选择块大小并存储实际内容。此外,这种情况发生的次数是有限的,因为UPT具有有界高度。回想一下,子块大小始终最多为先前块大小的一半。另外,回想一下,仅当最大所需块空间与最小所需空间之间的比率超过最大允许空间(最大页大小;例如1MB)与最小允许空间(例如,1kB)之间的比率时,我们才能拥有超大尺寸块,这些示例页大小为1024。然后,如果块大小小于1024,则不应有更多的超大尺寸块。最后,在一个实施例中,数据向量的最大长度可以是232。因此,最大高度不低于以下:
log2L-log21024≤32-10=22。
因此,编码为O(enc(L)·logL)。
解码
本部分提供了更多有关从PUPT数据结构读取的细节(参见图4中的406-408)。该处理称为解码。从PUPT数据结构读取通常涉及在给定的行位置查找值。该过程通常如下。首先,IMDBS 100(参见图1)确定PUPT数据结构中包含在给定行位置的值的块。其次,IMDBS100加载具有该块的页。第三,IMDBS 100从加载的页读取值。
更具体地说,IMDBS 100可以使用以下处理来获取给定行的值ID。假设指示IMDBS100获取集合R中所有行的编码数据向量中的值ID。为了有效地执行此操作,每次IMDBS 100加载任何(子)块P的页也获得某行r∈P∩R的值时,它不仅获得r的值ID,而且还获得P∩R中的所有行。这样,IMDBS 100不必多次加载P的页。
IMDBS 100通过从根节点(例如,302)开始遍历PUPT数据结构(参见图3),一次遍历一个块。IMDBS 100寻找尚未被查询的最小行r,获取与该行相同的块P中的所有行的值,并重复。
如果P是规则块,则P中包含的所有行都应被存储在IMDBS 100刚刚加载的页上,因此加载所需的值非常容易。
否则,如果P是超大尺寸块,则其值可以被存储在节点和页的层次结构中。行要加载的正确页可以是任何深度的任何节点的页序列,并且IMDBS 100执行以下处理以确定哪个页。
由于P处于根节点,因此刚刚加载的页包含指向P的所有子节点的参考元组列表(如上面“编码”部分所述)。此外,此列表的排序方式是:其边界包含给定行的第一节点就是该行所存储的节点。这是因为尽管父节点的边界也包含存储在子节点中的行,但是在PUPT数据结构中,在我们的参考列表中子节点始终出现在其父节点之前(参见“块大小选择”部分中的上述讨论)。通常,行的值存储在其边界包含该行的最深节点中。为了找到正确的参考元组,IMDBS 100在向前方向上顺序地迭代直到它到达其起始行小于或等于其正搜索的行的第一节点。IMDBS 100从节点参考中知道从哪一页开始存储节点。
因此,搜索超大尺寸块P中的所有行的该处理就像在整个数据向量上进行搜索,尽管一个关键的区别是IMDBS 100不应再遇到任何超大尺寸块,因为它总是在实际存储该行的节点中查找。首先,IMDBS 100在P∩R中寻找尚未被查询的最小行。然后,IMDBS 100确定存储该行的节点L和L内的块P′。然后,IMDBS 100加载表示P′的页,并获得P′∩R中所有行的值。然后,IMDBS 100重复这些步骤,直到获得P∩R中所有行的值为止。
当从页获取值时,IMDBS 100根据特定于在块上使用的任何压缩方法的现有解码算法来这样做。如果IMDBS 100正在搜索的行的集合是范围,则这些可以被优化。根据值的编码方式,此处理对于顺序访问可能比随机访问更为有效。
总体复杂度分析
本部分讨论与其他现有处理(如页可加载列处理)相比,PUPTE处理的性能。
我们首先评估获取单行的值ID的性能。与我们在上面的编码复杂度分析部分中解释的内容类似,行访问期间的瓶颈操作是加载页。参考上面解码部分中描述的处理,这需要一或两个页加载。IMDBS 100(参见图1)首先从根节点加载一页,该页可能已经是存储所需行的正确页。否则,由IMDBS 100加载的页对应于目录页,该目录页将其引导到正确页,涉及一个额外页加载。但是,通常,UPT树结构(参见图3)将仅具有单个节点,因为具有超大尺寸块的情况并不太常见,在这种情况下,仅一个页加载就足够了。但是相比之下,现有的页可加载列处理可以保证一个页加载足以应付所有情况。
现在,我们在不考虑加载操作的情况下分析运行时间。在最坏的情况下,为了识别存储行的节点涉及从目录页中的参考列表中索引。这涉及二进制搜索以给出参考元组的一般位置,然后进行线性搜索以缩小搜索范围。二进制搜索遍历所有节点参考元组,其时间复杂度与节点数成对数。仅在最坏的情况下对树中的所有节点执行线性搜索。在上面的编码复杂度分析部分,我们显示了树的高度为O(logL),这告诉我们节点数为O(L)。因此,节点的总搜索时间是O(L)。在IMDBS 100识别出节点之后,它可以利用O(1)算法来确定块。最后一步是解码块中的值,即O(dec(N))或仅O(dec(L))。因此,总的来说,获取单行值的时间复杂度如下:
O(L)+O(dec(L))。
通常,节点数将更接近于一个较小的常数,因此平均性能更类似于以下:
O(dec(L))。
然而,如果IMDBS 100一次查询多个值,我们可以期望在页加载数和一般时间复杂度方面都性能更好。解码处理确保IMDBS 100不需要访问同一页两次,否则,如果在首次使用之后从页缓冲区中退出页并随后重新加载页,则可能冒着性能下降的风险。当前的分页数据向量也可以从中受益,但是如果将大量查询值存储在同一页中,则更有益,尤其是对于可以将更多值压缩到每个页上的PUPTE处理而言。确定一行在哪个页上并加载页的成本将由多行共享,而确定哪些行在相同页上的附加成本则很小。在页内解码值的平均运行时间也可以得到改善,尤其是如果IMDBS 100正在查询的行是连续的,例如在进行范围扫描的情况下。读取多行时,有更多的顺序访问用途,这取决于与页相对应的块所使用的压缩方法,其效率可能比随机访问要高得多。
可选实施例
本部分讨论IMDBS 100(参见图1)的各种可选实施例。
首先,由于所得到的增加的简单性以及最坏情况下的稍好编码和解码性能,可能更可取的是使PUPT数据结构(参见图3)始终仅使用一个节点。这可以通过选择仅考虑最大或最小可压缩块的块大小并确保它能够容纳在最大页大小来实现。这样,根节点中的任何块都不会过大。当块之间所需空间的范围变化太大时,这样做的代价是不提供有效的存储。可能非常小的块仍然必须至少使用最小页大小,即使他们实际上需要比这少得多的空间。相比之下,上面讨论的块大小选择处理(例如,图5中的502、图6和相关文本)考虑到了最小的块,以确保它们不会浪费太多空间,而代价是允许超大尺寸块。
接下来,如果节点中的块过大,则仍会像该节点中的所有其他块一样为它分配页,即使其实际内容将存储在另一个节点中。除非该块位于根节点中,否则分配的页没有什么可存储的。实际上,该页将永远不会被加载,因为它在解码处理中是不必要的。当然,这导致空间浪费。可选地,IMDBS 100可以在页中存储一些额外的元数据,诸如与该块将对应的子节点有关的任何东西。对于IMDBS 100,另一种解决方案是在页链内具有空页,诸如具有空参考或空指针,尽管这种方法的可行性取决于分页系统的实现。最终,IMDBS 100可以在该页存储子节点的一些子块(例如,第一块),使得该子节点少存储一个页。这可能会使解码处理进一步复杂化,但应为每个附加节点节省一页空间,并且不会导致更多页加载或其他严重的性能影响。
另一个考虑因素是,需要更少空间的块仅在使用更小页时才节省空间。因此,最小化浪费空间主要取决于页大小的可用性。这根据范围和粒度两者。范围是指最小可用页大小和最大可用页大小的幅度。最好使最小页大小更小,使得使用大量空间的块不会被迫使用不必要的大页。在最小页大小和最大页大小之间存在较大的差异也略好一点,使得出现超大尺寸块的可能性较小,这会使数据结构递归且更加复杂。另一方面,粒度是指连续页大小的大小差异有多小。页大小最好是更细粒度,使得块可以使用更好的页大小,即使它稍小一点。例如,根据现有的存储器内数据库系统,前几个页大小比先前大4倍。然后,即使块比存储在这些页上的另一个块小3倍,也有可能最终使用相同的页大小。在使用较小的页之前,它最多需要缩小4倍。为了解决这些问题,IMDBS 100的可选实施例增加了更多的页大小,从而改变了底层分页系统。
最后,上面讨论的块大小选择处理(例如,图5中的502、图6和相关文本)效率低下。回想一下,PUPTE处理背后的想法是首先选择一个任意的初始块大小(参见图5中的502a),然后汇总关于在我们用该块大小对节点进行分区的情况下有关块将如何可压缩的概要统计(参见502d)。然后,IMDBS 100选择最适合那些概要统计的块大小(参见502e)。但是实际上,使用不同的块大小会改变每个块的内容。因此,一个块大小的压缩率并不总是另一块大小的压缩率的很好的估计。在随着IMDBS 100改变块大小块的压缩率保持一致的假设下,PUPTE处理最大程度地有效。尽管这可能适用于许多数据分发,但并非在所有情况下都适用。如果初始块大小不能很好地反映数据向量的整体可压缩性,则这尤其成问题。举一个简单的例子,考虑可以按照因子100000压缩的数据向量。如果IMDBS 100通过仅选择初始块大小1000来分析数据向量,则每个块可能将无法按照大于1000的因子来压缩,这远没有将整个数据向量压缩得那么好。为了解决这个问题,IMDBS 100可以以多个初始块大小多次执行编码处理,并选择具有最高压缩率的结果。
结论
总而言之,上述的PUPTE处理提供了一种用于在IMDBS 100(参见图1)中压缩分页数据向量的解决方案。它允许分页数据向量以类似于现有页可加载列处理的方式继续运行,其中,以页为单位从数据向量中加载值,而不是一次加载整个数据结构。同时,PUPTE处理添加要对数据使用的非统一压缩,这可以减少空间开销,从而减少总体拥有成本。
图8是用于实现上述各种实施例的示例计算机系统800的框图。例如,计算机系统800可以用于实现IMDBS 100(参见图1)。计算机系统800可以是台式计算机、膝上型计算机、服务器计算机或任何其他类型的计算机系统或其组合。存储器管理系统130、数据处理系统140或其组合的一些或全部元件可以被包括或实现在计算机系统800中。此外,计算机系统800可以实现许多操作、方法和/或以上描述的处理(例如,图2的方法200、图4的方法400等)。如图8所示,计算机系统800包括处理子系统802,该处理子系统802经由总线子系统826与输入/输出(I/O)子系统808、存储子系统810和通信子系统824进行通信。
总线子系统826被配置为促进计算机系统800的各种组件和子系统之间的通信。尽管在图8中将总线子系统826示出为单个总线,但是本领域普通技术人员将理解,总线子系统826可以被实现为多个总线。总线子系统826可以是使用多种总线架构中的任何一种的几种类型的总线结构中的任何一种(例如,存储器总线或存储器控制器、外围总线、本地总线等)。总线架构的示例可以包括工业标准体系结构(ISA)总线、微通道体系结构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)本地总线、外围组件互连(PCI)总线、通用串行总线(USB)等。
可以被实现为一个或多个集成电路(例如,传统微处理器或微控制器)的处理子系统802控制计算机系统800的操作。处理子系统802可以包括一个或多个处理器804。每个处理器804可以包括一个处理单元806(例如,单核处理器,诸如处理器804a)或几个处理单元806(例如,多核处理器,诸如处理器804b)。在一些实施例中,处理子系统802的处理器804可以被实现为独立处理器,而在其他实施例中,处理子系统802的处理器804可以被实现为将多个处理器集成到单个芯片或多个芯片中。另外,在一些实施例中,处理子系统802的处理器804可以被实现为独立处理器和集成到单个芯片或多个芯片中的多个处理器的组合。
在一些实施例中,处理子系统802可以响应于程序代码来执行各种程序或处理,并且可以维持多个同时执行的程序或处理。在任何给定时间,要执行的部分或全部程序代码可以驻留在处理子系统802或存储子系统810中。通过适当的编程,处理子系统802可以提供各种功能,诸如上面通过参考方法200(参见图2)、方法400(参见图4)、方法500(参见图5)等描述的功能。
I/O子系统808可以包括任何数量的用户界面输入设备和/或用户界面输出设备。用户界面输入设备可以包括键盘、指示设备(例如,鼠标,轨迹球等)、触摸板、并入显示器的触摸屏、滚轮、点击轮、拨盘、按钮、开关、键盘、带有语音识别系统的音频输入设备、麦克风、图像/视频捕获设备(例如,网络摄像头、图像扫描仪、条形码读取器等)、运动感应设备、手势识别设备、眼睛姿势(例如,闪烁)识别设备、生物特征输入设备或其他类型的输入设备。
用户界面输出设备可以包括视觉输出设备(例如,显示子系统、指示灯等)、音频输出设备(例如,扬声器、耳机等)等。显示子系统的示例可以包括阴极射线管(CRT)、平板设备(例如,液晶显示器(LCD)、等离子显示器等)、投影设备、触摸屏或其他类型的设备和机制,用于从计算机系统输出信息800向用户或其他设备(例如,打印机)输出信息。
如图8所示,存储子系统810包括系统存储器812、计算机可读存储介质820和计算机可读存储介质读取器822。存储子系统810可以实现主存储器110或辅存储器120(参见图1)。系统存储器812可以被配置为以处理子系统802可加载和可执行的程序指令形式存储软件,以及在程序指令执行期间生成的数据。在一些实施例中,系统存储器812可以包括易失性存储器(例如,随机存取存储器(RAM))和/或非易失性存储器(例如,只读存储器(ROM)、可编程只读存储器(PROM)、可编程只读存储器(EPROM),电可擦可编程只读存储器(EEPROM)、闪存等)。系统存储器812可以包括不同类型的存储器,诸如静态随机存取存储器(SRAM)和/或动态随机存取存储器(DRAM)。在一些实施例中,系统存储器812可以包括基本输入/输出系统(BIOS),被配置为存储基本例程,以便于在计算机系统800内的元件之间传递信息(例如,在启动期间)。这样的BIOS可以存储在ROM(例如,ROM芯片)、闪存或可以被配置为存储BIOS的另一种类型的存储器中。
如图8所示,系统存储器812包括应用程序814(例如,实现图1的存储器管理系统130或数据处理系统140)、程序数据816和操作系统(OS)818。OS 818可以是MicrosoftWindows、Apple Mac OS、Apple OS X、Apple macOS和/或Linux操作系统的各种版本,各种市售的UNIX或类UNIX操作系统(包括但不限于各种GNU/Linux操作系统、OS等)和/或移动操作系统(诸如Apple iOS、Windows Phone、Windows Mobile、Android、BlackBerry OS、Blackberry 10、Palm OS和WebOS操作系统)中的一个。
计算机可读存储介质820可以是被配置为存储软件(例如,程序、代码模块、数据构造、指令等)的非暂时性计算机可读介质。上述的许多组件(例如,图1的存储器管理系统130或数据处理系统140等)或处理(例如,图2的方法200、图4的方法400、图5的方法500)可以实现为软件,该软件在由处理器或处理单元(例如,处理子系统802的处理器或处理单元)执行时执行此类组件和/或处理的操作。存储子系统810还可以存储用于软件执行或在软件执行期间生成的数据。
存储子系统810还可以包括计算机可读存储介质读取器822,该被配置为与计算机可读存储介质820进行通信。计算机可读存储介质820一起并且可选地与系统存储器812组合,可以全面地表示远程、本地、固定和/或可移动存储设备以及用于临时和/或更永久地包含、存储、传输和检索计算机可读信息的存储介质。
计算机可读存储介质820可以是本领域中已知或使用的任何适当的介质,包括诸如以任何用于存储和/或传输信息的方法或技术实现的易失性、非易失性、可移动、不可移动介质的存储介质。此类存储介质的示例包括RAM、ROM、EEPROM、闪存或其他存储技术、光盘只读存储器(CD-ROM)、数字多功能磁盘(DVD)、蓝光光盘(BD)、磁带盒、磁带、磁盘存储(例如,硬盘驱动器)、Zip驱动器、固态驱动器(SSD)、闪存卡(例如,安全数字(SD)卡、CompactFlash卡等)、USB闪存驱动器或其他类型的计算机可读存储介质或设备。
通信子系统824用作用于从其他设备、计算机系统和网络接收数据以及向其他设备、计算机系统和网络发送数据的接口。例如,通信子系统824可以允许计算机系统800经由网络(例如,个人局域网(PAN)、局域网(LAN)、存储局域网(SAN)、校园网(CAN)、城域网(MAN)、广域网(WAN)、全球局域网(GAN)、企业内部网、互联网、任意数量不同类型的网络的网络等)连接到一个或多个设备。通信子系统824可以包括任何数量的不同通信组件。这样的组件的示例可以包括用于访问无线语音和/或数据网络(例如,使用诸如2G、3G、4G、5G等的蜂窝技术,诸如Wi-Fi、蓝牙、ZigBee等或其任意组合的无线数据技术)、全球定位系统(GPS)接收器组件或其他组件。在一些实施例中,除了被配置为用于无线通信的组件之外或代替被配置为用于无线通信的组件,通信子系统824可以提供被配置用于有线通信(例如,以太网)的组件。
本领域的普通技术人员将认识到,图8所示的架构仅是计算机系统800的示例架构,并且计算机系统800可以具有比所示的更多或更少的组件,或者具有不同的配置组件。图8中所示的各种组件可以在硬件、软件、固件或其任何组合中实现,包括一个或多个信号处理和/或专用集成电路。
图9是用于实现上述各种实施例的云计算系统900的框图。例如,客户端设备902-908之一可以用于实现用于访问IMDBS 100的客户端设备(参见图1),并且系统900的云计算系统912可以用于实现IMDBS 100本身。如图所示,系统900包括客户端设备902-908、一个或多个网络910以及云计算系统912。云计算系统912被配置为经由网络910向客户端设备902-908提供资源和数据。在一些实施例中,云计算系统900向任何数量的不同用户(例如,客户、租户、组织等)提供资源。云计算系统912可以由一个或多个计算机系统(例如,服务器)、在计算机系统上运行的虚拟机或其组合来实现。
如图所示,云计算系统912包括一个或多个应用914、一个或多个服务916以及一个或多个数据库918。云计算系统900可以将应用914、服务916和数据库918以自助、基于订阅、弹性可伸缩、可靠、高度可用和安全的方式提供给任意数量的不同客户。
在一些实施例中,云计算系统900可以适于自动地提供、管理和跟踪客户对由云计算系统900提供的服务的订阅。云计算系统900可以经由不同的部署模型来提供云服务。例如,可以在公共云模型下提供云服务,在该公共云模型中,云计算系统900由销售云服务的组织所拥有,并且云服务可用于公众或不同行业的企业。作为另一示例,可以在私有云模型下提供云服务,在私有云模型中,仅对单个组织来运行云计算系统900,并且可以为组织内的一个或多个实体提供云服务。也可以在社区云模型下提供云服务,在社区云模型中,相关社区中的几个组织共享云计算系统900和由云计算系统900提供的云服务。也可以在混合云模型下提供云服务,该混合云模型是两个或多个上述不同模型的组合。
在一些实例中,经由网络910从云计算系统900提供给客户端设备902-908的应用914、服务916和数据库918中的任何一个被称为“云服务”。通常,组成云计算系统900的服务器和系统与客户的本地服务器和系统不同。例如,云计算系统900可以托管应用,并且客户端设备902-908之一的用户可以经由网络910订购和使用该应用。
应用914可以包括被配置为在云计算系统912(例如,计算机系统或在计算机系统上运行的虚拟机)上执行并且可以经由客户端设备902-908被访问,控制,管理等的软件应用。在一些实施例中,应用914可以包括服务器应用和/或中间层应用(例如,HTTP(超文本传输协议)服务器应用、FTP(文件传输协议)服务器应用、CGI(公共网关接口)服务器应用、JAVA服务器应用等)。服务916是被配置为在云计算系统912上执行并经由网络910向客户端设备902-908提供功能的软件组件、模块、应用等。服务916可以是基于网络的服务或按需云服务。
数据库918被配置为存储和/或管理由应用914、服务916或客户端设备902-908访问的数据。例如,UPT结构300(参见图3)可以存储在数据库918中。数据库918可以驻留在云计算系统912本地(和/或驻留在)云计算系统912中的非临时性存储介质上、在存储区域网络(SAN)或位于远离云计算系统912本地的非临时存储介质上。在一些实施例中,数据库918可以是由关系数据库管理系统(RDBMS)管理的关系数据库等。数据库918可以是面向列的数据库、面向行的数据库或其组合。在一些实施例中,部分或全部数据库918是存储器内部数据库。也就是说,在一些这样的实施例中,用于数据库918的数据被存储和管理在存储器(例如,随机存取存储器(RAM))中。
客户端设备902-908被配置为执行和操作经由网络910与应用914、服务1716或数据库918通信的客户端应用(例如,网络浏览器、专有客户端应用等)。这样,客户端设备902-908可以访问应用914、服务916和数据库918提供的各种功能,而应用914、服务916和数据库918在云计算系统900上操作(例如,托管)。客户端设备902-908可以是计算机系统800(参见图8)。尽管系统900显示为具有四个客户端设备,但是可以支持任何数量的客户端设备。
网络910可以是被配置为使用各种网络协议中的任何一种来促进客户端设备902-908与云计算系统912之间的数据通信的任何类型的网络。网络910可以是个人局域网(PAN)、局域网(LAN)、存储局域网(SAN)、校园局域网(CAN)、城域网(MAN)、广域网(WAN)、全球局域网(GAN)、内联网、互联网、任意数量的不同类型网络的网络等。
上面的描述示出了本发明的各种实施例以及可以如何实现本发明的方面的示例。以上示例和实施例不应被认为是仅有的实施例,而是被呈现以说明由所附权利要求书限定的本发明的灵活性和优点。基于以上公开和所附权利要求,其他布置、实施例、实现方式和等同方案对于本领域技术人员将是显而易见的,并且可以在不脱离由权利要求限定的本发明的精神和范围的情况下采用。
Claims (20)
1.一种计算机实现的存储器内数据库的存储器管理方法,所述方法包括:
在辅存储器中存储分页数据向量,其中,分页数据向量包括多个块,其中,使用非统一压缩来压缩多个块,并且其中,多个块被逻辑地排列在分页数据向量中作为多个页;
接收数据请求;
识别与数据请求相关的多个页的子集;
从辅存储器向主存储器加载已被识别为与数据请求相关的多个页的子集中的至少一个页;以及
使用主存储器中的多个页的子集中的至少一个页来执行数据请求。
2.根据权利要求1所述的方法,其中,对于非统一压缩,使用第一压缩类型压缩至少第一块,并且使用第二压缩类型压缩至少第二块,其中第一块与第二块不同,并且其中第一压缩类型与第二压缩类型不同。
3.根据权利要求1所述的方法,其中,分页数据向量是通过以下方法生成,所述方法包括:
计算数据向量的块大小;以及
根据块大小对数据向量进行编码,以形成与分页数据向量相对应的分页统一分区树数据结构。
4.根据权利要求3所述的方法,其中,计算块大小包括:
选择初始块大小;
将数据向量划分为多个初步块;
使用相应选择的压缩类型压缩多个初步块中的每一个,并计算多个压缩率;
基于比较压缩率和误差容限来设置目标压缩率;以及
基于压缩率计算目标空间量,并基于适合目标空间量的最小适合页计算页大小,
其中,计算块大小最低限度以目标压缩率为目标。
5.根据权利要求3所述的方法,其中,编码数据向量包括:
将根节点构造为页链,根据块大小对数据向量进行划分以形成多个块,并使用相应选择的压缩类型将多个块中的每个块编码为瞬态数据结构,其中,页链最初是空页链;以及
将具有常规大小的多个块中的每一个从瞬态数据结构移动到最小适合页中,并将每个最小适合页附加到页链。
6.根据权利要求5所述的方法,其中,编码数据向量还包括:
参考子节点将超大尺寸的多个块中的每一个的空页附加到页链上;以及
递归地将超大尺寸的多个块中的每一个存储到相应的子节点中。
7.根据权利要求1所述的方法,其中,识别与数据请求相关的多个页的子集包括:
从根节点开始,遍历分页数据结构中的多个块,一次一个块。
8.根据权利要求1所述的方法,其中,分页数据向量具有根节点和至少一个子节点。
9.根据权利要求8所述的方法,其中,根节点对应于多个块的逻辑表示,并且其中子节点对应于根节点的多个块中的单个块。
10.根据权利要求8所述的方法,其中,至少一个子节点对应于至少一个超大尺寸块,其中特定子节点对应于特定超大尺寸块。
11.根据权利要求8所述的方法,其中,至少一个子节点对应于包括第一子节点和第二子节点的多个子节点,其中第二子节点是第一子节点的孩子。
12.根据权利要求1所述的方法,其中,分页数据向量具有根节点,该根节点是包含多个块的单个节点。
13.一种非暂时性计算机可读介质,存储用于控制计算机系统以执行用于存储器内数据库的存储器管理的处理的计算机程序,所述处理包括:
在辅存储器中存储分页数据向量,其中,分页数据向量包括多个块,其中,使用非统一压缩来压缩多个块,并且其中,多个块被逻辑地排列在分页数据向量中作为多个页;
接收数据请求;
识别与数据请求相关的多个页的子集;
从辅存储器向主存储器加载已被识别为与数据请求相关的多个页的子集中的至少一个页;以及
使用主存储器中的多个页的子集中的至少一个页来执行数据请求。
14.根据权利要求13所述的非暂时性计算机可读介质,其中,对于非统一压缩,使用第一压缩类型压缩至少第一块,并且使用第二压缩类型压缩至少第二块,其中第一块与第二块不同,并且其中第一压缩类型与第二压缩类型不同。
15.根据权利要求13所述的非暂时性计算机可读介质,其中,分页数据向量是通过以下处理生成,包括:
计算数据向量的块大小;以及
根据块大小对数据向量进行编码,以形成与分页数据向量相对应的分页统一分区树数据结构。
16.根据权利要求15所述的非暂时性计算机可读介质,其中,计算块大小包括:
选择初始块大小;
将数据向量划分为多个初步块;
使用相应选择的压缩类型压缩多个初步块中的每一个,并计算多个压缩率;
基于比较压缩率和误差容限来设置目标压缩率;以及
基于压缩率计算目标空间量,并基于适合目标空间量的最小适合页计算页大小,
其中,计算块大小最低限度以目标压缩率为目标。
17.一种用于存储器内数据库的存储器管理的系统,所述系统包括:
至少一个处理器,被配置为控制系统以接收数据请求;
主存储器;
辅存储器,被配置为存储分页数据向量,其中,分页数据向量包括多个块,其中,使用非统一压缩来压缩多个块,并且其中,多个块被逻辑地排列在分页数据向量中作为多个页;
解码器组件,被配置为识别与数据请求相关的多个页的子集;以及
页加载器组件,被配置为从辅存储器向主存储器加载已被识别为与数据请求相关的多个页的子集中的至少一个页;
其中,至少一个处理器被配置为控制系统使用主存储器中的多个页的子集中的至少一个页执行数据请求。
18.根据权利要求17所述的系统,其中,对于非统一压缩,使用第一压缩类型压缩至少第一块,并且使用第二压缩类型压缩至少第二块,其中第一块与第二块不同,并且其中第一压缩类型与第二压缩类型不同。
19.根据权利要求17所述的系统,还包括:
块大小计算器组件,被配置为计算数据向量的块大小;以及
编码器组件,被配置为根据块大小对数据向量进行编码,以形成与分页数据向量相对应的分页统一分区树数据结构。
20.根据权利要求19所述的系统,其中,计算块大小包括:
选择初始块大小;
将数据向量划分为多个初步块;
使用相应选择的压缩类型压缩多个初步块中的每一个,并计算多个压缩率;
基于比较压缩率和误差容限来设置目标压缩率;以及
基于压缩率计算目标空间量,并基于适合目标空间量的最小适合页计算页大小,
其中,计算块大小最低限度以目标压缩率为目标。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/215,276 | 2018-12-10 | ||
US16/215,276 US10725911B2 (en) | 2018-12-10 | 2018-12-10 | Non-Uniform pagination of columnar data |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111291041A CN111291041A (zh) | 2020-06-16 |
CN111291041B true CN111291041B (zh) | 2023-06-06 |
Family
ID=68835118
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911252406.8A Active CN111291041B (zh) | 2018-12-10 | 2019-12-09 | 列数据的非统一分页 |
Country Status (6)
Country | Link |
---|---|
US (3) | US10725911B2 (zh) |
EP (1) | EP3667511A1 (zh) |
JP (1) | JP7030767B2 (zh) |
CN (1) | CN111291041B (zh) |
AU (1) | AU2019279904A1 (zh) |
CA (1) | CA3064125A1 (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220237191A1 (en) * | 2021-01-25 | 2022-07-28 | Salesforce.Com, Inc. | System and method for supporting very large data sets in databases |
US11698915B1 (en) | 2021-04-15 | 2023-07-11 | Humana Inc. | Cloud platform based architecture for continuous deployment and execution of modular data pipelines |
CN113539405B (zh) * | 2021-06-24 | 2024-03-19 | 北京天健源达科技股份有限公司 | 电子病历表格运算控件的处理方法 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000062553A1 (en) * | 1999-04-13 | 2000-10-19 | The Delfin Project, Inc. | Improved recognition of a pre-defined region on a transmitted image |
WO2003012089A2 (en) * | 2001-07-26 | 2003-02-13 | Astex Technology Ltd | Crystal structure of beta-site app cleaving enzyme (bace) and use thereof |
CN1805547A (zh) * | 2004-12-17 | 2006-07-19 | 微软公司 | 用于高效无损数据压缩的可逆重叠算子 |
CN103560963A (zh) * | 2013-11-18 | 2014-02-05 | 中国科学院计算机网络信息中心 | 一种OpenFlow流表存储空间压缩方法 |
CN104484284A (zh) * | 2013-03-31 | 2015-04-01 | 英特尔公司 | 用于为安全飞地页面高速缓存提供高级分页能力的指令和逻辑 |
CN105630409A (zh) * | 2014-11-25 | 2016-06-01 | Sap欧洲公司 | 使用存储器内阵列和盘上页结构的双重数据存储 |
CN105630865A (zh) * | 2014-11-25 | 2016-06-01 | Sap欧洲公司 | 用于内存列式存储的n比特压缩版本化列数据阵列 |
CN108122239A (zh) * | 2016-11-29 | 2018-06-05 | Sap欧洲公司 | 使用深度分割的图像数据中的对象检测 |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7447865B2 (en) | 2005-09-13 | 2008-11-04 | Yahoo ! Inc. | System and method for compression in a distributed column chunk data store |
US8085426B2 (en) * | 2006-11-22 | 2011-12-27 | Sharp Laboratories Of America, Inc. | Intelligent page buffer allocation |
US9626421B2 (en) | 2007-09-21 | 2017-04-18 | Hasso-Plattner-Institut Fur Softwaresystemtechnik Gmbh | ETL-less zero-redundancy system and method for reporting OLTP data |
US7917494B2 (en) * | 2008-07-11 | 2011-03-29 | Adobe Software Trading Company Limited | System and method for a log-based data storage |
US8108361B2 (en) * | 2008-07-31 | 2012-01-31 | Microsoft Corporation | Efficient column based data encoding for large-scale data storage |
JP5343793B2 (ja) * | 2009-09-28 | 2013-11-13 | ブラザー工業株式会社 | 情報生成装置、情報生成プログラム、情報生成方法、ノード装置、ノードプログラム及び検索方法 |
DE102010006931A1 (de) * | 2010-02-04 | 2011-08-04 | Bienert, Jörg, 50354 | Verfahren zur Verarbeitung von Datensammlungen, insbesondere in Datenbanksystemen |
US8606818B2 (en) * | 2010-07-19 | 2013-12-10 | International Business Machines Corporation | Optimizing the storage of one-to-many external references to contiguous regions of hierarchical data structures |
JP2013085071A (ja) | 2011-10-07 | 2013-05-09 | Fujitsu Ltd | データ圧縮装置、及び方法 |
US8639672B2 (en) * | 2012-03-27 | 2014-01-28 | International Business Machines Corporation | Multiplex classification for tabular data compression |
US8694508B2 (en) * | 2012-06-04 | 2014-04-08 | Sap Ag | Columnwise storage of point data |
US8698657B2 (en) * | 2012-09-10 | 2014-04-15 | Canon Kabushiki Kaisha | Methods and systems for compressing and decompressing data |
US9286336B2 (en) | 2013-03-12 | 2016-03-15 | Sap Se | Unified architecture for hybrid database storage using fragments |
US9977802B2 (en) * | 2013-11-21 | 2018-05-22 | Sap Se | Large string access and storage |
US9606866B2 (en) * | 2014-03-20 | 2017-03-28 | Xyratex Technology Limited | Method of, and apparatus for, improved data recovery in a storage system |
GB2525448B (en) * | 2014-04-27 | 2018-01-24 | Gurulogic Microsystems Oy | Encoder and decoder |
US10089342B2 (en) | 2014-07-10 | 2018-10-02 | Sap Se | Main memory database management using page index vectors |
US20170193351A1 (en) * | 2015-12-30 | 2017-07-06 | Micron Technology, Inc. | Methods and systems for vector length management |
US10176090B2 (en) * | 2016-09-15 | 2019-01-08 | Qualcomm Incorporated | Providing memory bandwidth compression using adaptive compression in central processing unit (CPU)-based systems |
US10372534B2 (en) * | 2016-09-20 | 2019-08-06 | Samsung Electronics Co., Ltd. | Method of operating memory device using a compressed party difference, memory device using the same and memory system including the device |
US10686466B2 (en) * | 2017-10-05 | 2020-06-16 | Cable Television Laboratories, Inc. | System and methods for data compression and nonuniform quantizers |
-
2018
- 2018-12-10 US US16/215,276 patent/US10725911B2/en active Active
-
2019
- 2019-12-05 CA CA3064125A patent/CA3064125A1/en active Pending
- 2019-12-06 JP JP2019221382A patent/JP7030767B2/ja active Active
- 2019-12-09 CN CN201911252406.8A patent/CN111291041B/zh active Active
- 2019-12-09 AU AU2019279904A patent/AU2019279904A1/en active Pending
- 2019-12-09 EP EP19214410.3A patent/EP3667511A1/en active Pending
-
2020
- 2020-06-12 US US16/900,702 patent/US11080187B2/en active Active
-
2021
- 2021-06-30 US US17/363,736 patent/US11681618B2/en active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000062553A1 (en) * | 1999-04-13 | 2000-10-19 | The Delfin Project, Inc. | Improved recognition of a pre-defined region on a transmitted image |
WO2003012089A2 (en) * | 2001-07-26 | 2003-02-13 | Astex Technology Ltd | Crystal structure of beta-site app cleaving enzyme (bace) and use thereof |
CN1805547A (zh) * | 2004-12-17 | 2006-07-19 | 微软公司 | 用于高效无损数据压缩的可逆重叠算子 |
CN104484284A (zh) * | 2013-03-31 | 2015-04-01 | 英特尔公司 | 用于为安全飞地页面高速缓存提供高级分页能力的指令和逻辑 |
CN103560963A (zh) * | 2013-11-18 | 2014-02-05 | 中国科学院计算机网络信息中心 | 一种OpenFlow流表存储空间压缩方法 |
CN105630409A (zh) * | 2014-11-25 | 2016-06-01 | Sap欧洲公司 | 使用存储器内阵列和盘上页结构的双重数据存储 |
CN105630865A (zh) * | 2014-11-25 | 2016-06-01 | Sap欧洲公司 | 用于内存列式存储的n比特压缩版本化列数据阵列 |
CN108122239A (zh) * | 2016-11-29 | 2018-06-05 | Sap欧洲公司 | 使用深度分割的图像数据中的对象检测 |
Non-Patent Citations (1)
Title |
---|
基于分块编码的SoC测试数据压缩方法研究;成丽丽;《中国优秀硕士论文全文数据库电子期刊信息科技辑》(第200811期);全文 * |
Also Published As
Publication number | Publication date |
---|---|
US11681618B2 (en) | 2023-06-20 |
US20200301835A1 (en) | 2020-09-24 |
AU2019279904A1 (en) | 2020-06-25 |
EP3667511A1 (en) | 2020-06-17 |
CN111291041A (zh) | 2020-06-16 |
US20210326259A1 (en) | 2021-10-21 |
US11080187B2 (en) | 2021-08-03 |
US20200183839A1 (en) | 2020-06-11 |
US10725911B2 (en) | 2020-07-28 |
JP7030767B2 (ja) | 2022-03-07 |
CA3064125A1 (en) | 2020-06-10 |
JP2020098593A (ja) | 2020-06-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11232075B2 (en) | Selection of hash key sizes for data deduplication | |
US10956370B2 (en) | Techniques for improving storage space efficiency with variable compression size unit | |
US10310737B1 (en) | Size-targeted database I/O compression | |
US11586366B2 (en) | Managing deduplication characteristics in a storage system | |
US9910855B2 (en) | Reordering of database records for improved compression | |
CN111291041B (zh) | 列数据的非统一分页 | |
US8892586B2 (en) | Accelerated query operators for high-speed, in-memory online analytical processing queries and operations | |
US10505563B1 (en) | Techniques for optimizing entropy computations | |
US20230325375A1 (en) | Measuring and improving index quality in a distrubuted data system | |
US20220253417A1 (en) | Database management systems for managing data with data confidence | |
US20200134047A1 (en) | Techniques for selectively activating and deactivating entropy computation | |
US11940998B2 (en) | Database compression oriented to combinations of record fields | |
WO2016194159A1 (ja) | 計算機、データベース管理方法、データベース管理システム | |
CN116339987A (zh) | 数据处理方法、装置、电子设备及存储介质 | |
CN113312414A (zh) | 数据处理方法、装置、设备和存储介质 | |
WO2016051492A1 (ja) | データベース管理システム、データベース管理方法及び記憶媒体 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |