本申请要求于2012年4月30日提交的题为“FIXEDSTRINGDICTIONARY（固定字符串字典）”的第61/640,689号美国临时申请和于2012年5月11日提交的题为“UNIFIEDTABLEUSINGMULTI-LEVELSTORAGEARCHITECTURE（使用多级存储架构的统一表）”的第61/646,162号美国临时申请的优先权，其全部公开通过引用并入本文。
技术领域：
：这里描述的主题涉及使用具有多级存储的统一表架构（unifiedtablearchitecture）的内存数据库（in-memorydatabase）的数据管理，而且更具体地，涉及部分合并的系统和方法。
背景技术：
：：现代化业务应用中的数据管理是如今软件产业中最具挑战性的课题之一。不仅是因为数据驱动如今的业务，还因为提供了发展新颖的业务理念或业务案例的基础。所有不同情况中的数据管理已成为每个组织的核心资产。此外，数据管理已经得到高级管理层的相当重视，作为推动和发展当前业务的核心工具。在系统侧，数据管理场景已经变得极其复杂且难以管理。高效、灵活、健壮和具有成本效益的数据管理层是如今的业务环境中必不可少的多个不同应用场景的核心。最初，典型的企业资源规划（ERP）系统被实施为操纵（handle）这样的应用场景的信息处理中枢（backbone）。从数据库系统的角度来看，ERP系统的联机事务处理（onlinetransactionalprocessing,OLTP）的工作负荷通常需要操纵成千上万的并发用户以及具有高更新负荷和非常有选择性的点查询的事务。另一方面，数据仓库系统（通常被认为是OLTP的对应物）要么在巨大的数据量上运行聚集查询，要么对存储在数据库中的伪影（artifact）计算供分析的统计模型。不幸的是，像用于识别数据流中异常现象的实时分析或者ETL/信息集成任务的应用增加了种类繁多的不同的、而且在某些情况下对于现代业务应用环境中的数据管理层而言是绝对具有挑战性的要求。有些人已经推测，传统的数据库管理系统不再能够提供针对各种不同要求的完整答案。针对特定问题将涌现专门的系统。大型数据管理解决方案现在通常被看作是用于不同应用场景的、具有不同能力的不同系统的集合（zoo）。例如，典型的行存储仍然主导着的OLTP领域。对于基于实体的交互模型而言，在记录中保持逻辑实体和物理表示之间的1:1的关系似乎是显而易见的。基于列组织的数据结构在解析领域中获得越来越多的关注，从而避免所查询的列的投影并且实现显著更好的数据压缩率。键值存储被大举引入商业数据管理解决方案，以便不仅应对“大数据”容量而且提供用于将并行执行的过程代码的平台。此外，分布式文件系统提供了廉价的存储机制和类似云的弹性的灵活的并行度，从而分布式文件系统使得键值存储成为数据管理领域中的一等公民。三重存储使已经过多的系统更加完整，三重存储用于应对方案灵活的数据和基于图形的组织。由于方案伴随着数据，因此系统提供了高效的方式来显式地利用实体之间建模的关系、运行分析图形算法、并展示一般用于弱类型实体的存储库。虽然专门的系统可以在首先注重性能的角度被认为是聪明的举动，但是过多的系统在链接不同的系统、运行数据复制和传播作业、或在多个系统之间协调查询场景方面产生巨大的复杂性。此外，设置和维护这样的环境不仅是复杂且容易出错的，而且还伴有显着更高的总拥有成本（totalcostofownership，TCO）。从高级角度来看，对目前情况下的动机可以做出以下观察：使用前景：SQL不再被认为是唯一适合现代业务应用的交互模型。用户要么被应用层完全屏蔽，要么想要直接与他们的数据库进行交互。在第一种情况下，需要利用紧密耦合机制来最佳地支持应用层。在第二种情况下，需要利用用于特定应用域的内置数据库特征的脚本语言。此外，从编程的角度来看，还需要全面支持域特定的和专有的查询语言，而且还对使用户能够直接解决并行性的机制存在巨大需求。成本意识：存在明确的要求：要求通过为不同类型的工作负荷和使用方案提供综合的解决方案，来为完整的数据管理栈提供较低的TCO解决方案，范围从硬件成本到设置成本到运营和维护成本。性能：性能被连续不断地确定为使用专门的系统的主要原因。挑战在于提供能够在任何可能或需要的时候使用专门的运算符或数据结构的灵活的解决方案。不同的工作负荷特性不是使用专门的系统的集合的全部理由。我们以往操纵业务应用的经验使我们支持需要专门的运算符集合这样的假说。存在对具有各自生命周期和管理设置的单独系统的偏见。然而，提供单一的封闭系统太受限制，而且替代地，具有公共服务基本元素（primitive）的灵活的数据管理平台更受欢迎。不同的工作负荷特性（范围从通过支持主要读取的分析的DWH工作负荷的大量事务处理，到流处理领域的高更新场景）不是选择专门的系统的集合的全部理由。操纵业务应用的经验导致对专门的运算符集合的需要。除了纯数据处理性能之外，应用层和数据管理层之间缺乏适当耦合机制已经被确定为最先进（state-of-the-art）系统的主要缺陷之一。此外，具有各自生命周期和管理设置的单独系统更难以设置和管理，而单一的封闭系统通常又太受限制。需要的是灵活的数据管理平台，其一方面具有公共服务基本元素，另一方面具有单独的查询执行运行时环境。技术实现要素：本文档描述了内存数据库平台，而且描述了用于应对不同事务性工作负荷的数据管理的一些具体方面的细节。在一方面，系统和方法包括提供内存计算系统的统一表架构。统一表架构包括多级存储架构，该存储架构具有第一级存储结构，用于将传入的数据请求以逻辑行的格式存储为数据记录，第二级存储结构，用于以逻辑列的格式对数据记录进行编码和存储，以及主存储，用于压缩并存储已编码的数据记录以进行长期存储。系统执行用于执行部分合并的方法。该方法包括将主存储划分为被动主部分和主动主部分，主动主部分在部分合并开始时是空的，被动主部分存储主存储的、不经历部分合并的已编码的数据记录。该方法还包括将与被动主部分的已排序的字典相对应的值索引设置为基数n。该方法还包括将第二级存储结构的数据记录合并到主动主部分，主动主部分具有以值n+1开始的字典，从而到主动主部分的合并继续按照被动主部分的值索引的编码方案。当前主题的实现方式可以包括，但不限于，包括所描述的一个或多个特征的系统和方法以及物品，所述物品包括有形地具体实施的机器可读介质，可操作以使得一个或多个机器（例如，计算机等）产生这里所描述的操作。类似地，还描述了计算机系统，其可以包括一个或多个处理器以及耦合到所述一个或多个处理器的一个或多个存储器。存储器可以包括计算机可读的存储介质，而且可以包括、编码、存储等等一个或多个程序，所述一个或多个程序使得一个或多个处理器执行这里所描述的一个或多个操作。与当前的主题的一个或多个实施方式相一致的计算机实施的方法可以由驻留在单一计算系统或多个计算系统中的一个或多个数据处理器实施。这样的多个计算系统可以连接，而且可以通过一个或多个连接交换数据和/或命令或其他指令等，所述一个或多个连接包括但不限于通过网络（例如，因特网、无线广域网、局域网、广域网、有线网络等）的连接，通过多个计算系统中的一个或多个之间的直接连接等。这里所描述的主题的一个或多个变体的细节在附图和下面的描述中阐明。根据说明书和附图以及权利要求，这里所描述的主题的其他特征和优点将是明显的。虽然出于说明目的将当前公开的主题的某些特征与企业资源软件系统或其他业务软件解决方案或架构联系起来，但是应该容易理解的是，这样的特征并非旨在进行限制。要求保护的主题的范围由权利要求限定。附图说明附图被并入说明书并构成说明书的一部分，其与说明书一起示出这里所描述的主题的某些方面，帮助解释与所公开的实施方式相关联的一些原理。附图中，图1是图示系统的一些方面的示图，其示出了与当前的主题的实施方式相一致的特征；图2图示了与当前的主题的实施方式相一致的系统一起使用的数据库分层架构；图3图示了计算模型图形；图4图示了统一表存储架构；图5是统一表的持久性和保存点机制的概述；图6图示了使用统一表的增量（delta）合并过程；图7图示了使用统一表的另一合并操作；图8图示了利用重新排序的合并；图9图示了部分合并操作；图10图示了用于统一表的主动主存储器和被动主存储器的范围查询执行；图11图示了根据当前主题的实施方式的数据库记录生命周期；图12图示了L2存储器或主存储器中数据的删除操作；以及图13图示了从第一级数据存储到第二级数据存储的数据移动。实践时，相似的参考标记表示相似的结构、特征或元素。具体实施方式图1描绘了数据库系统100，其具有内存数据库系统（in-memorydatabasesystem，IMDS）102，诸如SAP的HANA数据库（作为例子，下文中有时可以互换使用）。IMDS102包括内存数据库104和多引擎查询处理环境，其提供支持从结构良好的关系数据到不规则结构的数据图形到非结构化的文本数据的不同程度的结构的数据的不同的数据抽象。处理引擎的这个完整系列（fullspectrum）基于作为底层物理数据表示的公共表抽象，以允许不同类型的数据的互操作性和组合。在示范性实现中，内存数据库系统102还包括实时复制服务108和数据服务110，它们分别与业务套件设计环境112、业务仓库设计环境122和第三方设计环境124接口。IMDS102支持特定于应用的业务对象112（诸如OLAP多维数据集（cube）和特定于域的函数库）的表示和直接位于数据库引擎内的逻辑。这允许应用语义与底层数据管理平台进行交换，利用这样的交换能够增加查询表达力（expressiveness），减少单个应用到数据库往返的数量，并减少数据库104和应用114、116之间传输的数据量。通过一方面为专有应用服务器提供共享的存储器通信，另一方面在数据管理层中直接支持本地的数据类型，IMDS102能够高效在数据库和应用层（即，专有应用114、第三方应用116和业务仓库应用118）之间通信。此外，应用服务器技术被直接集成到数据库系统集群基础结构中，以使得能够交织执行应用逻辑和数据库管理功能。数据库系统100还支持利用高度优化的面向列的数据表示，高效地处理同一物理数据库上的事务工作负荷和分析工作负荷二者。这是通过复杂的多步骤记录生命周期管理方法来实现的。IMDS102由具有不同组件的设备模型组成，以便产生用于数据分析场景的现成的包（packet）。在一些实施方式中，IMDS102提供对业务仓库（businesswarehouse，BW）系统112的本地支持（nativesupport），以便明显加快查询和转换（transformation）场景，而且还允许完全跳过个别具体化步骤。为了提供这种能力，IMDS102具有数据加载和转换工具，以及用于创建和维护流入和流出IMDS102的复杂数据流的建模工作室（modelingstudio）106。数据库系统102提供高效、灵活的数据存储和数据查询场景。数据库系统102遵循图2所示的严格的分层架构。与典型的系统类似，数据库系统102区分数据库请求的编译时202和运行时204。另外，虽然图2中未示出，但是诸如事务管理器、授权管理器、元数据管理器等的其他组件可以补充整体架构。如图2中可以看到的，不同的查询语言206可以经由用于与外部世界执行所有基础结构任务的公共连接和会话管理层208（JDBC，ODBC连接器等）进入系统。在第一步骤中，由语言解析引擎210将查询字符串翻译成内部优化的表示（类似于抽象语法树），这是对每一种特定于域的语言的本地化。在第二步骤中，由计算图形映射引擎212将查询表达式映射到计算图形214，其形成作为IMDS的分布式执行框架216的一部分的逻辑查询处理框架的心脏，IMDS包括一个或多个特定于客户的内存数据库218，内存数据库218的结构和操作将在下面进一步详细解释。计算图形模型计算图形模型松散地遵循典型的数据流图原则。源节点表示持久的表结构、或其他计算图形的结果（outcome）。内部节点反映消费（consume）一个或多个传入数据流的逻辑运算符并且产生任意数量的传出数据流。此外，一套计算图形运算符可以被分成两组运算符类型。一方面，计算模型定义了一套内建（intrinsic）运算符，例如聚集（aggression）、投影（projection）、联接（join）、合并（union）等。例如，SQL能够完全映射到这一类运算符。另一方面，计算模型提供实现如货币转换或日历功能的核心业务算法的运算符。最后，计算模型支持以下类型的运算符：SQL节点：计算模型运算符可以对传入数据流执行完整的SQL语句。语句可以是参数，并且被编译并在计算图形的运行时执行，从而产生“嵌套计算”模型的形式。自定义节点（customnode）：自定义节点可以被用于出于性能的原因以C++实现特定于域的运算符。例如，利用SAP专有语言（如FOX）的规划场景能够采用特殊的“解聚集（disaggregate）”运算符以便本地支持财务规划情况。其他的例子是经由专有WIPE图形语言对数据图形中的图形遍历和分析进行的优化操作。R节点：R节点可以被用于将传入数据集转发到R执行环境。R脚本被作为参数给出，然后将在数据库系统之外被执行，而且结果被移回计算图形以便进行进一步处理。L节点：语言L表示数据库系统的内部运行时语言。L被设计为C语言的安全子集，而且通常不能由终端用户或应用设计者直接访问。相反，L是不能被直接映射到数据流图的特定于域的语言的所有构造（即，各种强制控制逻辑）的目标语言。除了一套功能运算符以外，计算模型还提供“分割（split）”和“结合（combine）”运算符以便将数据流的分区动态地定义和重新分配为基础构造，以使能应用定义的数据并行化。不同的特定于域的语言的各个编译器试图优化从给定的查询脚本到计算图形的映射。对于SQL，映射基于查询表达式的明确定义的（well-defined）逻辑表示。在一般情况下，映射可以要么基于试探（heuristics）要么基于成本，这取决于所估计的输入数据的大小等。例如，编译器可以决定将循环展开到常规数据流图中或者生成用于特定表达的L码。在常规SQL的情况下，这种情况是迄今为止最大、最复杂的部分而且取自主存面向行的关系数据库系统（诸如SAP的P*Time1系统），内部表示被直接映射到只展示具有用于捕获SQL语句的意图的预定语义的运算符的计算图形。图3中描绘了样本计算模型图形300。计算模型要么经由单独的特定于域的语言的编译器间接地创建，要么可以直观地在数据库工作室中建模并注册为数据库系统的元数据存储库中的计算视图。这个过程背后的总体思路是独立于实际的查询语言定制复杂业务逻辑场景的特定片段（fragment），其能够在多数据库场景中进行微调整（fine-tuned）并重新使用，即，计算模型可以以虚拟表的形式从任何特定于域的语言栈被消费。计算模型的集合（collection）也称为数据库系统内容，并且经历独立的产品生命周期过程。图3中所示的计算模型图形300列出了相对于关系数据库系统中的常规查询规划的一些差异。例如，从应用的角度来看，运算符的结果可以已经为多个消费者优化了共享的公共子表达式。其次，标有“脚本（script）”的节点覆盖（wrap）强制语言片断，其要么来自计算模型设计者，要么是由特定于域的查询编译器所产生的系统。此外，节点“转换（conv）”示出使用内置的业务功能来执行特定于应用的转换例程，例如，货币转换或单位转换。计算图形编译和执行一旦用户定义的查询表达式或查询脚本被映射到计算模型中的数据流图，优化器就运行典型的规则和基于成本的优化程序，以将逻辑规划重构和转换为物理规划，物理规划然后可以由分布式执行框架执行。执行框架编排（orchestrate）实际数据流和物理运算符的分布式执行。在优化过程中，逻辑数据流图的片段被映射到由“引擎层”提供的物理运算符。引擎层本身由不同的物理运算符的集合以及一些局部优化逻辑组成，以将全局规划的片段适配到实际的物理运算符的具体特性。特别是，数据库系统提供以下一套运算符：-关系运算符：关系运算符的集合操纵典型的关系查询图形处理。如更详细地描述，关系运算符表现不同的特性，例如，如同等联接（equi-join）的一些运算符直接利用统一表的现有字典。-OLAP运算符：OLAP运算符被优化为用于具有事实表和维度表的星型联接（star-join）场景。当优化器识别出这类场景时，相应的查询规划片段到OLAP运算符的映射被枚举为具有相应的成本估算的可行的物理规划。-L运行时：内部语言L的运行时反映用于执行在给定的计算图形的L节点中表示的L代码的构件块（buildingblock）。通过使用“分割（split）和结合”运算符对，L运行时可以被调用以便在预定义的分区上并行工作。-文本运算符：文本搜索分析运算符的集合包括在某些产品（如SAP企业搜索产品）中已经可用的一套功能，用以提供范围从相似性测量到实体解析能力的全面的文本分析功能。-图形运算符：图形运算符提供对基于图形的算法的支持，以便有效地实现复杂的资源规划场景或社交网络分析任务。由于数据流图不仅分布在多个服务器实例（通常在不同的物理节点上运行）之间，而且还分布在不同类型的运算符之间，因此系统提供用于最佳数据传输和交换格式的一套工具。尽管所有的运算符都需要实现标准数据传输协议，但是不同的“集合”之内或之外的个别运算符可以具有高度特殊化的通信协议。例如，关系运算符和OLAP运算符以高度压缩和专有的格式交换数据。此外，R节点提供到R内部数据帧格式的映射。除了不同的物理运算符之间的“横向（horizontal）”通信，它们还利用到统一表层（unifiedtablelayer）的公共接口。如在下面的部分中更详细地概述的，数据库系统提供了对于不同的运算符而言具有多种访问方式的抽象表格视图。常见的表格结构实现了数据实体的完整的生命周期，而且基本上由行存储和列存储的组合构成，以便捕获最近的修改操作的影响。由于数据库系统中的表可以被标记为“历史的（historic）”，因此表层（tablelayer）还提供用于捕获活动实体的过去值的历史表的实现，并且提供对于时间旅行查询（timetravelqueries）的访问方法。在一些实现方式中，在丢失了主存储器（mainmemory）中所捕获的数据库状态的情况下，数据库系统依赖于持久层（persistencelayer）来提供可恢复能力。持久层基于页大小可变的虚拟文件的概念。持久层依赖于频繁的保存点（savepointing），以非常低的资源开销提供一致的快照（snapshot）。这些功能在下面进一步详细描述。相比于典型的系统，根据与本说明书一致的实现方式的数据库系统是支持多个（专有的）特定于域的语言的灵活的平台。灵活的数据流模型（计算图形模型）提供了系统的核心概念：一方面，查询表达式或查询脚本被映射到模型的实例。另一方面，所有不同的物理运算符都使用对于单个记录实现完整的生命周期管理的、相同的表层接口。日志（log）和数据区被用于在持久的存储装置（storage）中维护主存存储器数据库的事务一致的副本。如图4所示，统一表结构400为所有适用的物理运算符提供数据访问。统一表结构400为单个数据库记录提供生命周期管理。统一表的技术是为基于扫描的聚集查询和高选择性的点查询两者提供优良性能的关键。这提供了与传统的基于行的数据库架构的关键区别。虽然纪录在概念上在它的整个生命周期内保持在原地更新式（update-in-place-style）数据库系统中的同一地点，但是统一表结构400通过物理表示的不同阶段传播记录。虽然被设计成总体概念，但是对于常规表内的记录，最常用的设置由三个阶段组成，如下所述。如图4所示，统一表结构400包括L1增量（L1-delta）结构402。L1增量结构402也被称为“热增量（hotdelta）”（或简称为L1增量），其接受所有传入数据请求并以写入优化的方式存储它们，即，L1增量结构402保留记录的逻辑行格式，并被优化以进行快速插入和删除、字段更新和纪录投影。此外，L1增量结构402可以执行数据压缩。根据经验法则，L1增量结构402可以在每单一表中容纳10,000至100,000行，这取决于工作负荷特性和可用的存储器量。统一表结构400还包括L2增量结构404。L2增量结构404也被称为“冷增量（colddelta）”（或简称为L2增量），其代表记录生命周期的第二阶段，并且以列存储格式组织。相比于L1增量结构402，L2增量结构404采用字典编码以达到更好的存储器使用。然而，出于性能原因，字典未被排序，序从而要求二级索引（secondaryindex）结构来最佳地支持点查询访问模式，例如快速执行唯一约束检查。L2增量结构404非常适合存储多达1000万行或更多。统一表结构400还包括主存储406。主存储406表示具有最高压缩率而且采用多种不同的压缩方案的核心数据格式。默认情况下，一列中的所有值都经由已排序的字典中的位置来表示并且以位填充（bit-packed）的方式存储，以便具有紧密压缩的各个值。虽然字典总是使用各种前缀编码方案来压缩，但是应用不同的压缩技术（范围从简单的游程长度编码方案到更复杂的压缩技术）的结合，以进一步减少主存储的存储器占用（footprint）。采用统一表结构400的数据库系统被设计用于具有复杂和高容量负荷场景的、繁重的OLAP使用情况，而且系统提供了高效批量插入的特殊处理，其可以绕过L1增量直接进入L2增量。与条目的位置无关，当进入系统时将为任何传入的记录生成行ID（RowId）。此外，日志（logging）发生在行的第一次出现，而且对于常规更新/插入/删除操作，其位于L1增量内，或者在批量加载操作的情况下，其用于L2增量。统一表访问不同的数据结构共享一套公用数据类型。通过具有行和列迭代器（二者可选地基于字典）的公共抽象接口暴露访问。此外，一些物理运算符可以遵循传统ONC（开放网络计算）协议逐条记录地出栈（pull）记录，或者以矢量化的方式（即，逐块地）出栈，以使能流水线操作并尽可能减少中间结果对存储器的要求。其他物理运算符实施“全部具体化（materializeall）”策略，以避免在查询执行过程中运算符切换成本。优化器根据逻辑计算模型决定不同类型的运算符的混合，即，在最终的查询执行规划内无缝地集成不同类型的运算符。对于利用已排序的字典的运算符而言，统一表访问接口还经由全局的已排序的字典来暴露表的内容。两个增量结构的字典被计算（仅对于L1增量）和排序（对于L1增量和L2增量二者）并且在运行中（onthefly）与主字典合并。为了实现有效的唯一性约束的验证，统一表提供用于增量结构和主结构的倒排索引。记录生命周期是以一种方式进行组织，以便在它们的事务控制范围内通过系统异步传播单个记录，而不干涉当前正在运行的数据库操作。当前的数据库系统提供了两种转换，被称为“合并步骤”：L1到L2增量（L1-to-L2-delta）合并：从L1增量到L2增量的转换暗示从行组织到列组织的旋转（pivot）步骤。L1增量的行被分成它们相应的列值（columnarvalue），并且被逐列地插入到L2增量结构中。在接收侧，系统执行查找以识别字典结构中的潜在缺失值，并且可选地在字典的末尾插入新的条目以避免在字典内的任何重大的重构操作。在第二步骤中，使用字典编码（仅附加（append-only）结构）将相应的列值添加到值向量。这两个步骤可以并行地执行，因为要移动的元组的数量预先知道，这使得能够在实际插入它们之前在新的字典中保留编码。在第三步骤中，已传播的条目从L1增量中删除。所有运行中的操作要么看到完整的L1增量和旧的增量结束边界，要么看到L1增量结构的截断版本和L2增量的扩展版本。根据设计，从L1增量到L2增量的转变实质上是增加的（incremental），即，记录的转变在重组目标结构的数据方面没有任何影响。L2增量到主结构（L2-delta-to-main）合并：新的主结构是从L2增量和现有的主结构创建出来的。虽然L1到L2增量合并对正在运行的事务具有最小的侵略性，但是L2增量到主结构合并是资源密集型的任务，其必须精心安排并在物理层上高度优化。只要开始L2增量到主结构合并，就要关闭当前的L2增量的更新并创建一个新的空的L2增量结构以用作L1到L2增量合并的新的目标。如果合并失败，系统还是利用新的L2增量操作，并且利用以前版本的L2增量和主结构重试合并。核心算法以及不同的优化技术（诸如列优先（column-wise）或部分合并）的更多细节在下面进一步详细描述。上述的两种合并操作不影响表中包含的数据，但是表被重组。然而，合并操作独立于重启或备份日志重放。持久性映射虽然数据库系统是主存储器中心数据库系统，但是在定时关机或系统故障后重新启动系统的情况下，它的完全ACID支持保证了持续性以及原子性和恢复性。数据库系统的持久性可以基于多个持续性概念。如从图5中可以看出的，持久性500基于临时重做日志（REDOlog）502和用于短期恢复或长期备份的保存点数据区504中的保存点的组合。用于REDO（重做）目的日志记入只在新的数据进入系统（或者在L1增量内，或者是L2增量内的批量插入）时执行一次。当进入L1增量时，记录的新版本被记入日志。在从L1增量到L2增量的增加传播过程中发生的变化不经历REDO日志记入。相反，字典以及值索引的变化被添加到驻留在单个数据页中的数据结构，其最终被移动到下一保存点内的持久存储中。在合并尚未通过保存点而被持久化的情况下，在重新启动时可以使用主结构的较旧版本和较长的增量。由于合并是重组，因此表的内容仍然是相同的，以确保重新启动后一致的数据库开始。图6示出了持久性映射的操作。字典和值索引二者都基于由底层存储子系统管理的分页存储布局。在保存点基础结构的控制下，由存储子系统来刷新（flush）脏页（dirtypage），脏页或者是具有附加条目的现有页，或者是新的页。虽然按每列组织L2增量结构，但是系统可以在单一页内存储多个L2增量列的片段，以优化存储器消耗。特别是对于小且宽的表，在同一页内存储多个L2增量列可以是非常合理的。在保存点之后，可以截断REDO日志。在恢复期间，系统重新加载L2增量的上次快照（保存点），并应用自有关保存点以后写入的REDO日志条目。类似地，主存储的新的版本将被持久保存在稳定的存储上，并且能够被用于重新加载统一表的主存储。总之，L2增量的截断和主存储的变化都不会被记录在日志中，因为以前版本的映像仍然存在。典型的日志记入方案只被用于L1增量和到L2增量的批量加载。总之，数据库系统内的表的物理表示由三级组成：行存储（L1增量），用于高效捕捉传入的插入以及更新和删除请求；列格式的中间结构（L2增量），用于使写优化存储从读优化存储去耦合；以及主存储结构。这个第三结构非常适合OLAP类的查询，而且也通过利用倒排索引结构被有效地调整以回答点查询。在生命周期期间，纪录将通过存储结构异步传播以便在开始时处于更新高效率的存储区，而且在它的其余生命周期内留在读取最高效的存储区。合并优化上述统一表方法的主要思路是利用L2增量索引来去耦合两个极端，从而提供从写优化存储结构到读优化存储结构的透明记录传播。虽然可以在现有的数据结构没有重大中断的情况下进行L1增量到L2增量的转变，但是L2增量和主存储结构的合并需要对表的内容的重大重组。典型的合并在典型的合并操作的第一步骤中，L2增量的字典条目被以字典的方式编译成主结构的字典，以便为特定列产生已排序的新的主字典。新的字典只包含新的主结构的有效条目，丢弃全部已删除或已修改的记录的条目。字典的排序顺序不仅提供最佳压缩的先决条件，而且还是直接在字典编码的列上工作的特殊运算符的基础。图7示出了合并步骤的主要阶段。基于利用未排序字典的L2增量和利用已排序字典的旧的主结构，第一阶段生成的新的已排序字典并在主结构和L2增量内保存来自新的位置（其明显未被显式存储）和旧的位置的映射信息。在图7中可以看出，有些条目显示了在两个字典中的位置（例如，“LosGatos”），或者有些条目只在主结构或L2增量字典中出现（例如，增量中值为4的“Campbell”和在字典位置映射表的主结构侧的值-1）。在第二阶段中，利用参照现有的和新增的条目的新字典的位置构造新的主索引。例如，再次参照图7，“DailyCity”的条目被转移到新的主结构并具有新的位置值4。“LosGatos”的条目也从L2增量中的位置1和旧的主结构中的位置5被映射到新的位置（现在是6）。新的主结构（字典和值索引）被写入磁盘并且旧的数据结构被释放。在任何情况下，系统必须在主存储器中保留列的旧的和新的版本（字典和主索引），直到仍然参照旧版本的开放事务的所有数据库操作已经执行完毕。由于合并的基本版本是高度资源密集的，因此数据库系统实现了许多不同的优化。例如，如果L2增量的字典是主字典的子集，则跳过字典生成的第一阶段，这使得主条目的位置稳定。如果L2增量字典的值大于主字典中的值，例如存在不断增加的时间戳，则存在另一种特殊情况。在这种情况下，如果对字典值进行编码的比特的数量足够应对扩展的基数（cardinality），则L2增量d字典可以直接被添加到主字典。通过重新排序合并和部分合并策略的正交技术可以得到更复杂的优化。这两种技术都在下面更详细地概述。重新排序合并L2增量和主结构之间的合并的典型版本需要将字典条目的先前位置映射到新字典的新位置。该位置然后被编码为在位填充值索引内的实际值，即，如果C是列的不同值的数量，则系统花费这么多的位来对位置编码。该合并将旧的主值映射到新字典位置（利用相同数量或增加数量的位）并在新的值索引的末尾增加L2增量的条目。合并的扩展版本旨在重组全表的内容，以产生相对于所有列的数据分布提供更高压缩潜力的数据布局。由于数据库系统列存储利用了位置寻址方案，因此第k个记录的值必须位于每列中的第k个位置。因此，重新排序一列以获得最佳的压缩方案直接影响表内所有其他列的压缩潜力。在创建新的主结构之前，系统基于来自主结构和L2增量结构的统计来计算列的“最好”排序顺序。图8示出了必要的数据结构。除了将旧字典位置翻译为新字典中的位置的字典的映射表以外，重新排序合并的版本还创建行位置的映射表，以便能够在合并和重新排序各个列之后重构行。图8示出合并过程之前和合并过程中的相同表的列，其中列“城市（City）”和“产品（Prod）”已经合并，剩余的列（例如，“时间（Time）”等）仍然反映合并前的状态。因此，主结构的旧版本的条目对应于旧字典中的位置，例如，“城市”列的条目“LosGatos”在旧字典中用值5编码，而且在合并后的版本中利用值6编码。因此，在一般情况下，在对“城市”列应用合并之后，新的主索引显示新的字典的字典位置以及行的重新排序。如图所示，第7行现在可以在第二位置找到。“产品”列也在没有建立新的字典的情况下被合并，例如，字典位置值被保留。然而，“时间”列尚未合并，而且仍然引用旧字典和旧的排序顺序。如果要求具有已经合并的列的行构造，则对尚未合并列的任何访问需要采取经由行位置映射表的额外的间接步骤。在所有列的合并已经完成之后可以消除行位置映射表。虽然系统在概念上可以通过“堆积（stacking）”行位置映射表来推迟不常访问的列的合并，但是系统总是在开始新的合并生成之前完全完成对全表的合并操作。因此，应用重新排序合并是基于成本的决策，以便在合并所有列期间用于列访问的附加的位置映射的开销与所导致的潜在的更高压缩率之间达到平衡。向各个列应用合并的排序标准还依赖于多种因素，例如，点访问与范围访问（rangeaccess）的比、压缩潜力的改善等。部分合并典型的合并或重新排序合并的主要缺点包括创建主结构的新版本的整体开销。对于大表或分区，计算新的字典并重新生成主索引确实对可用的CPU和磁盘资源有负面影响。部分合并试图通过概括先前的算法来缓和这个问题。部分合并策略对饱和列（即，当字典中新条目的数量较小的情况）显示出最佳潜力。部分合并被配置为将主结构分成两个（或更多个）独立的主结构：被动主结构：被动主结构反映主存储的稳定部分，其一般不是合并过程的一部分。主动主结构：主动主结构是动态增长/收缩的列的部分，而且参与利用L2增量的合并过程。在一些实现方式中，部分合并策略内的合并间隔以空的主动主结构开始。被动主结构反映具有已排序的字典和相应的值索引的常规主结构。每当调度合并操作时，L2增量与（仍然为空的）主动主结构合并；被动主结构保持不变。与完全合并相比，部分合并显示一个小的例外。主动主结构的字典以n+1的字典位置值开始，其中n是被动主结构字典的基数。虽然现在系统有两个利用本地已排序的字典的主结构，但是各个主值索引结构的编码并不重叠。主动主结构的字典仅保持尚未存在于被动主结构的字典中的新值。图10示出了部分合并后的主动主结构和被动主结构的示例情况。主动主结构的字典代码以编码值n+1=6开始，从而它继续被动主结构的编码方案。当被动主结构的相应值索引结构只保持对被动主结构的字典中条目的引用时，主动主结构的值索引也可以展现被动主结构的编码值，使得主动主结构字典依赖于被动主结构字典。在被动字典内解决点访问。如果发现所请求的值，则相应的位置被用作被动主值索引和主动主值索引二者的编码值。执行并行扫描以发现相应的条目。然而，如果没有发现所请求的值，则只参考主动主结构的字典。如果存在该值，则只扫描主动主值索引以便识别所得到的行位置。对于范围访问，在两个字典中解决范围访问，而且对两个结构都执行范围扫描。对于主动主结构，扫描被分成两个部分范围，一个用于被动字典的编码范围值，一个用于主动主结构字典的编码范围值。图10图示了利用C％和L％之间的值进行范围查询的这种行为。为了保证事务一致性，查询处理附加地需要类似于L1增量和L2增量的合并。当系统运行时，主动主结构可以动态收缩和增长，直到调度了完全合并为止。该概念的主要优点是将完全合并延迟到低处理负荷的情况，并且降低L2到（主动）主结构合并的成本。此外，通过在每一步骤中将主动主结构的最大大小设置为0来强迫（典型的）完全合并，优化策略可以被部署为典型的合并方案。程序可以被扩展为针对本地字典的依赖关系形成逻辑链的多个被动主结构。这种配置适合缓慢改变的或稳定的字典的列（例如，“客户（Customer）”表中的“国家（Country）”列）。然而，对于大多数列，系统将只保持一个被动主结构。部分合并优化策略在数据库系统统一表概念的一般记录生命周期中实现附加步骤。越接近流水线的末端，越复杂且越耗费时间和资源的重组被应用于记录以便最终以传统的列存储的高度压缩的和读优化的格式结束。此外，数据库系统提供历史表的概念，以便透明地将记录的先前版本移动到分离的表构造中。然而，在创建时期间，表必须定义为类型“历史的”。此外，从应用的角度来看，可以使用分区功能来将最近的数据集与更稳定的数据集分离。如上所述，数据库系统利用记录生命周期管理的思路来为事务和分析工作负荷提供高效的访问。图11突出显示了所讨论的存储格式和传播步骤的不同特性。L1增量针对更新密集型工作负荷进行优化，并且可以被增加地且频繁地并入L2增量结构中。L2增量结构已经被适当调整以用于读操作，但是与高度读优化的主结构相比需要更大的存储器占用。然而，L2增量特别适合用作L1增量行或批量插入的目标。如前面所讨论的，被选择性地分成主动部分和被动部分的主结构展现出最高的压缩率并被优化以用于基于扫描的查询模式。由于资源密集型的重组任务，合并到主动主结构，特别是完全合并以创建新的主结构被调度的频率非常低。相反，可以逐渐增加地通过将数据附加到L2增量字典和值索引来执行L1到L2增量的合并。图12图示了用于内存计算系统的统一表架构的L2增量存储器604或主存储器606的数据的操作600。如上面所讨论的，统一表结构具有多级存储架构，包括第一级存储602（L1增量存储）结构，用于将来自公共查询执行引擎601的传入数据请求以逻辑行的格式存储为数据记录。统一表架构还包括第二级存储604（L2增量存储）结构，用于以逻辑列的格式对数据记录进行编码和存储，以及主存储606，用于压缩并存储已编码的数据记录以进行长期存储。数据记录由行ID定义。数据记录的删除操作包括使用其行ID在表中执行对数据记录的查找。首先在L1增量中执行查找。如果在L1增量存储中没有发现文档标识符，则在L2增量存储中执行查找。如果在L2增量存储中没有发现文档标识符，则在主存储中执行查找。当已经确定行的位置时，以将行标记为已删除的方式修改L1增量、L2增量或主存储各自的可见性信息。表的各个部分可以使用不同的可见性信息结构，诸如可见行的位图和特定于事务的增量位图的集合或每个记录的删除时间戳。在适当修改可见性信息后，将REDO日志条目写入数据库的REDO日志，并且将撤销（UNDO）日志条目写入事务的UNDO日志。在事务提交的情况下，当不存在可能读取已删除的行的一致看法（consistentview）时，在合并操作过程中其UNDO条目被丢弃而且已删除的行的数据空间被回收。在事务中止的情况下，执行UNDO操作以便回退对可见性信息的改变。数据记录的更新可以通过结合插入记录的新版本和删除记录的当前版本来实现。这是记录已经位于L2增量或主存储中的情况。在记录位于L1增量存储中的情况下，可以通过首先将记录在额外的版本空间中具体化，然后将来自版本空间的版本合并（consolidate）回L1增量存储，来原地更新记录。除了未压缩以外，这是L1增量的主要优点之一。由于更新是在原地完成的，因此不需要更新用于非键（non-key）更新的二级索引。在这种情况下，记录的行ID可以或可以不通过更新操作改变。L2增量和主存储中的更新总是生成用于已更新的记录的新的行ID。新版本被放置到L1增量中。再次，将REDO日志条目写入数据库的REDO日志中，并且将UNDO日志条目写入事务的UNDO日志中。在这种情况下，事务的回退（执行UNDO操作）将要么只适当标记新和旧行版本的可视性信息（在L2增量或主存储中更新），要么将从版本空间中去除新版本（L1增量的更新）。图13图示了从第一级数据存储702或L1增量到第二级数据存储704或L2增量的数据移动。这里描述的主题的一个或多个方面或特征可以在数字电子电路、集成电路、特别设计的专用集成电路（ASIC）、现场可编程门阵列（FPGA）、计算机硬件、固件、软件、和/或它们的组合中实现。这些各个方面或特征可以包括一个或多个计算机程序的实现方式，所述一个或多个计算机程序在包括至少一个可编程处理器的可编程系统上可执行和/或可解释，所述至少一个可编程处理器可以是专用或通用的，而且被耦合以便从/向存储系统接收/发送数据和指令，所述可编程系统还包括至少一个输入装置和至少一个输出装置。可编程系统或计算系统可以包括客户端和服务器。客户端和服务器一般相互远离，而且通常通过通信网络交互。客户端和服务器之间的关系通过在各自计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生。这些计算机程序还可以被称为程序、软件、软件应用、应用、组件或代码，而且包括用于可编程处理器的机器指令，并可以以高级过程和/或面向对象的编程语言、和/或汇编/机器语言实现。如这里所使用的，术语“机器可读介质”指的是任何计算机程序产品、装置和/或设备，例如磁盘、光盘、存储器、可编程逻辑器件（PLD），用于向包括机器可读介质的可编程处理器提供机器指令和/或数据，所述可编程处理器接收机器指令作为机器可读信号。术语“机器可读信号”指的是用于向可编程处理器提供机器指令和/或数据的任何信号。机器可读介质可以非暂时性地存储这样的机器指令，例如，是非暂时性固态存储器或磁性硬盘驱动器或任何等效的存储介质。机器可读介质可以替代地或附加地以暂时的方式存储这样的机器指令，例如，是处理器高速缓存或与一个或多个物理处理器核相关联的其它随机存取存储器。为了提供和用户的交互，这里所描述的主题的一个或多个方面或特征可以在具有显示设备和键盘以及指示设备的计算机上实现，显示设备例如是阴极射线管（CRT）或液晶显示器（LCD）或发光二极管（LED）监视器，用于向用户显示信息，指示设备例如是鼠标或轨迹球，用户利用它们可以提供到计算机的输入。其他种类的设备也可以被用来提供和用户的交互。例如，提供给用户的反馈可以是任何形式的感官反馈，例如视觉反馈、听觉反馈或触觉反馈；并且，可以以任何形式接收来自用户的输入，包括但不限于声音、语音或触觉输入。其他可能的输入设备包括但不限于触摸屏或其他触摸敏感设备，如单点或多点电阻式或电容式触控板、语音识别硬件和软件、光学扫描仪、光学指示器、数字图像捕获设备以及相关的解释软件等。这里所描述的主题可以根据期望的配置具体实施在系统、装置、方法和/或物品中。以上描述中所阐明的实现方式并不代表与这里所描述的主题一致的所有实现方式。相反，它们仅仅是与所描述的主题有关的一些方面相一致的一些例子。虽然上面已经详细描述了一些变体，但是其它修改或添加是可能的。特别是，除了这里所阐明的特征和/或变体以外，还可以进一步提供其他特征和/或变体。例如，可以将上述实现方式用于所公开的特征的不同组合和子组合、和/或以上进一步公开的一些特征的组合和子组合。此外，为了达到期望的结果，附图中描绘的和/或此处描述的逻辑流不一定要求所示的特定顺序或顺序的顺序。其他实现方式可以落入权利要求的范围内。当前第1页1 2 3 当前第1页1 2 3