CN116108049A

CN116108049A - 一种多索引连接检索方法、系统及装置

Info

Publication number: CN116108049A
Application number: CN202310072011.XA
Authority: CN
Inventors: 张安; 龚宇波; 辛润雪
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2023-01-12
Filing date: 2023-01-12
Publication date: 2023-05-12

Abstract

一种多索引连接检索方法，包括：根据辅表搜索条件查询辅表，得到第一辅表结果集；根据辅表与主表之间的文档关联映射表，将第一辅表结果集转化为第一主表结果集，根据主表搜索条件查询主表，得到第二主表结果集；将第二主表结果集中的主表文档与第一主表结果集中的主表文档进行比较，得到第三主表结果集；根据第三主表结果集查找文档关联映射表和第一辅表结果集，得到第二辅表结果集，将第三主表结果集和第二辅表结果集中的文档进行拼接，得到满足查询语句的查询结果集。在检索时，使用预先构建的各个辅表与主表之间的JoinDocMap获取相关文档信息，避免了连接查询执行中的多轮子查询造成的执行效率，大大提升了多索引连接检索的执行效率。

Description

一种多索引连接检索方法、系统及装置

技术领域

本发明涉及数据库查询领域,尤其涉及一种多索引连接检索方法、系统及装置。

背景技术

在数据库领域中，具有相同结构的文档通常存储在一张数据表中，即每一行为一个数据记录(在检索领域一般称数据记录为文档)，每一列是一个字段。用户在数据库中进行查询时，通常需要在这样的数据表上进行查询，找到满足条件的文档。为了避免扫描匹配这种低效率查找，数据库通常会针对数据表中的各个字段构建索引。例如，B+树、倒排索引等，以加速用户查询。在数据分析等领域，用户对海量数据下的相关性检索的需求更为强烈，通常数据库更侧重存储，而检索引擎通过对输入数据构建更加全面的索引，提供诸如倒排文本检索、向量检索等更加深度的索引检索手段和相关性计算手段，更适合处理这种相关性检索的需求。

目前绝大多数检索引擎都聚焦在如何针对一个数据表构建单索引进行检索，在分布式多索引之间的连接查询计算上还没有很高效解决方案。

发明内容

本申请提供了一种多索引连接检索方法、系统、装置、计算机可读介质以及计算机程序产品。在检索时，使用预先构建的各个辅表与主表之间的JoinDocMap获取相关文档信息，避免了连接查询执行中的多轮子查询造成的执行效率，大大提升了多索引连接检索的执行效率。

第一方面，本申请提供了一种多索引连接检索方法，包括：获取用户输入的查询语句，查询语句中包括：数据库中主表的搜索条件和辅表的搜索条件；基于主表中文档和辅表中文档间的文档关联映射表，将第一辅表结果集转化为第一主表结果集，其中，第一辅表结果集通过辅表的搜索条件查询辅表得到，文档关联映射表用于标识主表中的主表文档与辅表中的辅表文档之间的映射关系；基于第一主表结果集和第二主表结果集共同包含的文档的集合，得到第三主表结果集，其中，第二主表结果集通过主表的搜索条件查询主表得到；基于第一辅表结果集和第二辅表结果集共同包含的文档的集合，得到第三辅表结果集，第二辅表结果集通过第三主表结果集查找关联映射表得到；将第三主表结果集中的文档和第三辅表结果集中的文档进行拼接，并输出拼接后得到的结果集。

也就是说，检索引擎在根据用户输入的查询语句在数据库中的多个表中进行查询时，可以先根据查询语句中的辅表搜索条件，从辅表中获取满足辅表搜索条件的第一辅表结果集，以及根据主表查询条件从主表中获取满足主表搜索条件的第二主表结果集。然后，根据辅表和主表之间的文档关联映射表，可以将第一辅表结果集映射为主表中的文档结果集，即第一主表结果集。通过生成的第一主表结果集对第二主表结果集中的文档进行筛选，得到既满足主表搜索条件又与满足辅表搜索条件的辅表文档关联的主表文档集合，即第三主表集合。然后，对于满足主表搜索条件的第二主表集合，可以根据辅表和主表之间的文档关联映射表，得到与第二主表集合中的主表文档关联的辅表文档集合，即第二辅表结果集。由于第二辅表结果集中的辅表文档不一定满足辅表搜索条件，因此，可以将第一辅表结果集和第二辅表结果集取交集，以得到第二辅表结果集中满足辅表搜索条件的辅表文档集，即第三辅表文档集。最后将第三主表结果集中的文档和第三辅表结果集中的文档进行拼接，可以得到满足用户输入的查询条件的结果集。即，针对具有连接关系的数据表(比如主表和辅表)，使用预先构建的文档关联映射表，使得检索引擎可以使用为各个数据表各自创建的索引就可以执行多个索引之间的连接查询，而不必构建宽表索引。并且在执行过程中，各个索引之间的文档关联关系使用文档关联映射表进行“预计算”，避免了现有技术中在执行连接查询的过程中在线计算文档关联关系，以及避免了连接查询执行中的多轮子查询造成的执行效率，大大提升了多索引连接检索的执行效率。

在一个可能的实现方式中，在基于主表中文档和辅表中文档间的文档关联映射表，将第一辅表结果集转化为第一主表结果集之前，该方法还包括：根据主表和辅表之间的关联关系，得到主表中的主表文档和辅表中的辅表文档之间的文档关联关系；根据文档关联关系，得到主表和辅表之间的文档关联映射表。

也就是说，在根据用户输入的查询语句进行检索之前，还需要构建需要检索的各关数据表(主要是辅表和主表)之间的索引的关联关系，并将该关联关系存储到文档关联映射表中。其中，文档关联映射表是一个映射结构，表达两个数据表的文档之间的关联关系。它的key为其中一个索引的文档的id，va l ue为另一个索引中与该文档相关联的文档列表。

在一个可能的实现方式中，文档关联映射表包括：正向文档关联映射表和逆向文档关联映射表，正向文档关联映射表中的key值为主表文档id，va l ue值为辅表文档id列表，逆向文档关联映射表中的key值为辅表文档id，va l ue值为主表文档id列表。

也就是说，在辅表和主表之间存在两种文档关联映射表，即一种为主表文档id为key，与主表关联的辅表文档id列表为va l ue，称为正向文档关联映射表。一种为辅表文档id为key，与辅表关联的主表文档id列表为va l ue，称为逆向文档关联映射表。

在一个可能的实现方式中，基于主表中文档和辅表中文档间的文档关联映射表，将第一辅表结果集转化为第一主表结果集，包括：根据辅表与主表之间的逆向文档关联映射表，将第一辅表结果集转化为第一主表结果集。

也就是说，在将得到的第一辅表结果集转化为第一主表结果集时，可以根据辅表和主表之间正向文档关联映射表，将第一辅表结果集中的辅表文档id映射为主表文档id，即得到第一主表结果集。

在一个可能的实现方式中，第二辅表结果集通过第三主表结果集查找辅表与主表之间的正向文档关联映射表得到。

也就是说，在得到第三主表结果集以后，可以根据辅表和主表之间逆向文档关联映射表，得到与第三主表结果集中的主表文档id关联的辅表文档id，即得到第二辅表结果集。

在一个可能的实现方式中，该方法还包括：对目标表中的文档进行更新，对目标表中的文档进行更新包括：在目标表中增加第一文档、在目标表中删除第二文档、或者更新目标表中的第三文档中的部分字段，其中，目标表为主表或辅表；根据目标表中发生更新的文档，更新目标表对应的文档关联映射表。

也就是说，在构建辅表与主表之间的文档关联映射表以后，在主表或者辅表中的文档发生变化以后，还需要同步更新对应的文档关联映射表，以保证文档关联映射表和对应主表或者辅表中的数据、索引内容的一致性。

在一个可能的实现方式中，若在目标表中删除了第二文档，根据目标表中发生更新的文档，更新目标表对应的文档关联映射表，包括：在目标文档对应的文档关联映射表中，删除第二文档以及与第二文档关联的辅表文档。

也就是说，在主表或者辅表删除表中文档数据的情况下，需要同步删除主表或者辅表对应的文档关联映射表中的被删除文档对应的文档id。

在一个可能的实现方式中，目标表为主表；若在主表中增加了第一文档，根据主表中发生更新的文档，更新目标表的文档关联映射表，包括：根据第一文档，生成辅表上的第一查询条件；根据第一查询条件查询辅表，得到辅表中与第一文档关联的文档集合；根据文档集合和第一文档，更新主表与辅表之间的文档关联映射表。

也就是说，在目标表为主表且主表中增加了第一文档的情况下，可以根据增加的第一文档生成与主表关联的辅表上的第一查询条件。然后，根据第一查询条件查询对应的辅表，得到辅表中与第一文档关联的辅表文档集合。最后，可以根据该文档集合更新主表与辅表之间的正向文档关联映射表和逆向文档关联映射表。

在一个可能的实现方式中，目标表为主表，若更新主表中的第三文档中的部分字段，根据目标表中发生更新的文档，更新目标表对应的文档关联映射表，包括：在第三文档更新的字段为与辅表有关联关系的情况下，在主表与辅表的文档关联映射表中，删除第三文档以及与第三文档关联的辅表文档；根据更新后的第三文档，生成辅表上的第二查询条件；根据第二查询条件查询辅表，得到辅表中与第三文档关联的文档集合；根据文档集合和更新后的第三文档，更新主表与辅表之间的文档关联映射表。

也就是说，在目标表为主表且主表中的第三文档数据发生了更新的情况下，首先判断主表中更新的数据是否涉及主表与其他辅表关联条件中的字段。如果不涉及关联字段，即主表和辅表之间的连接关系不变，即不需要对主表与辅表的文档关联映射表进行更新。如果涉及关联字段，即主表和辅表之间的连接关系会发生改变。因此，需要对主表和辅表之间的文段关联映射表进行更新。

在一个可能的实现方式中，目标表为辅表，若在辅表中增加了第一文档，根据目标表中发生更新的文档，更新目标表对应的文档关联映射表，包括：根据第一文档，生成主表上的第三查询条件；根据第三查询条件查询主表，得到主表中与第一文档关联的文档集合；根据文档集合和第一文档，更新主表与辅表之间的文档关联映射表。

也就是说，在目标表为辅表且辅表中增加了第一文档的情况下，可以根据增加的第一文档生成与辅表关联的主表上的第一查询条件。然后，根据第一查询条件查询对应的主表，得到主表中与第一文档关联的主表文档集合。最后，可以根据该文档集合更新辅表与主表之间的正向文档关联映射表和逆向文档关联映射表。

在一个可能的实现方式中，目标表为辅表，若更新主表中的第三文档中的部分字段，根据目标表中发生更新的文档，更新目标表对应的文档关联映射表，包括：在第三文档更新的字段为与主表有关联关系的情况下，在主表与辅表的文档关联映射表中，删除第三文档以及与第三文档关联的主表文档；根据更新后的第三文档，生成主表上的第四查询条件；根据第四查询条件查询主表，得到主表中与第三文档关联的文档集合；根据文档集合和更新后的第三文档，更新主表与辅表之间的文档关联映射表。

也就是说，在目标表为辅表且辅表中的第三文档数据发生了更新的情况下，首先判断辅表中更新的数据是否涉及辅表与主表关联条件中的字段。如果不涉及关联字段，即辅表和主表之间的连接关系不变，即不需要对辅表与主表的文档关联映射表进行更新。如果涉及关联字段，即辅表和主表之间的连接关系会发生改变。因此，需要对辅表和主表之间的文段关联映射表进行更新。

第二方面，本申请提供了一种检索系统，包括：

接收模块，用于获取用户输入的查询语句，查询语句中包括：数据库中主表的搜索条件和辅表的搜索条件；

处理模块，用于根据主表中文档和辅表中文档间的关联映射表，将第一辅表结果集转化为第一主表结果集，其中，第一辅表结果集通过辅表的搜索条件查询辅表得到，文档关联映射表用于标识主表中的主表文档与辅表中的辅表文档之间的映射关系；

处理模块，还用于根据第一主表结果集和第二主表结果集共同包含的文档的集合，得到第三主表结果集，其中，第二主表结果集通过主表的搜索条件查询主表得到；

处理模块，还用于根据第一辅表结果集和第二辅表结果集共同包含的文档的集合，得到第三辅表结果集，第二辅表结果集通过第三主表结果集查找关联映射表得到；

输出模块，用于将第三主表结果集中的文档和第三辅表结果集中的文档进行拼接，并输出拼接后得到的结果集。

在一个可能的实现方式中，在基于主表中文档和辅表中文档间的文档关联映射表，将第一辅表结果集转化为第一主表结果集之前，处理模块还用于：

根据主表和辅表之间的关联关系，得到主表中的主表文档和辅表中的辅表文档之间的文档关联关系；

根据文档关联关系，得到主表和辅表之间的文档关联映射表。

在一个可能的实现方式中，文档关联映射表包括：正向文档关联映射表和逆向文档关联映射表，正向文档关联表中的key值为主表文档id，va l ue值为辅表文档id列表，逆向文档关联关系中的key值为辅表文档id，va l ue值为主表文档id列表。

在一个可能的实现方式中，处理模块用于：

根据辅表与主表之间的逆向文档关联映射表，将第一辅表结果集转化为第一主表结果集。

在一个可能的实现方式中，处理模块还用于：

获取第二辅表结果集，第二辅表结果集通过第三主表结果集查找辅表与主表之间的正向文档关联映射表得到。

在一个可能的实现方式中，处理模块还用于：

对目标表中的文档进行更新，对目标表中的文档进行更新包括：在目标表中增加第一文档、在目标表中删除第二文档、或者更新目标表中的第三文档中的部分字段，其中，目标表为主表或辅表；

根据目标表中发生更新的文档，更新目标表对应的文档关联映射表。

在一个可能的实现方式中，若在目标表中删除了第二文档，处理模块用于：

在目标文档对应的文档关联映射表中，删除第二文档以及与第二文档关联的辅表文档。

在一个可能的实现方式中，目标表为主表，若在主表中增加了第一文档，处理模块用于：

根据第一文档，生成辅表上的第一查询条件；

根据第一查询条件查询辅表，得到辅表中与第一文档关联的文档集合；

根据文档集合和第一文档，更新主表与辅表之间的文档关联映射表。

在一个可能的实现方式中，目标表为主表，若更新主表中的第三文档中的部分字段，处理模块用于：

在第三文档更新的字段为与辅表有关联关系的情况下，在主表与辅表的文档关联映射表中，删除第三文档以及与第三文档关联的辅表文档；

根据更新后的第三文档，生成辅表上的第二查询条件；

根据第二查询条件查询辅表，得到辅表中与第三文档关联的文档集合；

根据文档集合和更新后的第三文档，更新主表与辅表之间的文档关联映射表。

在一个可能的实现方式中，目标表为辅表，若在辅表中增加了第一文档，处理模块用于：

根据第一文档，生成主表上的第三查询条件；

根据第三查询条件查询主表，得到主表中与第一文档关联的文档集合；

在一个可能的实现方式中，目标表为辅表，若更新主表中的第三文档中的部分字段，处理模块用于：

在第三文档更新的字段为与主表有关联关系的情况下，在主表与辅表的文档关联映射表中，删除第三文档以及与第三文档关联的主表文档；

根据更新后的第三文档，生成主表上的第四查询条件；

根据第四查询条件查询主表，得到主表中与第三文档关联的文档集合；

第三方面，本申请提供了一种检索装置，包括：

存储器，用于存储程序；

处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

第四方面，本申请实施例提供了一种计算机存储介质，计算机存储介质中存储有指令，当指令在计算机上运行时，使得计算机执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

第五方面，本申请实施例提供了一种包含指令的计算机程序产品，当指令在计算机上运行时，使得计算机执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例提供的一种主表和辅表之间的连接关系示意图；

图2为本申请实施例提供的一种查询语句的结构示意图；

图3为本申请实施例提供的一种多索引连接检索输出结果示意图；

图4为本申请实施例提供的一种宽表的结构示意图；

图5为本申请实施例提供的一种嵌套子文档的结构示意图；

图6为本申请实施例提供的一种嵌套子文档的检索流程图示意图；

图7为本申请实施例提供的一种基于BlockLookupJoin多索引连接检索流程图；

图8(a)为本申请实施例提供的一种应用场景示意图；

图8(b)为本申请实施例提供的另一种应用场景示意图；

图9为本申请实施例提供的一种电子设备的结构示意图；

图10为本申请实施例提供的一种服务器的结构示意图；

图11为本申请实施例提供的一种多索引连接检索系统的结构示意图；

图12为本申请实施例提供的一种在相互关联的两个数据表之间生成的JionDocMap的过程示意图；

图13(a)为本申请实施例提供的一种更新JoinDocMap中的关联关系的方法流程图；

图13(b)为本申请实施例提供的又一种更新JoinDocMap中的关联关系的方法流程图；

图14(a)为本申请实施例提供的一种更新JoinDocMap中的关联关系的方法流程图；

图14(b)为本申请实施例提供的又一种更新JoinDocMap中的关联关系的方法流程图；

图15为本申请实施例提供的一种基于两个索引的连接检索方法的流程示意图；

图16为本申请实施例提供的一种基于两个索引的连接检索流程示意图；

图17为本申请实施例提供的一种多索引连接检索方法的流程示意图；

图18为本申请实施例提供的一种多索引连接检索方法的流程示意图；

图19为本申请实施例提供的一种商品-广告-用户数据关联关系示意图；

图20为本申请实施例提供的一种Jo i nDocMap构建过程中对g1文档的处理过程示意图；

图21为本申请实施例提供的一种Jo i nDocMap构建过程示意图；

图22为本申请实施例提供的一种根据辅表搜索条件分别查询辅表的过程示意图；

图23为本申请实施例提供的一种根据主表搜索条件分别查询主表的过程示意图；

图24为本申请实施例提供的一种连接查询输出的结果集的示意图；

图25为本申请实施例提供的一种对JoinDocMap进行维护的流程示意图；

图26为本申请实施例提供的又一种对JoinDocMap进行维护的流程示意图；

图27为本申请实施例提供的又一种对JoinDocMap进行维护的流程示意图；

图28为本申请实施例提供的又一种对JoinDocMap进行维护的流程示意图；

图29为本申请实施例提供的一种检索装置的结构示意图；

图30为本申请实施例提供的一种芯片的结构示意图。

具体实施方式

为了使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图，对本申请实施例中的技术方案进行描述。

在本申请实施例中的描述中，“示例性的”、“例如”或者“举例来说”的任何实施例或设计方案不应该被理解为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”、“例如”或者“举例来说”等词旨在以具体方式呈现相关概念。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

在介绍本方案之前，首先对本方案中涉及的技术术语进行解释。

1、数据表：数据库领域中，具有相同结构的文档(即这些文档具有相同的模式schema)通常存储在一张数据表中，即每一行为一个数据记录(检索领域一般称数据记录为文档)，每一列是一个字段。

2、索引：即可查询的词，在检索引擎中被索引的词。在检索引擎中，查询一般是由句子组成的，对句子进行分词就可以得到一个term的有序序列，检索引擎的查询处理一般是以term为单位进行处理的。

3、Term：即可查询的词，在检索引擎中被索引的词。在检索引擎中，查询一般是由句子组成的，对句子进行分词就可以得到一个term的有序序列，检索引擎的查询处理一般是以term为单位进行处理的。

4、Doc：在信息检索领域中，可以将网页、条目等数据抽象化为文档(document)。文档是一个term的有序序列。在某些诸如网页搜索的场景下，doc还可以分为多个字段(field)，每个可分词的字段相互独立且都为term有序序列。每个文档在检索引擎中，通常都具有一个文档id，作为该文档的唯一身份标识。

5、文本检索：是一种文档的检索方式，通常用来在文档集合中找出满足用户指定过滤条件的文档集合。过滤条件一般是文档中包含的某些关键词，或者其它的文档属性比较条件，返回的满足条件的文档集合，通常需要以相关性排序后返回最相关的k个结果，相关性衡量用户查询和文档之间的相关程度，一般由检索引擎本身的实现和用户指定的输入决定。

6、倒排索引：是一种文档的索引方法，用来存储某个term在哪些文档中出现的映射关系，是一个doc id从小到大排列的有序列表，代表在这些doc中含有该倒排代表的term。例如term”A”在id为0,2,5的文档中出现，则A的倒排列表就可以表示为{0,2,5}。而为了能够找到文章中多个term组成的短语，我们还需要记录term在文档中的位置。假设A在文档0的11,25,46三个位置上出现，在文档2的54位置上出现，在文档5的14,39位置上出现，则我们就有了倒排列表{(0,<11,25,46>),(2,<54>),(5,<14,39>)}。同时，倒排链表还可以记录term在doc中出现的次数(词频)，以及其他term在doc上具有的一些属性(例如某个term在doc中不同位置出现均可以记录不同的属性)。检索引擎通过预先构建输入数据上的倒排索引结构，达到快速得在海量索引下检索的目的。

7、正排索引：是一种记录文档属性的索引方法，记录每个doc自身的静态属性信息，比如某个文档的网页质量、网页ur l、网页点击次数等等，多用于读取这些静态属性，作用于相关性打分的过程中。

8、连接关系：在实际应用中，数据分析通常涉及多个数据表(索引)之间的联合分析，数据表(索引)之间的数据通常以某种关联关系连接在一起。例如数据库领域的外键概念，就是一种“一对一”的连接关系，外键作为一个索引中文档的一个属性，表达在另外一个数据表(索引)中，与该文档关联的那条数据的主键。除外键以外，还存在更多更灵活的连接关系，例如索引之间以一种固定的查询关系连接，即针对某表内某个文档x的各个字段的值，构建在其它关联索引上的查询，在关联索引上满足查询条件的文档就是与该文档x关联的数据，这是一种“多对多”的连接关系。

9、主表(主索引)：在多索引连接查询中，作为被召回主体的被查询数据表，多索引连接查询返回的结果集合，每个元素是一个主表中的文档。

10、辅表(辅索引)：在多索引连接查询中，作为主表文档的子字段形式召回的被查询数据表。

11、连接查询：连接查询是一种在多个有关联关系的数据索引之间的查询。在逻辑上将多个索引的数据，根据连接查询指定的连接关系结合成一个索引，在上面检索满足各表过滤条件的文档。被检索的索引分为一个主表和一或多个辅表，检索结果为“被满足各辅表过滤条件的辅表文档关联的，且满足主表过滤条件的主表文档”。

12、宽表：在检索引擎处理多索引连接查询时，一种常用的方法是预先将多个索引按照预先定义的连接关系连接数据，将互相具有连接关系的文档合并为一个文档，则包含这种合并后的文档的数据表称为“宽表”，在这种宽表上构建的索引称为宽表索引。则多索引连接检索被转化为在宽表索引上的单索引检索。

13、索引解耦：与宽表相反的一种多索引连接查询处理方式。即检索引擎不构建宽表，而是正常地对各个数据表构建各自地索引，通过其它额外地机制，来完成这些索引之间的数据逻辑关联，以及在逻辑关联的数据上进行连接查询。

接下来，对本申请涉及的技术方案进行介绍。

针对分布式多索引连接检索问题，在对数据进行查询时，通常会涉及：数据关联关系、多表连接查询和检索结果。接下来，分别对数据关联关系、多表连接查询和检索结果进行介绍。

数据关联关系：

在数据库领域中，具有相同结构的文档通常存储在一张数据表中，即每一行为一个数据记录，每一列是一个字段。如表1中所示的部门表格，每行是一个文档，代表一个部门，每列则分别是部门的主键id，部门名，部门办公地点等字段信息。

表1

id	name	Base	....
				1	Search	Beijing	....
2	Test	Beijing	....
				3	Marketing	Hangzhou	....
4	Maintenance	Beijing	....

在实际应用过程中，数据库中存在多张数据表，多张数据表之间是存在关联关系的。例如，表2所示的职员表，职员表中除了主键id、姓名、年龄等字段信息外，每个职员还工作在某个部门中。因此，表2所示的职员表中通过字段“Depart_id”，来表达职员所属部门的部门主键，这个“Depart_id”字段通常可以称为“外键”。

表2

id	name	age	Depart_id	....
					1	Andrew Z	21	4	....
2	Alice M	25	1	....
					3	Join C	43	2	....
4	Andrew H	30	1	....
					5	L.Andrew	20	1
6	Andrew C	23	3

因此，在关系型数据库中，在进行数据分析时，通常会使用连接语法来联合两个数据表，以查询想要的结果。例如，查询“公司内雇员名字带“Andrew”、年龄在18-25岁之间，且办公地点在北京的部门，按照部门名排序”，则在数据库中对应的结构化查询语言(structured query l anguage，SQL)的查询语句为：

其中“d.id＝e.depart_id”为查询语句中包含的连接关系，““e.name.contains(“Andrew”)AND“e.age in range(18,25)AND d.base＝Bei j ing”为查询语句中包含的过滤条件。

针对上述SQL表达的查询，数据库或者检索引擎的一种处理方式为：

a.检索办公地点在北京的部门主键集合M＝{1,2,4}(即{Search,Maintenance})；

b.遍历或者通过索引，针对所有雇员进行检索，检索出“名字带Andrew，年龄在12-25岁之间”的雇员结果主键集合E＝{1,5,6}；

c.对上述雇员结果集E＝{1,5,6}中的每个雇员，分别找到它的外键{1:4,5:1,6:3}，找到外键在M中的雇员，即雇员{1,5}；

d.输出存在上述雇员对应的的部门主键集合RES＝{1,4}，则RES为查询需要输出的结果。

上述“外键”引用通常是一种N对1关系。例如，多个雇员一般属于1个部门，对于检索引擎和数据库来说，外键一般是外部数据指定的，即在输入检索引擎和数据库时，就已经知道雇员工作于哪个部门，这种连接关系可以称之为先验连接关系。而在很多实际数据场景中，数据表之间的数据通常是具有一种逻辑后验连接关系，这种连接关系通常是以“查询条件”的形式来表达的，外键仅仅是在这种查询处理后的一种存储形式。而且，实际场景中连接查询涉及的索引数通常多于两个。

接下来，以一个具体的示例对数据库中的数据关联关系进行说明。

在一个商品广告推送场景中，由系统维护广告商提供的广告数据，商品平台维护商品数据信息，而用户运维平台维护用户数据。其中商品平台维护的商品数据信息如表3所示，广告商提供的广告数据如表4所示，用户平台维护的用户数据如表5所示。

表3商品表(表明Item)

id	name	Category	Brand	price	....
						1	Huawei P50	C1	B1	1.8	....
2	Huawei Mate 40Pro	C1	B1	2	....
						3	RxdMi pro	C2	B2	2	....
4	Huawei Mate 40	C1	B1	1.9

表4广告表(表名Ads)

id	Target_Category	Target_Brand	Target_platform	Audience
					g1	C1	B1	mobile	1
g2	C1	B1	mobile	2
					g3	C1	B1	pc	1
g4	C2	B2	pc	2

表5用户表(表名User)

id	name	gender	age	tag
					h1	Andrew Z	M	16	1
h2	Alice P	F	23	2
					h3	Join D	M	19	2
h4	Joe S	F	42	1
					h5	Jack C	M	20	1,3

其中，广告-商品关系：广告投放哪些符合目标类型和目标品牌的商品，则商品表和广告表之间的连接关系以SQL形式进行表达时，可以表示为如下查询条件：

Ads JOIN Item ON

Ads.target_category＝＝Item.category AND Ads.target_brand＝＝Item.brand

广告-用户关系：广告投放目标用户为哪些人群特征标签中包含该广告目标人群的用户，则广告表和用户表之间的连接关系以SQL形式进行表达时，可以表示为如下查询条件：

Ads JOIN User ON Contains(User.tag,Ads.Aud ience)

上述广告表和商品表以及广告表和用户表之间的连接关系可以如图1所示。参见图1，Ads表中的g1和Item表中的1、2、4相关联，Ads表中的g2和Item表中的1、2、4相关联，Ads表中的g3和Item表中的1、2、4相关联，Ads表中的g4和Item表中的3相关联；Ads表中的g1和User表中的h1、h4、h5相关联，Ads表中的g2和User表中的h2、h3相关联，Ads表中的g3和User表中的h1、h4、h5相关联，Ads表中的g4和User表中的h2、h3相关联。

可以观察到图1中所示的关联关系是一种后验的多对多的关系。这种连接关系的特征为：

a.两表之间一般是N对N的关系；

b.连接关系定义不变的情况下，两表数据的实时变化会导致表间连接状态的变化。

多表连接查询：

在上述连接关系的基础上，系统查询需求为：生成一批广告投放计划，目标用户为年龄在18-25岁之间的男性用户，广告投放平台需要是移动端，且投放的商品价格低于1.9。最后返回的投放计划包括投放广告、该条广告涉及用户列表以及该条广告涉及投放商品列表。该查询的SQL表达形式图2所示。

参见图2，一个多索引连接查询分为3个部分，

(1)召回字段：即在检索结果中，展示哪些字段，这些字段可以来自所有检索涉及到的数据表索引；

(2)查询对象：表示进行索引检索的对象，以及定义这些对象的连接关系，主要涉及到的索引表可以分为主表和辅表；

其中，主表：是召回主体的目标索引，在一个查询中只能有一个。即召回结果以主表文档为单位，在上述示例中，主表是广告表，因此召回的每一条结果是一个满足条件的广告。

辅表：是与主表有关联关系的目标索引，一个查询中可以定义一个或多个辅表，每个辅表与主表之间的查询需要定义连接关系，召回时，作为主表的子字段形式召回。在上述示例中，存在商品表和用户表2个数据表作为辅表，商品表和主表广告表之间的连接关系为“广告目标类型等于商品目标类型，且广告目标品牌等于商品品牌”，用户表和主表广告表之间的连接关系为用户人群tag中存在广告的目标人群aud ience取值。

(3)搜索条件：针对具备连接关系的主表、辅表，分别定义针对它们的检索条件。一个主表的文档只有满足如下所有条件时才会被考虑为满足该查询的检索条件：

a.该主表文档满足主表过滤条件；

b.满足辅表文档搜索条件，并满足辅表之间的条件组合关系。具体地，满足一个辅表A的文档关联过滤条件的定义为：对于这个主表文档，在所有该主表文档关联的辅表A的文档中，存在辅表文档满足辅表A的过滤条件。在上述示例中，针对商品辅表，对于一个广告x，存在一个与x关联的商品满足商品价格小于1.9，则视为x满足商品辅表文档关联过滤条件，反之若不存在这样一个商品则不满足。

在上述示例中，对于一个广告x，当且仅当x满足针对广告表的搜索条件，并且(AND)存在与x关联的商品满足商品表的搜索条件，并且(AND)存在与x关联的用户满足用户表搜索条件时，广告x才会被考虑为满足该查询搜索条件的一个文档。

可以理解的是，上述示例中SQL只是查询的其中一种表达显示，只是示意性的说明。在具体实现时，检索引擎也可以选择其他输入形式的查询语句，本申请并不对此进行限定。

检索结果：

多索引连接检索的检索结果形式为：

a.每一个结果为一个满足搜索条件的主表文档；

b.对于每条主表文档x，每个辅表作为x的一个子字段，该字段中包含0到多个与x关联并且满足辅表搜索条件的辅表文档。

针对上述示例中的检索，检索返回结果如图3所示。参见图3满足搜索条件的广告为一行。在每个广告结果上与该广告关联并且满足商品搜索条件的多个商品文档，作为Items子字段存在于每个广告结果中(在上述示例中g1和g2分别关联了商品{1,2,4},但是只有1和4满足条件)。以及在每个广告结果上，与该广告关联并且满足用户搜索条件的多个用户文档，作为Users子字段存在于每个广告结果中(在上述示例中g1投放Aud ience为1，在对应用户{h1,h4,h5}中，只有h5满足用户搜索条件，g2同理只有h3满足用户搜索条件)。

针对上述示例中的分布式多索引连接检索，方案一将多个索引之间的连接查询转化为单索引查询问题。检索引擎数据提供者根据各个数据表之间的连接关系，在检索引擎构建索引之前，使用诸如数据库等其它工具，提前计算数据表之间的连接关系，并将计算出的相关联的各表数据合并到一张数据表中，即构建一张宽表。比如，针对表3所示的商品表和表4所示的广告表，表3和表4之间的数据连接关系如图1所示。通过穷举数据连接关系，每当两个表的文档之间有连接关系，就组合为一条新的文档输入宽表中，可以得到表3和表4构建的宽表如表6所示。

表6广告-商品宽表

Ads_id

Target_platform

Audience

Item_id

name

Category

Brand

price

g1

mobile

1

Huwei P50

C1

B1

1.8

g1

mobile

1

2

Huwei Mate 40Pro

C1

B1

2

g1

mobile

1

4

Huwei Mate 40

C1

B1

1.9

g2

mobile

2

1

Huwei P50

C1

B1

1.8

g2

mobile

2

Huwei Mate 40Pro

C1

B1

2

g2

mobile

2

4

Huwei Mate 40

C1

B1

1.9

g3

pc

1

Huwei P50

C1

B1

1.8

g3

pc

1

2

Huwei Mate 40Pro

C1

B1

2

g3

pc

1

4

Huwei Mate 40

C1

B1

1.9

g4

pc

2

3

RxdMi Pro

C2

B2

2

由于，表3和表4中的所有相关数据都存储在表6所示的宽表中。因此，检索引擎可以针对这张宽表构建索引，将多索引连接查询的问题转化为单索引查询。例如查询“广告投放目标为移动端，且商品名中带有Huawei”的连接查询，就可以直接在宽表上查询，比如：

SELECT*

FROM Ads_Item_宽表

WHERE Target_p l atform＝“mobi le”AND pr ice<1.9

在上述查询语句中，不再有JOIN ON相关的逻辑，因为此时检索引擎是在宽表上构建的索引，所有查询均在该宽表索引内部执行，无需处理多索引协同连接。

通过上述构建宽表索引，检索引擎将多索引连接查询的处理问题转换为了一个单索引查询的处理问题，由于连接关系离线计算(数据之间的连接关系在构建索引前就已经确定了)，因此检索引擎可以利用成熟的单索引检索中的检索性能优化措施，从而以很高的性能执行宽表查询。

上述表6表示的是两个数据表互联时的处理方式。当存在3个数据表互相连接时，若应用宽表方案，则需要考虑三个数据表之间的两组连接关系的笛卡尔积作为宽表文档集合。以表3、表4、表5为例，生成的宽表，如图4所示，由于数据膨胀严重，图4仅仅示出了与广告g1相关的宽表文档。参见图4可知，g1与商品{1,2,4}关联，g1与用户{h1,h4,h5}关联，因此在宽表中有9个g1相关文档。

上述方案一虽然能够通过构建宽表解决分布式多索引连接检索问题，但是构建的宽表仍然存在有以下缺点：

(1)数据冗余：可以观察到每一对来自两个索引之间的文档具有连接关系，都会在宽表中生成一个新文档。而如果有N个辅表与主表之间具有连接关系，则由于宽表文档数量连接关系数量与笛卡尔积的大小相关。因此，将N个辅表与主表文档之间连接关系的笛卡尔积作为N个辅表与主表文档之间连接关系数量的集合，导致宽表数据量随涉及数据表数量成指数增长，数据的冗余非常严重。造成索引膨胀以及可能的检索性能下降。

(2)灵活性较差：宽表数据的生成依赖于数据表之间的连接关系定义，因此一种宽表仅适用于数据表之间的一种连接关系。如果数据表之间存在多种逻辑连接关系(数据分析领域经常需要挖掘数据之间的不同联系关系)，那么每种连接关系都需要构建一个对应的宽表，代价高昂，无法灵活应对数据关系多变的场景。

(3)易用性较差：检索引擎的宽表方案要求输入数据就已经是完成连接关系计算的宽表数据，实质上要求检索引擎的数据维护者实现复杂的连接计算逻辑，易用性较差。

(4)数据更新困难：宽表数据是源表数据的连接关系结果，一个源数据表中的文档可能对应宽表中很多文档。当源数据表内容更新时，会涉及到大量宽表内容更新，而检索引擎的索引更新的开销通常随涉及更新文档数量增大而增大。因此宽表数据更新开销通常很高，导致宽表方案无法适应数据高频更新场景，索引数据时效性不可接受。

针对方案一中的宽表会产生大量的数据冗余的问题，方案二提供了一种通过嵌套子文档方式来缓解宽表方案的指数级的数据冗余问题。具体地，检索引擎的数据维护者按照数据表之间的连接关系，将各个数据表的数据按照连接关系聚合成一张数据表(也称为“聚合表”)。与上述宽表不同的是，聚合表中每个文档都是一个主表文档x。与x相关联的辅表文档集合则作为x的“子文档”，以“子文档字段”内容的形式输入检索引擎。图5示出了在图1的关联关系基础上，生成的聚合表。参照图5可知，聚合表的每一行是一个广告(主表)数据。对于广告g1，与g1关联的商品表数据{1,2,4}，以子文档列表的形式存在于聚合表广告的items字段中，与g1关联的用户表数据{h1,h4,h5}，以子文档列表形式存在于聚合广告的User字段中。

检索引擎根据上述聚合表构建带父子文档关系的索引。在该索引中，文档顺序为子文档在前，父文档在后。如图6所示，索引的构建顺序为：与广告g1关联的商品子文档、与广告g1关联的用户子文档、父文档g1、属于g2的商品子文档等。在检索引擎构建索引时，当处理到聚合表中文档g1时，先索引g1的子文档(如图5中与g1关联的商品1，2，4和关联的用户h1,h4,h5)，再索引g1文档本身的字段。g1处理完成后再处理g2，直到所有聚合表中的数据处理完成。

当检索引擎在构建好的索引数据上检索时，从前向后查找索引，以处理图2中表达的查询为例。检索流程如图6所示包括：

步骤601，接收查询请求。

在本步骤中，检索引擎可以接收如图2所示的查询请求，该查询请求中包含了主表(父文档)的搜索条件和辅表(子文档)的搜索条件以及表间条件的组合关系。

步骤602，确定g1的商品子文档中是否存在满足商品检索条件的商品子文档，若存在，执行步骤603，否则执行步骤607。

在本步骤中，处理商品子文档，查询广告g1关联的商品子文档{1,2,4}中是否存在商品子文档满足商品检索条件。经过查询，存在{1,4}满足“价格小于等于1.9”的商品子文档检索条件。

步骤603，确定g1的用户子文档中是否存在满足用户检索条件的用户子文档，若存在，执行步骤604，否则执行步骤607。

在本步骤中，处理用户子文档，查询广告g1关联的用户子文档{h1,h4,h5}中是否存在用户子文档满足用户检索条件。经过查询，存在用户{h5}满足，“18-25岁男性”的用户子文档检索条件。

步骤604，确定g1是否满足广告检索条件，若满足执行步骤605，否则执行步骤607。

在本步骤中，处理父文档广告g1，查询g1是否满足广告检索条件。经过查询，g1满足“投放平台为mobi le”的广告检索条件。

步骤605，确定商品与用户与广告条件的满足情况是否满足查询定义的条件组合关系，若满足，执行步骤606，否则执行步骤607。

在本步骤中，处理检索条件组合关系，确定上述检索条件是否满足查询定义的条件组合关系，若满足则该广告g1满足检索要求，进入结果集。若不满足，则处理下一个文档g2。图2中定义3个条件的组合关系为AND，由于三条都满足，因此g1满足检索要求，进入结果集。

步骤606，将g1加入到结果集。

步骤607，处理下一个广告g2。

在上述方案二中，虽然嵌套子文档的方案，一定程度上解决了主文档的冗余，并且缓解了宽表的指数级文档膨胀。但是嵌套子文档方案本质上还是一种宽表方案，辅表文档依然是存在大量冗余。因此，嵌套子文档方案存在的问题没有根本解决宽表方案的问题，具有宽表方案的所有缺陷(数据冗余、灵活性较差、易用性较差、数据更新困难)。

方案三提供了一种利用分块哈希BlockLookupJoin算法来处理多个分布式索引之间的连接检索的方法。该方法不再构建宽表，而是采用各个涉及的索引之间解耦的方式(以下简称索引解耦)，即各个索引独立存在与检索引擎中。图7示出了该方案的检索过程。如图7所示，该方案在处理两个索引之间的连接检索时，检索引擎将这两个索引分为左表索引和右表索引(图7中的Left I ndex和Right I ndex)，检索过程如下。

步骤1，检索引擎针对左表，执行左表检索条件，获取左表结果集合，并将该左表结果集分为多个结果集块，如图7中的Left Block 1,2,3。

步骤2，针对左表结果集块1(Left Block1)进行处理，包括：

a.遍历左表文档，对每一个块内的左表文档根据连接关系构造针对右表的检索条件，将生成的检索条件取“或”关系(称这个取或关系的检索条件为该左表结果集块的“块连接条件”)；

b.生成右表的查询，查询形式为“块连接条件&右表检索条件”，其中“右表检索条件”为用户输入的针对右表的查询条件；

c.检索引擎通过处理该组合后的查询，召回那些既满足右表检索条件，又满足左表块连接条件的右表文档集合RES_1。通过遍历的方式，为每个左表结果集块1中的左表文档找到在RES_1中对应连接的右表文档，拼接后加入最终的连接检索结果集。

步骤3，处理完结果集块1后，对下一个左表结果集块重复步骤2，直到处理完所有左表结果集块，最终的连接检索结果集为连接检索输出结果。

在上述方案中，相关联的数据表的检索引擎索引之间完全解耦，各个子索引独立维护，因此不存在数据膨胀且更新开销小，以及连接关系完全在线计算，在检索引擎中数据表之间的连接关系没有额外的数据存储开销，也无需预先定义，用户可以针对两个检索引擎中的索引数据，临时定义这些索引数据之间的连接关系并执行查询，灵活性很强，适用于数据分析领域。但是，在上述方案中，由于连接关系在线计算，每个左表结果都需要产生针对右表的一个查询条件，查询开销高。并且一次查询过程中涉及到多轮针对右表的检索，引入多次网络开销。因此，随着数据量的增长，检索开销也会持续增长，无法满足高吞吐、低时延这些检索引擎的基本通用需求。在针对3个以及3个以上索引连接时处理逻辑更加复杂，需要涉及更多轮检索、召回、连接计算。

针对上述方案中的问题，本申请实施例提供了一种多索引连接检索系统，在进行检索之前通过定义索引间连接关系数据结构“文档关联映射表”(JoinDocMap)，以及在检索引擎内维护具有连接关系的两个数据表之间的文档间数据连接关系。使得可以在数据表之间连接关系为简单的外键关联关系或者复杂的查询式关联关系场景下，以及在数据表、索引独立维护的前提下，支持索引时效性更新以及高性能多索引连接检索。

接下来，对本申请实施例提供的技术方案进行介绍。

示例性的，图8(a)示出了一种应用场景，如图8(a)所示，该场景下可以包括电子设备100。电子设备100上配置有多索引连接检索系统。电子设备100可以通过多索引连接检索系统，根据用户输入的查询语句在数据库中进行检索，并输出相应的检索结果。

示例性的，图8(b)示出了另一种应用场景，如图8(b)所示，该场景下可以包括电子设备100和服务器200。在该场景中，多索引连接检索系统可以配置在服务器200上，或者，部分配置在电子设备100上，部分配置在服务器200上。多索引连接检索系统配置在服务器200上时，服务器200可以通过多索引连接检索系统，根据用户输入的查询语句在数据库中进行检索，并输出相应的检索结果。最后，服务器200将生成的检索结果发送给电子设备100进行显示。当多索引连接检索系统一部分配置在服务器200上，另一部分配置在电子设备100中时，电子设备100可以访问到服务器200提供的数据。

在一些实施例中，电子设备100与服务器200之间可以通过有线网络(wi rednetwork)或无线网络(wi re l ess network)等网络连接。例如，该网络可以为局域网(loca l area networks，LAN)，也可以为广域网(wide area networks，WAN)(例如互联网)。电子设备100与服务器200之间的网络均可使用任何已知的网络通信协议来实现，上述网络通信协议可以是各种有线或无线通信协议，诸如以太网、通用串行总线(un iversa l seri a l bus，USB)、火线(f i rewi re)、全球移动通讯系统(g loba l system for mob i le commun icat ions，GSM)、通用分组无线服务(genera l packet rad i o serv i ce，GPRS)、码分多址接入(code d iv i s ionmu l t i p l e access，CDMA)、宽带码分多址(wideband code d iv i s ion mu l t i p l e access，WCDMA)，时分码分多址(t ime-div i s i on code d iv i s ion mu l t i p l e access，TD-SCDMA)、长期演进(l ongterm evo l ut ion，LTE)、新空口(new rad io，NR)、蓝牙(b l uetooth)、无线保真(wi rel ess f ide l ity，Wi-F i)等通信协议。

示例性的，图9示出了一种电子设备100的硬件结构。其中，电子设备100可以但不限于为手机、平板电脑、笔记本电脑、可穿戴设备、智能电视等电子设备。电子设备的示例性实施例包括但不限于搭载iOS、andro id、Wi ndows、鸿蒙系统(Harmony OS)或者其他操作系统的电子设备。本申请实施例对电子设备的类型不做具体限定。

如图9所示，该电子设备100可以包括：包括处理器110、存储器120、显示屏130、通信模块140和输入设备150。其中，处理器110、存储器120、显示屏130、通信模块140和输入设备150可以通过总线或其他方式连接。

其中，处理器110是电子设备100的计算核心及控制核心。处理器110可以包括一个或多个处理单元。例如，处理器110可以包括应用处理器(app l icat ion processor，AP)、调制解调器(modem)、图形处理器(graph ics process i ng un it，GPU)、图像信号处理器(image s igna l processor，I SP)、控制器、视频编解码器、数字信号处理器(d igita ls igna l processor，DSP)、基带处理器、和/或神经网络处理器(neura l-networkprocess i ng un i t，NPU)等中的一项或多项。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

存储器120可以存储有程序，程序可被处理器110运行，使得处理器110执行本申请实施例中提供的电子设备100所需执行的部分或全部方法。存储器120还可以存储有数据。处理器110可以读取存储器120中存储的数据。存储器120和处理器110可以单独设置。可选地，存储器120也可以集成在处理器110中。

显示屏130用于显示图像，视频等。显示屏130包括显示面板。显示面板可以采用液晶显示屏(l iqu i d crysta l d i sp l ay，LCD)，有机发光二极管(organ ic l ight-emitt i ng d iode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matr ix organ ic l ight emitt i ng d iode的，AMOLED)，柔性发光二极管(f l exl ight-emi tt i ng d iode，FLED)，M i n i l ed，M icroLed，M i cro-oLed，量子点发光二极管(quantum dot l ight emitt i ng d iodes，QLED)等。

通信模块140可以包括移动通信模块和无线通信模块中的至少一种。其中，当通信模块140包括移动通信模块时，通信模块140可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。比如，全球移动通讯系统(g l oba l system for mob i le commun i cat i ons，GSM)、通用分组无线服务(genera l packet rad io serv i ce，GPRS)、码分多址接入(code d iv i s ionmu l t i p l e access，CDMA)、宽带码分多址(wideband code d iv i s ion mu l t i p l e access，WCDMA)，时分码分多址(t ime-div i s ion code d iv i s ion mu l t i p l e access，TD-SCDMA)、长期演进(l ongterm evo l ut ion，LTE)、新空口(new rad io，NR)等。当通信模块140包括无线通信模块时，通信模块140可以提供应用在电子设备100上的包括无线局域网(wi re l ess l oca larea networks，WLAN)(如无线保真(wi re l ess f ide l ity，Wi-F i)网络)，蓝牙(b luetooth，BT)，全球导航卫星系统(g l oba l nav igat ion sate l l ite system，GNSS)，调频(frequency modu l at i on，FM)，近距离无线通信技术(near f ie l dcommun i cat ion，NFC)，红外技术(i nfrared，I R)等无线通信的解决方案。示例性的，通信模块140可以用于电子设备100与服务器200进行通信，以完成数据交互。

在一些实施例中，电子设备100还可以包括输入设备150。通过该输入设备150可以向电子设备100输入信息和/或下发控制指令等。示例性的，该输入设备150可以但不限于为鼠标、键盘等。

可以理解的是，本申请实施例图9示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

示例性的，图10示出了一种服务器200的硬件结构。其中，服务器200可以但不限于用于提供云服务，其可以为一种可以与电子设备100建立通信连接、且能为电子设备100提供数据处理功能、运算功能和/或存储功能的服务器或者是超级电子设备。其中，服务器200可以是硬件服务器，也可以植入虚拟化环境中，例如，服务器200可以是在包括一个或多个其他虚拟机的硬件服务器上执行的虚拟机。

如图10所示，该服务器200可以包括：处理器210，网络接口220，及存储器230。其中，处理器210，网络接口220，及存储器230可通过总线或其他方式连接。

本申请实施例中，处理器210(或称为中央处理器(centra l process i ng unit,CPU))是服务器200的计算核心及控制核心。

网络接口220可以包括标准的有线接口，无线接口(如WI-F I，移动通信接口等)，受处理器210的控制用于收发数据，例如，从网络上接收电子设备100发送的查询语句等。

存储器230(memory)是服务器200的记忆设备，用于存放程序和数据，例如存放预训练模型等。可以理解的是，此次的存储器230可以是高速RAM存储器，也可以是非易失性存储器(non-vo l at i l e memory)，例如至少一个磁盘存储器；可选地还可以是至少一个位于远离前述处理器210的存储装置。存储器230提供存储空间，该存储空间存储了服务器的操作系统和可执行程序代码，可包括但不限于：Wi ndows系统(一种操作系统)，L i nux系统(一种操作系统)，鸿蒙系统(一种操作系统)等等，在此不做限定。

可以理解的是，本申请实施例图10示意的结构并不构成对服务器200的具体限定。在本申请另一些实施例中，服务器200可以为云服务器。服务器200可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

以上即是对申请实施例中涉及的应用场景、电子设备100的硬件结构和服务器200的硬件结构的相关介绍。接下来基于上述描述的内容，对本申请实施例中提供的一种多索引连接检索系统进行介绍。

示例性的，图11示出了本申请实施例提供的一种多索引连接检索系统的结构示意图。参照图11，该系统包括：连接关系处理模块1101、多索引连接检索模块1102、存储模块1103。

连接关系处理模块1101用于生成并维护每一对主表和辅表的文档之间的关联关系，并将该关联关系存储在对应的文档关联映射表J ionDocMap中。具体地，连接关系处理模块1101负责根据主表和辅表之间的关联关系，使用检索引擎中针对这些数据表构建的各自的索引，生成相关联的两个数据表之间的文档关联关系，并将该关联关系存储在文档关联映射表J ionDocMap中。

可以理解的是，文档关联映射表J ionDocMap是一个映射结构，用于表达两个数据表的文档之间的关联关系。其中，J ionDocMap中的key为两个相关联的数据表中的一个索引文档的id，va l ue为另一个索引中与该文档相关联的文档列表。

在多索引连接检索系统中，针对相互连接的数据表之间的身份关系，主索引和辅索引之间存在两种J ionDocMap，正向J ionDocMap和逆向J ionDocMap。在正向JionDocMap中主表文档id为key，与主表文档关联的辅表文档id列表为va l ue，在逆向JionDocMap中辅表文档id为key，与辅表关联的主表文档id列表为va l ue。

示例性的，图12示出了相互关联的两个数据表之间生成的J ionDocMap的示意图。参见图12，<主表ads，辅表Item>之间连接关系如图12中的两个表间的连线所示，对应生成JoinDocMap的关联文档映射如图12中的“Ads-Item JoinDocMap”所示。其中，正向JoinDocMap中key为主表ads的文档id：g1,g2,g3,g4；va l ue为与这些主表ads文档有关联关系的辅表Item的id列表。逆向JoinDocMap中，key为辅表Item的文档id：1,2,3,4，va l ue为与这些辅表Item文档有关联关系的主表ads的id列表。

<主表ads，辅表User>之间连接关系如图12中两个表间的连线所示，对应的正向、逆向JoinDocMap如图12中“Ads-User JoinDocMap”所示。其中，正向JoinDocMap中key为主表ads的文档id：g1,g2,g3,g4；va l ue为与这些主表ads文档有关联关系的辅表User的id列表。逆向JoinDocMap中，key为辅表User的文档id：h1,h2,h3,h4，h5,va l ue为与这些辅表User文档有关联关系的主表ads的id列表。

连接关系处理模块1101用于对两个数据表之间的JoinDocMap中的数据进行维护。当数据表中的数据发生更新时，连接关系处理模块1101根据检索引擎针对数据表生成的索引，相关联的两个数据表之间的连接关系转化为针对检索引擎的索引查询，并进行JoinDocMap的构建和更新，以保证JoinDocMap中保存的关联关系与数据表、索引内容的一致性。其中连接关系处理模块1101对JoinDocMap中的数据进行维护包括：

构建：当数据表中增加一条数据时，在JoinDocMap中增加相应的关联关系；

删除：当数据表中删除一条数据时，在JoinDocMap中删除相应的关联关系；

更新：当数据表中已存在的一条数据更新时，在JoinDocMap更新相对应的关联关系。

示例性的，图13(a)示出了一种更新JoinDocMap中的关联关系的方法流程图。如图13(a)所示，当主表中增加一个文档x时，连接关系处理模块1101对JoinDocMap中的关联关系进行更新的过程包括：1311-1314。

步骤1311，对于每一个与主表关联的辅表(令辅表为B)，根据各个辅表与主表的关联关系，用文档x构建对应的在辅表B上的查询Q。

步骤1312，根据查询Q，在辅表B对应的索引中进行查询，得到结果集RES_B_x，其中，RES_B_x为辅表B中与主表文档x相关联的文档y的集合。

步骤1313，在主表与辅表B的正向JoinDocMap中，增加主表与辅表B的关联关系<x,RES_B_x>。

步骤1314，对于RES_B_x中的每个元素y，在主表与辅表B的逆向JoinDocMap中，增加主表与辅表B的关联关系<y,va l ue_y+x>。

辅表B中的文档可以用y进行表示，对于每个RES_B_x中的元素y,找到逆向JoinDocMap中key为y的条目，在va l ue集合中加入x。

可以理解的是，步骤1313和步骤1314之间是不存在执行的先后顺序的。

示例性的，图13(b)示出了又一种更新JoinDocMap中的关联关系的方法流程图。如图13(b)所示，当辅表B中增加一个文档y时，连接关系处理模块1101对JoinDocMap中的关联关系进行更新的过程包括：1321-1324。

步骤1321，根据辅表B与主表的关联关系，用文档y构建针对主表的查询Q。

步骤1322，根据查询Q，在主表对应的索引中进行查询，得到结果集RES_y，其中，RES_y为主表中与辅表B中的文档y相关联的主表文档x的集合。

步骤1323，对于RES_y中的元素x，在主表与辅表B的正向JoinDocMap中，找到正向JoinDocMap中key为x的条目，在va l ue集合中加入y。

步骤1324，在主表与辅表B的逆向JoinDocMap中，新增key为y，va l ue为RES_y的条目。

可以理解的是，步骤1323和步骤1324之间不存在执行的先后顺序。

示例性的，图14(a)示出了又一种更新JoinDocMap中的关联关系的方法流程图。如图14(a)所示，当主表中删除一个文档x时，连接关系处理模块1101对JoinDocMap中的关联关系进行更新的过程包括：1411-1413。

步骤1411，获取主表与辅表B的正向JoinDocMap中x对应的va l ue集合l i st_B。

步骤1412，对于l i st_B中的每个元素y，删除主表与辅表B的逆向JoinDocMap中，key为y的va l ue中的x。

步骤1413，删除正向JoinDocMap中key为x对应的条目。

在本示例中，当主表删除一个文档x时，需要将正向和逆向JoinDocMap中有关x的信息删除。

示例性的，图14(b)示出了又一种更新JoinDocMap中的关联关系的方法流程图。如图14所示，当辅表中删除一个文档y时，连接关系处理模块1101对JoinDocMap中的关联关系进行更新的过程包括：1421-1423。

步骤1421，获取主表A与辅表B的逆向JoinDocMap中y对应的va l ue集合l i st_A。

步骤1422，对于l i st_A中的每个元素x，删除主表A与辅表B的正向JoinDocMap中，key为x的va l ue中的y。

步骤1423，删除逆向JoinDocMap中key为y对应的条目。

在本示例中，当辅表删除一个文档y时，需要将正向和逆向JoinDocMap中有关y的信息删除。

在一个可能的示例中，当需要对主表或者辅表中的数据进行更新时，需要确定更新的数据字段是否为与辅(主)表有关联关系的字段。若更新的数据不涉及与辅(主)表有关联关系的字段，由于主表和辅表之间的关联关系保持不变，则不需要对JoinDocMap进行更新。可以理解的是，在本示例中所涉及的对主表或者辅表中的数据进行更新，针对的是对主表和辅表之间有关联关系的字段的更新。

当主表A文档x发生更新时，若该更新涉及主表与辅表有关联关系的字段，则对于每个涉及的辅表对应的JoinDocMap，执行图14(a)所示的更新JoinDocMap中的关联关系的方法流程，将JoinDocMap中保存的关于文档x的关联关系删除。然后，再针对主表文档x的最新取值，执行图13(a)所示的更新JoinDocMap中的关联关系的方法流程，在JoinDocMap中增加更新后的文档x的关联关系。

当辅表B的文档y发生更新时，若该更新涉及主表与辅表有关联关系的字段，则对于主表A与辅表B的JoinDocMap，执行图14(b)所示的更新JoinDocMap中的关联关系的方法流程，将JoinDocMap中保存的关于文档y的关联关系删除。然后，再针对辅表文档y的最新取值，执行图13(b)所示的更新JoinDocMap中的关联关系的方法流程，在JoinDocMap中增加更新后的文档y的关联关系。

多索引连接检索模块1102用于根据索引引擎中的索引以及主表和各个辅表的JoinDocMap，查询出满足查询条件的关联文档结果集。

示例性的，以两个数据表的索引的连接查询为例，对多索引连接检索模块1102的检索过程进行说明。其中，两个数据表包括主表A和辅表B，两个索引的连接检索方法的流程图如图15所示，包括：步骤1501-步骤1507。

步骤1501，获取用户输入的查询条件，所述查询条件中包括主表查询条件和辅表查询条件。

在本实施例中，用户输入的查询条件如图2所示，包括：包括召回字段、查询字段和搜索(查询)条件。

步骤1502，根据辅表查询条件检索辅表索引，得到辅表结果集RES_B，其中，RES_B在辅表空间，即RES_B集合中元素为辅表文档id。

在本实施例中，多索引连接检索模块1102根据辅表的查询条件对辅表中的索引进行检索，可以得到满足辅表查询条件的结果集RES_B。

在一个可能的示例中，如图16所示，主表A和主表B之间的JoinDocMap包括正向JoinDocMap和逆向JoinDocMap。其中，正向JoinDocMap如表7(a)所示，逆向JoinDocMap如表7(b)所示。

表7(a)

main_id	aux_ids
		g1	{3}
g2	{1,2,5}
		g3	{3,4,6}
g4	{1,2}
		g5	{4}

表7(b)

aux_id	main_ids
		1	{g2,g4}
2	{g2,g4}
		3	{g1,g3}
4	{g3,g5}
		5	{g2}
6	{g3}

在一个示例中，如图16所示，多索引连接检索模块1102根据辅表的查询条件对辅表中的索引进行检索，得到的辅表结果集RES_B＝{3,4,5}。

步骤1503，针对辅表结果集RES_B，利用主表和辅表之间的JoinDocMap，将RES_B转化为主表空间结果集LOOK_UP。

在本实施例中，多索引连接检索模块1102在获取到辅表结果集RES_B＝{3,4,5}以后，多索引连接检索模块1102可以通过主表A和辅表B之间的逆向JoinDocMap将获取的辅表结果集RES_B＝{3,4,5}转化为主表空间文档集合MJD_B＝{g1,g2,g3,g5}，即主表空间结果集LOOK_UP。即LOOK_UP变成与那些“满足辅表条件的辅表文档”相关联的主表文档id集合

在一个可能的示例中，多索引连接检索模块1102获取到辅表结果集RES_B＝{3,4,5}以后，根据辅表结果集RES_B查找主表A和辅表B之间的逆向JoinDocMap。比如，多索引连接检索模块1102根据RES_B中的辅表文档id“3”查找表7(b)所示的逆向J ionDocMap得到与“3”关联的主表文档id为{g1,g3}。同样的，多索引连接检索模块1102根据RES_B中的辅表文档id“4”查找表7(b)所示的逆向J ionDocMap得到与“4”关联的主表文档id为{g3,g5}，根据RES_B中的辅表文档id“5”查找表7(b)所示的逆向J ionDocMap得到与“5”关联的主表文档id为{g2}。然后，多索引连接检索模块1102将{g1,g3}、{g3,g5}、{g2}求并集可得到辅表结果集RES_B＝{3,4,5}对应的主表空间结果集LOOK_UP为{g1,g2,g3,g5}。

步骤1504，根据主表检索条件检索主表索引，得到满足主表索引条件的主表文档x。

在本实施例中，多索引连接检索模块1102在获取到辅表结果集RES_B＝{3,4,5}以后，多索引连接检索模块1102根据主表的查询条件对主表中的索引进行检索，可以得到满足主表查询条件的主表文档x。

在一个可能的示例中，如图16所示，当主表索引中存在多个满足主表索引条件的主表文档x时，多个主表文档x的文档id可以构成主表结果集RES_A＝{g3,g5,g6}。

可以理解的是步骤1502和步骤1504之间不存在执行执行的先后顺序。

步骤1505，确定主表文档x是否包含在主表空间结果集LOOK_UP中，若主表文档x包含在LOOK_UP中，执行步骤1506，否则执行步骤1504寻找下一个满足主表索引条件的主表文档x。

在本实施例中，多索引连接检索模块1102在获取到主表结果集RES_A以后，需要依次将主表结果集RES_A中的文档id与主表空间结果集LOOK_UP中的文档id进行比较。由于LOOK_UP中包含的主表文档id为与“满足辅表条件的辅表文档”相关联的主表文档id集合。因此，多索引连接检索模块1102将获取到的主表结果集RES_A与LOOK_UP中的文档id进行比较，当存在有主表文档x的id既包含在主表结果集RES_A中又包含在LOOK_UP中,则表明该主文档x满足用户输入的查询条件中的连接条件。在一个可能的示例中，多索引连接检索模块1102在获取到主表结果集RES_A以后，通过查询主表空间结果集LOOK_UP可知，RES_A中{g3,g5}满足连接条件。

步骤1506，根据主表和辅表之间的正向JoinDocMap以及辅表结果集RES_B确定与文档x关联的辅表文档y。

在本实施例中，多索引连接检索模块1102在确定既满足主表查询条件又满足连接条件的主表文档x以后，多索引连接检索模块1102还需要获取与该主表文档关联的辅表文档y。

在一个可能的示例中，如图16所示，多索引连接检索模块1102在确定既满足主表查询条件又满足连接条件的主表文档为{g3,g5}。对于g3，多索引连接检索模块1102通过主表和辅表之间的正向JoinDocMap得知g3与辅表的{3,4,6}关联。然后，多索引连接检索模块1102将与g3关联的辅表文档id集合{3,4,6}与辅表结果集RES_B＝{3,4,5}取交集，得到集合{3,4}。即，集合{3,4}中的文档id对应的辅表文档，既满足用户输入的查询语句中的辅表查询条件，又与满足用户输入的查询语句中的主表查询条件中的主表文档相关联。

步骤1507，将主表文档x和辅表文档y进行拼接，并将拼接后的文档记录到结果集中。

在本实施例中，多索引连接检索模块1102在确定既满足主表查询条件又满足连接条件的主表文档x，以及与该主表文档x相关联且满足辅表查询条件的辅表文档y以后，多索引连接检索模块1102需要将该主表文档x和辅表文档y进行拼接，并将拼接后的文档记录到结果集中，用于后续的查询结果输出。

在一个可能的示例中，多索引连接检索模块1102生成的结果集如图16中所示。

多索引模块1101在将主表文档x和辅表文档y进行拼接，并将拼接后的文档记录到结果集中以后，多索引模块1101继续根据主表检索条件检索主表索引，得到满足主表索引条件的主表文档x，然后执行步骤1505-步骤1507的操作直到主表中不存在满足主表索引条件的主表文档。

在一个可能的示例中，多索引模块1101根据主表检索条件检索主表索引得到多个满足主表检索条件的主表文档x。然后，对于满足主表检索条件的多个主表文档x中的每一个主表文档x执行步骤1505-步骤1507的操作。

可以理解的是，在上述实施例中，针对两个索引的连接查询只是示意性的说明，并不对本发明申请进行限定。在本发明申请实施例中，多索引连接检索模块1102可以实现对数据库的多索引连接查询。

在一个可能的示例中，多个索引连接查询之间的连接检索如图2所示。在本示例中，以1个主表、N个辅表为例进行说明，其中N为大于等于2的自然数。多个索引的连接检索方法的流程图如图17所示，包括：步骤1701-步骤1706。

步骤1701，获取用户输入的查询条件，所述查询条件中包括主表查询条件和辅表查询条件。

在本实施例中，接收的用户输入的查询条件，该查询条件中可以包括：召回字段，查询对象和搜索条件。其中，召回字段用于标识需要召回的主体，即返回结果中需要包含的字段，查询对象中用于标识需要查询的多个数据表，以及多个数据表之间的连接关系，搜索条件用于标识各个数据表对应的搜索条件，以及各个数据表之间的查询条件的组合关系。

步骤1702，根据辅表查询条件，检索N个辅表的索引，得到各自的辅表结果集{AUX_RES_1,AUX_RES_2,…,AUX_RES_N}。

在本实施例中，当用户输入的查询语句中包括N个辅表查询条件时，多索引连接检索模块1102需要根据根据查询语句中包括的N个辅表查询条件对N个辅表的索引进行检索，得到每一个辅表的辅表结果集。

步骤1703，对于N个辅表结果集中的每一个辅表结果集，根据该辅表结果集对应的辅表与主表之间的逆向JoinDocMap，将该的辅表结果集转化为主表空间结果集LOOK_UP。

在本实施例中，对于得到的N个辅表结果集中的每一个辅表结果集，多索引连接检索模块1102根据该辅表结果集对应的辅表与主表之间的逆向JoinDocMap，将该辅表结果集转化为表空间结果集，可以得到N个辅表结果集各自对应主表空间下的MAIN_JOIN_DOCS集合(简称MJD){MJD_1,MJD_2,…,MJD_N}。

在一个可能的示例中，在得到N个辅表结果集各自对应主表空间下的集合MJD_1,MJD_2,…,MJD_N以后，可以将集合MJD_1,MJD_2,…,MJD_N取并集得到N个辅表结果集对应的主表空间结果集LOOK_UP。

其中，根据辅表结果集以及该辅表对应的辅表与主表之间的逆向JoinDocMap，将该辅表结果集转化为主表空间结果集的具体过程可以参照上述实施例中的步骤1503，在此不再赘述。

步骤1704，根据主表检索条件检索主表索引，得到满足主表索引条件且满足查询语句中的连接条件的主表文档x。

在本实施例中，根据主表检索条件检索主表索引，得到满足主表索引条件的主表文档，然后对满足主表索引条件的主表文档进行筛选，得到既满足主表索引条件又满足查询语句中的连接条件的主表文档x。其中，确定既满足主表索引条件又满足查询语句中的连接条件的主表文档x的具体过程可以参照上述实施例中的步骤1504和步骤1505，在此不再赘述。

步骤1705，获取辅表1到辅表N中既与主表文档x关联，又满足辅表各自过滤条件的辅表文档集合y。

在本实施例中，在获取到既满足主表索引条件又满足查询语句中的连接条件的主表文档x以后，还需要在辅表1到辅表N中获取与主表文档x关联的辅表文档集合y，其中辅表文档集合y中的辅表文档还需要满足其对应的辅表检索条件。

在一个可能示例中，对于辅表1，利用辅表1与主表之间的正向JoinDocMap_1，查找与主表文档x关联的辅表1中的文档集合，然后，将该文档集合与辅表1的辅表结果集AUX_RES_1取交集，得到辅表1中既与主表文档x关联，又满足辅表1对应的辅表搜索条件的辅表1中的辅表文档集合。

同理，可以得到其他辅表中既与主表文档x关联，又满足该辅表对应的辅表搜索条件的辅表文档集合。

步骤1706，将主表文档x与辅表集合y中的辅表文档进行拼接并将拼接后的文档记录到结果集中。

在本实施例中，在获取到与主表文档x关联的辅表文档集合y以后，还需要将该主表文档x与该辅表文档集合y中的辅表文档进行拼接，得到用于输出的文档集合。

在本申请实施例中，在索引解耦的前提下，通过检索引擎对各个数据表构建的互相结构的索引以及预先定义的索引间连接关系，构建出各个辅表与主表之间的正向和逆向JoinDocMap。以及通过应用正向、逆向JoinDocMap，使得使用检索引擎为数据表构建的各自的索引，就可以完成多索引之间的连接检索需求，并且主索引和其它辅索引之间的连接关系在JoinDocMap构建时确定，检索时使用JoinDocMap获取相关文档信息，性能远高于在执行用户查询时临时计算。

在本施例中，在多索引连接检索模块1102进行检索之前，对各个索引之间的文档关联关系使用JoinDocMap进行“预计算”，使得多索引连接检索模块1102在执行连接查询的过程中，避免了在线计算文档关联关系，以及避免了多索引连接检索模块1102在执行连接查询的过程中执行多轮子查询造成的执行效率低的问题。

存储模块1103用于存储文档关联映射表JoinDocMap。其中，文档关联映射表JoinDocMap是一个映射结构，表达两个数据表的文档之间的关联关系。它的key为其中一个索引的文档的id，va l ue为另一个索引中与该文档相关联的文档列表。

基于上述实施例中提供的多索引连接检索系统，本申请实施例还提供了一种多索引连接检索方法。示例性的，图18为本申请实施例提供的一种多索引连接检索方法的流程示意图，该方法可以由检索引擎执行，检索引擎上包括图11所示的多索引连接检索系统。参照图18，该方法包括：步骤1801-步骤1806。

步骤1801，接收用户输入的查询语句，该查询语句中包括：召回字段、查询对象、搜索条件，该搜索条件中包括：主表搜索条件和辅表搜索条件。

在本实施例中，以广告推送场景为例进行说明。在广告推送场景中，系统维护广告商提供的广告数据，商品平台维护商品数据信息，而用户运维平台维护用户数据。其中，其中商品平台维护的商品数据信息如表8所示，包括：商品的主键id，商品名称name，商品类型category、商品品牌brand、商品价格pr ice以及其它字段。广告上提供的广告数据如表9所示，包括：广告主键id，目标投放商品类型Target_Category，目标投放商品品牌target_brand，投放平台target_p l atform，投放目标人群aud ience以及其它字段。用户平台维护的用户数据如表10所示，包括：用户主键id，姓名name，性别gender，年龄age，以及人群特征标签tag。

表8商品表(表明I tem)

表9广告表(表名Ads)

id	Target_Category	Target_Brand	Target_platform	Audience
					g1	C1	B1	mobile	1
g2	C1	B1	mobile	2
					g3	C1	B1	pc	1
g4	C2	B2	pc	2
					g5	C1	B2	mobile	4

表10用户表(表名User)

在一个可能的示例中，在上述“商品–广告–用户”三个表相互连接的基础上，用户需要投放的一批广告投放计划为：目标用户为年龄在18-25岁之间的男性用户，广告投放平台需要是移动端，且投放的商品价格低于1.9，最后返回的投放计划包括投放广告、该条广告涉及用户列表以及该条广告涉及投放商品列表。那么，根据用户的广告投放计划，可以生成对应的用户查询语句。其中，生成的查询语句如图2所示，包括：召回字段，查询对象和搜索条件。其中，召回字段用于标识需要召回的主体，即返回结果中需要包含的字段，查询对象中用于标识需要查询的多个数据表，以及多个数据表之间的连接关系，搜索条件用于标识各个数据表对应的搜索条件，以及各个数据表之间的查询条件的组合关系。

在一个可能的示例中，检索引擎在接收到用户输入的查询语句，并根据该查询语句进行检索之前，检索引擎还需要检索的数据库中的数据表的索引，以及各个数据表对应的文档关联映射表JoinDocMap。

在一个可能的示例中，根据表8所示的商品表，表9所示的广告表，表10所示的用户表，可以得到广告与商品、广告与用户之间的关联关系，可以理解的是，连接关系本质是一种查询条件。

广告-商品关系：广告投放哪些符合目标类型和目标品牌的商品，则商品表和广告表之间的连接关系以SQL形式进行表达时，可以表示为如下查询条件：

Ads JOIN Item ON

Ads.target_category＝＝Item.category AND Ads.target_brand＝＝Item.brand

Ads JOIN User ON Contains(User.tag,Ads.Aud ience)

上述广告表和商品表以及广告表和用户表之间的连接关系可以如图19所示，其中，广告Ads为主表，商品Item和用户User表分别为辅表。参见图19，Ads表中的g1和Item表中的1、2、4相关联，Ads表中的g2和Item表中的1、2、4相关联，Ads表中的g3和Item表中的1、2、4相关联，Ads表中的g4和Item表中的3相关联；Ads表中的g1和User表中的h1、h4、h5相关联，Ads表中的g2和User表中的h2、h3相关联，Ads表中的g3和User表中的h1、h4、h5相关联，Ads表中的g4和User表中的h2、h3相关联。

在一个可能的示例中，在通过检索引擎完成索引的检索以及索引之间的连接关系检索之前，还需要构建索引以及构建辅表和主表的文档之间的关联关系JoinDocMap。针对表8、表9、表10所示的3个数据表，可以构建它们各自的检索引擎索引：I ndex_Item,Index_Ads,I ndex_User。然后，可以构建辅表Item与主表Ads之间的JoinDocMap，以及辅表User与主表Ads之间的JoinDocMap。

在一个可能的示例中，以主表Ads中的g1文档为例，对辅表Item与主表Ads之间的JoinDocMap的构建过程进行说明。具体地，如图20所示，检索引擎在构建辅表Item与主表Ads之间的JoinDocMap时，首先根据辅表Item与主表Ads之间的连接关系构建针对辅表的商品索引I ndex_Item的查询条件。其中，主表Ads与辅表Item之间的连接关系为：Ads的target_Category和Item的Categroy要相等，且Ads的Target_Brand和Item的Brand要相等。由于，主表Ads中的文档g1的Target_Category为C1，Target_Brand为B1，则构建针对商品索引I ndex_Item的查询“SELECT id FROM Item WHERE Category＝＝C1 AND Brand＝＝B1”。检索引擎在I ndex_Item索引上执行该索引查询，得到结果集RES_Item_g1＝{1,2,4}，即商品表文档1,2,4与广告g1关联。然后将上述结果集分别添加到辅表Item与主表Ads的正向JoinDocMap和逆向JoinDocMap中，可以得到Ads_ItemJoinDocMap的正向JoinDocMap中的key为g1时，对应的Va l ue为{1,2,4}，逆向JoinDocMap中的key为1时，对应的Va l ue为{g1}，key为2时对应的Va l ue为{g1},key为3时对应的Va l ue为{g1}。

可以理解的是，在上述示例中，在构建针对商品索引I ndex_Item的查询时，使用SQL的形式来进行构建，并不对本申请实施例进行限定，在本申请实施例中，可以根据需要选择其他的形式进行构建。

对于每一个与主表Ads相关联的辅表文档，遍历主表Ads中的所有文档，重复上述针对主表g1文档构建对辅表Item与主表Ads之间的JoinDocMap的构建过程，可以得到辅表与主表之间的JoinDocMap。参照图21，辅表Item与主表Ads之间的Ads_ItemJoinDocMap中的正向JoinDocMap中的key为g1时对应的Va l ue为{1,2,4}，key为g2时对应的Va l ue为{1,2,4}，key为g3时对应的Va l ue为{1,2,4}，key为g4时对应的Va l ue为{3}。Ads_ItemJoinDocMap中的逆向JoinDocMap中的key为1时对应的Va l ue为{g1,g2,g3},key为2时对应的Va lue为{g1,g2,g3},key为3时对应的Va l ue为{g4},key为4时对应的Va l ue为{g1,g2,g3}。

同理，可以得到辅表User与主表Ads之间的User_ItemJoinDocMap中的正向JoinDocMap中的key为g1时对应的Va l ue为{h1,h4,h5}，key为g2时对应的Va l ue为{h2,h3}，key为g3时对应的Va l ue为{h1,h4,h5}，key为g4时对应的Va l ue为{h2,h3}。User_ItemJoinDocMap中的逆向JoinDocMap中的key为h1时对应的Va l ue为{g1,g3},key为h2时对应的Va l ue为{g2,g4},key为h3时对应的Va l ue为{g2,g4},key为h4时对应的Va l ue为{g1,g3},key为h5时对应的Va l ue为{g1,g3}。

当检索引擎构建完成表8、表9、表10对应的索引I ndex_Item,I ndex_Ads,Index_User，以及表8、表9、表10之间对应的文档关联映射表Ads_ItemJoinDocMap(简称JoinDocMap_Item)和Ads_UserJoinDocMap(简称JoinDocMap_User)以后，检索引擎就可以根据用户输入的检索条件在构建好的索引上进行连接查询。

步骤1802，根据查询条件中的辅表搜索条件和辅表间的组合关系，得到辅表结果集，并将根据辅表与主表之间的文档关联关系，将该结果集转换为对应的主表空间结果集MJD。

在本实施例中，检索引擎根据辅表搜索条件分别查询辅表Item和User索引，得出辅表Item的结果集AUX_RES_Item以及辅表User的结果集AUX_RES_User。如图22所示，商品索引结果集AUX_RES_Item＝{h3,h5}满足价格小于0.9的条件,用户索引结果集AUX_RES_User＝{1,4}满足“18到25岁的男性”。

检索引擎在分别获取到辅表Item和User的结果集以后，还需要根据辅表Item与主表Ads之间的逆向JoinDocMap_Item将AUX_RES_Item中的文档id转换为对应的主表中的文档id集合MJD_Item，以及根据辅表User与主表Ads之间的逆向JoinDocMap_User将AUX_RES_User中的文档id转换为对应的主表中的文档id集合MJD_User。如图22所示，AUX_RES_User＝{h3,h5}，查询逆向JoinDocMap，对应关联主表id分别为{g2,g4},{g1,g3}，取并集得到MJD_User＝{g1,g2,g3,g4}。AUX_RES_Item＝{1,4}，查询逆向JoinDocMap，对应关联主表id分别为{g1,g2,g3},{g1,g2,g3}，取并集得到MJD_User＝{g1,g2,g3}。

参照图2，由于在用户输入的查询语句中，Item表和User表的过滤条件为AND关系。因此，还需要将MJD_Item和MJD_User取交集，得到对应的主表空间结果集MJD＝{g1,g2,g3}。MJD可以作为LOOK_UP结构参与后续对主表索引的检索过程。

可以理解的是，检索引擎在根据辅表搜索条件，找到满足辅表条件的辅表结果集，根据辅表结果集构建一个LOOK_UP结构。其中，LOOK_UP结构功能为：输入一个满足主表过滤条件的主表文档x，用LOOK_UP来确定“是否存在与主表文档x关联的辅表文档y满足辅表过滤条件”。

步骤1803，根据查询条件中的主表搜索条件，得到满足主表搜索条件的主表结果集RES_Ads。

在本实施例中，如图23所示，检索引擎根据主表搜索条件查询主表Ads，得到满足“足Target_p l atform为mobi le”的主表结果集RES_Ads＝{g1,g2,g5}。

步骤1804，将主表结果集RES_Ads与主表空间结果集MJD进行比较，得到主表结果集RES_Ads_Joined，其中，RES_Ads_Joined中的主表文档id同时包含在主表结果集RES_Ads和主表空间结果集MJD中。

在本实施例中，对于主表结果集RES_Ads＝{g1,g2,g5}中的每一个主表文档，检索引擎查询主表空间结果集MJD，以确定该主表文档是否包含在MJD中。

在一个可能的示例中，参照图23，将主表结果集RES_Ads＝{g1,g2,g5}与主表空间结果集MJD＝{g1,g2,g3}取交集，得到既满足主表搜索条件，又满足连接检索查询条件的主表文档集合RES_Ads_Joined＝{g1,g2}。参见图19可知，主表结果集RES_Ads中的主表文档g5,虽然满足图2中所示的主表搜索条件，但是不满足图2中所示的连接条件。

步骤1805，根据辅表与主表之间的文档关联关系，确定主表结果集RES_Ads_Joined中的每个主表文档相关联辅表文档。

在本实施例中，搜索引擎在获取到既满足主表搜索条件，又满足连接检索查询条件的主表文档集合RES_Ads_Joined＝{g1,g2}以后，还需要确定RES_Ads_Joined中各个主文档关联的辅表文档，其中，在确定与RES_Ads_Joined中主文档关联的辅表文档时，该辅表文档还需要满足辅表搜索条件。

在一个可能的示例中，如图23所示，对于RES_Ads_Joined中的每个主表文档，需要找到与他们相关联的各辅表文档列表，拼接出连接查询结果集。对于RES_Ads_Joined中广告g1，通过广告Ads与商品Item之间的正向JoinDocMap_Item，查到与g1关联的商品文档集合ids为{1,2,4}，将该集合与步骤1802中得到的商品辅表结果集AUX_RES_Item＝{1,4}取交集，得到集合{1,4}。则集合{1,4}对应的辅表Item中的辅表文档，为连接查询结果集中g1的Items子文档列表。同理，通过广告Ads与用户User之间的正向JoinDocMap_User，查到与g1关联的用户文档集合ids为{h1,h4,h5}，将该集合与步骤1802中得到的用户辅表结果集AUX_RES_User＝{h3,h5}取交集，得到集合{h5}，则为集合{h5}对应的辅表User中的辅表文档，为连接查询结果集中g1的User子文档列表。然后，检索引擎将RES_Ads_Joined中广告g1和与g1关联的Items中的子文档列表，User中的子文档列表进行拼接，得到图24中所示的连接查询结果集。

同理，对RES_Ads_Joined中广告g2进行与g1相同的处理，可以得到图24中所示的连接查询结果集。

步骤1806，对于主表结果集RES_Ads_Joined中的每个主表文档，将主表文档和与该主表文档相关联的辅表进行拼接，得到满足用于查询条件的结果集。

在本实施例中，对于RES_Ads_Joined中的每个主表文档，检索引擎需要找到与他们相关联的各辅表文档列表，拼接出连接查询结果集。

在一个可能的示例中，基于图2所示的查询条件，得到连接查询的结果集如图24所示。

在本申请实施例中，在索引解耦的前提下，通过检索引擎对各个数据表构建的的索引以及预先定义的索引间连接关系，构建出各个辅表与主表之间的正向和逆向JoinDocMap，并利用JoinDocMap和各个索引，高效地处理多索引之间地连接检索，输出满足连接查询需求地连接文档集合。解决了现有索引解耦的技术中，不同索引中的文档关联关系，需要在处理连接查询的过程中临时计算，而导致的开销高而效率低的问题。以及本发明申请实施例在每对具有连接关系的索引之间，使用正向和逆向JoinDocMap，使得检索引擎可以使用为各个数据表各自创建的索引就可以执行多个索引之间的连接查询，而不必构建宽表索引。并且在执行过程中，各个索引之间的文档关联关系使用JoinDocMap进行“预计算”，避免了现有技术中在执行连接查询的过程中在线计算文档关联关系，避免了连接查询执行中的多轮子查询造成的执行效率，大大提升了多索引连接检索的执行效率。

在上述实施例中，检索引擎在根据用户输入的查询语句进行检索之前，需要预先构建具有关联关系的索引之间的文档关联映射表JoinDocMap，并在执行检索的过程中，在每对具有连接关系的索引之间，使用正向和逆向JoinDocMap，使得检索引擎可以使用为各个数据表各自创建的索引就可以执行多个索引之间的连接查询，有效提高了查询的效率。

针对上述实施例中，检索引擎预先构建的有关联关系的索引之间的文档关联映射表JoinDocMap，本发明申请实施例还提供了对已生成的JoinDocMap的维护方法。其中，对JoinDocMap维护包括：(1)在主表新增数据的情况下，对JoinDocMap进行维护、(2)在辅表新增数据的情况下，对JoinDocMap进行维护、(3)在主表删除数据的情况下，对JoinDocMap进行维护、(4)在辅表删除数据记录的情况下，对JoinDocMap进行维护、(5)在主表更新数据的情况下，对对JoinDocMap进行维护、(6)在辅表更新数据的情况下，对JoinDocMap进行维护。

(1)在主表新增数据的情况下，对JoinDocMap进行维护。

在本示例中，以表9所示的广告表Ads为例。在广告表Ads中新增一条数据g6，在检索引擎更新广告表Ads对应的广告索引{g1,g2,g3,g4,g5}更新为{g1,g2,g3,g4,g5,g6}以后，检索引擎还需要针对每个与广告表相关联的辅表更新该辅表与广告表之间的JoinDocMap。

在一个可能的示例中，针对辅表Item与主表Ads之间的JoinDocMap_Item更新过程如图25所示，包括：步骤a-步骤c。

步骤a，检索引擎根据g6的字段值以及辅表Item与主表Ads的连接条件生成针对辅表Item的查询Q_g6为“SELECT id FROM Item WHERE"Category＝＝C1 AND Brand＝＝B1"”。

步骤b，检索引擎在辅表Item对应的索引上执行查询Q_g6，得到结果集RES_Item_g6＝{1,2,4}，即结果集RES_Item_g6中的索引对应的商品与新增主表广告有关联关系。

步骤c，根据结果集RES_Item_g6分别更新辅表Item与主表Ads之间的正向JoinDocMap_Item和逆向JoinDocMap_Item。

在本实施例中，如图25所示，在辅表Item与主表Ads之间的正向JoinDocMap_Item中增加key的值为g6,以及g6对应的Va l ue为{1,2,4}。在辅表Item与主表Ads之间的反向JoinDocMap_Item中的key为1对应的Va l ue中增加g6，key为2的Va l ue中增加g6，以及key为4对应的va l ue中增加g6。

可以理解的是，广告表Ads中新增一条数据以后，辅表User与主表Ads之间的JoinDocMap_User的更新过程，与辅表Item与主表Ads之间的JoinDocMap_User的更新过程相同，在此不再赘述。

(2)在辅表新增数据的情况下，对JoinDocMap进行维护。

在本示例中，以表8所示的商品表Item为例。在商品表Item中新增一条id为5的文档数据，在检索引擎更新商品表Item对应的商品索引{1,2,3,4}更新为{1,2,3,4,5}以后，检索引擎还需更新商品表(辅表)Item与主表Ads之间的JoinDocMap_Item。

在一个可能的示例中，针对辅表Item与主表Ads之间的JoinDocMap_Item更新过程如图26所示，包括：步骤a-步骤c。

步骤a，检索引擎根据商品5的字段值以及辅表Item与主表Ads的连接条件生成针对广告主表的查询Q_5为“SELECT id FROM AdsWHERE"Target_Category＝＝C1 ANDTarget_Brand＝＝B1"”。

步骤b，检索引擎在主表广告表Ads对应的索引上执行查询Q_5，得到结果集RES_Ads_5＝{g1,g2,g3,g6}，即结果集RES_Ads_5中的索引对应的广告与辅表Item中新增的商品有关联关系。

步骤c，根据结果集RES_Ads_5分别更新辅表Item与主表Ads之间的正向JoinDocMap_Item和逆向JoinDocMap_Item。

在本实施例中，如图26所示，在辅表Item与主表Ads之间的正向JoinDocMap_Item中key为g1对应的Va l ue中增加商品id“5”，key为g2的Va l ue中增加商品id“5”，key为g3的Va l ue中增加商品id“5”,以及key为g6对应的va l ue中增加商品id“5”。在辅表Item与主表Ads之间的反向JoinDocMap_Item中增加key的值为5,以及key为“5”对应的Va l ue为{g1,g2,g3,g6}。

可以理解的是，当辅表User中增加用户数据以后，辅表User与主表Ads之间的JoinDocMap_User的更新过程，与辅表Item与主表Ads之间的JoinDocMap_User的更新过程相同，在此不再赘述。

(3)在主表删除数据的情况下，对JoinDocMap进行维护。

在本示例中，以图25所示的主表Ads为例。在主表Ads中删除数据g6，在检索引擎更新广告表Ads对应的广告索引{g1,g2,g3,g4,g5,g6}更新为{g1,g2,g3,g4,g5}以后，检索引擎还需要针对每个与广告表相关联的辅表更新该辅表与广告表之间的JoinDocMap。

在一个可能的示例中，针对辅表Item与主表Ads之间的JoinDocMap_Item更新过程如图27所示，包括：步骤a-步骤c。

步骤a，读取辅表Item与主表Ads之间的正向JoinDocMap_Item中key为g6对应的val ues，得到在商品索引中与g6关联的商品文档集合为{1,2,4,5}。

步骤b，删除正向JoinDocMap_Item中key为g6的键值对。

步骤c，在逆向JoinDocMap_Item中，分别删除key为1,2,4,5对应的va l ues中的g6。

在本实施例中，如图27所示，在辅表Item与主表Ads之间的正向JoinDocMap_Item中删除key值为g6,以及g6对应的Va l ue值{1,2,4,5}。在辅表Item与主表Ads之间的反向JoinDocMap_Item中删除各个key对应的Va l ue中的值g6。执行删除操作以后的辅表Item与主表Ads之间JoinDocMap_Item如图27中所示。

可以理解的是，广告表Ads中删除一条数据以后，辅表User与主表Ads之间的JoinDocMap_User的更新过程，与辅表Item与主表Ads之间的JoinDocMap的更新过程相同，在此不再赘述。

(4)在辅表删除数据记录的情况下，对JoinDocMap进行维护。

在本示例中，以图26所示的辅表Item为例。在辅表Item中删除一条id为5的文档数据，在检索引擎更新辅表Item对应的商品索引{1,2,3,4,5}更新为{1,2,3,4}以后，检索引擎还需更新商品表(辅表)Item与主表Ads之间的JoinDocMap_Item。

在一个可能的示例中，针对辅表Item与主表Ads之间的JoinDocMap_Item更新过程如图28所示，包括：步骤a-步骤c。

步骤a，读取辅表Item与主表Ads之间的逆向JoinDocMap_Item中key为5对应的val ues，得到在广告索引中与商品5关联的广告文档集合为{g1,g2,g3}。

步骤b，删除逆向JoinDocMap_Item中key为5的键值对。

步骤c，在正向JoinDocMap_Item中，分别删除key为g1,g2,g3对应的va l ues中的5。

在本实施例中，如图28所示，在辅表Item与主表Ads之间的正向JoinDocMap_Item中删除各个key对应的Va l ue中的值5。在辅表Item与主表Ads之间的反向JoinDocMap_Item中删除key值为5,以及5对应的Va l ue值{g1,g2,g3}。执行删除操作以后的辅表Item与主表Ads之间JoinDocMap_Item如图28中所示。

可以理解的是，辅表User中删除一条数据以后，辅表User与主表Ads之间的JoinDocMap_User的更新过程，与辅表Item与主表Ads之间的JoinDocMap的更新过程相同，在此不再赘述。

(5)在主表更新数据的情况下，对对JoinDocMap进行维护。

在本示例中，主表中数据的更新分为两种，在第一种情况下，主表数据更新不涉及主表与辅表相关联的关联条件中的字段。因此，主表中的数据更新前后，主表和辅表之间的连接关系不变。所以，主表与辅表之间的JoinDocMap无需进行更新，检索引擎直接更新对应主表索引。

第二种情况，主表数据更新涉及与某些辅表关联的字段，则需要对这些辅表与该主表的JoinDocMap进行更新。其中，辅表与主表之间的JoinDocMap的更新过程包括：步骤a和步骤b。

步骤a，执行主表删除流程，在主表中删除需要更新的数据，并删除对应的辅表与主表之间的正向、逆向JoinDocMap中相关数据。

在本示例中，主表中删除需要更新的数据以后，更新对应辅表与主表之间的正向JoinDocMap和逆向JoinDocMap的过程可以参照上述示例中图27所对应的JoinDocMap更新过程，在此不再赘述。

步骤b，执行主表新增流程，在主表中新增更新后的数据，并在对应的辅表与主表之间的正向、逆向JoinDocMap中新增相关数据。

在本示例中，在主表中新增更新后的数据以后，更新对应辅表与主表之间的正向JoinDocMap和逆向JoinDocMap的过程可以参照上述示例中图25所对应的JoinDocMap更新过程，在此不再赘述。

(6)在辅表更新数据的情况下，对JoinDocMap进行维护。

在本示例中，辅表中数据的更新分为两种，在第一种情况下，辅表数据更新不涉及辅表与主表相关联的关联条件中的字段。因此，辅表中的数据更新前后，辅表和主表之间的连接关系不变。所以，辅表与主表之间的JoinDocMap无需进行更新，检索引擎直接更新对应辅表索引。

第二种情况，辅表数据更新涉及与主表关联条件中的字段，因此，需要对该辅表与主表之间的JoinDocMap进行更新。其中，辅表与主表之间的JoinDocMap的更新过程包括：步骤a和步骤b。

步骤a，执行辅表删除流程，在辅表中删除需要更新的数据，并删除该辅表与主表之间的正向、逆向JoinDocMap中相关数据。

在本示例中，辅表中删除需要更新的数据以后，更新该辅表与主表之间的正向JoinDocMap和逆向JoinDocMap的过程可以参照上述示例中图28所对应的JoinDocMap更新过程，在此不再赘述。

步骤b，执行辅表新增流程，在辅表中新增更新后的数据，并在该辅表与主表之间的正向、逆向JoinDocMap中新增相关数据。

在本示例中，在辅表中新增更新后的数据以后，更新该辅表与主表之间的正向JoinDocMap和逆向JoinDocMap的过程可以参照上述示例中图26所对应的JoinDocMap更新过程，在此不再赘述。

在本申请实施例中，提供了检索引擎中JoinDocMap的数据维护方法。当被连接的数据更新时，该方法利用检索引擎针对数据表生成的索引，将数据表之间的连接关系转化为针对检索引擎的索引查询，使用查询结果集合对索引之间的JoinDocMap进行数据维护，保证关联关系JoinDocMap和对应数据、索引内容的一致性。在本申请实施例中，由于多个数据表的索引解耦更新一个数据表，不会牵连其它数据表相关数据更新，其次，在索引更新后，仅需要更新JoinDocMap，更新代价小。

可以理解的是，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。此外，在一些可能的实现方式中，上述实施例中的各步骤可以根据实际情况选择性执行，可以部分执行，也可以全部执行，此处不做限定。另外，上述实施例中的任意特征的全部或部分在不矛盾的前提下，可以自由地、任何地组合。组合后的技术方案也在本申请的范围之内。

示例性的，图29示出了本申请实施例提供的一种检索装置的结构示意图。如图29所示，该检索装置2900包括：接收模块2901、处理模块2902、输出模块2903。

接收模块2901用于接收用户输入的查询语句，所述查询语句中包括：召回字段、查询对象、搜索条件，所述搜索条件中包括：主表搜索条件和辅表搜索条件。

处理模块2902用于根据辅表搜索条件查询辅表中满足辅表搜索条件的第一辅表结果集，以及用于根据第一辅表结果集查找文档关联映射表JoinDocMap，将该第一辅表结果集转化为第一主表结果集LOOK_UP，其中，文档关联映射表JoinDocMap用于标识主表文档和辅表文档之间的映射关系。

处理模块2902还用于根据主表搜索条件查询辅表中满足主表搜索条件的第二主表结果集，以及将第二主表结果集中的主表文档与第一主表结果集中的主表文档进行比较，得到第三主表结果集，其中，第三主表结果集中的主表文档同时包含在第一主表结果集和第二主表结果集中。

处理模块2902还用于根据辅表文档与主表文档之间的文档关联关系，确定第三主表结果集中。对于第三主表结果集中的每一个主表文档，确定该主表文档关联的辅表文档，并确定该辅表文档是否包含在第一辅表结果集中。当该辅表文档包含在第一辅表结果集中时，处理模块2902将该主表文档和辅表文档进行拼接，作为查询结果文档存储在输出结果集中。

输出模块2903用于输出(或者显示)输出结果集中的查询结果文档。

图29所描述的检索装置实施例仅仅是示意性的。例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。

例如，图29中的各个模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。例如，采用软件实现时，上述处理模块2902可以是由附图9中的至少一个处理器110读取存储器120中存储的程序代码后，生成的软件功能模块来实现。图29中的上述各个模块也可以是由检索装置中的不同硬件分别实现，例如处理模块2902由附图9中至少一个处理器110中的一部分处理资源(例如多核处理器中的一个核)实现，而接收模块2901和输出模块2903由附图9的输入设备150和至少一个处理器110中的其余部分处理资源(例如多核处理器中的其他核)，或者采用FPGA、或协处理器等可编程器件来完成。显然上述功能模块也可以采用软件硬件相结合的方式来实现，例如接收模块2901和输出模块2903由硬件可编程器件实现，而处理模块2902是由CPU读取存储器中存储的程序代码后，生成的软件功能模块。

在一个可能的示例中，采用软件实现时，上述处理模块2902可以是由附图10中的至少一个处理器210读取存储器230中存储的程序代码后，生成的软件功能模块来实现。图29中的上述各个模块也可以是由检索装置中的不同硬件分别实现，例如处理模块2902由附图10中至少一个处理器20中的一部分处理资源(例如多核处理器中的一个核)实现，而接收模块2901和输出模块2903由附图9的网络接口220和至少一个处理器210中的其余部分处理资源(例如多核处理器中的其他核)，或者采用FPGA、或协处理器等可编程器件来完成。显然上述功能模块也可以采用软件硬件相结合的方式来实现，例如接收模块2901和输出模块2903由硬件可编程器件实现，而处理模块2902是由CPU读取存储器中存储的程序代码后，生成的软件功能模块。

基于上述实施例中的方法，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，当计算机程序在处理器上运行时，使得处理器执行上述实施例中的方法。

基于上述实施例中的方法，本申请实施例提供了一种计算机程序产品，其特征在于，当计算机程序产品在处理器上运行时，使得处理器执行上述实施例中的方法。

基于上述实施例中的方法，本申请实施例提供了一种计算设备，计算设备包括主板和芯片。其中，芯片集成在主板上，芯片包括至少一个存储器，用于存储程序；至少一个处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述实施例中的方法。在本申请实施例中，计算设备可以是服务器、主机等网络设备。

本申请实施例用于执行方法实施例的网络设备还可以是芯片。请参阅图30，图30为本申请实施例提供的一种芯片的结构示意图。如图30所示，芯片3000包括一个或多个处理器3001以及接口电路3002。可选的，芯片3000还可以包含总线3003。当网络设备是芯片时，网络设备中的基于通信模块所实现的操作例如可以基于芯片中的接口电路来实现，网络设备中基于处理模块所实现的操作例如可以基于芯片的处理器实现。

处理器3001可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器3001中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器3001可以是通用处理器、数字通信器(DSP)、专用集成电路(AS I C)、现场可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

接口电路3002可以用于数据、指令或者信息的发送或者接收，处理器3001可以利用接口电路3002接收的数据、指令或者其它信息，进行加工，可以将加工完成信息通过接口电路3002发送出去。

可选的，芯片3000还包括存储器，存储器可以包括只读存储器和随机存取存储器，并向处理器提供操作指令和数据。存储器的一部分还可以包括非易失性随机存取存储器(NVRAM)。

可选的，存储器存储了可执行软件模块或者数据结构，处理器可以通过调用存储器存储的操作指令(该操作指令可存储在操作系统中)，执行相应的操作。

可选的，接口电路3002可用于输出处理器3001的执行结果。

需要说明的，处理器3001、接口电路3002各自对应的功能既可以通过硬件设计实现，也可以通过软件设计来实现，还可以通过软硬件结合的方式来实现，这里不作限制。

应理解，上述方法实施例的各步骤可以通过处理器中的硬件形式的逻辑电路或者软件形式的指令完成。

本申请的实施例中的方法步骤可以通过硬件的方式来实现，也可以由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(random access memory，RAM)、闪存、只读存储器(read-only memory，ROM)、可编程只读存储器(programmable rom，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于AS I C中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。

Claims

1.一种多索引连接检索方法，其特征在于，包括：

获取用户输入的查询语句，所述查询语句中包括：数据库中主表的搜索条件和辅表的搜索条件；

基于所述主表中文档和所述辅表中文档间的文档关联映射表，将第一辅表结果集转化为第一主表结果集，其中，所述第一辅表结果集通过所述辅表的搜索条件查询所述辅表得到，所述文档关联映射表用于标识所述主表中的主表文档与辅表中的辅表文档之间的映射关系；

基于所述第一主表结果集和第二主表结果集共同包含的文档的集合，得到第三主表结果集，其中，所述第二主表结果集通过所述主表的搜索条件查询所述主表得到；

基于所述第一辅表结果集和第二辅表结果集共同包含的文档的集合，得到第三辅表结果集，所述第二辅表结果集通过所述第三主表结果集查找所述关联映射表得到；

将所述第三主表结果集中的文档和所述第三辅表结果集中的文档进行拼接，并输出拼接后得到的结果集。

2.根据权利要求1所述的方法，其特征在于，在基于所述主表中文档和所述辅表中文档间的文档关联映射表，将第一辅表结果集转化为第一主表结果集之前，所述方法还包括：

根据所述主表和所述辅表之间的关联关系，得到所述主表中的主表文档和所述辅表中的辅表文档之间的文档关联关系；

根据所述文档关联关系，得到所述主表和所述辅表之间的文档关联映射表。

3.根据权利要求1或2所述的方法，其特征在于，所述文档关联映射表包括：正向文档关联映射表和逆向文档关联映射表，所述正向文档关联映射表中的key值为主表文档id，value值为辅表文档id列表，所述逆向文档关联映射表中的key值为辅表文档id，value值为主表文档id列表。

4.根据权利要求3所述的方法，其特征在于，所述基于所述主表中文档和所述辅表中文档间的文档关联映射表，将第一辅表结果集转化为第一主表结果集，包括：

根据所述辅表与主表之间的逆向文档关联映射表，将所述第一辅表结果集转化为第一主表结果集。

5.根据权利要求3所述的方法，其特征在于，所述第二辅表结果集通过所述第三主表结果集查找所述辅表与主表之间的正向文档关联映射表得到。

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

对目标表中的文档进行更新，所述对目标表中的文档进行更新包括：在目标表中增加第一文档、在目标表中删除第二文档、或者更新目标表中的第三文档中的部分字段，其中，所述目标表为所述主表或所述辅表；

根据所述目标表中发生更新的文档，更新所述目标表对应的文档关联映射表。

7.根据权利要求6所述的方法，其特征在于，若在所述目标表中删除了第二文档，所述根据所述目标表中发生更新的文档，更新所述目标表对应的文档关联映射表，包括：

在所述目标文档对应的文档关联映射表中，删除所述第二文档以及与所述第二文档关联的辅表文档。

8.根据权利要求6所述的方法，其特征在于，所述目标表为主表；

若在所述主表中增加了第一文档，所述根据所述主表中发生更新的文档，更新所述目标表的文档关联映射表，包括：

根据所述第一文档，生成辅表上的第一查询条件；

根据所述第一查询条件查询辅表，得到辅表中与第一文档关联的文档集合；

根据所述文档集合和所述第一文档，更新所述主表与辅表之间的文档关联映射表。

9.根据权利要求6所述的方法，其特征在于，所述目标表为主表，

若更新主表中的第三文档中的部分字段，所述根据所述目标表中发生更新的文档，更新所述目标表对应的文档关联映射表，包括：

在所述第三文档更新的字段为与辅表有关联关系的情况下，在所述主表与辅表的文档关联映射表中，删除所述第三文档以及与所述第三文档关联的辅表文档；

根据更新后的第三文档，生成辅表上的第二查询条件；

根据所述第二查询条件查询辅表，得到辅表中与第三文档关联的文档集合；

根据所述文档集合和所述更新后的第三文档，更新所述主表与辅表之间的文档关联映射表。

10.根据权利要求6所述的方法，其特征在于，所述目标表为辅表，

若在所述辅表中增加了第一文档，所述根据所述目标表中发生更新的文档，更新所述目标表对应的文档关联映射表，包括：

根据所述第一文档，生成主表上的第三查询条件；

根据所述第三查询条件查询主表，得到主表中与第一文档关联的文档集合；

11.根据权利要求6所述的方法，其特征在于，所述目标表为辅表，

在所述第三文档更新的字段为与主表有关联关系的情况下，在所述主表与辅表的文档关联映射表中，删除所述第三文档以及与所述第三文档关联的主表文档；

根据更新后的第三文档，生成主表上的第四查询条件；

根据所述第四查询条件查询主表，得到主表中与第三文档关联的文档集合；

12.一种检索系统，其特征在于，包括：

接收模块，用于获取用户输入的查询语句，所述查询语句中包括：数据库中主表的搜索条件和辅表的搜索条件；

处理模块，用于根据所述主表中文档和所述辅表中文档间的关联映射表，将第一辅表结果集转化为第一主表结果集，其中，所述第一辅表结果集通过所述辅表的搜索条件查询所述辅表得到，所述文档关联映射表用于标识所述主表中的主表文档与辅表中的辅表文档之间的映射关系；

所述处理模块，还用于根据所述第一主表结果集和第二主表结果集共同包含的文档的集合，得到第三主表结果集，其中，所述第二主表结果集通过所述主表的搜索条件查询所述主表得到；

所述处理模块，还用于根据所述第一辅表结果集和第二辅表结果集共同包含的文档的集合，得到第三辅表结果集，所述第二辅表结果集通过所述第三主表结果集查找所述关联映射表得到；

输出模块，用于将所述第三主表结果集中的文档和所述第三辅表结果集中的文档进行拼接，并输出拼接后得到的结果集。

13.根据权利要求12所述的系统，其特征在于，在基于所述主表中文档和所述辅表中文档间的文档关联映射表，将第一辅表结果集转化为第一主表结果集之前，所述处理模块还用于：

14.根据权利要求12或13所述的系统，其特征在于，所述文档关联映射表包括：正向文档关联映射表和逆向文档关联映射表，所述正向文档关联映射表中的key值为主表文档id，value值为辅表文档id列表，所述逆向文档关联映射表中的key值为辅表中文档id，value值为主表文档id列表。

15.根据权利要求14所述的系统，其特征在于，所述处理模块用于：

16.根据权利要求14所述的系统，其特征在于，所述处理模块还用于：

获取第二辅表结果集，所述第二辅表结果集通过所述第三主表结果集查找所述辅表与主表之间的正向文档关联映射表得到。

17.根据权利要求12或13所述的系统，其特征在于，所述处理模块还用于：

18.根据权利要求17所述的系统，其特征在于，若在所述目标表中删除了第二文档，所述处理模块用于：

19.根据权利要求17所述的系统，其特征在于，所述目标表为主表，若在所述主表中增加了第一文档，所述处理模块用于：

根据所述第一文档，生成辅表上的第一查询条件；

20.根据权利要求17所述的系统，其特征在于，所述目标表为主表，若更新主表中的第三文档中的部分字段，所述处理模块用于：

根据更新后的第三文档，生成辅表上的第二查询条件；

21.根据权利要求17所述的系统，其特征在于，所述目标表为辅表，若在所述辅表中增加了第一文档，所述处理模块用于：

根据所述第一文档，生成主表上的第三查询条件；

22.根据权利要求17所述的系统，其特征在于，所述目标表为辅表，若更新主表中的第三文档中的部分字段，所述处理模块用于：

根据更新后的第三文档，生成主表上的第四查询条件；

23.一种检索装置，其特征在于，包括：

存储器，用于存储程序；

处理器，用于执行所述存储器存储的程序，当所述存储器存储的程序被执行时，所述处理器用于执行如权利要求1-11任一所述的方法。

24.一种计算机可读介质，所述计算机存储介质中存储有指令，当所述指令在计算机上运行时，使得计算机执行如权利要求1-11任一所述的方法。

25.一种包含指令的计算机程序产品，当所述指令在计算机上运行时，使得所述计算机执行如权利要求1-11任一所述的方法。