CN103810224A - 信息持久化和查询方法及装置 - Google Patents

Abstract

本申请公开了一种应用于key-value数据库的信息持久化方法和装置，针对任一业务实体对象，将该业务实体对象的属性值分别存储到数据表的同一行的不同列中，并基于该业务实体对象的属性值而生成行键。由于HBase等数据库是基于列的存储模式来实现信息的持久化，而该方案正是将对应于同一业务实体对象的属性值存储在同一行的不同列中，因此，相比于现有技术提供的针对关系数据库的信息持久化方案，本申请实施例提供的该方案更能够匹配于key-value数据库关于存储模式的特性。本申请还公开一种面向对象的查询方法和装置。

Description

信息持久化和查询方法及装置

技术领域

本申请涉及信息搜索技术领域，尤其涉及一种应用于key-value数据库的信息持久化和查询方法及装置。

背景技术

HBase（Hadoop Database）是key-value数据库，其是一个分布式的、面向列的开源数据库，该技术来源于Chang et al所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。

HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。与关系数据库的另一个不同的是HBase采用的是基于列存储模式。目前，针对关系数据库，已有众多关系对象映射（ORM）框架来对JDBC进行面向对象的封装，并产生了JDO（Java Data Object）和JPA（Java Persistence API）等针对由Java类表示的业务实体对象的持久化规范。其中，JDO提供了透明的业务实体对象持久化方案，除关系数据库外，其还可以提供包括对象数据库等在内的其他类型的数据库的业务实体对象持久化方案。

现有技术提供的这些方案总体来说是针对关系数据库的存储特性而提出的，并没有考虑到HBase的一些特性，如HBase是基于列的存储模式等，从而存在不支持对同一业务实体对象的多个版本的持久化和查询，在查询业务实体对象时不能充分缩减查询范围，查询通常需要扫描HBase中存储有业务实体对象的整张表，从而会浪费较多的处理资源。

发明内容

本申请实施例提供一种应用于key-value数据库的信息持久化方法和装置，用以提供一种基于key-value数据库（如HBase）的特性而提出的信息持久化方案。

本申请实施例还提供一种面向对象的查询方法和装置，用以对按照本申请实施例提供的持久化方法存储在key-value数据库（如HBase）中的信息进行查询。

本申请实施例采用以下技术方案：

一种应用于key-value数据库的信息持久化方法，包括：

根据针对业务实体对象设置的注解信息，确定存储该业务实体对象的主表、主表行键生成策略和用于生成主表行键的第一属性；确定该业务实体对象所包含的与第一属性对应的属性值，并按照在不同列中存储不同属性值的存储方式，将确定的属性值分别存储到主表的同一行的不同列中；根据主表中存储的属性值在其所在行中的第一排列顺序、主表行键生成策略以及所述确定的属性值，生成主表行键。

一种基于上述信息持久化方法的面向对象的查询方法，包括：

获得针对业务实体对象的查询条件，并通过对查询条件的解析，获得查询条件包含的属性值；根据指定属性和查询条件中包含的属性值，判断出查询条件中包含对应于指定属性的指定属性值时，针对数据表中存储的各个行键，执行分别确定生成该行键的属性值所构成的第一属性值集合；确定包含有查询条件所包含的指定属性值的第一属性值集合；从确定的包含有查询条件所包含的指定属性值的第一属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的行键；以及根据查询条件中包含的属性值，查询确定的行键所在的数据表的行中存储的属性值。

一种应用于key-value数据库的信息持久化装置，包括：

第一注解信息解析单元，用于根据针对业务实体对象设置的注解信息，确定存储该业务实体对象的主表、主表行键生成策略和用于生成主表行键的第一属性；第一属性值确定单元，用于确定该业务实体对象所包含的、与第一注解信息解析单元确定的第一属性对应的属性值；第一属性值存储单元，用于按照在不同列中存储不同属性值的存储方式，将第一属性值确定单元确定的属性值，分别存储到注解信息解析单元确定的主表的同一行的不同列中；主表行键生成单元，用于根据主表中存储的所述确定的属性值在其所在行中的第一排列顺序、第一注解信息解析单元单元确定的主表行键生成策略以及第一属性值确定单元确定的属性值，基于按照所述第一排列顺序排列主表行键中包含的字段所对应的属性值的方式，生成主表行键。

一种基于上述信息持久化装置的面向对象的信息查询装置，包括：

查询条件解析单元，用于通过对针对业务实体对象的查询条件的解析，获得查询条件包含的属性值；第一集合确定单元，用于根据指定属性和查询条件解析单元获得的查询条件中包含的属性值，判断出查询条件中包含对应于指定属性的指定属性值时，针对数据表中存储的各个行键，执行分别确定生成该行键的属性值所构成的第一属性值集合；第二集合确定单元，用于从第一集合确定单元确定的第一属性值集合中，确定包含有查询条件所包含的指定属性值的第一属性值集合；行键确定单元，用于从第二集合确定单元确定的第一属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的行键；查询单元，用于根据查询条件解析单元获得的属性值，查询行键确定单元确定的行键所在的数据表的行中存储的属性值。

本申请实施例的有益效果如下：

本申请实施例提供的上述方案针对任一业务实体对象，将该业务实体对象的属性值分别存储到数据表的同一行的不同列中，并将基于该业务实体对象的属性值而生成的行键。由于HBase等数据库是基于列的存储模式来实现信息的持久化，而该方案正是将对应于同一业务实体对象的属性值存储在同一行的不同列中，因此，相比于现有技术提供的针对关系数据库的信息持久化方案，本申请实施例提供的该方案更能够匹配于key-value数据库关于存储模式的特性。

附图说明

图1为本申请实施例提供的一种信息持久化方法的具体流程示意图；

图2为本申请实施例提供的一种面向对象的查询方法的具体流程示意图；

图3为实际应用中用于实现本申请实施例提供的方案的架构示意图；

图4为本申请实施例提供的方案在电子商务网站领域中的具体应用流程示意图；

图5为本申请实施例提供的一种信息持久化装置的具体结构示意图；

图6为本申请实施例提供的一种信息查询装置的具体结构示意图。

具体实施方式

为了提供一种面向对象数据库的基于key-value数据库特性的信息持久化方案，以解决现有技术中的业务实体对象持久化方案不适用于如HBase等key-value数据库的特性的问题，本申请实施例提供了一种信息持久化方案。该方案针对任一业务实体对象，将该业务实体对象的属性值分别存储到数据表的同一行的不同列中。由于HBase等key-value数据库是基于列的存储模式来实现信息的持久化，而该方案正是将对应于同一业务实体对象的属性值存储在同一行的不同列中，并可选的，将作为业务实体对象查询依据的行键（Row-Key）存储到第一列以便于后续查找，因此，相比于现有技术提供的针对关系数据库的信息持久化方案，本申请实施例提供的该方案更能够匹配于key-value数据库关于存储模式的特性。

以下结合附图，详细说明本申请实施例提供的信息持久化方案。

请参见图1，其为本申请实施例提供的一种信息持久化方法的具体流程示意图，包括以下步骤11-13。

步骤11，针对每个待持久化的业务实体对象，根据针对该业务实体对象设置的注解信息，分别确定存储该业务实体对象的主表、主表行键生成策略和用于生成主表行键的第一属性。

本申请实施例中，可以针对业务实体对象预先设置相应的注解信息。比如，针对某一类业务实体对象（如针对商品的评价信息或商品购买事件信息），可以预先设置包括存储该业务实体对象的主表、主表行键生成策略和用于生成主表行键的属性值等在内的注解信息。其中，这里的主表一般指key-value数据库中的子存储单元。

以针对商品的评价信息为例，针对该评价信息的注解信息中可以包含：存储该评价信息的主表、主表的行键的生成策略、用于生成主表行键的属性。其中，用于生成主表行键的属性可以是该评价信息对应的用户ID、商品ID和评价时间。主表的行键的生成策略可以是将用于生成行键的第一属性的具体值转换成字符串并组合；或对用于生成行键的第一属性的具体值进行组合后取MD5（MD5是一种hash算法，可以根据一段文本生成一个唯一的值，该唯一的值也可以用MD5表示），并以MD5作为行键；将用于生成行键的第一属性的具体值转换成字符串后再对字符串执行反转、组合操作，并以反转、组合后得到的字符串作为行键。

可选的，当需要满足快速查询的需求时，还可以在数据库中存储不同版本的业务实体对象。此时，注解信息中还可以进一步包括存储该业务实体对象的索引表、索引表行键生成策略和用于生成索引表行键等信息。本申请实施例中，不同版本的业务实体对象的含义在于：具有相同的信息内容、但对应的存储空间，且存储空间中的业务实体对象属性值的存储顺序不同。

步骤12，根据确定的第一属性，确定该业务实体对象所包含的与第一属性对应的属性值，并按照在不同列中存储不同属性值的存储方式，将确定的属性值分别存储到主表的同一行的不同列中；

比如，针对上述评价信息，当该评价信息的第一属性为用户ID、商品ID和评价时间时，可以从该评价信息中确定用户ID、商品ID和评价时间的具体值即属性值，比如分别为1、2、3。按照上述存储方式，可以将属性值1、2、3存储在主表的同一行的不同列中。本申请实施例中，主表中存储属性值的列不包括第1列，这是由于该第1列往往用于存储作为属性值查询依据的行键。基于key-value数据库的特性可知，其是基于列的存储模式来实现信息的持久化，并且在后续进行信息查询时，也采用的是基于列的查询模式。因此，本申请实施例中将行键存储在第一列中的方式，可以便于后续在进行信息查询时，能够迅速获取到用于匹配查询条件的行键。

步骤13，根据主表中存储的上述确定的属性值在其所在行中的第一排列顺序、主表行键生成策略以及上述确定的属性值，生成主表行键。

比如，假设上述属性值1、2、3在其所在行中的第一排列顺序为：1在2之前、2在3之前，且假设主表关键字生成策略为将用于生成行键的第一属性的具体值转换成字符串并组合，则根据属性值1、2、3、该第一排列顺序和该生成策略，按照第一排列顺序排列上述属性值的方式，可以生成主表行键1_2_3。

又比如，假设上述属性值1、2、3在其所在行中的第一排列顺序为：2在1之前、1在3之前，且假设主表关键字生成策略为将用于生成行键的第一属性的具体值转换成字符串并组合，则根据属性值1、2、3、该第一排列顺序和该生成策略，按照第一排列顺序排列主表行键中包含的字段所对应的属性值的方式，可以生成主表行键2_1_3。

通过执行步骤13而生成的主表行键的特点在于：其能够体现其所在的行中存储的属性值的排列顺序。同时，基于key-value数据库的特性可知，在后续进行信息查询时，采用的是基于列的查询模式。结合主表行键所表征的属性值排列顺序和该查询模式可以确定：采用本申请实施例提供的该行键的生成方式，在后续进行信息查询时，可以根据行键确定出属性值的存储顺序，从而根据该存储顺序，实现以存储位置比较靠前、且与查询条件相匹配的属性值所在行，作为优先查询的行。

一般地，生成的主表行键可以存储到主表的存储所述确定的属性值的行中，尤其是在存储属性值的行的第一列没有存储有属性值时，可以根据主表行键与用于生成主表行键的属性值的对应关系，将生成的各个主表行键对应存储到相应的属性值所在行的第一列中。

本申请实施例中，假设根据注解信息还确定出存储该业务实体对象的索引表、索引表行键生成策略和用于生成索引表行键的第二属性，则上述方法还可以进一步包括如下步骤：

首先，确定该业务实体对象所包含的与第二属性对应的属性值，并按照在不同列中存储不同属性值的存储方式，将确定的与第二属性对应的属性值分别存储到索引表的同一行的不同列中；一般地，索引表中存储第二属性对应的属性值的列可以不包括第一列；

以前文所述的评价信息为例，假设第二属性与第一属性相同，则按照该步骤，可以将属性值1、2、3存储在索引表的同一行的不同列中。比如，将属性值3存储在第1行的第2列，将属性值1存储在第1行的第2列，并将属性值2存储在第1行的第3列。

其次，根据索引表中存储的第二属性对应的属性值在其所在行中的第二排列顺序、索引表行键生成策略以及第二属性对应的属性值，基于索引表行键中包含的字段所对应的属性值按照第二排列顺序进行排列的生成方式，生成索引表行键；

由前述假设可知，通过执行该步骤生成的索引表行键为312。

最后，可以将生成的索引表行键存储到索引表的存储第二属性对应的属性值的行中。可选的，当索引表中存储属性值的列不包括第一列时，可以根据索引表行键与用于生成索引表行键的属性值的对应关系，将生成的各索引表行键对应存储到相应的属性值所在行的第一列中。

通过执行上述针对索引表的步骤，本申请实施例提供的该方法可以实现在key-value数据库中存储不同版本的业务实体对象，这是现有技术提供的针对关系数据库的信息持久化方案所没有实现的。

本申请实施例提供的上述方案通过将对应于同一业务实体对象的属性值存储在同一行的不同列中，并将作为业务实体对象查询依据的行键存储到第一列以便于后续查找，从而相比于现有技术提供的针对关系数据库的信息持久化方案，其更能够匹配于key-value数据库基于列的存储模式。

基于上述信息持久化方法，本申请实施例还提供一种面向对象的查询方法，用以实现对按照上述信息持久化方法存储在数据库中的信息进行查询。该面向对象的查询方法的具体流程示意图如图2所示，包括下述步骤：

步骤21，获得针对业务实体对象的查询条件，并通过对查询条件的解析，获得查询条件包含的属性值；

比如，若需要查找包含属性值1、2、3的上述评价信息，可以以属性值1、2或包含属性值1、2在内的信息作为查询条件；或者，也可以以属性值1、3或包含属性值1、3在内的信息作为查询条件；或者，还可以以属性值1、2、3或包含属性值1、2、3在内的信息作为查询条件。

步骤22，根据指定属性和查询条件中包含的属性值，判断出查询条件中包含对应于指定属性的指定属性值时，针对数据表中存储的各个行键，执行分别确定生成该行键的属性值所构成的第一属性值集合；

本申请实施例中，所述指定属性值可以但不限于是常用于作为查询条件或常包含于查询条件中的属性值。具体地，可以通过对用户输入的查询条件的统计而确定指定属性值。

针对上述评价信息，若假设指定属性为用户ID，且假设查询条件中包含上述属性值1、2，则可以确定该查询条件中包含对应于用户ID这一属性的属性值，即属性值1。此时，针对数据表中存储的各个行键，可以分别确定相应的第一属性值集合。比如，针对数据表中的行键123、213，可以分别确定相应的第一属性值集合均为（1，2，3），而针对数据表中的行键23，则可以确定相应的第一属性值集合为（2，3）。

步骤23，确定包含有查询条件所包含的指定属性值的第一属性值集合；

由上述假设可知，（1，2，3）这一第一属性值集合中包含有指定属性值1，而（2，3）这一第一属性值集合中没有包含指定属性值1。

步骤24，从确定的包含有查询条件所包含的指定属性值的第一属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的行键；

以上述假设为例，通过执行步骤24，可以从确定的包含有指定属性值1的第一属性值集合（1，2，3）所对应的行键123、213中，确定包含的第一个字段所对应的属性值与指定属性值1匹配一致的行键为123。

步骤25，根据查询条件中包含的属性值，查询确定的行键所在的数据表的行中存储的属性值。由于根据业务实体对象的属性值就可以生成业务实体对象，因此，查询属性值即实现了对业务实体对象的查询。

仍然以上述假设为例，由于通过执行步骤24而确定的行键为123，因此，步骤25中可以以行键123所在行作为查询对象，对其中存储的属性值进行查询。

本申请实施例中，数据表中可以冗余存储用于生成行键的属性值外的其他属性值（如一般不用于生成行键的评价信息内容这一属性值）。冗余存储的该些属性值虽然不会从行键出体现出来，然而其有可能仍然是用户所需求的信息。并且，当查询条件中包含冗余存储的该些属性值时，根据查询到的属性值所生成的业务实体对象中若能包含冗余存储的该些属性值，则更能满足用户的需求。在该场景下，本申请实施例提供的上述方案还可以进一步包括步骤：从查询条件所包含的属性值中，确定不属于任意第一属性值集合的属性值。基于确定出的不属于任意第一属性值集合的属性值，上述步骤25之后还可以进一步包括下述步骤：

首先，从查询到的对应于不同行键的属性值所分别构成的第二属性值集合中，确定包含确定的不属于任意第一属性值集合的属性值的第二属性值集合；

然后，针对包含确定的不属于任意第一属性值集合的属性值的各第二属性值集合，执行根据该第二属性值集合中包含的属性值，生成业务实体对象。

本申请实施例中，为了进一步缩小查询范围，以提高查询效率，如图2所示的方法还可以进一步包括步骤：从确定的包含有查询条件所包含的指定属性值的第一属性值集合中，确定包含与查询条件所包含的属性值匹配一致的属性值的个数最多的目标属性值集合。基于该步骤，上述步骤24的一种具体实现方式可以包括：从确定的目标属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的行键。

通过执行上述步骤，可以在确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的行键之前，先从包含有查询条件所包含的指定属性值的第一属性值集合中，确定出包含与查询条件所包含的属性值匹配一致的属性值的个数最多的目标属性值集合，从而减少了与查询条件相关性较小的第一属性值集合的数量，实现了在保证查询结果准确性的前提下，缩小了查询范围，提高了查询效率。

以下以一个具体的实施流程为例，详细说明本申请实施提供的上述方案在实际中的应用过程。由于在实际应用中，是先实现对业务实体对象的持久化操作，然后再实现对持久化后的业务实体对象的查询，因此下文将按照该顺序，并结合图3对本申请实施例的实际应用过程进行说明。

图3为实现该实际应用过程的架构示意图，其针对业务实体对象的持久化提供了一个名为HobjectManager的接口，并针对业务实体对象的查询提供了一个名为Query的接口。基于HobjectManage可以实现业务实体对象在HBase中的持久化，基于Query可以实现对HBase中存储的业务实体对象的查询。

具体地，通过HobjectManage可执行的操作为：根据为业务实体对象设置的注解信息（该注解信息中包含有用于存储业务实体对象的HBase的存储空间（即HBase的列（Column））的信息等，详见后文），确定该注解信息与Hbase中存储该业务实体对象的存储空间的映射关系（Annotation Mapping），并通过Java程序应用编程接口（Java Client API）对HBase进行访问而实现根据该映射关系将业务实体对象存储到HBase中的相应的存储空间，以实现业务实体对象在HBase中的持久化。

而通过Query这一接口可执行的操作为：首先，获得查询条件（针对HBase的查询条件一般是HQL语句），并根据获得的查询条件确定待查询的业务实体对象，以及确定针对待查询的业务实体对象的查询计划（Query Plan）；然后，根据Annotation Mapping确定Hbase中存储待查询的该业务实体对象的存储空间；最后，通过Java Client API对HBase进行访问，从而实现从确定出的存储空间中获取待查询的该业务实体对象。

上述通过HobjectManage可执行的操作和通过Query可执行的操作可以由一个称作业务实体对象持久化和查询服务器（以下简称服务器）的设备实现。

以电子商务网站中常见的评价功能为例，以下具体介绍基于图3所示的该架构实现业务实体对象持久化和查询的过程。该过程主要包括如图4所示的下述步骤：

步骤41，某用户购买某商品后，向服务器输入针对该商品的评价信息（Comment）；

一般地，用户ID、商品ID和评价时间可以唯一确定一条评价信息，在服务器中，评价信息是以一个Java类来表示的。比如，用于表示该评价信息的Java类的伪代码如下：

步骤42，服务器按照预先指定的注解项目，设置针对该评价信息的注解信息；

本申请实施例中，预先指定的注解项目可以但不限于包括以下内容：

Persistent（持久化）：对于该注解项目，服务器需设置的注解为：该评价信息是否需要在HBase中持久化。

Table（表）：对于该注解项目，服务器需设置的注解为：HBase中用于存户持久化的该评价信息的表的元信息。该些元信息可以但不限于包括表名，表包含的列族，表中预先划分的区域（region）等。

Column Family（列族，是构成表的元素，往往由多个列组成）：对于该注解项目，服务器需设置的注解为列族的存储特性，包括：TTL（Time To Live，数据的存活时间，数据的存储时间长度超过这个时间，数据就会被删除）、最大版本（可以保持的同一数据的版本的最大个数）及用于确定存储在列族中的数据是否进行压缩的信息等；

Column（列，是构成列族的元素）：对于该注解项目，服务器需设置的注解为：评价信息的属性值是否需要持久化、存储映射关系（该映射关系是指存储评价信息的列族和评价信息之间的映射关系）的列的标识信息、qualifier和由评价信息的属性值所生成的行键（RowKey）所包含用于描述各个属性值的字符个数。其中，以上述评价信息为例，该评价信息的属性值可以是该评价信息对应的用户ID、商品ID和评价时间等属性的具体数值。

Key Field（关键领域）：对于该注解项目，服务器需设置的注解为：评价信息的属性值是否被用作生成Rowkey、以及存储评价信息时所采用的数据排序方式（正序或倒序）；

RowKey：对于该注解项目，服务器需设置的注解为：Rowkey所包含的KeyField（这里所述的KeyField即生成Rowkey的属性值）和Rowkey的生成策略。现提供三种Rowkey生成策略：将评价信息的多个属性值转换成字符串并组合为Rowkey；对评价信息的多个属性值进行组合后取MD5，并以MD5作为Rowkey；将用于生成行键的属性值转换成字符串后再对字符串执行反转、组合操作，并以反转、组合后得到的字符串作为Rowkey。基于上述生成策略所生成的RowKey能体现用于生成该RowKey的属性值在HBase中的存储顺序。比如，假设生成某RowKey的属性为用户ID、商品ID和评价时间，且用户ID这一属性的具体数值为1，商品ID这一属性的具体数值为2，评价时间这一属性的具体数值为3，则按照第一种RowKey生成策略，其组合而成的Rowkey可以表示为1_2_3。该1_2_3表示的含义为：首先，该Rowkey是由用户ID、商品ID和评价时间这三个属性的具体数值1、2、3生成的；其次，用户ID、商品ID和评价时间的具体数值在HBase中的存储顺序为用户ID的具体数值存储在第一列、商品ID的具体数值存储在第二列，评价时间的具体数值存储在第三列。此外，第一种RowKey生成策略生成的Rowkey还可以调整为2_1_3，其除表示该Rowkey由用户ID、商品ID和评价时间这三个属性的具体数值1、2、3生成外，还表示：用户ID、商品ID和评价时间的具体数值在HBase中的存储顺序为用户ID的具体数值存储在第二列、商品ID的具体数值存储在第一列，评价时间的具体数值存储在第三列。

Index（索引）：对于该注解项目，服务器需设置的注解为：组成该索引的Rowkey所包含的KeyField，组成该索引的Rowkey的生成策略。

Indexes（索引集合）。对于该注解项目，服务器需设置的注解为：Indexes所包含的各个Index。

以上述评价信息为例，为了将该评价信息持久化至HBase，可以先根据上述注解项目设置相应的注解信息，具体的注解信息的伪代码如下：

步骤43，服务器中的HobjectManagerFactory模块根据针对评价信息所设置的注解信息，确定存储该评价信息的表名，并判断HBase是否存在以该表名命名的表，若不存在，则在HBase中设置以该表名命名的表。

比如，服务器根据针对Table这一注解项目所设置的注解信息，就可以确定存储该评价信息的表名。

步骤44，HobjectManagerFactory模块根据上述注解信息，从评价信息的属性值中，确定用于生成Rowkey的属性值，并根据上述注解信息，确定Rowkey的生成策略。

具体地，HobjectManagerFactory模块可以根据服务器所设置的针对RowKey这一注解项目的注解信息，确定用于生成Rowkey的评价信息的属性值和Rowkey的生成策略。

步骤45，HobjectManagerFactory模块按照确定的生成策略，根据确定的用于生成Rowkey的评价信息的属性值，生成Rowkey。

步骤46，HobjectManagerFactory模块将确定的用于生成Rowkey的属性值保存于HBase的comment表中，并根据comment表中的该些属性值的排列顺序，将生成的该Rowkey所包含的对应于该些属性值的字段的排列顺序，调整为与表中的该些属性值的排列顺序对应一致后，再在comment表中对应保存调整后的该Rowkey。为了便于描述，本申请实施例将执行上述调整后得到的Rowkey称为Rowkey1，该Rowkey1可以由1_2_3这样的字段表示。该字段中的1、2、3分别表示用户ID、商品ID和评价时间的具体数值，该字段中的1、2、3的排列顺序与HBase中存储的1、2、3的排列顺序对应一致。

以上述评价信息保存为例，通过执行上述步骤46，可以实现在HBase的comment表中对应保存评价信息的属性值和Rowkey1。具体地，comment表可以采用如下表1的格式：

表1：

可选的，表1中可以冗余保存除生成Rowkey的属性值外的其他属性值，如commentContent。

本申请实施例中，如需要针对存储在HBase中的该评价信息设置有效期，则HobjectManagerFactory模块可以根据TTL和针对该评价信息所设置的“对象失效时间戳”，生成该评价信息的保存时间戳。该保存时间戳所指示的时间段即该评价信息的有效期。具体地，保存时间戳的计算方式可以采用如下式[1]所示的公式：

保存时间戳=对象失效时间戳-TTL*1000     [1]

其中，TTL为针对Column Family这一注解项目所设置的注解信息。

HobjectManagerFactory模块在计算出针对该评价信息的保存时间戳后，可以通过Java Client API实现将该保存时间戳也保存于如图1所示的comment表中。

步骤47，HobjectManagerFactory模块在判断出注解信息中包含针对Index这一注解项目的注解信息时，在HBase中的索引表comment idx nid中对应存储通过执行步骤45生成的Rowkey和用于生成该Rowkey的属性值。本申请实施例中，HBase中的索引表可以是服务器根据注解信息，判断出需设置针对Index这一注解项目的注解信息后设置的。该索引表即HBase中的一个存储空间。

本申请实施例中，HobjectManagerFactory模块一般会先将用于生成Rowkey的属性值存储到该索引表comment_idx_nid中，然后与步骤46类似的，HobjectManagerFactory模块再根据索引表commenL_idx_nid中保存该些属性值的排列顺序，将由该些属性值生成的Rowkey中对应于该些属性值的字段的排列顺序，调整为与comment_idx_nid中保存的属性值的排列顺序对应一致后，再在索引表comment_idx_nid中对应保存调整后的该Rowkey。为了与上文中的Rowkey1相区分，本申请实施例将存储于索引表comment_idx_nid中的该Rowkey称为Rowkey2。

以上述评价信息保存为例，通过执行步骤47，可以实现在HBase的索引表comment_idx_nid中对应保存评价信息的属性值和Rowkey2。具体地，表comment_idx_nid可以采用如下表2的格式：

表2：

可选的，表2中还可以冗余保存除生成Rowkey的属性值外的其他属性值，如commentContent。本申请实施例中，还可以在该索引表comment_idx_nid中存储如表3所示的属性值和Rowkey3。

表3：

用于表示Rowkey3的3_2_1的具体含义与前文所介绍的用于表示Rowkey1的123的含义类似，在此不再赘述。

或者，本申请实施例中还可以在该索引表comment_idx_nid中存储如表4所示的属性值和Rowkey4。

表4：

用于表示Rowkey4的231的具体含义与前文所介绍的用于表示Rowkey1的123的含义类似，在此不再赘述。

基于上述表1~4，以下通过对下述步骤的介绍，具体说明对HBase中保存的评价信息的查询过程。

步骤48，服务器通过Query接口，获得查询条件。

针对HBase的查询条件一般是HQL语句。

步骤49，服务器通过对获得的查询条件的解析，确定针对待查询的评价信息的最优查询计划（QueryPlan）。

具体地，步骤49的具体实现过程可以包括下述子步骤：

子步骤1：服务器分别确定用于保存评价信息的表中存储的Rowkey和索引表中存储的Rowkey，为了区分存储评价信息的表中存储的Rowkey和索引表中存储的Rowkey，前者可以称为注释表Rowkey，而后者则可以称为索引表Rowkey；

子步骤2：服务器根据注释Rowkey（即主表行键）和索引Rowkey（即索引表行键），分别确定生成注释Rowkey、索引Rowkey的评价信息的属性值所构成的属性值集合，为了区分分别生成注释Rowkey、索引Rowkey的评价信息的属性值所构成的属性值集合，下文将生成注释Rowkey的评价信息的属性值所构成的属性值集合称为第一属性值集合，而将生成索引Rowkey的评价信息的属性值所构成的属性集合称为第二属性值集合，其中，第一属性值集合所包含的属性值与第二属性值集合所包含的属性值可能完全相同，也可能完全不同，还可能部分相同；

子步骤3：服务器通过对查询条件的解析，从该查询条件中确定出其所包含的待查询的评价信息的属性值；

比如，若用户需要查询持久化于HBase中的前述评价信息，则通过用户终端输入服务器的查询条件往往会包含该评价信息的属性值，如用户ID、商品ID、评价时间和/或评价信息的内容等属性的具体数值。服务器通过对查询条件的解析，可以从中解析出相应的属性值。根据实际情况，从查询条件中解析出的评价信息的属性值可能为一个，也可能为多个。

子步骤4：服务器比较第一属性值集合、第二属性值集合和从查询条件中解析出的待查询的评价信息的属性值；

子步骤5：服务器根据执行上述比较而得到的比较结果，从解析出的属性值中，确定与第一属性值集合所包含的属性值匹配一致的属性值，并确定与第二属性值集合所包含的属性值匹配一致的属性值，以及确定与第一属性值集合或第二属性值集合所包含的属性值均匹配不一致的属性值；

本申请实施例中，比较不同属性值以确定其是否匹配一致的伪代码可以如下：

为了便于描述，下文将从解析出的属性值中确定的、与第一属性值集合所包含的属性值匹配一致的属性值所构成的集合称为第一KeyTerms，并将从解析出的属性值中确定的、与第一属性值集合所包含的属性值匹配不一致的属性值所构成的集合称为第一NonKeyTerms；将从解析出的属性值中确定的、与第二属性值集合所包含的属性值匹配一致的属性值所构成的集合称为第二KeyTerms，并将从解析出的属性值中确定的、与第二属性值集合所包含的属性值匹配不一致的属性值所构成的集合称为第二NonKeyTerms。

子步骤6：本申请实施例中，假设不同KeyTerms（如上述第一KeyTerms、第二KeyTerms）分别代表不同的QueryPlan，则服务器通过比较确定出的各个KeyTerms，就可以确定最优的QueryPlan；

具体地，针对上述第一KeyTerm和第二KeyTerms，服务器可以按照如下规则来选择最优QueryPlan：

首先，确定第一KeyTerm所包含的属性值的个数（下文简称为第一个数）和第二KeyTerms所包含的属性值的个数（下文简称为第二个数）；

然后，通过比较第一个数和第二个数，确定较大的个数对应的KeyTerm，KeyTerm（第一KeyTerm或第二KeyTerm）中包含的属性值的个数越多，说明相应的表中更加可能存在与查询条件更为匹配的评价信息；

最后，选取确定的该KeyTerm所代表的QueryPlan作为最优QueryPlan。

需要说明的是，针对第一KeyTerm和第二KeyTerms分别包含的属性值的个数相同的情况，则可以根据第一KeyTerm和第二KeyTerms分别对应的表的类型来确定选取的最优QueryPlan。具体确定规则是：选取对应于存储评价信息的comment表作为待查询的表，从而以“查询选取的对应于存储评价信息的表”作为最优QueryPlan。

此外需要说明的是，在第一个数小于第二个数时，若此时存在多个待选择的第二KeyTerms，且该些第二KeyTerms都包含第二个数的属性值，则最优QueryPlan的选取规则为：

首先，根据预先指定的属性，从解析出的属性值中确定对应于预先指定的该属性的属性值，为便于描述，后文将确定出的该对应于预先指定的属性的属性值称为指定属性值，其中，该指定属性值相当于是优先与HBase中存储的评价信息进行匹配的属性值；

由于用户所输入的查询条件往往是针对自己评价过的商品的，因此查询条件中常包含用户ID或商品ID的属性值。鉴于此，可以将用户ID、商品ID设置为预先指定的属性，从而后续可以优先利用相应的指定属性值进行与存储的评价信息的匹配操作。需要说明的是，虽然根据评价时间也能最终定位到用户欲查询的评价信息，但由于根据评价时间对评价信息进行查询时，面向的是海量用户在该同一评价时间做出的海量评价信息，因此根据评价时间进行查询不利用快速定位到欲查询的评价信息，从而往往不将评价时间设置预先指定的属性。

然后，从各个第二KeyTerms分别对应的索引Rowkey中，确定包含的第一个字段所对应的属性值与所述指定属性值匹配一致的索引Rowkey；

由于如前文所述，每个Rowkey都能体现其所对应的表中存储的属性值的存储顺序，而针对HBase所存储的信息的查询正是按照列的排列顺序依次对各列中保存的数据进行查询的，因此，针对确定出的指定属性值，可以先确定出将该指定属性值存储在第一列的索引表，以便尽快从表中查询到与指定属性值匹配的属性值。

最后，将确定的索引Rowkey所对应的索引表作为待查询的索引表，并将“查询该待查询的索引表”作为确定出的最优QueryPlan。一般地，确定出的索引Rowkey可能有多个。

通过对步骤49的执行，实际上达到的目的是从HBase中存储的海量的表中确定出一些待查询的表，以缩小查询范围。

步骤410，服务器根据从查询条件中解析出的属性值，对最优QueryPlan所对应的表进行查询，并通过查询，获得包含有解析出的属性值的各条评价信息，流程结束。

具体地，当最优QueryPlan所对应的待查询的表为存储评价信息的comment表时，服务器执行比较该comment表中的各个注释Rowkey与从查询条件中解析出的属性值的操作，并通过比较，确定包含有从查询条件中解析出的所有属性值的注释Rowkey（下文将包含有从查询条件中解析出的所有属性值的Rowkey简称为目标Rowkey）。基于HBase针对同一评价信息的属性值的存储规则（同一评价信息的各个属性值会被分别存储在表的同一行的不同列中），服务器就可以从该目标Rowkey所在行中，获取生成该目标Rowkey的所有属性值，以及冗余保存在表中的其他属性值。由于获得的该些属性值可以唯一定义一个评价信息，因此至此服务器完成了对评价信息的查找。

而当最优QueryPlan所对应的待查询的表为索引表comment_idx_nid时，服务器执行比较该索引表comment_idx_nid中的各个索引Rowkey与从查询条件中解析出的属性值的操作，并通过比较，确定出目标Rowkey。基于HBase针对同一评价信息的属性值的上述存储规则，服务器就可以从该目标Rowkey所在行中，获取生成该目标Rowkey的所有属性值，以及冗余保存在表中的其他属性值，从而实现对评价信息的查找。

在实际应用中，服务器根据目标Rowkey所获取到的评价信息还可能包含未用于生成该目标Rowkey的属性值。此时为了进一步保证获取到的属性值与查询条件的匹配程度，可以利用前文所述的第一NonKeyTerms和第二NonKeyTerms（合称NonKeyTerms）对获取到的评价信息进行筛选。具体地，服务器通过比较获取到的评价信息和NonKeyTerms中的属性值，可以确定出包含NonKeyTerms中的属性值的评价信息，从而以该些评价信息作为最终的查询结果。针对包含NonKeyTerms中的属性值的评价信息有多条的情况，可以进一步比较该些评价信息所包含的与NonKeyTerms中的属性值匹配一致的属性值的个数，并以最大的该个数对应的评价信息作为最终的查询结果。

通过本申请实施例提供的上述方案在实际中的应用，可以提供基于HBase存储特性的注解信息，以描述持久化存储在HBase中的信息的元信息。基于该注解信息，可以方便地持久化和获取业务实体对象，简化HBase Client API的使用。通过上述应用，可以建立并自动维护索引表，并支持对查询条件的分析以及按Rowkey实现业务实体对象的快速查询。

对应于本申请实施例提供的信息持久化方法，本申请实施例还提供一种应用于key-value数据库的信息持久化装置。该装置的具体结构示意图如图5所示，包括以下功能单元：

第一注解信息解析单元51，用于根据针对业务实体对象设置的注解信息，确定存储该业务实体对象的主表、主表行键生成策略和用于生成主表行键的第一属性；

第一属性值确定单元52，用于确定该业务实体对象所包含的、与第一注解信息解析单元51确定的第一属性对应的属性值；

第一属性值存储单元53，用于按照在不同列中存储不同属性值的存储方式，将第一属性值确定单元52确定的属性值，分别存储到注解信息解析单元确定的主表的同一行的不同列中；

主表行键生成单元54，用于根据主表中存储的由第一属性值确定单元52确定的属性值在其所在行中的第一排列顺序、第一注解信息解析单元51单元确定的主表行键生成策略以及第一属性值确定单元52确定的属性值，基于按照第一排列顺序排列主表行键中包含的字段所对应的属性值的方式，生成主表行键。

可选的，当主表中存储属性值的列不包括第一列时，上述装置还可以进一步包括主表行键存储单元55，其主要用于主表行键与用于生成主表行键的属性值的对应关系，将主表行键生成单元54生成的主表行键存储到相应的属性值所在行的第一列中。

在需要存储不同版本的业务实体对象的场景下，上述装置还可以进一步包括以下功能单元：

第二注解信息解析单元，用于根据注解信息，确定存储该业务实体对象的索引表、索引表行键生成策略和用于生成索引表行键的第二属性；

第二属性值确定单元，用于确定该业务实体对象所包含的与第二注解信息解析单元确定的第二属性对应的属性值；

第二属性值存储单元，用于按照在不同列中存储不同属性值的存储方式，将第二属性值确定单元确定的属性值分别存储到索引表的同一行的不同列中；

索引表行键生成单元，用于根据索引表中存储的第二属性对应的属性值在其所在行中的第二排列顺序、第二注解信息解析单元确定的索引表行键生成策略以及第二属性值确定单元确定的属性值，基于按照第二排列顺序排列索引表行键中包含的字段所对应的属性值的方式，生成索引表行键。

可选的，当索引表中存储第二属性对应的属性值的列不包括第一列时，上述装置还可以进一步包括索引表行键存储单元，其主要用于根据索引表行键与用于生成索引表行键的属性值的对应关系，将索引表行键生成单元生成的各索引表行键对应存储到相应的属性值所在行的第一列中。

本申请实施例提供的上述装置针对任一业务实体对象，将该业务实体对象的属性值分别存储到数据表的同一行的不同列中，并将基于该目标的属性值而生成的行键存储到该行的第一列中。由于HBase等key-value数据库是基于列的存储模式来实现信息的持久化，而该方案正是将对应于同一业务实体对象的属性值存储在同一行的不同列中，并将作为业务实体对象查询依据的行键存储到第一列以便于后续查找，因此，相比于现有技术提供的针对关系数据库的信息持久化方案，本申请实施例提供的该装置更能够匹配于key-value数据库关于存储模式的特性。

对应于本申请实施例提供的面向对象的查询方法，本申请实施例还提供一种基于上述信息持久化方法或装置的信息查询装置。该装置的具体结构示意图如图6所示，包括以下功能单元：

查询条件解析单元61，用于通过对针对业务实体对象的查询条件的解析，获得查询条件包含的属性值；

第一集合确定单元62，用于根据指定属性和查询条件解析单元61获得的查询条件中包含的属性值，判断出查询条件中包含对应于指定属性的指定属性值时，针对数据表中存储的各个行键，执行分别确定生成该行键的属性值所构成的第一属性值集合；

第二集合确定单元63，用于从第一集合确定单元62确定的第一属性值集合中，确定包含有查询条件所包含的指定属性值的第一属性值集合；

行键确定单元64，用于从第二集合确定单元63确定的第一属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的行键；

查询单元65，用于根据查询条件解析单元61获得的属性值，查询行键确定单元64确定的行键所在的数据表的行中存储的属性值。

可选的，为了提供与查询条件匹配度较高的业务实体对象，上述信息查询装置还可以进一步包括：

属性值确定单元，用于从查询条件解析单元获得的属性值中，确定不属于任意第一属性值集合的属性值；

第三集合确定单元，用于从查询单元查询到的对应于不同行键的属性值所分别构成的第二属性值集合中，确定包含属性值确定单元确定的属性值的第二属性值集合；

业务实体对象生成单元，用于针对包含第三集合确定单元确定的各第二属性值集合，执行根据该第二属性值集合中包含的属性值，生成业务实体对象。

可选的，为了在保证查询结果准确性的前提下缩小查询范围，以及为了提高查询效率，如图6所示的装置还可以进一步包括：第四集合确定单元，用于从第二集合确定单元确定的第一属性值集合中，确定包含与查询条件所包含的属性值匹配一致的属性值的个数最多的目标属性值集合。在该装置包括第四集合确定单元的前提下，行键确定单元64具体可以用于：从第四集合确定单元确定的目标属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的表行键。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (12)

1.一种应用于key-value数据库的信息持久化方法，其特征在于，包括：

根据针对业务实体对象设置的注解信息，确定存储该业务实体对象的主表、主表行键生成策略和用于生成主表行键的第一属性；

确定该业务实体对象所包含的与第一属性对应的属性值，并按照在不同列中存储不同属性值的存储方式，将确定的属性值分别存储到主表的同一行的不同列中；

根据主表中存储的属性值在其所在行中的第一排列顺序、主表行键生成策略以及所述确定的属性值，生成主表行键。

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

根据所述注解信息，确定存储该业务实体对象的索引表、索引表行键生成策略和用于生成索引表行键的第二属性；

确定该业务实体对象所包含的与第二属性对应的属性值，并按照在不同列中存储不同属性值的存储方式，将确定的与第二属性对应的属性值分别存储到索引表的同一行的不同列中；

根据索引表中存储的第二属性对应的属性值在其所在行中的第二排列顺序、索引表行键生成策略以及第二属性对应的属性值，基于按照第二排列顺序排列索引表行键中包含的字段所对应的属性值的方式，生成索引表行键。

3.如权利要求1所述的方法，其特征在于，主表中存储属性值的列不包括第一列；则

所述方法还包括：根据主表行键与用于生成主表行键的属性值的对应关系，将生成的各个主表行键对应存储到相应的属性值所在行的第一列中。

4.一种基于权1~3任一所述的信息持久化方法的面向对象的查询方法，其特征在于，包括：

获得针对业务实体对象的查询条件，并通过对查询条件的解析，获得查询条件包含的属性值；

根据指定属性和查询条件中包含的属性值，判断出查询条件中包含对应于指定属性的指定属性值时，针对数据表中存储的各个行键，执行分别确定生成该行键的属性值所构成的第一属性值集合；

确定包含有查询条件所包含的指定属性值的第一属性值集合；

从确定的包含有查询条件所包含的指定属性值的第一属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的行键；以及

根据查询条件中包含的属性值，查询确定的行键所在的数据表的行中存储的属性值。

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

从查询条件所包含的属性值中，确定不属于任意第一属性值集合的属性值；则

根据查询条件中包含的属性值，查询确定的行键所在的数据表的行中存储的属性值之后，还包括：

从查询到的对应于不同行键的属性值所分别构成的第二属性值集合中，确定包含确定的不属于任意第一属性值集合的属性值的第二属性值集合；

针对包含确定的不属于任意第一属性值集合的属性值的各第二属性值集合，执行根据该第二属性值集合中包含的属性值，生成业务实体对象。

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

从确定的包含有查询条件所包含的指定属性值的第一属性值集合中，确定包含与查询条件所包含的属性值匹配一致的属性值的个数最多的目标属性值集合；则

从确定的包含有查询条件所包含的指定属性值的第一属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的表行键，具体包括：

从确定的目标属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的表行键。

7.一种应用于key-value数据库的信息持久化装置，其特征在于，包括：

第一注解信息解析单元，用于根据针对业务实体对象设置的注解信息，确定存储该业务实体对象的主表、主表行键生成策略和用于生成主表行键的第一属性；

第一属性值确定单元，用于确定该业务实体对象所包含的、与第一注解信息解析单元确定的第一属性对应的属性值；

第一属性值存储单元，用于按照在不同列中存储不同属性值的存储方式，将第一属性值确定单元确定的属性值，分别存储到注解信息解析单元确定的主表的同一行的不同列中；

主表行键生成单元，用于根据主表中存储的所述确定的属性值在其所在行中的第一排列顺序、第一注解信息解析单元单元确定的主表行键生成策略以及第一属性值确定单元确定的属性值，基于按照所述第一排列顺序排列主表行键中包含的字段所对应的属性值的方式，生成主表行键。

8.如权利要求7所述的装置，其特征在于，还包括：

第二注解信息解析单元，用于根据所述注解信息，确定存储该业务实体对象的索引表、索引表行键生成策略和用于生成索引表行键的第二属性；

第二属性值确定单元，用于确定该业务实体对象所包含的与第二注解信息解析单元确定的第二属性对应的属性值；

第二属性值存储单元，用于按照在不同列中存储不同属性值的存储方式，将第二属性值确定单元确定的属性值分别存储到索引表的同一行的不同列中；

索引表行键生成单元，用于根据索引表中存储的第二属性对应的属性值在其所在行中的第二排列顺序、第二注解信息解析单元确定的索引表行键生成策略以及第二属性值确定单元确定的属性值，基于按照第二排列顺序排列索引表行键中包含的字段所对应的属性值的方式，生成索引表行键。

9.如权利要求7所述的装置，其特征在于，主表中存储属性值的列不包括第一列；则

所述装置还包括：

主表行键存储单元，用于根据主表行键与用于生成主表行键的属性值的对应关系，将主表行键生成单元生成的各主表行键对应存储到相应的属性值所在行的第一列中。

10.一种基于权7~9任一所述的信息持久化装置的面向对象的信息查询装置，其特征在于，包括：

查询条件解析单元，用于通过对针对业务实体对象的查询条件的解析，获得查询条件包含的属性值；

第一集合确定单元，用于根据指定属性和查询条件解析单元获得的查询条件中包含的属性值，判断出查询条件中包含对应于指定属性的指定属性值时，针对数据表中存储的各个行键，执行分别确定生成该行键的属性值所构成的第一属性值集合；

第二集合确定单元，用于从第一集合确定单元确定的第一属性值集合中，确定包含有查询条件所包含的指定属性值的第一属性值集合；

行键确定单元，用于从第二集合确定单元确定的第一属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的行键；

查询单元，用于根据查询条件解析单元获得的属性值，查询行键确定单元确定的行键所在的数据表的行中存储的属性值。

11.如权利要求10所述的装置，其特征在于，还包括：

属性值确定单元，用于从查询条件解析单元获得的属性值中，确定不属于任意第一属性值集合的属性值；

第三集合确定单元，用于从查询单元查询到的对应于不同行键的属性值所分别构成的第二属性值集合中，确定包含属性值确定单元确定的属性值的第二属性值集合；

业务实体对象生成单元，用于针对包含第三集合确定单元确定的各第二属性值集合，执行根据该第二属性值集合中包含的属性值，生成业务实体对象。

12.如权利要求10所述的装置，其特征在于，还包括：

第四集合确定单元，用于从第二集合确定单元确定的第一属性值集合中，确定包含与查询条件所包含的属性值匹配一致的属性值的个数最多的目标属性值集合；则

所述行键确定单元具体用于：从第四集合确定单元确定的目标属性值集合所对应的行键中，确定包含的第一个字段所对应的属性值与查询条件包含的指定属性值匹配一致的表行键。

Images