CN102171695A - 用于基于列的数据编码的结构的查询的高效大规模联接 - Google Patents

Abstract

本发明涉及基于列的数据编码的结构的查询，其允许对大规模数据存储的高效查询处理，尤其是关于联接运算。最初，接收根据基于列的组织以及已经实现实时的非常高效且快速的查询响应的各种压缩和数据打包技术来表示数据的压缩结构。除了已经由压缩的面向列的结构实现的快速查询之外，提供了用于存储器中的查询处理的可伸缩的快速算法，该算法构造用于联接运算的同样是面向列的辅助数据结构，该辅助数据结构进一步利用了存储器内数据处理和访问的特性，以及压缩数据结构的面向列的特性。

Description

用于基于列的数据编码的结构的查询的高效大规模联接

技术领域

本发明一般涉及与对大量数据的查询有关的高效的基于列的联接运算。

背景技术

作为关于常规数据查询系统的背景，当大量数据被存储在数据库中时，如当服务器计算机收集很长时间段内的大量数据记录或事务时，其他计算机有时候希望访问该数据或该数据的目标子集。在这一情况下，其他计算机可经由一个或多个查询运算符来查询所需数据。在这一方面，历史上，关系型数据库已经出于此目的而演变，并且已经被用于此类大规模数据集合，并且已经开发了指示数据库管理软件代表查询客户机从关系型数据库或一组分布式数据库中检索数据的各种查询语言。

传统上，关系型数据库是根据对应于记录的、具有字段的行来组织的。例如，第一行可能包括关于其对应于各列的字段的各种信息(姓名1、年龄1、地址1、性别1等)，这些信息定义了该第一行的记录；而第二行可能包括关于第二行的各个字段的各种不同信息(姓名2、年龄2、地址2、性别2等)。然而，客户机对巨大量的数据的常规查询或对本地查询或本地商业智能检索巨大量的数据受到限制，因为它们无法满足实时或近乎实时的要求。尤其是在客户机希望具有来自服务器的最新数据的本地副本的情况下，在给定有限的网络带宽和有限的客户机高速缓存存储的情况下，从服务器传输这样大规模量的数据对于许多应用迄今仍是不切实际的。

作为进一步的背景，由于将不同的行概念化为不同记录对于作为体系结构的一部分的关系型数据库是很方便的，因此由于关系型数据库是如何组织的本质，用于减小数据集大小的技术迄今已聚焦于行。换言之，行信息通过将每一记录的所有字段一起保持在一行上来保存每一记录，并且用于减小聚集数据的大小的传统技术将字段保持在一起来作为编码其自身的一部分。

因此，期望提供一种在数据大小减小和查询处理速度方面达到同时增益的解决方案。除了以产生对大量数据的非常高效的查询的方式来应用压缩之外，还期望在其中可以预期将执行相同或相似查询的查询环境中提供改进的数据查询技术。在这一点上，在其中许多查询根据各种数据密集型应用来运行的环境中当一组分开的查询蕴含了相同或相似的数据或数据子集时，期望试图重复使用结果。

更具体地，在查询处理中，在大多数情况下，查询将蕴含联接多个表以便达到组合来自多个表的结果集的目标的需求。例如，如果销售(sales)数据被存储在销售表中而产品(product)细节被存储在产品表中，则应用可能希望报告按照产品类别来拆分的销售。在SQL中，这可被表达为“select from”构造，如：

Select产品类别，和(数量)from销售内部联接产品on sales.sku＝product.sku。

对于以上示例，满足该联接运算的常规方式包括散列联接、合并联接和嵌套循环联接运算。散列联接按照库存单位(SKU)到产品类别来在产品上构建散列结构，并在销售表中查找来自该散列结构的每一SKU。合并联接按照SKU对销售记录和产品表两者进行排序，然后同时扫描这两个集合。嵌套循环联接扫描产品表来寻找销售表中的每一行，即，嵌套循环联接对销售表中的每一行在产品上运行查询。然而，这些常规方式或者不是特别高效的，例如，嵌套循环联接，或者在该过程的前端引入显著的开销，这对于对大量数据的实时查询要求可能是不合需要的。由此，需要用于数据密集型应用环境中的对大量数据的查询的快速且可伸缩算法。

当今的关系型数据库和对应的查询技术的上述缺点仅旨在提供常规系统的一些问题的概览，并且不旨在是穷尽性的。常规系统的其他问题以及此处所描述的各非限制性实施例的对应的益处可以在审阅以下描述后变得更显而易见。

概述

此处提供了简化概述以帮助能够对以下更详细的描述和附图中的示例性、非限制性实施例的各方面有基本或大体的理解。然而，本概述并不旨在作为详尽的或穷尽的概观。相反，本概述的唯一目的是以简化的形式来提出与一些示例性非限制性实施例相关的一些概念，作为以下各实施例的更为详细的描述的序言。

描述了基于列的数据编码的结构的查询的各实施例，这些实施例允许对大规模数据存储的高效查询处理，尤其是关于联接运算。最初，接收根据已经实现实时的非常高效且快速的查询响应的基于列的组织以及各种压缩和数据打包技术来表示数据的压缩结构。除了已经由压缩的面向列的结构实现的快速查询之外，提供了用于存储器中的查询处理的可伸缩的快速算法，该算法构造用于联接运算的辅助数据结构，该辅助数据结构进一步利用了存储器内数据处理和访问的特性，以及压缩数据结构的面向列的特性。

这些和其他实施例在下面将更详细地描述。

附图简述

各非限制性实施例参考附图来进一步描述，附图中：

图1是根据一实施例的用于形成高速缓存的一般过程的流程图；

图2是示出结合处理查询使用的辅助高速缓存240的形成的框图；

图3示出了对关于查询所接收到的列数据的存储器内客户机侧处理的工作可在多个核之间拆分，以便共享处理跨列组织的大量行的负担；

图4是示出可在查询处理期间跨面向列的压缩数据结构的各个段使用的辅助高速缓存的框图；

图5是示出此处描述的使用懒惰高速缓存(lazy cache)来跳过查询的某些联接运算的技术的应用的第一流程图；

图6是示出此处描述的使用懒惰高速缓存来跳过查询的某些联接运算的技术的应用的第二流程图；

图7是示出基于列的编码技术以及对已编码数据的查询的存储器内客户机侧处理的一般框图；

图8是示出采用基于列的编码技术的编码装置的示例性、非限制实现的框图；

图9是示出用于向大规模数据应用基于列的编码的示例性、非限制过程的流程图；

图10是原始数据的基于列的表示的图示，其中记录被分解成其各自的字段，相同类型的字段然后被串行化来形成向量；

图11是例示记录数据的列化的非限制框图；

图12是示出字典编码的概念的非限制框图；

图13是示出值编码的概念的非限制框图；

图14是示出在混合压缩技术的一方面中应用的位打包的概念的非限制框图；

图15是示出在混合压缩技术的另一方面中应用的行程长度编码的概念的非限制框图；

图16是示出采用基于列的编码技术的编码装置的示例性、非限制实现的框图；

图17是示出根据一实现的用于向大规模数据应用基于列的编码的示例性、非限制过程的流程图；

图18-19是执行贪婪行程长度编码压缩算法的方式的示例性图示，包括任选地应用阈值节省算法来应用一替代压缩技术；

图20是进一步示出贪婪行程长度编码压缩算法的框图；

图21是示出混合的行程长度编码和位打包压缩算法的框图；

图22是示出基于总计的位节省分析来自适应地提供不同类型的压缩的混合压缩技术的应用的流程图；

图23是示出根据本发明的各实施例的基于列的编码的示例执行来减小总体数据大小的框图；

图24示出了关于纯和非纯区域之间的转换(以及相反)可应用于基于列的已编码数据的桶化过程；

图25示出了根据一实施例的关于列的桶化的非纯等级；

图26示出了将查询/扫描运算符高效地划分成对应于与当前查询/扫描相关的列中存在的不同类型的桶的子运算符；

图27示出了基于列的编码的能力，其中所得的纯桶表示数据的超过50％的行；

图28示出了用于以标准化方式指定对数据的查询的、用于查询语言的示例性、非限制查询构件块；

图29示出了对消费客户机设备所请求的对于可经由网络获得的大规模数据的样本查询的代表性处理；

图30是示出根据各实施例的用于根据列来编码数据的过程的流程图；

图31是示出根据一个或多个实施例的用于位打包整数序列的过程的流程图；

图32是示出用于对数据的基于列的表示进行查询的过程的流程图；

图33是表示其中可实现此处所描述的各实施例的示例性、非限制性联网环境的框图；以及

图34是表示其中可实现此处所描述的各实施例的一个或多个方面的示例性、非限制性计算系统或操作环境的框图。

详细描述

概览

作为以下内容的路标，首先描述各实施例的概览，然后更详细地讨论示例性的、非限制任选实现来提供补充的上下文和理解。然后，描述了关于用于对大量数据打包的基于列的编码的某些补充上下文，包括经由混合压缩技术自适应地在行程长度编码和位打包的性能益处之间进行折中的实施例。最后，阐明了其中可应用各实施例的某些代表性计算环境和设备。

如在背景中所讨论的，特别地，由于当前压缩技术的限制、网络上的传输带宽的限制以及本地高速缓冲存储器的限制，常规系统不足以处理在存储器内非常快地从服务器或“云”中的其他数据存储读取巨大量的数据的问题。该问题在具有实时要求的各种不同数据密集型应用执行许多查询时变复杂。

因此，在各非限制实施例中，除了对大量数据的高效的面向列的编码之外应用一种技术，该技术同时对数据进行压缩和组织，使得对该数据的稍后的扫描/搜索/查询运算更为高效。在各实施例中，当发生查询时在本地高速缓存存储器中生成辅助的面向列的数据结构来通知将来的查询，从而使得查询随着时间的推移会更快，而不会引入显著开销以在前端生成复杂数据结构。

在一个实施例中，最初，根据涉及可忽略开销的步骤形成“懒惰”(lazy)高速缓存。接着，在查询期间只要发生未中(miss)就填充该高速缓存，然后在导出结果集方面使用该高速缓存。

由于辅助数据结构和压缩数据结构都是根据数据的基于列的视图来组织的，因此高效地实现了对数据的重复使用，因为在本地高速缓存中表示的结果可在适当时在应用于该压缩数据结构的列的联接运算中被快速替换，得到对给定查询所蕴含的结果的整体上更快且更高效的联接。

采用辅助高速缓存的数据的基于列的数据联接

如在概览中所提到的，可向大量数据应用面向列的编码和压缩来压缩且同时组织数据以使得稍后对数据的扫描/搜索/查询运算显著更高效。在各实施例中，除了这一面向列的编码和扫描技术之外，提供了一种利用存储器内特性以及数据的压缩编码的面向列的特性的可伸缩的快速算法。

在一个实施例中，如图1所示，最初，接收压缩的面向列的数据结构100，在该数据结构上可以根据下节中详细描述的扫描技术来处理查询。一般而言，为了加速数据密集型环境中的查询处理，在110，根据涉及可忽略的开销的步骤来形成“懒惰”高速缓存。在一个实施例中，该懒惰高速缓存被构造为在一开始未被初始化或未初始化的向量。接着，在120，在查询期间在发生未中的任何地方填充该高速缓存。然后，在130，在导出结果集140方面使用该高速缓存。

在这一点上，执行对大量数据的查询所蕴含的联接运算在此处呈现的各实施例中被高效地执行，因为避免了常规系统所蕴含的昂贵的前端排序或散列运算。

一般而言，使用压缩的面向列的结构的系统在图2中示出。面向列的压缩结构235从大规模数据存储200中被检索出来满足查询。基于列的编码器210压缩来自存储200的数据以便通过传输网络215在存储器内230接收，用于数据消费者220的组件250的快速解码和扫描。面向列的压缩结构235是对应于根据以下更详细描述的技术来编码和压缩的列值的一组压缩的列序列。

在一个实施例中，当根据上述技术的压缩列在消费客户机系统上在存储器内加载时，该数据跨每一列C1、C2、C3、C4、C5、C6来分段，以形成段300、302、304、306等等，如图3所示。在这一点上，由于每一段可包括数亿行或更多，并行化提高了例如根据查询对数据的处理或扫描速度。每一段的结果被聚集，以形成一组完整的结果，而每一段被分开处理。

如图4所示，最初，在其中要执行快速查询的数据消费者400的存储器内430形成懒惰高速缓存420。在一个实施例中，如图所示，懒惰高速缓存420被压缩的面向列的数据结构的不同段410、412、414、……、418共享。各段也是用于如下所述的多个处理器基础上的扫描的并行化单元。在这一点上，根据各实施例，辅助高速缓存420由此可由解码器和查询处理器440使用来创建关于以下更详细描述并可跨段410、412、414、……、418使用的联接运算的处理快捷方式。

在一个实施例中，高速缓存420用-1来初始化(未被初始化)，这是不昂贵的运算。然后，在背景中给出的示例的上下文中，其中应用可能希望报告按照产品类别来拆分的销售，在查询的生存期上，高速缓存420由来自产品表的匹配数据ID来填充，然而仅在需要时才这样做。例如，如果销售表被另一表，例如顾客表，大量地过滤，则该向量中的许多行将保持未初始化。这表示优于传统解决方案的性能好处，因为它实现了跨表过滤好处。

关于填充懒惰高速缓存，当发生扫描时，使用外键数据ID，例如此处使用的示例中的sales.sku作为对懒惰高速缓存420的懒惰扫描向量的索引。如果该值为-1，则实际联接在段410、412、414、……、418的适当的列上发生。关系遍历因此在进行中发生，并且检索感兴趣的列的数据ID，例如本示例中的产品类别。另一方面，如果该值不为-1，则这意味着联接阶段可被跳过，改为利用该值，产生大量的性能节省。另一好处是不需要像关系型数据库中那样执行锁定，因为在存储器内430写入向量是核心处理器数据类型的原子操作。尽管联接可被解析两次，但在-1值被改变之前，这通常是罕见的情况。因此，来自懒惰高速缓存的值可以用实际列值来替换。随着时间的推移，高速缓存420的值随着数据消费者400执行更多查询而增加。

图5是示出此处描述的使用懒惰高速缓存来跳过查询的某些联接运算的技术的应用的流程图。在接收到压缩的面向列的数据结构500之后，在510，按照对应于数据存储中的数据的不同列的整数编码且压缩的值序列来接收数据子集。在520，通过确定本地高速缓存是否包括对应于联接运算所蕴含的列的任何非默认值来确定联接运算的结果集。在530，当在本地高速缓存包括对应于联接运算所蕴含的列的任何非默认值的情况下确定结果集时，替换非默认值。在540，将结果集的结果存储在本地高速缓存中以便用于关于附加查询或同一查询的其他联接运算的替换。

图6是示出此处描述的使用懒惰高速缓存来跳过查询的某些联接运算的技术的应用的另一流程图。在接收到压缩的面向列的数据结构600之后，在610，生成懒惰高速缓存，该懒惰高速缓存被响应于查询按照对应于不同数据列的整数编码且压缩的值序列来检索的压缩数据的各段所共享。在620，响应于查询参考蕴含联接运算的懒惰高速缓存来处理查询。

在630，扫描压缩的值序列，并且根据预定算法来用来自表的数据值填充懒惰高速缓存，供查询处理的生存期上数据值的重复使用。在一个实施例中，该预定算法包括在640确定懒惰高速缓存中对应于外键数据ID的值是否是默认值(例如，-1)。如果否，则在650，可使用懒惰高速缓存中的数据值，即，在懒惰高速缓存中替换-1值以供潜在的重复使用。如果是，则在步骤660，可执行对值序列的实际联接。

此处使用的“懒惰”指的是不需要先期执行大量提前工作，而是高速缓存随着时间的推移且视与给定系统所处理的查询相一致的需要变为被填充的概念。存储器内高速缓存的非限制优点是它是无锁的，并且另外，该高速缓存可跨段(并行化单元，见图3-4)共享。因此，提供了可通过处理查询的各种应用来填充的跨维度过滤的高速缓存。结果，例如用于蕴含联接运算的已过滤查询的速度和可伸缩性提高了一个数量级。

补充上下文参考：基于列的数据编码

如在概览中所提到的，在各实施例中可向大量数据应用面向列的编码和压缩来压缩且同时组织数据以使得稍后对数据的扫描/搜索/查询运算显著更高效。在各实施例中，为了开始编码和压缩，原始数据最初被重新组织为列化的数据流，并且参考以下对于围绕懒惰高速缓存的补充上下文来呈现的各种非限制示例来解释压缩和扫描过程。

在一示例性、非限制实施例中，在将原始数据列化成一组值序列，对每一列有一个值序列(例如，串行化数据列的各字段，例如，所有“姓”串行化为一个序列，或所有“PO订单号”串行化为另一序列，等等)之后，对该数据进行“整数化”以便形成每一列的整数序列，该整数序列根据字典编码、值编码或字典编码和值编码一起以任意次序来统一地表示。该整数化阶段得到统一表示的列向量，并且本身能达到显著的节省，尤其是在数据中记录了诸如文本串等长字段的情况下。接着，检查所有的列，压缩阶段迭代地将行程长度编码应用于任何列的行程，这将导致对整体的列向量集合的最大量的整体大小节省。

如上所述，打包技术是基于列的，其不仅提供了优秀的压缩，而且该压缩技术本身有助于在一旦将压缩的整数列向量递送到客户机侧之后快速地处理数据。

在各非限制实施例中，如图7所示，提供了基于列的编码器/压缩器710来用于压缩大规模数据存储700并且还用于使得结果对于数据的扫描/搜索/查询运算显著更高效。响应于数据处理区C中的数据消费设备720的查询，压缩器710通过数据传输区B的传输网络715来发送涉及该查询的压缩列。该数据被递送到存储器内存储730，且因此对相关列的解压可以由数据处理区C中的解码器和查询处理器740来非常快地执行。在这一点上，向涉及该查询的解压的列所表示的行应用桶走查来获得额外的高效处理层。在桶走查期间充分利用行的相似性，使得重复动作被一起执行。如以下更详细描述的，当以具有196GbRAM的标准或商用服务器将该技术应用于真实的样本数据，如大量的web通信数据或交易数据时，以大约每秒1.5T字节数据实现了服务器数据的查询/扫描，这是超越常规系统的能力的极大飞跃，却只花费了显著降低的硬件成本。

尽管可被压缩的具体数据类型决不限于任何特定数据类型，且取决于对巨大量的数据的大规模扫描的情形数量类似地是无限的，但在实时商业智能应用中将这些技术应用于商业数据或记录的商业重要性是不容置疑的。该压缩技术所实现的查询处理速度的极大获益将实时报告和趋势标识带到了一个全新的水平。

编码器的一个实施例在图8中概括地示出，其中在800，从存储接收或读取原始数据，此时编码装置和/或编码软件850在810处将数据组织为列。在820处，将列流变换成统一向量表示。例如，可应用整数编码来将像姓名或地点这样的各个条目映射到整数。这一整数编码可以是字典编码技术，该技术可将数据减小2倍到10倍。另外，或另选地，值编码可在大小上提供1倍到2倍的减小。这在820处为每一列留下了一整数向量。这一性能提高对所压缩的数据敏感，并且这一大小减小范围仅作为非限制估计来给出，以便给出不同步骤的相对性能的一般概念。

然后，在830处，可进一步压缩已编码的统一列向量。在一个实施例中，应用行程长度编码技术，该技术确定所有列上的最频繁的值或值的出现，在这一情况下，为该值定义一行程长度，且该过程迭代直到行程长度编码的益处为边际效益的时刻，例如对于在列中具有至少64次出现的重复出现的整数值。

在另一实施例中，检查应用行程长度编码所得的位节省，并且在该迭代过程的每一步，通过应用对行程长度的重新排序和定义来选择各列中达到最大位节省的列。换言之，由于目标是用尽可能少的位来表示列，因此在每一步，在提供最大节省的列处最大化了位节省。就这一点而言，行程长度编码本身可以提供显著的压缩改善，例如100倍或更多。

在另一实施例中，在830处应用混合压缩技术，该技术采用了位打包和行程长度编码的组合。应用检查两种技术的潜在节省的压缩分析，并且在例如认为行程长度编码导致不足够的净位节省的情况下，则向列向量的其余值应用位打包。因此，一旦根据一个或多个准则确定行程长度节省是最小的，则该算法对于该列的其余相对唯一的值切换到位打包。例如，在列中所表示的值变得相对唯一(其中非独唯一或重复值已经被行程长度编码)的情况下，可对这些值应用位打包而非行程长度编码在840处，输出的是对应于根据上述技术编码并压缩的列值的一组压缩的列序列。

图9概括地根据以原始数据900的输入为开始的流程图描述了上述方法。在910，如上所述，根据原始数据900的列来重新组织数据，而不是像常规系统那样将记录的每一字段保持在一起。例如，如图10所示，每一列形成一独立的序列，如序列C1001、C1002、C1003、C1004、C1005、C1006。在零售交易数据是该数据的情况下，例如，列C1001可能是产品价格的串，列C1002可能表示购买日期的串，列C1003可能表示商店位置，等等。考虑到计算机系统所收集的大多数真实世界数据在所表示的值方面并不是非常不同的，因此基于列的组织维持了数据类型内的固有相似性。在920处，基于列的数据经历一个或多个转换来形成统一表示的基于列的数据序列。在一个实施例中，步骤920经由字典编码和/或值编码将每一列简化为数据的整数序列。

在930处，用行程长度编码过程以及可任选地用位打包来压缩基于列的序列。在一个实施例中，行程长度编码过程对所有各列中达到最高压缩节省的列的列数据值序列重新排序。由此，行程长度编码达到最高节省的列被重新排序来对由行程长度编码替换的共同值进行分组，然后为重新排序的组定义行程长度。在一个实施例中，跨各列迭代地应用行程长度编码算法，在每一步检查每一列来确定将达到最高压缩节省的列。

当根据一个或多个准则应用行程长度编码的益处变为边际效益或最小，如不足够的位节省或节省小于一阈值时，则其应用的益处相应地下降。结果，该算法可以停止，或者对于每一列中未被行程长度编码来编码的剩余值，可应用位打包来进一步降低对这些值的存储要求。在组合中，混合行程长度编码和位打包技术可能是强大的，以便减小列序列，尤其是具有序列中表示的有穷或有限数量的值的那些序列。

例如，字段“性别”仅有两个字段值：男和女。采用行程长度编码，这一字段可被相当简单地表示，只要数据是根据如上所述的原始数据的基于列的表示来编码的。这是因为背景中所描述的聚焦于行的常规技术实际上通过将每一记录的字段保存在一起而破坏了列数据的共同性。接在诸如“21”等年龄值后面的“男”不如仅仅接在“男”或“女”值后面的“男”值压缩得那样好。由此，数据的基于列的组织启用了高效的压缩，且该过程的结果是数据940的一组离散的、统一表示且压缩的、基于列的序列。

图11给出了基于实际数据的列化过程的示例。图11的示例针对4个数据记录1100、1101、1102和1103，但这仅出于图示简单的目的，因为本发明可适用于上万亿字节的数据。一般而言，当计算机系统记录交易数据时，它是逐个记录地记录的，且一般按照接收记录的时间次序来记录。由此，数据实际上具有对应于每一记录的行。

在图11中，记录1100具有带有值“Jon”1111的姓名字段1110、带有值“1150-1212”1121的电话字段1120、带有值“jon@go”1131的电子邮件字段1130、带有值“2 1st St”1141的地址字段1140、以及带有值“Wash”1151的州字段1150。

记录1101具有带有值“Amy”1112的姓名字段1110、带有值“123-4567”1122的电话字段1129、带有值“Amy@wo”1132的电子邮件字段1130、带有值“1 2nd Pl”1142的地址字段1140、以及带有值“Mont”1152的州字段1150。

记录1102具有带有值“Jimmy”1113的姓名字段1110、带有值“765-4321”1123的电话字段1120、带有值“Jim@so”1133的电子邮件字段1130、带有值“9 Fly Rd”1143的地址字段1140、以及带有值“Oreg”1153的州字段1150。

记录1103具有带有值“Kim”1114的姓名字段1110、带有值“987-6543”1124的电话字段1120、带有值“Kim@to”1134的电子邮件字段1130、带有值“91 Y St”1144的地址字段1140、以及带有值“Miss”1154的州字段1150。

当行表示1160被列化为重新组织的列表示1170时，代替具有各自有5个字段的4个记录，形成对应于这些字段的5个列。

由此，列1对应于带有值“Jon”1111、之后是值“Amy”1112、之后是值“Jimmy”1113、之后是值“Kim”1114的姓名字段1110。类似地，列2对应于带有值“555-1212”1121、之后是值“123-4567”1122、之后是值“765-4321”1123、之后是值“987-6543”1124的电话字段1120。列3对应于带有值“jon@go”1131、之后是值“Amy@wo”1132、之后是值“Jim@so”1133、之后是值“Kim@to”1134的电子邮件字段1130。进而，列4对应于带有值“2 1st St”1141、之后是值“1 2nd Pl”1142、之后是值“9 Fly Rd”1143、之后是值“91 Y St”1144的地址字段1140。以及，列5对应于带有值“Wash”1151、之后是值“Mont”1152、之后是值“Oreg”1153、之后是值“Miss”1154的州字段1150。

图12是示出此处所描述的实施例采用的字典编码的非限制示例的框图。典型的城市列1200可包括值“Seattle”、“Los Angeles”、“Redmond”等等，且这些值可以不断地重复自己。采用字典编码，已编码的列1210包括对应于每一不同值的码元，如每一值一个唯一整数。由此，代替多次表示文本“Seattle”，存储整数“1”，这要紧凑得多。越经常重复自己的值可以用到最紧凑表示(最少位、最少位变化等)的映射来枚举。值“Seattle”仍作为字典1220的一部分被包括在编码中，但是“Seattle”只需被表示一次而非许多次。已编码列1210的存储节省远超过了字典1220所蕴含的额外存储。

图13是示出此处所描述的实施例采用的值编码的非限制示例的框图。列1300表示销售额，且包括典型的包括小数的美元和美分表示，这涉及浮点存储。为了使存储更紧凑，采用值编码来编码的列1310可向其应用因子10，例如10²，以便使用整数代替浮点值来表示各值，其中整数需要较少的位来存储。该变换可类似地应用于减少表示值的整数数量。例如，列中始终以百万结束的值，如2,000,000、185,000,000等都可除以10⁶来将值减小到更紧凑的表示2、185等。

图14是示出此处所描述的实施例采用的位打包的非限制示例的框图。列1400表示通过字典和/或值编码来整数化的订单量，但保留了每行32位来表示这些值。位打包试图对段中的值使用最少数量的位。在该示例中，可使用10位/行来表示值590、110、680和320，这表示了对于被应用来形成列1410的第一层位打包的充分节省。

位打包还可移除共同的10(或其他数字)的幂来形成第二打包列1420。由此，如果值如同该示例中那样以0结束，这意味着不需要使用3位/行来表示订单量，且将存储结构减少到7位/行。类似于字典编码，位节省远超过了由于将数据恢复到列1400所需的元数据(如使用10的几次幂)而引起的任何增加的存储。

作为形成第三打包列1430的另一层位打包，可以认识到它采取7位/行来表示像68那样的值，但是由于最低值是11，则范围可位移11(将每一个值减去11)，因而最高数是68-11＝57，这可以仅用6位/行来表示，因为有2⁶＝64个值可能性。尽管图14表示了打包层的特定次序，但各层可用不同的次序来执行，或者另选地，打包层可被选择性地移除或用其他已知的位打包技术来补充。

图15是示出此处所描述的实施例采用的行程长度编码的非限制示例的框图。如图所示，由于值的重复，诸如列1500等表示订单类型的列可用行程长度编码来高效地编码。列值行程表1510将订单类型映射到订单类型的行程长度。尽管表1510的元数据的表示上允许些许变化，但基本思想是行程长度编码对于100的行程长度可给出50倍的压缩，这要优于位打包一般可为同一数据集提供的增益。

图16是此处提供的一实施例的概括框图，其中将图7-10的技术合成到统一编码和压缩方案的各实施例中。原始数据1600根据列组织1610被组织为列流。字典编码1620和/或值编码1630提供了如上所述的相应大小减小。然后，在混合RLE和位打包阶段，压缩分析1640在确定是应用行程长度编码1650还是位压缩1660时跨各列检查潜在的位节省。

在图17的流程图中对图16进行扩展。在1700，根据固有行表示来接收原始数据。在1710，将数据重新组织为列。在1720，应用字典和/或值编码来第一次减小数据。在1730，可应用如上所述的混合RLE和位打包技术。在1740，存储基于压缩的且编码的列的数据序列。然后，当客户机请求全部基于压缩的已编码列的数据序列或请求其一子集时，在1750，将受影响的列发送到作出请求的客户机。

图18是执行混合压缩技术的压缩分析的示例性方式的框图。例如，从列1810中计算直方图1800，该直方图表示值的出现频率，或各个行程长度的出现频率。任选地，可设置阈值1812，使得行程长度编码不应用于其中行程长度增益可能最小的、数量上较少的值的重复出现。另选地，或另外地，位节省直方图1820不仅表示了值的出现频率，而且还表示了将通过应用该混合压缩模型的压缩技术中的一种或另一种来达到的总的位节省。另外，再一次可任选地应用阈值1822以便画出其中行程长度编码益处不足以应用该技术的线。取而代之，可对列的这些值应用位打包。

另外，任选地，在应用列1800的行程长度编码之前，可对列1800重新排序来将所有最相似的值分组为经重新排序的列1830。在该示例中，这意味着将A分组在一起以供行程长度编码，并留下B进行位打包，因为对于2个B值，频率和总的位节省都未证明行程长度编码是合理的。在这一点上，可向其他列应用重新排序来保持记录数据处于锁定步骤，或者它可经由关于如何撤消行程长度编码的重新排序的列专用元数据来记住。

图19示出了一相似的示例，其中向相似的列1900应用压缩分析，但是更改了每一次替换行程长度的位节省，使得现在，根据混合压缩分析判断要对2个B值执行行程长度编码(即使是在10个A值之前)，因为2个B值导致更高的净位节省。在这一点上，与贪食者从具有不同食物的10个不同盘子中进行选择非常相像，应用行程长度编码是“贪婪的”，这表现在它在每一步都跨所有列寻找大小减小方面的最高增益。类似于图13，可构建频率直方图1910和/或位节省直方图1920数据结构，以便作出关于是应用如所描述的行程长度编码还是位打包的确定。同样，在决定是否采取RLE或位打包时可使用任选阈值1912和1922。经重新排序的列1930可帮助行程长度编码定义更长的行程长度，且因此达到更大的行程长度节省。

图20示出了行程长度编码的“贪婪”方面，该方面在每一步跨所有列来检查哪里达到最高位节省，并且可任选地包括将列重新排序为列2030、2032等来最大化行程长度节省。在某一点，行程长度节省可能相对不重要，因为值是相对唯一的，此时停止行程长度编码。

在混合实施例中，向其余值的范围应用位打包，这在图21中示出。在这一点上，应用混合压缩技术，经重新排序的列2100包括RLE部分2110和位打包部分2120，它们一般分别对应于重复出现的值和相对唯一的值。类似地，经重新排序的列2102包括RLE部分2112和BP部分2122。

在图22所示的一个实施例中，混合算法计算来自位打包的位节省和来自行程长度编码的位节省2200，然后在2210将来自位打包的位节省和来自行程长度的位节省进行比较或检查这两种节省以便在2220确定哪一压缩技术最大化位节省。

上述编码和压缩技术的示例性执行示出了可在真实数据样本2301、2302、2303、2304、2305、2306、2306、2307和2308上达到的显著增益，其范围在大约9倍到99.7倍的性能改进，且特别地取决于特定的大规模数据样本中的相对的值重复量。

图24是示出此处在各实施例中描述的列化、编码和压缩过程的最终结果的框图。在这一点上，每一列C1、C2、C3、…、CN包括具有向其应用行程长度编码的同类重复值的区域，以及图中标记为“其他”的、表示列中的各组异类值的其他区域。具有由行程长度定义的相同的重复值的区域是纯区域2420，且具有多样化值的区域是非纯区域2410，如图例中所指示的。在这一方面，当一个人的眼睛“走查”各列时，作为此处讨论的压缩技术的固有好处，浮现数据上的新视图。

跨所有各列，在非纯区域2410和纯区域2420之间或从相反方向的第一转换点，按照从第一行到转换点处的行的各行来定义桶。在这方面，桶2400沿着各列向下在每一转换点处定义，如虚线所示。桶2400由各转换之间的行来定义。

图25示出了基于跨特定行的纯和非纯区域的数量来为桶定义的命名法。纯桶2500是没有非纯区域的桶2000。单非纯桶2510是跨该桶的各行具有1个非纯区域的桶。双非纯桶2510是跨该桶的各行具有2个非纯区域的桶。三非纯桶具有3个非纯区域，以此类推。

由此，在示例性数据加载过程期间，以适合稍后的高效查询的表示来对数据进行编码、压缩、存储，并且压缩技术可以是所使用的查找一段内的数据分布并试图比位打包更频繁地使用RLE压缩的技术。在这一点上，RLE对于压缩和查询都提供了以下优点：(A)RLE通常比位打包需要少得多的存储，以及(B)RLE包括高效地“快进”通过数据范围同时执行诸如“按……分组”、“过滤”和/或“聚集”等查询构件块运算的能力；这些运算可以在数学上变成对按列组织的数据的高效运算。

在各非限制实施例中，代替在对同一段中的另一列进行排序之前一次对一个列进行排序，该压缩技术基于数据的分布来对数据行进行聚类，且由此增加了在段中对RLE的使用。如此处所使用的，术语“桶”用于描述行的聚类，为了避免疑惑，该术语应被认为与术语“分区”不同，分区是定义明确的在线分析处理(OLAP)和RDBMS概念。

以上讨论的技术由于认识到数据分布是歪斜的且在大量数据中很少存在均匀分布，因而是有效的。在压缩用语中，算术编码通过以总统使用较少的位为目的，使用较少的位来表示频繁使用的字符，并使用较多的位来表示不频繁使用的字符，来充分利用这一点。

采用位打包，利用固定大小的数据表示来进行较快的随机存取。然而，此处描述的压缩技术还具有使用RLE的能力，这提供了对于较频繁的值使用较少的位的方式。例如，如果原始表(为图示简明起见，包括一个列“Col1”)表现如下：

Col1
	100
100
	100
100
	200
300
	400

则在压缩之后，Col1表现如下，其被划分成应用行程长度编码的第一部分和应用位打包的第二部分：

如从以上可见，最常见的值100的出现被折叠成RLE，而较不频繁出现的值仍以固定宽度的、经位打包的存储来存储。

在这一点上，上述数据打包的实施例包括两个不同阶段：(1)数据分析，用于确定桶化，以及(2)段数据的识别，用于遵守桶化布局。这两个阶段中的每一个在以下示例性地详述。

关于确定桶化的数据分析，目标是用RLE来覆盖段内尽可能多的数据。由此，该过程朝向偏向“较厚”列，即具有大基数的列来偏斜，而不是将在查询期间被更频繁使用的列。也可应用基于使用的优化。

对于另一简单示例，出于图示的目的，使用以下的小表。实际上，此类小表一般不被包括在上述压缩的范围内，因为对此类表的压缩的好处往往并非有价值的。并且，此类小表一般不被包括是因为在执行编码之后发生压缩，并且在一个实施例中压缩对数据标识(ID)而非值本身起作用。由此，为了图示，还添加了行号列。

在各列上，桶化过程通过找到在段数据中占据最多空间的单个值来开始。如上关于图18和19所提到的，这可例如如下对每一列使用简单直方图统计来完成。

列	最常见的值	出现次数	节省的空间
				Col1	100	5	45位
Col2	1231	3	33位

一旦选择了该值，对段中的行进行逻辑重排序，使得该值的所有出现按顺序出现，以便最大化RLE行程的长度：

在一个实施例中，在每一列段中，属于同一行的所有值存在于同一索引处，例如，col1[3]和col2[3]都属于第三行。确保这一点提供了对同一行中的值的高效的随机存取，而不会导致通过用于每一次存取的映射表的间接性的成本。因此，在对贪婪RLE算法或混合RLE和位打包算法的应用的当前描述的实施例中，当对一列中的值重新排序时，这意味着其他列段中的值也被重新排序。

在以上示例中，现在存在两个桶：{1，2，4，6，7}和{3，5}。如所提到的，此处所应用的RLE是贪婪算法，这意味着该算法遵循以找到全局最优为期望来在每一阶段作出局部最优选择的问题解决元启发(metaheuristic)。在找到最大桶的第一阶段之后，下一阶段是选择次大桶，并且在该桶内重复该过程。

现在，当相应地对行重排序时，有三个桶：{2，7}、{1，4，6}、{3，5}。最大桶是第二个，但是那里没有重复值。第一个桶所有列具有RLE行程，并且其余值是唯一的，因此知道在Col1中不会得到进一步的RLE增益。考虑{3，5}桶，有可被转换到RLE的另一值1231。有趣的是，1231也出现在前一桶上，并且该桶可被重新排序，使得1231在底部，并准备好与下一桶的顶部合并。下一步得到以下结果：

在以上示例中，现在存在四个桶：{2，7}、{6，4}、{1}、{3，5}。当无法进一步减少更多数据时，该过程移至段数据重组织的下一阶段。

尽管最上面的图示也对行重新排序，但出于性能原因，对桶的确定可以纯粹基于来自对每一列段中的数据重排序的动作的统计。对每一列段中的数据重排序的动作可以基于可用核使用作业调度器来并行化。

如所提到的，对上述技术的使用对于小数据集是不实用的。对于顾客数据集，上述技术频繁地经历数万步骤，这可能会耗时。由于该算法的贪婪本质，绝大部分的空间节省发生在前几步中。在前几千步中，会被节省的大多数空间已经被节省了。然而，如在压缩的数据的扫描侧上观察到的那样，打包的列中的RLE的存在在查询期间给出了显著的性能提升，因为在查询期间即使是微小的压缩增益也会收获报偿。

由于一次处理一个段，因此可使用多个核，从而将从数据源中将数据读入段中所花费的时间与压缩前一段所花费的时间重叠。采用常规技术，以约100K行/秒的速率从关系型数据库中读取，8M行的段将花费约80秒，这是可供这一工作使用的相当大量的时间。任选地，在一个实施例中，对前一段的打包也可在一旦用于下一段的数据可用时就停止。

基于列的数据编码的处理

如所提到的，根据基于列的编码的各实施例的组织数据的方式有助于在数据的消费侧的高效扫描，其中处理可以在存储器内在选定数量的列上非常快地执行。上述数据打包和压缩技术在行编码期间更新压缩阶段，而扫描包括查询优化器和处理器来充分利用智能编码。

该扫描或查询机制可用于高效地向商业智能(BI)查询返回结果，并且是针对由上述数据打包和压缩技术产生的聚类布局而设计的，且被优化来得到增加的RLE使用，例如，期望在查询处理期间，将使用RLE来压缩大量的用于查询的列。另外，该快速扫描过程引入了面向列的查询引擎，而非在列存储上的行级查询处理器。由此，即使是在包含位打包数据(不是RLE数据)的桶中，由于数据局部性而获得的性能增益也可能是显著的。

除了引入上述数据打包和压缩技术以及高效扫描之外，能以高度有效的方式来支持查询中的“或”片(slice)以及指定了关系的多个表之间的“联接”。

如以上所提到的，该扫描机制采用了段包含包含跨段的桶，并且在“纯”RLE行程或“非纯”的其他位打包存储中包含列值，如图24所示。

在一个实施例中，在段上调用扫描，关键是一次对一个桶工作。在桶内，取决于查询规范，扫描过程在各阶段内执行面向列的处理。第一阶段是收集关于什么列区域是纯的以及什么区域是非纯的统计信息。接着，可以处理过滤，之后处理分组操作，之后处理代理列。接着，可处理聚集作为另一阶段。

如早先所提到的，注意到此处呈现的用于扫描的各实施例实现了面向列的查询处理，而非像常规系统那样是面向行的。由此，对于这些阶段的每一个，所执行的实际代码可以特定于：(1)所操作的列是否是行程长度编码的，(2)用于位打包的压缩类型，(3)结果是稀疏还是致密的，等等。对于聚集，考虑另外的因素：(1)编码类型(散列或值)，(2)聚集函数(求和/最小/最大/计数)，等等。

一般而言，扫描过程因而遵循图26的形式，其中来自各种标准查询/扫描运算符2600的查询结果是所有桶行的函数。查询/扫描运算符2600实际可以在数学上进行分解，使得过滤、分组、代理列和聚集在各阶段中彼此分开地处理。

在这一点上，对于每一处理步骤，根据桶走查过程，在2610处，根据桶的不同纯度来处理运算符。因此，代替对所有桶行的一般化的且昂贵的扫描，采用此处描述的编码和压缩算法的工作引入的不同桶的专门化，结果因而是纯桶、单非纯桶、双非纯桶等等的处理的聚集结果。

图24示出了桶的示例分布以及该压缩体系结构的能力，因为对纯桶执行的处理由于处理数学缩减到简单运算而是最快的，之后的第二快的是单非纯桶，且对于其他的非纯桶以此类推。此外，已经发现数量大得令人惊奇的桶是纯的。例如，如图29所示，对于查询所蕴含的六个列，如果每一列具有大约90％的纯度(意味着90％的值由于相似数据而用行程长度编码来表示)，则大约60％的桶是纯的，大约1/3将是单非纯桶，大约8％将是双非纯桶，且其余将总计仅有1％。由于对纯桶的处理是最快的，且对单非纯桶和双非纯桶的处理仍然是相当快的，因此具有3个或更多非纯区域的桶的“更复杂”处理被保持在最小。

图28描绘了具有某些样本标准查询构件块的样本查询2800，这些标准查询构件块例如样本“按列过滤”查询构件块2802、样本“按列分组”查询构件块2804、以及样本“按列聚集”查询构件块2806。

图29是示出通过列选择性而产生的带宽减少的另一方面的框图。回顾样本查询2900，可以看到涉及所有列2910中不超过6个列2920，且因此只需要将6个列加载到本地RAM中来获得高效的查询。

因此此处已描述了各实施例。图30示出了用于编码数据的一个实施例，包括在3000处根据对应于该数据的不同数据字段的一组基于列的值序列来组织该数据。然后，在3010，根据诸如字典编码和/或值编码等至少一个编码算法将该组基于列的值序列变换成一组基于列的整数序列。然后，在3020，根据至少一个压缩算法来压缩该组基于列的整数序列，压缩算法包括跨该组基于列的整数序列应用的贪婪行程长度编码算法、或位打包算法、或行程长度编码和位打包的组合。

在一个实施例中，分析该整数序列来确定是应用行程长度编码(RLE)压缩还是位打包压缩，包括分析RLE压缩相对于位打包压缩的位节省来确定何处达到最大位节省。该过程可包括生成直方图来协助确定何处达到最大位节省。

在另一实施例中，如图31所示，位打包技术包括在3100处接收表示数据列的整数值序列的各部分，以及位打包的潜在缩减的三个阶段。在3110，可基于表示数据字段所需的位数来缩减数据。在3120，可通过跨该整数序列的各部分的值移除任何共享的数字幂来缩减数据。在3130，也可通过跨一范围偏移整数序列的各部分的值来缩减数据。

在另一实施例中，如图32的流程图所示，响应于查询，在3200，检索数据的子集作为对应于数据的不同列的整数编码的且压缩的值序列。然后，在3210，基于出现在数据子集的整数编码的且压缩的值序列的任一个中的压缩类型的变化来定义跨数据子集的处理桶。接着，在3220，基于为了得到高效查询处理而处理的当前桶的类型来执行查询运算。这些运算可以在存储器内执行，并且在多核体系结构中并行化。

不同的桶包括：(1)跨各序列桶中不同部分的值都是根据行程长度编码压缩来压缩的，从而定义了纯桶，(2)除了一个部分之外都是根据行程长度编码来压缩的，从而定义了单非纯桶，或(3)除了两个部分之外都是根据行程长度编码来压缩的，从而定义了双非纯桶。

改进的扫描允许更高效地执行各种标准查询和扫描运算符，尤其是对于最纯的桶。例如，当应用桶走查技术且基于桶类型来执行处理时，逻辑“或”查询片运算、已指定了关系的多个表之间的查询联接运算、过滤运算、分组运算、代理列运算或聚集运算都可以更高效地执行。

示例性联网和分布式环境

本领域普通技术人员可以理解，此处所描述的基于列的编码和查询处理的各实施例可以结合任何计算机或其它客户机或服务器设备来实现，该任何计算机或其它客户机或服务器设备可作为计算机网络的一部分来部署或者被部署在分布式计算环境中，并且可以连接到任何种类的数据存储。就此，此处所描述的各实施例可以在具有任意数量的存储器或存储单元以及出现在任意数量的存储单元上的任意数量的应用程序和进程的任何计算机系统和环境中实现。这包括但不限于具有部署在具有远程或本地存储的网络环境或分布式计算环境中的服务器计算机和客户计算机的环境。

分布式计算通过计算设备和系统之间的通信交换提供了计算机资源和服务的共享。这些资源和服务包括信息的交换、对于诸如文件等对象的高速缓存存储和盘存储。这些资源和服务还包括多个处理单元之间的处理能力共享以便进行负载平衡、资源扩展、处理专门化，等等。分布式计算利用网络连接，从而允许客户机利用它们的集体力量来使整个企业受益。在这一点上，各种设备可具有应用、对象或资源，它们可以协作来执行本发明的各实施例中的任一个的一个或多个方面。

附图33提供了示例性的联网或分布式计算环境的示意图。该分布式计算环境包括计算对象3310、3312等以及计算对象或设备3320、3322、3324、3326、3328等，这些计算对象或设备可包括如由应用程序3330、3332、3334、3336、3338表示的程序、方法、数据存储、可编程逻辑等。可以理解，对象3310、3312等以及计算对象或设备3320、3322、3324、3326、3328等可包括不同的设备，诸如PDA、音频/视频设备、移动电话、MP3播放器、个人计算机、膝上型计算机等。

每一个对象3310、3312等以及计算对象或设备3320、3322、3324、3326、3328等可通过通信网络3310直接或间接与一个或多个其他对象3312、3320等以及计算对象或设备3322、3324、3326、3328、3340等进行通信。即使在附图33中被示为单个元件，但网络3340可包括向附图33的系统提供服务的其他计算对象或解释设备，和/或可表示未示出的多个互连网络。每一个对象3310、3312等或3320、3322、3324、3326、3328等还可包含诸如应用3330、3332、3334、3336、3338等应用，应用可利用API或适用于与根据本发明的各实施例来提供的基于列的编码和查询处理进行通信或适用于该基于列的编码和查询处理的实现的其他对象、软件、固件和/或硬件。

存在支持分布式计算环境的各种系统、组件和网络配置。例如，计算系统可以由有线或无线系统、本地网络或广泛分布的网络连接在一起。当前，许多网络被耦合至因特网，后者为广泛分布的计算提供了基础结构并包含许多不同的网络，但任何网络基础结构可用于变得与如各实施例中所描述的基于列的编码和查询处理相关联的示例性通信。

因此，可以利用诸如客户机/服务器、对等、或混合体系结构等网络拓扑结构和网络基础结构的主机。“客户机”是使用与它无关的另一类或组的服务的一个类或组中的成员。客户机可以是进程，即大致上是请求由另一程序或进程提供的服务的一组指令或任务。客户机进程利用所请求的服务，而不必知道摂有关其他程序或服务本身的任何工作细节。

在客户机/服务器体系结构中，尤其在联网系统中，客户机通常是访问由例如服务器等另一计算机提供的共享的网络资源的计算机。在附图33的图示中，作为非限制性示例，计算机3320、3322、3324、3326、3328等可被认为是客户机而计算机3310、3312等可被认为是服务器，其中服务器3310、3312等提供数据服务，诸如从客户机计算机3320、3322、3324、3326、3328等接收数据、存储数据、处理数据、向客户机计算机3320、3322、3324、3326、3328发送数据等，但任何计算机都可取决于环境而被认为是客户机、服务器或两者。这些计算设备中的任一个可以处理数据、编码数据、查询数据、或请求可蕴含如此处对于一个或多个实施例描述的基于列的编码和查询处理的服务或任务。

服务器通常是可通过诸如因特网或无线网络基础架构等远程网络或本地网络访问的远程计算机系统。客户机进程可以在第一计算机系统中活动，而服务器进程可以在第二计算机系统中活动，它们通过通信介质彼此通信，从而提供分布式功能并允许多个客户机利用服务器的信息收集能力。按照基于列的编码和查询处理来利用的任何软件对象可以被单独提供或分布在多个计算设备或对象上。

在其中通信网络/总线3340是因特网的网络环境中，服务器3310、3312等可以是客户机3320、3322、3324、3326、3328等通过诸如超文本传输协议(HTTP)等多种已知协议中的任一种与其通信的web服务器。服务器3310、3312等也可担当客户机3320、3322、3324、3326、3328等，这是分布式计算环境的特性。

示例性计算设备

如上所述，有利的是，此处所描述的技术可适用于其中期望快速查询大量数据的任何设备。从而，应当理解，构想了所有种类的手持式、便携式和其他计算设备和计算对象来用于各实施例，即，在设备可能期望扫描或处理巨大量的数据来得到快速且高效的结果的任何地方。因此，以下在附图34中描述的通用远程计算机只是计算设备的一个示例。

尽管并非所需，但各实施例可以部分地经由操作系统来实现，以供设备或对象的服务开发者使用，和/或被包括在用于执行此处所描述的各实施例的一个或多个功能方面的应用软件中。软件可以在由诸如客户机工作站、服务器或其它设备等一个或多个计算机执行的诸如程序模块等计算机可执行指令的通用上下文中描述。本领域的技术人员可以理解，计算机系统具有可用于传递数据的各种配置和协议，并因此没有特定配置或协议应被认为是限制性的。

因此，图34示出了其中可实现各实施例的一个或多个方面的合适的计算系统环境3400的一个示例，尽管如上所述，计算系统环境3400仅为合适的计算环境的一个示例，并非对使用范围或功能提出任何限制。也不应该将计算环境3400解释为对示例性操作环境3400中示出的任一组件或其组合有任何依赖性或要求。

参考附图34，用于实现一个或多个实施例的示例性远程设备包括计算机3410形式的通用计算设备。计算机3410的各组件可包括但不限于，处理单元3420、系统存储器3430、以及将包括系统存储器在内的各系统组件耦合到处理单元3422的系统总线3420。

计算机3410通常包括各种计算机可读介质，并可以是可由计算机3410访问的任何可用介质。系统存储器3430可以包括诸如只读存储器(ROM)和/或随机存取存储器(RAM)等易失性和/或非易失性存储器形式的计算机存储介质。作为示例而非限制，存储器3430还可以包括操作系统、应用程序、其他程序模块、和程序数据。

用户可以通过输入设备3440向计算机3410输入命令和信息。监视器或其他类型的显示设备也经由接口，诸如输出接口3450连接至系统总线3422。除监视器之外，计算机还可以包括其他外围输出设备，如扬声器和打印机，它们可以通过输出接口3450连接。

计算机3410可使用至一个或多个远程计算机，诸如远程计算机3470的逻辑连接在网络化或分布式环境中操作。远程计算机3470可以是个人计算机、服务器、路由器、网络PC、对等设备或其他常见网络节点、或任何其他远程媒体消费或传输设备，并且可以包括上面关于计算机3410所描述的任何或全部元件。附图34所示的逻辑连接包括诸如局域网(LAN)或广域网(WAN)等的网络3472，但也可以包括其他网络/总线。这样的联网环境在家庭、办公室、企业范围计算机网络、内联网和因特网中是常见的。

如上所述，尽管结合各种计算设备和网络体系结构描述了各示例性实施例，但基本概念可被应用于其中需要压缩大规模数据或在大规模数据上处理查询的任何网络系统和任何计算设备或系统。

而且，存在实现相同或相似功能的多种方法，例如适当的API、工具箱、驱动程序代码、操作系统、控件、独立或可下载软件对象等，它们使得应用和服务能够使用该高效的编码和查询技术。由此，此处的各实施例从API(或其他软件对象)的观点以及从提供基于列的编码和/或查询处理的软件或硬件对象构想。因此，此处描述的各实施例可以具有完全采用硬件、部分采用硬件并且部分采用软件、以及采用软件的方面。

在本文中使用的词语“示例性”意味着用作示例、范例或说明。为避免疑惑，本文公开的主题不受限于这样的示例。此外，本文描述为“示例性”的任何方面或设计不必解释成优于其他方面或设计或比其他方面或设计有利，它也不旨在排除本领域的普通技术人员所知的等效示例性结构和技术。而且，就术语“包括”、“具有”、“包含”和其他类似的词语在详细描述或权利要求书中的使用而言，为避免疑惑，这样的术语旨在以类似于术语“包括”作为开放的过渡词的方式解释而不排除任何附加或其他元素。

如上所述，此处所述的各种技术可结合硬件或软件，或在适当时以两者的组合来实现。如在此所使用的，术语“组件”、“系统”等同样指的是计算机相关实体，或者是硬件、硬件和软件的组合、软件或执行中的软件。例如，组件可以是，但不限于是，在处理器上运行的进程、处理器、对象、可执行码、执行的线程、程序和/或计算机。作为说明，运行在计算机上的应用程序和计算机本身都可以是计算机组件。一个或多个组件可以驻留在进程和/或执行的线程中，并且组件可以位于一个计算机内和/或分布在两个或更多计算机之间。

已经关于若干组件之间的交互描述了前述系统。应该理解，这样的系统和组件可以包括根据前述的各种置换和组合的那些组件或指定的子组件、指定的组件或子组件中的某一些、和/或另外的组件。子组件也可以被实现为通信耦合至其他组件而非被包括在父组件(分层)内的组件。另外，应注意到一个或多个组件可被组合成提供聚集功能的单个组件，或被分成若干单独的子组件，且诸如管理层等任何一个或多个中间层可被设置成通信耦合到这样的子组件以便提供集成功能。此处描述的任何组件也可以与在此未具体描述但本领域的技术人员公知的一个或多个其他组件交互。

考虑到以上描述的示例性系统，参考各附图的流程图将可以更好地理解依照所描述的主题实现的方法。尽管为了简洁起见，作为一系列框示出和描述了方法，但是，应该理解，所要求保护的主题不仅限于所描述的框的顺序，一些框可以按与此处所描绘和描述的不同的顺序进行和/或与其他框并发地进行。尽管经由流程图示出了非顺序或分支的流程，但可以理解，可实现达成相同或类似结果的各种其他分支、流程路径和框次序。此外，并非所有的所示出的方框都是实现下面所描述的方法所必需的。

除了此处所描述的各实施例之外，可以理解，可以使用其他相似的实施例或者可对所述实施例作出修改和添加以便执行对应的实施例的相同或等效的功能而不背离这些实施例。此外，多个处理芯片或多个设备可共享此处所描述的一个或多个功能的执行，并且类似地，存储可以跨多个设备实现。因此，本发明不应限于任何单个实施例，而是应该根据所附权利要求书的广度和范围来解释。

Claims (20)

1.一种用于处理数据的方法，包括：

响应于蕴含对至少一个数据存储中的数据的至少一个联接运算的查询，按照对应于所述至少一个数据存储中的数据的不同列的整数编码且压缩的值序列来接收510数据子集；

确定520所述至少一个联接运算的至少一个结果集，包括确定本地高速缓存是否包括对应于所述至少一个联接运算所蕴含的列的任何非默认值；以及

在所述本地高速缓存包括对应于所述至少一个联接运算所蕴含的列的任何非默认值的情况下，在确定所述至少一个结果集时替换530所述非默认值。

2.如权利要求1所述的方法，其特征在于，还包括：

在所述本地高速缓存中存储540所述至少一个结果集的至少一个结果，用于关于第二查询的替换。

3.如权利要求2所述的方法，其特征在于，所述存储540包括在存储器中对所述至少一个结果的无锁存储。

4.如权利要求1所述的方法，其特征在于，所述确定520包括用多个处理器以及从所述序列划分的对应数量的段来并行化所述查询所定义的运算，每一段由至少一个不同处理器来处理。

5.如权利要求1所述的方法，其特征在于，还包括：

在启动查询处理之前将所述本地高速缓存设置为默认值。

6.如权利要求5所述的方法，其特征在于，所述设置包括在启动查询处理之前将所述本地高速缓存设为负一(“-1”)值。

7.如权利要求1所述的方法，其特征在于，所述替换530包括在确定所述至少一个结果集时替换所述非默认值而非扫描所述值序列中的对应的列。

8.如权利要求1所述的方法，其特征在于，还包括：

在所述本地高速缓存包括对应于所述至少一个联接运算所蕴含的列的默认值的情况下，处理660所述值序列中的对应的列来检索所述至少一个结果集的至少一个结果。

9.如权利要求1所述的方法，其特征在于，所述接收510包括从关系型数据库接收所述数据子集，并且所述数据的不同列对应于所述关系型数据库的列。

10.一种包括用于执行如权利要求1所述的方法的计算机可执行指令的计算机可读介质。

11.一种用于查询处理的方法，包括：

生成610被压缩数据的段共享的懒惰高速缓存，所述压缩数据是响应于查询作为对应于表示一组表的至少一个数据存储中的数据的不同列的整数编码且压缩的值序列而被检索的；以及

响应于蕴含对至少一个数据存储中的数据的至少一个联接运算的查询，参考蕴含对所述至少一个数据存储的至少一个联接运算的懒惰高速缓存来处理620所述查询；

其中所述处理620包括根据预定算法用来自所述一组表中的至少一个表的至少一个数据值来填充所述懒惰高速缓存，以供所述查询处理的生存期上所述至少一个数据值的潜在的重复使用。

12.如权利要求11所述的方法，其特征在于，所述生成610包括根据具有对应于所述值序列的值的至少一个向量来组织所述懒惰高速缓存，所述值序列对应于数据的不同列。

13.如权利要求11所述的方法，其特征在于，所述处理620还包括扫描所述值序列，其中所述处理包括根据预定算法用来自所述一组表中的至少一个表的至少一个数据值来填充所述懒惰高速缓存，以供所述查询处理的生存期上所述至少一个数据值的潜在的重复使用。

14.如权利要求11所述的方法，其特征在于，所述处理620包括使用来自所述值序列的外键数据标识(ID)作为对所述懒惰高速缓存的索引。

15.如权利要求14所述的方法，其特征在于，所述处理620包括确定所述懒惰高速缓存的对应于外键数据ID的值是否为默认值。

16.如权利要求15所述的方法，其特征在于，如果所述懒惰高速缓存的所述值是默认值，则对所述值序列执行所述至少一个联接运算。

17.如权利要求14所述的方法，其特征在于，如果所述懒惰高速缓存的所述值不是所述默认值，则跳过对所述值序列的所述至少一个联接运算，并改为使用所述懒惰高速缓存的对应于所述外键数据ID的所述值。

18.如权利要求11所述的方法，其特征在于，所述处理620包括接收结果集，并且还包括将所述结果集的至少一个结果写入所述懒惰高速缓存，作为不需要用于一致性的锁的核心处理器数据类型的原子操作。

19.一种包括用于执行如权利要求所述的方法的装置的计算设备。

20.一种用于处理数据的设备，包括：

高速存储器内存储230，用于存储按照对应于数据的不同列的整数编码且压缩的值序列来接收的数据子集，并用于存储对应于所述不同列的值的向量；以及

至少一个查询处理器250，所述至少一个查询处理器处理对所述数据子集的查询，并在所述向量中找到对于给定列的默认值的情况下跳过对所述数据子集的所述查询所蕴含的至少一个联接运算，并改为用所述向量的值替换所述至少一个联接运算。

Images