CN107077480A - 基于查询需求自适应地从当前时间的行存储数据库中构建列存储数据库的方法和系统 - Google Patents

Abstract

一种从行存储数据库中动态构建列存储数据库的方法。所述方法包括：构建存储数据的行存储数据库，其中，每行包括多个属性，且行存储数据库中的数据相对于当前时间点是最新的。所述方法包括：构建列存储数据库，其包括为满足接收到的分析查询而构造的数据。所述方法包括：从列存储数据库的初始状态开始，对于每个后续接收的分析查询，将目标量数据从处于对应当前时间状态下的行存储数据库导入到列存储数据库中，以满足相应的后续接收的分析查询。

Description

基于查询需求自适应地从当前时间的行存储数据库中构建列 存储数据库的方法和系统

背景技术

基于数据记录的存储格式，关系数据库系统中，可用行存储或列存储来保存数据记录。在行存储数据库中，数据记录以行格式排列。在通常包含INSERT/DELETE/UPDATE操作的联机事务处理(online transaction processing，OLTP)事务中，行存储通常表现出良好的性能。例如，可为涉及一个磁盘I/O操作的整行更改信息。另一方面，在列存储数据库中，数据记录以列格式排列。列存储在联机分析处理(online analytical processing，OLAP)查询方面性能良好，因为它只需要读取处理查询所需的那些列，大大减少了磁盘I/O操作。

由于行存储和列存储适用于不同类型的查询，因此已提出在数据库系统中同时包含行存储和列存储，即混合行/列存储，来处理混合工作负载。目标是在单个数据库系统实现良好的OLTP性能并输出实时(或几乎实时)的分析结果。从行存储数据库中构建列存储数据库的常见方法是：从行存储中提取数据记录，并转换它们，再将数据加载到各自列的属性向量中。即，在接收或执行任何分析查询前，列存储是静态构建的。例如，在数据库不可用于联机访问的非高峰期，执行ETL(Extract-Transform-Load，抽取-转换-加载)流程，以向列存储数据库转移数据。

然而，构建列存储数据库的典型方法是有问题的，因为根据所述方法，必须过度构建数据库以包括与任何后续查询无关的数据。特别地，哪些查询会在数据库上运行，这些查询又针对哪些数据，都是很难预见的。因此，列存储最可能被过度构建以便涵盖所有可能的查询(例如，为行存储数据库中的每个属性都构建属性向量或列)。

同时，随着世界各地的客户和公司对数据库记录不断访问的需求的日益增长，可能没有足够长的好时间窗来执行ETL流程，以将数据从行存储转移至列存储。即，不再有任何非高峰期，也没有足够的时间来构建列存储数据库而又不会严重影响数据库系统的可访问性。

此外，传统的混合行/列存储数据库系统不能提供实时分析。即，分析查询不能实时执行，因为查询必须等ETL操作在查询执行前的调度时间期间完成后进行。

因此，现有的混合行/列存储数据库系统仍然依赖于猜测查询执行期间会访问哪些属性的预测方法，并倾向于在接收或执行任何查询前过度构建其列存储数据库。此外，为了加快访问速度，这些传统的列存储数据库构建在如随机存取存储器(random accessmemory，RAM)等主存储器中，但是当整个列存储数据库被擦除时，在系统崩溃期间会遭受巨大性能损失。因此，在重建整个列存储数据库的系统恢复过程中，系统仍然宕机。

从行存储数据库构建列存储数据库将是有利的，该行存储数据库不是对于需要访问数据的查询而被过度构建的，并且提供实时查询分析执行。

发明内容

在本发明的一些实施例中，公开了一种从行存储数据库中动态构建列存储数据库的计算机系统。该计算机系统包括存储器，存储计算机可执行指令和处理器，执行该计算机可执行指令。该指令包括构建存储数据的行存储数据库，其中，该行存储数据库的每行包括多个属性。该行存储数据库中的数据相对于当前时间点是最新的。该指令包括：构建列存储数据库，其包括为满足接收到的分析查询而构造的数据。该指令包括：从该列存储数据库的初始状态开始，对于每个后续接收的分析查询，将目标量数据从处于对应当前时间状态下的行存储数据库导入到列存储数据库中，以满足后续接收的分析查询。

在其他实施例中，公开了一种访问信息的方法。所述方法包括：构建存储数据的行存储数据库，其中该行存储数据库的每行包括多个属性。该行存储数据库中的数据相对于当前时间点是最新的。所述方法包括：构建列存储数据库，其包括为满足接收的分析查询而构造的数据。所述方法包括：从列存储数据库的初始状态开始，对于每个后续接收的分析查询，将目标量数据从处于对应当前时间状态下的行存储数据库导入到列存储数据库中，以满足后续接收的分析查询。

在本发明的又一些实施例中，公开了一种非瞬时性计算机可读介质，具有用于使计算机系统执行信息访问方法的计算机可执行指令。所述方法包括：构建存储数据的行存储数据库，其中该行存储数据库的每行包括多个属性。该行存储数据库中的数据相对于当前时间点是最新的。所述方法包括：构建列存储数据库，其包括为满足接收的分析查询而构造的数据。所述方法包括：从列存储数据库的初始状态开始，对于每个后续接收的分析查询，将目标量数据从处于对应当前时间状态下的行存储数据库导入到列存储数据库中，以满足后续接收的分析查询。

在阅读多个示图描述的下面实施例的具体细节后，本领域普通技术人员将意识到本发明多个实施例的这些以及其他目的和优势。

附图说明

附图包含在并且构成本说明书的一部分，其中相同的数字描绘相同的元件，附图说明本发明的实施例，并且与描述内容一起用于解释本发明的原理。

图1是本发明实施例提供的一种包括行存储数据库和列存储数据库的数据库系统的框图，其中，所述列存储数据库使用自适应、即时、恰好足够的流程构建；

图2A是本发明实施例提供的前述定义的雇员表的行条目的示例性示意图；

图2B是本发明实施例提供的图2A所示的雇员表中工资属性的示例性属性向量的示意图；

图3A是本发明实施例提供的使用自适应、即时、恰好足够的过程从行存储数据库构建的列存储数据库中访问数据的方法的流程图；

图3B是本发明实施例提供的通过导入为满足执行查询的数据而动态自适应地构建列存储数据库，从而提供查询的实时分析结果的方法的流程图；

图4是本发明实施例提供的雇员表的B树的示意图，其中，当在列存储数据库中自适应构建引用属性向量时，主索引用于进行部分表扫描；

图5是本发明实施例提供的实现用以管理元数据的示例性算法的示图，所述元数据指示在列存储数据库中已经构建了哪些属性向量以及哪些范围的信息包含在这些属性向量内；

图6A至图6F是本发明实施例提供的比较属性向量的覆盖区间和查询范围的各种实例的示意图；

图7是本发明实施例提供的用于通过导入用于满足执行查询的数据来动态自适应地构建列存储数据库的统一建模语言(Unified Modeling Language，UML)序列图的示意图。

具体实施方式

现将详细地对本发明的各种实施例、附图示出的示例做出参考。虽然会结合这些实施例进行描述，但可以理解的是它们并不用于将本发明限制于这些实施例。相反，本发明旨在覆盖可以包括在由所附权利要求书限定的本发明公开的精神和范围内的替代物、修改和等同物。另外，在以下本发明的详细描述中，阐述了许多特定细节以便提供对本发明的透彻理解。然而，可以理解的是，实际应用中，可以不包括本发明的这些特定细节。在其他实例中没有详细描述众所周知的方法、流程、部件和电路，以免对本发明的各方面造成不必要地模糊。

因此，本发明实施例提供用于从行存储数据库自适应地构建列存储数据库的方法和系统，以满足针对引用属性向量或列的分析查询。本发明其他一些实施例提供了从行存储数据库中构建列存储数据库的方法和系统，没有使用对访问数据库的分析查询无用的数据过度构建所述行存储数据库。本发明又一些实施例提供了使用在多个接收到的查询中的每一个运行时自适应构建的列存储数据库实时执行查询的方法和系统。

下面详细描述的一些部分以能够在计算机存储器中执行的数据位上的操作的程序、步骤、逻辑块、处理、以及其他象征性的表现形式呈现。这些描述和表现形式是数据处理领域技术人员用于向本领域其他技术人员最有效传达其工作实质的方式。在此将程序、计算机生成的步骤、逻辑块、过程等一般设想为首尾一致的步骤或指令序列，以产生期待结果。步骤是需要物理量的物理操作的那些步骤，是指计算系统的动作和过程，等等，该计算系统包括：处理器，用于将表示为计算机系统的寄存器和存储器内的物理(电子)量的数据处理并转换为类似地表示为计算机系统的存储器或寄存器或其他此类信息存储、传输或显示设备内的物理量的其他数据。

根据本发明实施例，描述了提供视频分段的方法的示例性流程图。虽然在流程图中公开了具体步骤，但这些步骤是示例性的。即，本发明的实施例非常适合执行流程图中列举的步骤的各种其他步骤或变型。而且，本文描述的实施例可以在计算机可执行指令的一般上下文中进行讨论，所述指令驻留在某种形式的诸如程序模块等的计算机可读存储介质上，由一个或多个计算机或其他设备执行。作为示例而非限制，软件产品可以存储在一个非易失性或非瞬时性计算机可读存储介质中，其可以包括非瞬时性计算机存储介质和通信介质。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件以及数据结构等。程序模块的功能可以根据需要结合或分布在各种实施例中。

图1是本发明实施例提供的包括行存储数据库150和列存储数据库170的数据库系统100的框图，所述列存储数据库170使用自适应、即时、恰好足够的过程来构建。具体地，列存储数据库170在每个接收到的分析查询运行时动态逐步地构建，所述列存储数据库自适应地构建以满足每个查询。

根据本发明实施例，数据库系统100可包括处理器和存储器，其中，处理器用于执行存储在存储器中的计算机可执行指令，处理器用于实现基于自适应、即时、恰好足够的语句的迁移流程，构建列存储数据库。在一实施例中，所述处理器用于执行图3A和3B、图5、和图7所示的流程。例如，处理器可用于执行此处所描述和/或说明的一个或多个示例性实施例的功能，例如查询/事务管理器120执行的操作。所述处理器可以包含在能够执行计算机可读指令的单处理器或多处理器的计算机设备或系统中。其最基本形式中，计算设备可包括至少一个处理器和系统存储器。系统存储器耦合到所述处理器，一般表示能够存储数据和/或其他计算机可读指令的任何类型或形式的易失性或非易失性存储设备或介质。系统存储器的示例包括但不限于RAM、ROM、闪存或任何其他合适的存储设备。

出于讨论目的，“存储数据库系统”或“主存储器数据库系统”是指包括CPU和“主存储器”的数据库系统，所述主存储器用于容纳所有数据以便功能正常发挥。这是典型的用于存储数据的传统系统。例如，主存储器可以包括随机存取存储器(random access memory，RAM)。主存储器可以使用永久性存储器或者使用电池备份系统进行备份。出于说明目的，100GB主存储器数据库系统用于在主存储器中存储所有100GB。

另一方面，本发明实施例公开了一种数据库系统，其允许数据单独或组合地分布在主存储器和永久存储器中。例如，在一实施例中，如果不是全部数据，也有大部分数据存储在永久存储器中。即，以所述100GB的存储器系统为例，数据存储在永久存储器中，主存储器(例如，4GB)用于较快访问，比如通过缓冲器。在这种方式下，笔记本电脑是现阶段存储大量数据的合适介质，而传统上笔记本电脑不适合配置100GB的主存储器。在又一实施例中，数据存储在主存储器中用于正常操作，并在永久存储器有备份。

由于行存储和列存储适用于不同类型的查询，本发明实施例使用包括行存储数据库和列存储数据库的数据库系统。具体地，本发明实施例提供数据库系统100中的混合行/列存储访问，以处理混合OLTP/OLAP工作负载。因此，在混合工作负载环境下，混合行存储和列存储数据库系统100实现了高OLTP性能并输出实时(或几乎实时)分析结果。

如图1所示，数据库100包括行存储数据库150。行存储数据库150的每行包括多个属性。例如，行存储数据库150可定义为雇员表，包括8个属性，其中，表是记录的集合。为便于说明，雇员表可包括公司雇员相关的信息，该信息定义为属性。下面提供了定义示例性雇员表的属性的表定义：

CREATE TABLE Employee

(

EmpNo int not null primary key,

Name varchar(127)not null,

Gender char(1)not null,

DeptNo int not null,

StartDate date,

Title varchar(50)not null,

Salary Decimal(10,2)null,

Comment varchar(255)null,

PRIMARY KEY(EmpNo),

INDEX(Name),

INDEX(DeptNo)

)；

图2A是本发明实施例提供的前述定义的雇员表的行条目200A的示例性示意图。例如，雇员表包括雇员编号属性201、雇员姓名属性202、性别属性203、部门编号属性204、入职日期属性205、职位属性206、工资属性207以及评语属性208。

行存储数据库150包括行数据缓冲器153，用于将数据存储在非永久性主存储器例如RAM中。另外，行存储数据库150包括行数据文件155，可永久存储数据，如存储到磁盘中。行日志管理器(未示出)管理对行存储数据库150的更新和改变。

在一实施例中，行存储数据库150处于一致的数据库状态。即，行存储数据库150相对于当前时间点而言是最新的。例如，行存储数据库150可配置为静态的数据集合，并提供数据库内的数据快照。

另外，数据库系统100包括列存储数据库170，其包括为满足接收的分析查询而构造的数据。列存储数据库170包括列数据缓冲器163，用于将数据存储在非永久性性主存储器例如RAM中。另外，列存储数据库170包括列数据文件165，可永久存储数据，如存储到磁盘中。列存储日志管理器167管理对列存储数据库170的更新和改变。

在列存储数据库170中，访问数据库系统100的多个查询的任何一个引用的每个列或属性存在一个属性向量。该属性向量包括表中每个扫描记录的一对信息(例如，RowID，值)。RowID唯一标识与列存储数据库中的信息对应的相关行条目。在另一实施例中，主键用于引用行存储数据库中的行条目，主键可映射到相应的RowID。在一实施例中，值是借助于字典定义的数据的缩写/编码的内部表现形式。

根据本发明实施例，列存储数据库的属性向量的覆盖范围是指主键值范围。即，合适的主键值范围可以用于定义任何属性向量的覆盖范围。如同rowID，主键值也可以唯一标识记录。RowID和主键之间存在一一映射的关系。例如，在以上提供的雇员表中，主键是雇员编号(EmpNo)，其可以用于(例如通过映射)唯一地标识行存储数据库的行条目。每个行条目唯一对应一个不同的雇员。当分析查询需要使用表扫描操作时，即使在给定的查询中未引用所述主键，也会构建主键列的属性向量。该属性向量提供主键值和对应的rowID之间的映射。针对涉及全表扫描操作的查询，覆盖范围仅是具有所有可能值的一个单个区间。对于涉及主键值范围的部分表扫描操作的查询，则使用覆盖该范围的记录的子集来构建引用属性的对应属性向量。

更具体地，从列存储数据库的初始状态开始，对于每个后续接收的分析查询，将目标量数据从处于对应当前时间状态下的行存储数据库导入到列存储数据库中，以满足相应的后续接收的分析查询。查询管理器/优化器120用于确定目标量数据，如果有的话，则从行存储数据库150导入到列存储数据库170。即，所述查询管理器/优化器120用于确定执行查询的最有效的路径，包括查询所引用的数据。特别地，查询管理器/优化器120用于接收后续接收到的分析查询，例如接收到的查询的序列中的任何一个。所标识的后续接收的分析查询针对多个属性中的第一引用属性(例如，工资)的主键属性的查询范围。例如，寻求雇员编号大于8000的男性雇员的平均工资的查询可在大于8000的主键属性(雇员编号)的查询范围内访问两个属性向量(例如，性别和工资)。

查询管理器/优化器120中的范围标识器125用于确定列存储数据库120对应的属性向量(例如，第一引用属性)关联的主键属性的覆盖范围是否在主键属性的查询范围内或包括主键属性的查询范围。特别地，范围标识器125与列存储元数据管理器通信，以访问包括元数据的状态信息的元数据。即，元数据包括与在列存储数据库170中构建的属性向量相关的状态信息。更具体地，元数据包括与列存储数据库中的每个属性向量对应的覆盖范围(例如，主键属性)。在这种方式下，查询管理器/优化器120可以确定覆盖范围是否包括满足查询的查询范围。

当存储在列存储数据库170中的针对第一引用属性的属性向量的主键属性的覆盖范围包括查询范围时，则不需要进行增强，因为列存储数据库170中包含的数据足以满足查询。即，例如，当列存储数据库包括足以满足查询的数据时，要导入的目标量数据是空的数据集合。

另一方面，当存储在列存储数据库170中的针对第一引用属性的属性向量的主键属性的覆盖范围不包括查询范围时，则增强覆盖范围以满足查询。在一实施例中，增强包括：导入包括最小量数据或恰好足够的数据的目标量数据，以支持并满足当前执行的分析查询。以查询雇员编号(EmpNo)大于8000的男性的平均工资为例，包括工资信息的属性向量可包括大于9000的雇员编号的信息。此时，覆盖范围(大于9000的雇员编号)不包括工资属性向量的查询范围(大于8000的雇员编号)。这样，使用目标数据增强工资属性向量，使得主键属性的覆盖范围包括该引用属性的主键属性的查询范围。导入到列存储数据库的目标数据包括从8000到9000的雇员编号的工资信息。更具体地，查询管理器/优化器120的数据导入器127用于从处于对应的当前时间状态下的行存储数据库150导入目标数据，以增强属性向量的覆盖范围来包含查询范围。

当引用属性的主键属性的覆盖范围为空集时，则从行存储数据库构建引用属性的属性向量。即，主键属性的查询范围的值用于构建引用属性的属性向量。

在一实施例中，目标量数据包括最小量数据，或恰好足够的数据，以支持并满足当前执行的分析查询。在一些实施例中，例如，当列存储数据库包括足以满足查询的数据时，目标量数据是空的数据集合。

图3A是本发明实施例提供的访问列存储数据库中信息的方法的流程图300A。在一实施例中，流程图300A示出了一种访问列存储数据库信息的计算机实现方法。在另一个实施例中，流程图300A在计算机系统中实现，该计算机系统包括处理器以及耦合到处理器的存储器，存储器中存储有指令。如果计算机系统执行所述指令，则所述系统执行访问列存储数据库信息的方法。在又一个实施例中，用于执行所述方法的指令存储在包含计算机可执行指令的非瞬时计算机可读存储介质中，所述计算机可执行指令使计算机系统执行访问列存储数据库信息的方法。在本发明一些实施例中，流程图300A的操作分别在图1和图8的数据库系统100、查询管理器/优化器120及系统800中实现。

在310中，所述方法包括构建存储数据的行存储数据库，所述行存储数据库的每行包括多个属性。在一实施例中，行存储数据库为真值的源。即，行存储数据库是用于构建例如列存储数据库等其他数据库的数据的源。

另外，行存储数据库中数据的状态相对于当前时间点是最新的。即，结合当前时间点，行存储数据库不包括在该当前时间点之后执行的信息改变(例如，INSERT/DELETE/UPDATE操作)。在一种情况下，相对于当前时间点而言最新的行存储数据库是从包含给定当前时间点的最新信息的数据库生成的，并且是其子集。

在320中，所述方法包括构建列存储数据库，其包括为满足接收的分析查询而构造的数据。列存储数据库包含表中的属性向量的集合。更具体地，访问数据库系统的多个查询的任一个引用的每个列或属性存在一个属性向量。如前所述，属性向量包括表(例如，行存储数据库)的每个扫描记录的一对信息(例如，rowID，值；或主键，值)。图2B是本发明实施例提供的雇员表200A的工资属性的示例性属性向量200B的示意图。如包含工资的属性向量200B的信息块250所示，列中的每个条目包括标识行存储数据库中的相关行条目的rowID和表示对应雇员的工资的值。例如，在字段251中，行条目是“0001”，工资“xxx”；在字段252中，行条目是“0002”，工资“yyy”；对于字段259，行条目是“000N”，工资“zzz”。

在一实施例中，在运行时查询的扫描操作期间，动态自适应地从对应的行存储数据库中导出列存储数据库的属性向量。更具体地，在330中，所述方法包括：从列存储数据库的初始状态开始，对于每个后续接收的分析查询，将目标量数据从处于对应当前时间状态下的行存储数据库导入到列存储数据库中，以满足后续接收的分析查询。具体地，在导入目标信息期间，对行存储数据库执行扫描操作(全表扫描或部分表扫描)，从而在行存储查询行存储时，构建/增强列存储中每个引用列的属性向量。一般来说，第一组分析查询会较慢，因为在其所需范围内的属性向量是逐步构建的。然而，不需导入目标数据，可使用列存储中现有的属性向量快速执行稍后的分析查询。下面图3B将会更充分地描述导入目标数据的过程。

图3B是本发明实施例提供的通过导入为满足执行查询的数据而动态自适应地构建列存储数据库，从而提供查询的实时分析结果的方法的流程图300B。在一实施例中，流程图300B示出了通过导入用于满足执行查询的数据来动态自适应地构建列存储数据库的计算机实现的方法。在另一实施例中，流程图300B在计算机系统中实现，所述计算机系统包括处理器和耦合到处理器的存储器，存储器中存储有指令。如果计算机系统执行所述指令，则所述系统执行通过导入用于满足执行查询的数据而动态自适应构建列存储数据库的方法。在又一实施例中，用于执行所述方法的指令存储在非瞬时性计算机可读存储介质中，该非瞬时性计算机可读存储介质具有计算机可执行指令，使得计算机系统执行通过导入用于满足执行查询的数据来动态自适应地构建列存储数据库的方法。在本发明的一些实施例中，流程图300B的操作分别在图1和图8的数据库系统100、查询管理器/优化器120及系统800中实现。

通过实现流程图300B中概述的流程构建自适应于接收到的分析查询的列存储，以动态即时地处理该接收到的查询；并且使用恰好足够的数据来构建列存储数据库，以服务于从行存储数据库的一致数据库状态(例如，当前时间状态)导入的每个接收到的分析查询。

特别地，通过在接收和执行分析查询时实现流程图300B来自适应动态地构建/增强列存储数据库的属性向量。在350中，所述方法包括：接收第一分析查询，所述第一分析查询针对与多个属性中的第一引用属性对应的第一引用属性向量的主键属性的查询范围。第一分析查询表示接收到的用于访问行存储数据库中最初包含的数据的分析查询序列中的任一个。更具体地，第一分析查询在其执行或运行期间引用一个或多个列，以包括每个引用属性及其属性向量的主键属性的查询范围内的数据。例如，查询管理器/优化器(例如，图1的管理器120)用于确定第一分析查询引用了哪些范围内的哪些属性向量。对于特定查询，主键属性的查询范围应用到该查询引用的每个属性向量。

在一实施例中，当运行时的查询中引用了列并且首先调用了表扫描操作来获取表记录时，构建属性向量。与不同列对应的不同属性向量可以在不同时间构建，这取决于它们在运行时的查询中被引用的时间。如果在后续查询中引用了附加范围，则可以稍后增强属性向量。

在一实施例中，对于除了主键属性外的任何接收到的分析查询中未引用的列，不需要构建对应的属性向量，并且不需要将其加载到列存储数据库中。另外，对于为满足查询范围而执行的扫描操作期间从未扫描过的数据记录(即它们不在范围断定中)，这些数据记录不包括在列存储数据库的属性向量中。因此，从不会使用对任何接收的分析查询无用的任何数据过度构建列存储数据库。与静态构建列存储(例如，ETL)相比，本发明实施例公开了自适应动态地构建列存储数据库的属性向量，更有效满足存储需求，因为没有资源用于存储在任何接收的分析查询期间未引用的数据。

在360中，所述方法包括：确定与列存储数据库中第一引用属性对应的第一引用属性向量的主键属性的覆盖范围是否在主键属性的查询范围内。例如，第一属性向量内的工资属性的覆盖范围可包括大于8000的雇员编号的信息。查询范围定义了查询请求的信息范围。例如，查询的范围可针对大于9000的雇员编号(例如，主键范围)的工资信息，在这种情况下，查询范围包含在覆盖范围内。在其他情况下，查询范围可能不包含在属性向量的覆盖范围内。例如，查询范围可能针对大于5000的雇员编号的工资信息。因此，查部分查询范围不包含在覆盖范围内，具体地，在5000到8000之间的雇员编号的信息是目标量数据。

在一实施例中，生成和存储元数据，其跟踪在列存储数据库中构建的属性向量及其记录或覆盖范围。流程图300B中概述的方法包括：访问元数据，其包括与列存储数据库中每个属性向量相关的信息和列存储数据库中每个属性向量对应的覆盖范围(例如，主键的范围)，以确定引用属性向量的覆盖范围是否包括第一分析查询的查询范围。例如，查询管理器/优化器用于访问和查询元数据，以确定每个分析查询引用了哪些范围内的哪些属性向量。如果列存储数据库包含查询的整个数据集，则查询管理器/优化器用于指示查询直接访问列存储数据库。

另一方面，如果列存储数据库不包含查询的整个数据集合，那么查询管理器/优化器用于使用为满足查询而导入的目标数据来增强列存储数据库。更具体地，在370中，当主键属性的覆盖范围没有在引用属性的引用属性向量的主键属性的查询范围内，所述方法包括：在查询执行期间，从行存储数据库导入目标量数据，增强覆盖范围，以包括查询范围满足第一分析查询。

特别地，当执行查询时，通常使用扫描算子访问行存储数据库中的数据。当在行存储数据库上执行查询时，本发明实施例能够搭载在扫描算子执行的操作之上，以构建/增强列存储中的每个引用列的属性向量。在本发明实施例中，扫描算子执行的扫描操作可通过执行全表扫描接触表中的所有记录，或通过部分表扫描接触表中部分记录。这样，可执行全表扫描或部分表扫描(例如，通过扫描算子)，来访问导入到列存储数据库的目标量数据。

在列存储数据库中，表数据通过列保存，每列一个文件。这样，当访问一列数据时，只用进行一次磁盘I/O。当有十列的新记录添加到表中，所述系统需要修改列存储中的十个文件。在一实施例中，批量处理记录，以加速修改列存储数据库。

在一实施例中，更新列存储数据库中的属性向量相关的元数据来反映改变，元数据包括列存储数据库中的每个属性向量相关的信息和列存储数据库中每个属性向量对应的覆盖范围(例如，主键范围)。特别地，更新属性向量的覆盖范围，以反映为满足查询而导入的目标量数据。

在一实施例中，一旦使用为满足第一分析查询而导入的目标量数据修改列存储，所述方法包括将列存储数据库永久存储到磁盘。在这种方式下，当数据库系统故障时，即使主存储器(例如，缓冲器或RAM)中存在的列存储数据库也可能故障，列存储数据库的备份也会存储在非易失性存储器中(例如，磁盘)，可从非易失性存储器中进行恢复。

在本发明实施例中，与后续的分析查询相比，接收的第一组分析查询将执行得较慢。这是因为新构建了属性向量并构建了覆盖范围。然而，随着接收和执行每个后续的分析查询，逐步构建列存储数据库的属性向量，稍后接收的分析查询执行地更快，因为列存储数据库中已经构建属性向量，并且可能或者可能不需要增强来满足相应查询。

全表扫描

仅为了说明目的，在先前介绍的雇员表上执行以下分析查询序列，其中，在图2A中描述行条目200A。在该示例中，将该序列中用于分析包含在雇员表或行存储数据库(例如，包含图2A中的行条目200A的数据库)内的数据的第一分析查询呈现为SQL语句，如下：“SELECT SUM(salary)FROM Employee”。该查询针对行存储数据库中的一个或多个属性的工资属性。为了效率，如图2B所示，本发明实施例从包含工资信息的对应属性向量或列中访问工资信息。在一实施例中，进行全表扫描，以访问导入到列存储数据库中对应属性向量的目标量数据，以满足查询。例如，为工资列构建属性向量。

继续以此为例，呈现序列中的第二分析查询，如下：“SELECT Name FROM EmployeeWHERE StartDate>‘mm/dd/yyyy’；”。在行存储的入职日期列上没有次索引的情况下，查询管理器/优化器将使系统扫描整个表以获取姓名值。这样，将为姓名列构建属性向量，并包括雇员姓名属性，也会为入职日期列构建另一属性向量并包括雇员入职日期。在所呈现的序列中，在前一次查询期间构建工资属性之后，构建姓名和入职日期属性向量。该示例示出了为运行时间查询自适应即时地构建属性向量。

在一实施例中，不需要构建在接收到的分析查询中未引用的列或列的范围，并且不需要将它们加载到列存储数据库中。即，使用自适应即时的方法构建列存储数据库的属性向量以满足运行时间查询，不会使用接收的分析查询未引用或无用的列过度构建列存储数据库。例如，如果未在任何分析查询中引用，前述呈现的雇员表中‘评语’列将不会出现在列存储中。

在一实施例中，当数据库系统使用次索引来获取记录时，不需要使用次索引访问方法构建属性向量。即，当系统需要从行存储数据库中仅获取少量记录时，可使用次索引。这是因为当仅需要少量记录时，列存储数据库不会显示良好性能优点。对于该查询，数据库系统可以直接从行存储中获取记录。继续以此为例，呈现序列中的第三分析查询，如下：“SELECT*FROM Employee WHERE EmpNo＝2001；”。该选择查询使用主索引从行存储数据库中仅检索一个记录(例如，雇员编号2001的)，而没有进行全表扫描。在这种情况下，数据库系统直接从行存储中获取记录。当执行该查询时，不需要构建/增强列存储。

部分表扫描

当构建列存储数据库的属性向量以满足查询时，可使用部分表扫描访问行存储数据库。出于说明目的，呈现新的查询序列来说明部分表扫描操作的使用。例如，在先前介绍的雇员表上执行如下分析查询序列，其中，图2A中描述了行条目200A。在该示例中，将该序列中用于分析包含在雇员表或行存储数据库(例如，包含图2A中的行条目200A的数据库)内的数据的第一分析查询呈现为SQL语句，如下：

SELECT EmpNo,Name,DeptNo,Title FROM Employee WHERE EmpNo>8000；

在一实施例中，数据库系统使用主键/索引来获取记录以构建引用属性的对应属性向量，尤其是当访问大量记录时。对于上述查询，当为包含雇员编号在8000之后的信息的列导入目标量数据时，主键/索引可用于获取那些工资记录，而不是进行全表扫描。如果查询对表进行连续部分扫描，则为扫描的那些记录构建引用属性向量或向量。即，那些属性向量是最初构建的。当执行后续查询，扫描其余记录时，可增强这些属性向量。

假设前面介绍的雇员表在行存储数据库中的主键列雇员编号上有类似B树的簇索引。例如，图4是本发明实施例提供的雇员表的B树400的示意图，其中，当自适应地构建列存储数据库中的引用属性向量时，主索引用于进行部分表扫描。第一层包括指向包含雇员标识的第二层420中的各种字段的指针。第二层中的指针提供对包含整个雇员记录的第三层的各种字段的访问。

如图所示，主键为雇员标识，定义在第二层420的字段中。可使用合适的主键/索引引用B树400的一部分。例如，可以跟随雇员1的主索引的指针401，然后跟随指针411，获得雇员编号标识1、100和200的记录。并且，可以跟随雇员300的主索引的指针402，然后跟踪指针412，获得雇员标识300、400和500的记录。进一步地，可以跟随雇员8000的主索引的指针403，然后跟随指针413，获得雇员标识8000、8100和8200的记录。

可使用部分表扫描访问引用数据，执行上述查询。首先使用8000的主键定位雇员记录，然后前向扫描以进行部分表扫描。如果这是第一次部分扫描雇员表，则为雇员编号列中大于8000的记录，构建雇员编号、姓名、部门编号和职位属性向量。元数据还保存在属性向量的可用范围和覆盖范围内。

继续以此为例，呈现序列中的第二分析查询，如下：

SELECT EmpNo,Name,DeptNo,Title FROM Employee

WHERE EmpNo>9000；

因为查询引用的大于9000的雇员编号的查询范围在大于8000的雇员编号的属性向量的覆盖范围内，所以不需要增强属性向量。这是因为覆盖范围包含查询范围。

继续以此为例，呈现序列中的第三分析查询，如下：

SELECT EmpNo,Name,DeptNo,Title FROM Employee

WHERE EmpNo>5000；

由于查询引用的大于5000的雇员编号的查询范围不在大于8000的雇员编号的属性向量的覆盖范围内，现在需要增强属性向量。这是因为查询范围是覆盖范围的超集。因此，需要使用雇员编号5000到雇员编号8000的记录来增强雇员编号的属性向量的覆盖范围。

在本发明实施例中，对于分析查询序列中未扫描的记录，如上述情况中小于5000的雇员编号的记录，不需要使用小于5000的雇员编号的记录对应的数据来构建或增强属性向量。即，在构建属性向量的覆盖范围的自适应和恰好足够的方法中，不使用任何接收的分析查询无用的或未引用的任何数据记录来构建列存储数据库。

元数据

在本发明实施例中，构建列存储数据库的自适应、即时、恰好足够的方法引用包括关于数据库中属性向量信息的元数据。例如，元数据指示已经在列存储数据库中已经构建了哪些属性向量，以及哪些信息范围(如主键范围)包含在这些属性向量内。因此，查询管理器/优化器用于在分析查询运行时查询元数据，以决定是否需要构建/增强引用属性向量。例如，如果列存储数据库包含查询引用的全部数据集，则查询管理器/优化器直接使查询访问列存储。

图5是本发明实施例提供的实现用以管理元数据的示例性算法500的示图，所述元数据指示在列存储数据库中已经构建了哪些属性向量以及哪些信息范围(例如主键范围)包含在这些属性向量内。在本发明的一些实施例中，分别在图1和图8的数据库系统100、元数据管理器160及系统800中实现算法500的操作。

假设min表示簇索引(也称为主键)的最小可能值，max表示相同簇索引的最大可能值。元数据中需要反映属性向量的所有覆盖范围(例如，主键的范围)。特别地，对于每个覆盖区间i，保存两个范围点(Li，Ui)，其中，Li是下限值，Ui是上限值。

SQL查询中的选择断定可分解为由OR算子连接的一个或多个不相交范围。具有连续区间的每个不相交范围可具有以下格式之一：1)范围条件(A<v)可规范地表示为(min<A<v)；2)范围条件(A>v)可规范地表示为(v<A<max)；3)范围条件‘(A>u)且(A<v)’可表示为(u<A<v)。

如果包括全部表格范围，则覆盖区间的范围(例如，主键范围)设置为(min，max)。当覆盖全部表格时，则应及早退出确定和存储元数据的过程，因为不会再改变覆盖区间。

算法500的条件包括：合并簇索引A上的查询范围断定LA<A<UA和已经覆盖的范围(例如，主键范围)。另一个条件包括通过INCL指示是否包括LA。即，当INCL为真，单侧范围条件为LA<＝A；否则，LA<A。又一个条件包括通过INCU指示是否包括UA。另一个条件包括通过min表示表中最小可能主键值，通过max表示表中最大可能主键值。又一个条件包括：对于元数据中的覆盖区间，定义Li为区间i的下限，Ui为覆盖区间i的上限。

如算法500所示，所有不相交覆盖区间(例如，主键范围)的上限和下限按照以下属性顺序排列：L1<U1<L2<U2<L3<U3<……大多数情况下，不期待在后续查询快速执行前，使用很多执行查询的区间来充分构建列存储数据库的属性向量。期待的是列的覆盖区间可以快速合并到一个区间(min，max)。一旦(min，max)覆盖整个列，则不再改变给定列或属性向量的元数据。因此，在一实施例中，简单的一维阵列(或向量)足以包含覆盖区间所有边界值。在存在很多覆盖区间的情况下，可以使用二叉树，例如AVL-tree，来包含所有上限/下限值，以便可以快速定位查询范围断定的LA和UA。

图6A-6F是本发明实施例提供的将属性向量的覆盖区间与查询范围进行比较的各种示例的示意图。

如图6A所示，对于情况1，属性向量600包括在min和max之间的范围(例如，主键范围)内的信息。覆盖范围包括区间1，其下限为L1，上限为U1。覆盖范围还包括区间2，其下限为L2，上限为U2。覆盖范围还包括区间3，其下限为L3，上限为U3。在情况1中，查询范围的下限为LA，上限为UA。因为查询范围完全包含在区间1中，所以不改变元数据，且无需导入额外数据，属性向量600就足以满足该查询。

如图6B所示，对于情况2，现在查询范围(LA，UA)与区间1重叠，使得覆盖范围不足以包含查询范围。例如，查询范围的下限LA在区间1内，而上限UA在区间1至3中任一个之外的未覆盖空间中。当查询运行时，使用增强区域610中的范围(U1，UA)内的记录来增强属性向量600。在元数据中，区间1的边界修改为新形成的连续区间的(L1，UA)。即，区间1的上限修改为UA。

如图6C所示，对于情况3，查询范围(LA，UA)与两个区间重叠：区间1和区间2。查询范围的下限LA在区间1内，而上限UA在区间2内。当查询运行时，使用增强区620中的范围(U1，L2)内的记录来增强属性向量600。在元数据中，将区间1和区间2替换为范围为(L1，U2)的新连续区间。例如，区间1的上限可修改为U2，而将区间2擦除。同样有效地，区间2的下限可修改为L1，而将区间1擦除。

如图6D所示，对于情况4，如增强区630所示，查询范围完全在单个未覆盖的区间中。当查询运行时，使用增强区630中所示的范围(LA，UA)内的记录增强属性向量600。元数据包括范围为(LA，UA)的新区间4。

如图6E所示，对于情况5，查询范围(LA，UA)完全覆盖区间2。然而，下限LA和上限UA在不同的未覆盖区间中。例如，下限LA在区间1和区间2之间，上限UA在区间2和区间3之间。当查询运行时，使用增强区640的范围(LA，L2)内的记录和增强区650的范围(U2，UA)内的记录来增强属性向量600。在元数据中，将区间2替换为范围为(LA，UA)的新区间。

如图6F所示，对于情况6，下限LA在区间1和区间2之间的未覆盖区间中，上限UA在覆盖区间3中。当查询运行时，使用增强区660的范围(LA，L2)内的记录和增强区670的范围(U2，L3)内的记录来增强属性向量600。在元数据中，将区间2和区间3合并，并替换为范围为(LA，U3)的连续区间。例如，区间2的下限和上限可修改为(LA，U3)，而将区间3擦除。同样有效地，区间3的下限和上限可修改为(LA，U3)，而将区间2擦除。

图7是本发明实施例提供的通过导入目的为满足执行查询的数据，动态自适应地构建列存储数据库的统一建模语言(Unified Modeling Language，UML)序列图700的示意图。仅出于说明目的，通过执行样本查询来描述UML序列图700，如下：“SELECT DeptNo,SUM(salary)FROM Employee GROUP BY DeptNo；”。SELECT语句要求对每个部门员工的工资求和。如图7所示，在执行SELECT语句时，在组件之间按照时间顺序安排各种交互。

在操作705中，查询管理器790接收查询或SELECT语句。查询管理器790管理构建列存储数据库和访问列存储数据库中数据的过程，以处理查询并获得结果。在操作710中，从列元数据793中(例如，从列日志文件中)获取列存储数据库中的属性向量的覆盖范围/区间(例如，主键范围)，并返回到查询管理器790。在操作715中，查询管理器790比较覆盖范围和查询范围/区间，以确定是否需要构建属性向量或增强覆盖范围。如果需要增强属性向量，则查询管理器790执行并管理略图701中定义的流程。否则，属性向量的覆盖范围足以满足查询，在操作770中，从列数据缓冲器794中获取列数据，或在771中，从列数据文件795(例如，磁盘)中获取，并返回至列数据缓冲器794。在操作775中，返回列数据至查询管理器790，以处理查询。

查询管理器/优化器790用于使用表扫描算子来获取查询引用的所有雇员记录，以计算结果。当需要构建或增强属性向量时，执行略图701中的操作。在操作720中，从行数据缓冲器791中获取未覆盖区间(例如，主键范围上)内的数据。如果缓冲器791不包含该数据，则在操作725中，从行数据文件792中获取未覆盖区间中的数据，并在操作730中，将其返回至行数据缓冲器791。在735中，将未覆盖区间中检索的数据(例如，目标量数据)转移至列数据缓冲器794。在操作740中，提交所应用的改变，并报告给列日志管理器796。另外，在操作745中，保存属性向量及其对应的元数据至磁盘。在提交改变后，在操作750中，返回函数调用至行数据缓冲器，在操作755中，返回另一个函数调用至查询管理器790。在操作760中，查询管理器合并更新列元数据793，以反映改变，返回函数调用765至查询管理器790。在这种方式下，查询管理器790理解可使用列存储数据库处理查询。继续该流程，以在操作770中，从列数据缓冲器794中获取列数据，或当数据不在存储器中，在771中，从列数据文件795(例如，磁盘)中获取列数据，并返回至列数据缓冲器794。在操作775中，返回列数据至查询管理器790以处理查询。

在一实施例中，应该在一个事务中完成更新属性向量及其元数据，从而保持元数据的内容与对应的属性向量一致。应注意，在一实施例中，内部构建列存储及其元数据，以加快分析查询。即，它们对于终端用户是透明的。这样，终端用户仅接触行存储数据库中定义的表模式。

因此，根据本发明实施例，描述了从行存储数据库中自适应构建列存储数据库的系统和方法，以满足针对引用属性向量或列的分析查询。

虽然以上披露使用具体的方框图、流程图以及示例阐明各种实施例，本文中所述和/或图示的每个方框图组件、流程图步骤、操作和/或组件都可以通过各种硬件、软件或固件(或者它们的任意组合)配置单独地和/或共同地实施。另外，对其他组件之中包括的任意组件的披露应该看作为示例，因为可以实施许多其他架构来达到同样的功能。

本文中所述和/或图示的进程参数和步骤顺序仅仅是为了举例并且可以按需要更改。例如，虽然本文中所图示和/或描述的步骤可以按照特定顺序来示出或讨论，但这些步骤并非必须按照所图示或所讨论的顺序来执行。本文中所述和/或所图示的各种示例方法还可以省略本文中所述和/或所图示的一个或多个步骤或还可以包括除披露的那些步骤之外的额外步骤。

虽然本文已经在全功能性计算系统的背景下对不同的实施例进行了描述和/或图示，这些示例实施例中的一个或多个能够以多种方式作为一个程序产品来分发，而不管用于实际进行该分发的计算机可读介质的具体形式如何。本文中所披露的实施例还可以通过使用执行一些特定任务的软件模块来实施。这些软件模块可以包括脚本、成批文件或其他可执行文件，其中这些可以存储在一种计算机可读介质上或者一种计算机系统中。这些软件模块可以配置一个计算机系统以用于执行本文中所披露的一个或多个示例实施例。本文中所披露的一个或多个软件模块可以在云计算环境中实施。云计算环境可以通过互联网提供不同的业务和应用程序。这些基于云的业务(例如，软件即服务、平台即服务、基础设施即服务等等)可以通过网络浏览器或其他远程接口进行访问。本文中所述的各种功能可以通过远程桌面环境或任意其他基于云的计算环境来提供。

虽然已详细地描述了本发明及其优点，但是应理解，可以在不脱离如所附权利要求书所界定的本发明的精神和范围的情况下对本发明做出各种改变、替代和更改。根据上述教导，许多修改和变更是可能的。选出和描述的各个实施例的目的是为了更好地解释本发明的原理和其实际应用，因而使本领域技术人员能够更好利用本发明各个实施例和适合预期特定用途的各种变更。

此外，本发明的范围并不局限于说明书中所述的过程、机器、制造、物质组分、构件、方法和步骤的具体实施例。所属领域的一般技术人员可从本发明中轻易地了解，可根据本发明使用现有的或即将开发出的，具有与本文所描述的相应实施例实质相同的功能，或能够取得与所述实施例实质相同的结果的过程、机器、制造、物质组分、构件、方法或步骤。相应地，所附权利要求范围旨在包括这些流程，机器，制造，物质组分，构件，方法，及步骤。

根据本发明的实施例如此处所述。虽然本发明已经在特定实施例中进行了描述，但是应理解，本发明不应该被解释为这些实施例的限制，而是根据以下权利要求书进行解释。

Claims (20)

1.一种访问信息的计算机系统，其特征在于，包括：

存储器，存储有计算机可执行指令；

处理器，执行所述计算机可执行指令，所述计算机可执行指令包括：

构建存储数据的行存储数据库，其中，所述行存储数据库的每行包括多个属性，所述行存储数据库的数据相对于当前时间点是最新的；

构建列存储数据库，其包括为满足接收到的分析查询而构造的数据；

从所述列存储数据库的初始状态开始，对于每个后续接收的分析查询，将目标量数据从处于对应当前时间状态下的行存储数据库导入到列存储数据库中，以满足相应的后续接收的分析查询。

2.根据权利要求1所述的计算机系统，其特征在于，所述计算机可执行指令中的所述导入目标量数据包括：

接收第一分析查询，其中，所述第一分析查询针对所述多个属性中的引用属性对应的引用属性向量的主键属性的查询范围；

判断所述主键属性在所述引用属性向量的覆盖范围是否在所述主键属性的所述查询范围内；

当所述覆盖范围不在所述查询范围内，在执行所述第一分析查询时，从所述行存储数据库导入所述目标量数据，以增强所述覆盖范围以包含所述查询范围。

3.根据权利要求2所述的计算机系统，其特征在于，所述计算机可执行指令中的所述判断覆盖范围包括：

访问元数据，其中，所述元数据包括与所述列存储数据库中的每个属性向量相关的信息和所述列存储数据库的每个属性向量对应的主键属性的覆盖范围。

4.根据权利要求1所述的计算机系统，其特征在于，所述处理器执行的计算机可执行指令还包括：

更新元数据以反映所述目标量数据，其中，所述元数据包括与所述列存储数据库中的每个属性向量相关的信息和所述列存储数据库的每个属性向量对应的主键属性的覆盖范围。

5.根据权利要求1所述的计算机系统，其特征在于，所述计算机可执行指令中的所述导入数据包括：

进行所述行存储数据库的全表扫描，以访问所述目标量数据。

6.根据权利要求1所述的计算机系统，其特征在于，所述计算机可执行指令中的所述导入数据包括：

进行所述行存储数据库的部分表扫描，以访问所述目标量数据。

7.根据权利要求1所述的计算机系统，其特征在于，所述处理器执行的计算机可执行指令还包括：

将所述目标量数据更新后的所述列存储数据库持续存储到磁盘。

8.一种从行存储数据库中动态构建列存储数据库的方法，其特征在于，包括：

构建存储数据的所述行存储数据库，其中，所述行存储数据库中的每行包括多个属性，所述行存储数据库中的数据相对于当前时间点是最新的；

构建列存储数据库，其包括为满足接收到的分析查询而构造的数据；

从所述列存储数据库的初始状态开始，对于每个后续接收的分析查询，将目标量数据从处于对应当前时间状态下的行存储数据库导入到列存储数据库中，以满足相应的后续接收的分析查询。

9.根据权利要求8所述的方法，其特征在于，所述导入目标量数据包括：

接收第一分析查询，其中，所述第一分析查询针对所述多个属性中的引用属性对应的引用属性向量的主键属性的查询范围；

判断所述主键属性在所述引用属性向量的覆盖范围是否在所述主键属性的所述查询范围内；

当所述覆盖范围不在所述查询范围内，在执行所述第一分析查询时，从所述行存储数据库导入所述目标量数据，以增强所述覆盖范围以包含所述查询范围。

10.根据权利要求9所述的方法，其特征在于，所述判断覆盖范围包括：

访问元数据，其中所述元数据包括与所述列存储数据库中的每个属性向量相关的信息和所述列存储数据库的每个属性向量对应的主键属性的覆盖范围。

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

更新元数据以反映所述目标量数据，其中，所述元数据包括与所述列存储数据库中的每个属性向量相关的信息和所述列存储数据库的每个属性向量对应的主键属性的覆盖范围。

12.根据权利要求8所述的方法，其特征在于，所述导入数据包括：

进行所述行存储数据库的全表扫描，以访问所述目标量数据。

13.根据权利要求8所述的方法，其特征在于，所述导入数据包括：

进行所述行存储数据库的部分表扫描，以访问所述目标量数据。

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

将所述目标量数据更新后的所述列存储数据库持续存储到磁盘。

15.一种非瞬时性计算机可读介质，包括使计算机系统执行方法的计算机可执行指令，其特征在于，所述方法包括：

构建存储数据的行存储数据库，其中，所述行存储数据库的每一行包括多个属性，所述行存储数据库中的数据相对于当前时间点是最新的；

构建列存储数据库，其包括为满足接收到的分析查询而构造的数据；

从所述列存储数据库的初始状态开始，对于每个后续接收的分析查询，将目标量数据从处于对应当前时间状态下的行存储数据库导入到列存储数据库中，以满足相应的后续接收的分析查询。

16.根据权利要求15所述的计算机可读介质，其特征在于，所述方法中的所述导入目标量数据包括：

接收第一分析查询，其中，所述第一分析查询针对所述多个属性中的引用属性对应的引用属性向量的关键属性的查询范围；

判断所述主键属性在所述引用属性向量的覆盖范围是否在所述主键属性的所述查询范围内；

当所述覆盖范围不在所述查询范围内，在执行所述第一分析查询时，从所述行存储数据库导入所述目标量数据，以增强所述覆盖范围从而包含所述查询范围。

17.根据权利要求16所述的计算机可读取介质，其特征在于，所述方法中的所述判断覆盖范围包括：

访问元数据，其中所述元数据包括与所述列存储数据库中的每个属性向量相关的信息和所述列存储数据库的每个属性向量对应的主键属性的覆盖范围。

18.根据权利要求15所述的计算机可读取介质，其特征在于，所述方法还包括：

更新元数据以反映所述目标量数据，其中，所述元数据包括与所述列存储数据库中的每个属性向量相关的信息和所述列存储数据库的每个属性向量对应的主键属性的覆盖范围。

19.根据权利要求15所述的计算机可读取介质，其特征在于，所述方法中所述导入数据包括：

进行所述行存储数据库的全表扫描，以访问所述目标量数据。

20.根据权利要求15所述的计算机可读取介质，其特征在于，所述方法中所述导入数据包括：

进行所述行存储数据库的部分表扫描，以访问所述目标量数据。