位向量搜索索引的制作方法

背景技术：

互联网和其他电子资源上的可用信息和数字内容的数量继续快速增长。考虑到大量的信息，搜索引擎已经被开发出来以便于搜索电子文档。具体地，用户或计算机可以通过提交搜索查询来搜索信息和文档，该搜索查询可以包括比如一个或多个字。在接收到搜索查询之后，搜索引擎基于搜索查询来标识相关的文档。

在高层次上，搜索引擎通过对文档与搜索查询的相关性进行排名来标识搜索结果。排名通常基于大量的文档特征。考虑到庞大的文档集，针对搜索查询，对所有文档进行排名是不可行的，因为这将花费无法接受的时间量。因此，搜索引擎通常采用包括从最终排名过程的考虑中移除文档的初级操作的流水线。该流水线传统上包括匹配器，其从搜索查询中过滤掉没有项目的文档。匹配器使用搜索索引进行操作，该搜索索引包括通过爬寻文档或以其他方式分析文档以收集关于文档的信息而收集的信息。搜索索引通常由在文档中找到的各种项目的倒排列表(postinglist，有时被称为倒排索引)组成。特定项目的倒排列表由包含项目的文档列表组成。当接收到搜索查询时，匹配器采用搜索索引来标识包含从搜索查询中标识的项目的文档。然后，可以通过流水线中的一个或多个下游过程来考虑匹配文档，该下游过程进一步移除文档并且最终返回排名后的搜索结果集合。

技术实现要素：

提供本发明内容是为了以简化形式介绍下文将在具体实施方式中进一步描述的概念的选择。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用作确定所要求保护的主题的范围的辅助。

本文中所描述的技术提供了一种搜索系统，其使用位向量来索引数据，而非传统倒排列表。位向量包括数据结构，其试图最大化信息密度，以在现有搜索系统上产生大的效率增加。按照本文中所描述的技术的位向量搜索索引使用若干个位向量来索引关于文档的信息。位向量包括位阵列，其存储关于项目集合的信息。位向量中的每个位位置(或位)指示一个或多个文档是否包含来自项目集合的一个或多个项目。因为位向量可以与项目集合相对应，所以它不能从单个位向量中的设定位得知，那些项目中的哪个项目被包含在与该设定位相对应的文档中。为了解决这个问题，项目可以被包括在多个位向量中。

附图说明

下文参考附图对本文中所提供的技术的各方面进行详细描述，其中

图1是图示了按照本文中所描述的技术的一方面的用于单个项目的位向量的图；

图2是图示了按照本文中所描述的技术的一方面的用于三个项目的组合的位向量的图；

图3是图示了按照本文中所描述的技术的一方面的包括多个位向量中的项目的图；

图4a至图4c是图示了按照本文中所描述的技术的一方面的将位向量相交以标识包括项目的文档的图；

图5是图示了按照本文中所描述的技术的一方面的每位具有不同数目的文档的位向量的图；

图6是图示了按照本文中所描述的技术的一方面的使用位向量来生成搜索索引的方法的流程图；

图7是图示了按照本文中所描述的技术的一方面的使用位向量的简化搜索索引700的图；

图8是图示了按照本文中所描述的技术的一方面的用于匹配器以标识匹配来自搜索查询的项目的文档的方法的流程图；

图9是图示了按照本文中所描述的技术的一方面的首先使用短位向量将位向量相交的方法的流程图；

图10是图示了按照本文中所描述的技术的一方面的可用于来自搜索查询的项目的位向量的示例的图；

图11是图示了按照本文中所描述的技术的一方面的排序用于交叉的位向量的图；

图12是图示了按照本文中所描述的技术的一方面的形成查询计划的图；

图13是图示了按照本文中所描述的技术的一方面的用于查询计划的树的图，其中每个框与位向量相对应；

图14至图17是图示了按照本文中所描述的技术的一方面的按照图13的查询计划的树的位向量的交叉的图；

图18是图示了按照本文中所描述的技术的一方面的用于匹配器以生成匹配器计划的方法的流程图，该匹配器计划提供用于交叉位向量的有效次序；

图19是图示了按照本文中所描述的技术的一方面的使用加强行来匹配文档的方法的流程图；

图20a至图20b是图示了按照本文中所描述的技术的一方面的使用用于短语的位向量的示例的图；

图21是提供长文档的示例的图；

图22是图示了按照本文中所描述的技术的一方面的使用位向量来生成用于搜索索引的分片(shard)的方法的流程图；

图23是图示了按照本文中所描述的技术的一方面的用于使用多个分片来执行搜索的方法的流程图；

图24是图示了按照本文中所描述的技术的一方面的用于生成数据结构的方法的流程图，该数据结构(诸如条带表)将项目特点映射到位向量配置；

图25是图示了按照本文中所描述的技术的一方面的使用显式映射和adhoc(即席)信息来确定位向量存储位置的方法的流程图；

图26是图示了按照本文中所描述的技术的一方面的用于搜索查询的行修整/扩充的方法的流程图；

图27是图示了按照本文中所描述的技术的一方面的用于搜索查询的行修整/扩充的另一方法的流程图；

图28是图示了按照本文中所描述的技术的一方面的用于将文档添加到基于位向量的搜索索引的方法的流程图；

图29是图示了具有长度随所标识的文档的“列”变化的位向量集合的简化搜索索引的图；

图30是图示了按照本文中所描述的技术的一方面的用于从位向量搜索索引中移除文档的方法的流程图；

图31a至图31d是图示了按照本文中所描述的技术的一方面的从位向量搜索索引移除文档的图；

图32a和图32b是图示了将文档添加到阵列的图；

图33a至图33d是图示了将文档添加到阵列的其他图；

图34a和图34b是分别图示了将文档复制到较大阵列并且开始新阵列的图；

图35a至图35h是图示了将文档写入阵列并且将文档从阵列复制到阵列的图；

图36是图示了在不同类型的存储器上存储不同阵列的图；

图37是图示了按照本文中所描述的技术的一方面的使用累积缓冲器来索引位向量搜索索引中的文档的方法的流程图；

图38是图示了按照本文中所描述的技术的一方面的提供初级排名的示例性系统的框图；

图39是图示了按照本文中所描述的技术的一方面的基于与搜索查询的相关性来对多个文档进行评分的方法的流程图；

图40是图示了按照本文中所描述的技术的另一方面的基于与搜索查询的相关性来对多个文档进行评分的方法的流程图；

图41是图示了按照本文中所描述的技术的一方面的用于将项目的数据添加到得分表的空隙的方法的流程图；

图42是图示了按照本文中所描述的技术的一方面的用于采用匹配修正以从概率匹配器移除下游的无效匹配文档的方法的流程图；

图43是图示了按照本文中所描述的技术的一方面的用于采用匹配修正以从概率匹配器移除下游的无效匹配文档的另一方法的流程图；

图44是图示了其中可以采用本文中所描述的技术的各方面的示例性搜索系统的框图；以及

图45是适用于实现本文中所描述的技术的各方面的示例性计算环境的框图。

具体实施方式

本文中所提供的技术的各方面的主题在本文中进行具体描述以满足法定要求。然而，描述本身并不旨在限制本专利的范围。而是，发明人已经设想，所要求保护的主题还可以结合其他当前或未来的技术以其他方式来实现，以包括与本文中所描述的步骤类似的不同步骤或步骤的组合。此外，尽管术语“步骤”和/或“框”在本文中可以用于暗示所采用的方法的不同元件，但是这些术语不应该被解释为暗指本文中所公开的各个步骤之中或之间的任何特定顺序，除非以及除了各个步骤的次序被明确描述。

本文中所描述的每个方法可以包括计算过程，其使用硬件、固件和/或软件的任何组合来执行。比如，各种功能可以由执行存储在存储器中的指令的处理器执行。该方法还可以被实现为存储在计算机存储介质上的计算机可用指令。这些方法可以由独立应用、服务或托管服务(独立或与其他托管服务组合)、或者插件向另一产品提供，仅举以上几例。

可替代地或附加地，本文中所描述的功能性可以至少部分地由一个或多个硬件逻辑部件来执行。例如，但不限于，可以使用的说明性类型的硬件逻辑部件包括现场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、片上系统(soc)、复杂可编程逻辑器件(cpld)等。

当评估搜索系统的设计时，可能会考虑若干个度量。一个度量是搜索系统用来索引关于文档语料库的信息的存储消耗。该度量可以是若干个文档的测量，其可以在搜索系统(“d”)中的每个机器上被索引。另一度量是用于搜索查询的处理速度。该度量可以是每秒由搜索系统(“q”)处理的若干个查询的测量。搜索系统的设计中的另一考虑在于即使搜索索引需要被周期性地更新它也应该始终可用于索引关于文档改变和新文档的信息。在一些设计中，搜索系统通过下载索引服务器的库来更新它们，同时使其他库运行，使得所有库随时间而被更新。随着互联网上可用文档的不断增加，更新搜索索引的时间不断上升至目前的设计可能变得不可行的程度。最后，用于搜索系统的另一设计目标可以在新文档变得可用时，快速更新搜索索引。在信息变得可用时，这对于索引信息(诸如其中用户希望接近实时地看到信息的新闻或社交馈送)是特别理想的。

当考虑上述设计度量时，传统使用的倒排列表(或倒排索引)会存在若干个缺点，其影响有多少文档可以被存储在搜索系统(d)中的机器上以及查询(q)的处理速度这两者。倒排列表保持被排序，以使两个倒排列表的连接(或交叉)可以被有效地执行。然而，重新排序倒排列表使得信息的即时更新不切实际，因为每次更新都必须重建大量的数据。因此，倒排列表通常需要批量更新来分摊大量更新的排序成本。为了加快查询处理速度，倒排列表中添加了若干复杂性，诸如跳过列表，其当在倒排列表中搜索包含搜索查询项目的匹配文档时，提供了跳过文档的方式。附加地，因为倒排列表通常按文档来排序，所以如果添加新文档，则可能必须插入倒排列表的中间的某个位置。鉴于这些复杂性，倒排列表不会允许快速插入新文档或文档改变，相反可能需要重写倒排列表。即使该设计确实有助于插入新文档或文档改变，但是因为跳过列表和/或添加到倒排列表中的其他复杂性以便于查询处理，所以插入它可能会非常复杂。因此，更新用于庞大文档(诸如可通过互联网获得的文档)的语料库的搜索索引的时间可能会继续增加至其损坏搜索系统的可用性的程度。附加地，这些问题对搜索系统提供用于新近可用信息(例如，新闻、社交馈送等)的实时搜索结果的能力产生了负面影响。

本文中所描述的技术的各方面采用若干种技术来在现有搜索系统上产生效率的大幅提高(例如，随着即时更新，在所有搜索引擎上为2倍至3倍，在搜索引擎上为10倍)。这包括用试图在i/o信道上最大化信息密度的数据结构来替换倒排列表。比如，在今天的xeon计算机中，限制信道可能是从存储器到cpu的路径，其中存储器可能是比如双倍数据速率随机存取存储器(ddrram或ddr)、固态驱动器(ssd)或硬盘驱动器(hdd)。数据的组织主要通过熵来优化，以便逼近理论最大信息密度。本文中所描述的技术的各方面采用概率途径，其允许在匹配过程期间出现假阳性结果。换句话说，匹配器可以返回不包含来自搜索查询的项目的文档。这与精确的倒排列表相反——匹配器只会返回包含来自搜索查询的项目的文档。然而，由本文中所描述的各种配置所采用的技术所产生的效率改进如此深刻，以至于即使在后期阶段考虑到移除假阳性的成本时，与利用该倒排列表的系统相比较，匹配的总成本显著降低。附加地，虽然匹配器可能会返回假阳性，但不会移除真正匹配的文档(除了在使用not运算符时)。

图44提供了示出了提供本文中所描述的特征的概览的示例性搜索系统4400的框图。应当理解，本文中所描述的这种和其他布置仅作为示例被阐述。除了所示的那些之外或者替代所示的那些，可以使用其他布置和元件(例如，机器、接口、功能、次序和功能的分组等)，并且一些元件可以被完全省略。进一步地，本文中所描述的元件中的许多元件是功能实体，其可以被实现为离散或分布式部件或结合其他部件来实现，并且以任何合适组合和位置来实现。本文中被描述为由一个或多个实体执行的各种功能可以由硬件、固件和/或软件来执行。比如，各种功能可以由执行存储在存储器中的指令的处理器来执行。尽管图44示出了具有若干个不同特征的搜索系统4400，但是应该理解，搜索系统可以采用与本文中所讨论的其他特征无关的特征中的任意特征。

如图44所示，搜索系统4400采用位向量搜索索引4410而非使用倒排列表的搜索索引。位向量搜索索引4410使用若干个位向量来表示索引文档。如下文将更详细描述的，位向量是存储用于项目集合的信息的位阵列。位向量中的每个位位置(或位)与一个或多个文档是否包含来自项目集合的一个或多个项目的断言相对应。如本文中所使用的，“文档”是指其中信息可以由搜索系统来索引的任何电子内容项目。电子内容项目不限于文本，并且可以包括比如图像、音频、视频、地理数据等。如本文中所使用的，“项目”与关于文档的任何断言相对应，其包括文档包含一个或多个特定字的断言。在一些实例中，项目可能是单个字；而在其他实例中，项目可能是多字短语。“字”是指任何数目的符号(例如，字母、数字、标点符号等)或任何二进制数据(诸如散列、索引、id等)。在一些配置中，项目可能是“元字(metaword)”，其可以对字或字集合之外的其他类型的断言进行编码。比如，项目可能与文档用法语书写的断言相对应。

因为位向量可以与项目集合相对应，所以位向量在它不会从那些项目中的哪个项目被包含在与设定位相对应的文档中的单个位向量中的设定位得知的这个意义上讲包括噪声。为了解决这个问题，项目可能被包括在多个位向量中。为了标识包含给定项目的文档，与该项目对应的位向量被标识并且交叉。包含项目的文档被标识为与用于该项目的位向量中的每个位向量中设置的某个位相对应的文档。应该指出，该描述的大部分讨论了位向量的交叉。然而，配置还可以采用联合和否定，如此，在提及交叉的情况下，可以代之以联合或否定。

位向量可以包括长位向量和短位向量两者。长位向量是其中每个位与单个文档相对应的位向量。因此，长位向量中的位指示与该位相对应的文档是否包含与该位向量相对应的项目中的一个或多个项目。短位向量是其中每个位与两个或更多个文档相对应的位向量。因此，短位向量中的位指示与该位相对应的两个或更多个文档中的任一文档是否包含与该位向量相对应的项目中的一个或多个项目。搜索索引可以存储不同长度的短位向量(例如，每位两个文档、每位四个文档、每位八个文档等)。

使用基于位向量的搜索索引提供了优于倒排列表的若干个益处。比如，通过使用位序列，该途径通过避免倒排列表的复杂性(包括需要对文档进行排序以及使用跳过列表)来创建非常高的效率。这尤其允许对搜索索引进行即时或近乎即时的更新，从而防止停机时间过长以更新搜索索引，并且便于实时或接近实时地添加新的/改变后的文档(例如，用于新闻、社交馈送等)。附加地，系统的设计可以被配置成满足q和d设计目标。比如，该途径可以在不牺牲d的情况下(即，高d，而d与现有系统相当)提供极高的q。作为另一示例，该途径可以在不牺牲q的情况下(即，高d，而q与现有系统相当)提供高d。

在一些配置中，基于位向量的搜索索引被划分成不同的分片4412，如图44所表示的。每个分片索引与文档长度的不同范围(例如，为文档索引的独特项目的数目)相对应的不同文档集合。比如，第一分片可以索引具有0至100个项目的文档，第二分片可以索引具有101至200个项目的文档，第三分片可以索引具有201至300个项目的文档等。这解决了当长度变化很大的文档一起被存储时丢失的效率的问题。比如，如果非常长的文档(即，很多项目被索引)与非常短的文档(即，只有很少项目被索引)一起被存储，则长文档的列将设置很多位，而短文档的列将设置非常少的位。如本文中所使用的，“列”是指每个位向量中与给定文档或文档组相对应的位。这使得在位向量中难以维护均匀位密度(即，被设置为“1”的位的百分比)。通过对分片中相似长度的文档进行分组，可以以更好地控制位密度的方式来配置项目的分布。

基于位向量的搜索索引中的项目的分布可以通过将不同的位向量配置指派给不同的项目来在一些配置中实现。项目的位向量配置表示用于项目的位向量的数目和长度，并且还可以指定每个位向量的存储类型(例如，ddr、ssd、hdd等)。按照本文中所描述的技术的一些方面，可以基于项目特点将项目分组为频带，并且可以为每个频带指派特定的位向量配置。这避免了在每一项目的基础上指派位向量配置的复杂性，并且避免了对于所有项目使用单位向量配置的一刀切式解决方案的低效率。项目特点到位向量配置的映射可以由搜索系统4400存储在数据结构中，诸如在图44所示的条带表4414中。

一些配置对用于项目的位向量的存储位置的标识进行寻址。比如，当生成和更新搜索索引时，位向量存储位置被标识。附加地，为了标识用于搜索查询的匹配文档的目的，当检索位向量时，位向量存储位置被标识。按照本文中所描述的技术的一些方面，采用了用于标识位向量存储位置的混合途径。为一些项目提供了显式映射。比如，这可能包括在搜索查询和/或文档中出现频率最高的项目。显式映射为每个项目标识特定的位向量存储位置。显式映射可以由搜索系统4400存储在数据结构中，诸如图44所示的项目表4416。对于其他项目，采用了adhoc途径。具体地，可以为与特定项目特点相对应的项目的频带提供了映射算法。可以采用每个频带的映射算法来得出具有指派给每个对应频带的项目特点的项目的位向量存储位置。每个映射算法可以比如根据项目的散列来确定存储位置。映射算法与项目特点的对应关系可以由搜索系统4400存储在数据结构中，诸如在图44所示的条带表4414中。

搜索系统4400可以在索引生成时间和查询时间这两者处使用条带表4414和项目表4416。如本文中所使用的，“索引生成时间”是指用于索引关于搜索索引中的文档的信息的过程。这包括最初生成搜索索引，以及通过添加/更新/移除文档来随时间而递增地更新搜索索引。如本文中所使用的，“查询时间”是指处理搜索查询以返回搜索结果。条带表4414和项目表4416可以在索引生成时间由索引器4418使用以索引关于位向量搜索索引4410的位向量中的文档的信息。具体地，条带表4414和项目表4416可以用于标识项目的位向量配置，并且当将文档信息添加到位向量搜索索引4410时，标识项目的位向量位置。在查询时间，匹配器4404可以采用条带表4414和/或项目表4416来标识用于从所接收的搜索查询中标识的项目的位向量位置。

索引器4418可以操作以从位向量搜索索引4410添加和/或移除文档。向位向量搜索索引4410添加文档可以简单地需要标识文档的“列”(即，与该文档相对应的每个位向量中的位)，并且基于该文档中的项目的存在来设置与该列相对应的位向量中的位。在一些实例中，可以采用更快的存储设备(例如，ddrram)来存储位向量，并且文档可以一次索引一个。在其他实例中，较慢的存储设备(例如，ssd；hdd)当写入位向量时可能呈现一些效率低下。因而，一些配置采用本文中被称为“累积缓冲器”的内容以将文档索引到较慢的存储设备以抵消效率低下。通常，文档可以在累积缓冲器中的位向量中进行最初索引。一旦满足阈值(例如，基于时间；基于文档)，信息就从累积缓冲器被传送到另一存储设备。根据设计目标，可以采用任何数目和大小的累积缓冲器来将文档索引到最终存储设备。

图44图示了用于为搜索查询4402提供排名后的搜索结果4428的多级途径。当搜索系统4400接收到搜索查询4402时，基于搜索查询4402来标识项目。这些项目可以是如恰好包括在搜索查中的项目、和/或基于搜索查询4402中的项目得出的项目。匹配器4404操作以基于来自搜索查询4402的项目来标识匹配文档4420的集合。匹配器4404包括位向量选择部件4406，其通常操作以从位向量搜索索引4410中选择用于这些项目的位向量。匹配器4406还包括位向量处理部件4408，该位向量处理部件4408操作以交叉(或者执行联合或排除(例如，非))所选择的位向量以标识匹配文档4420的集合。

位向量选择部件4406可以采用若干种技术来选择用于交叉的位向量，以便控制所返回的匹配文档。本文中所描述的技术的一些方面可以在其中可以返回太多匹配文档的实例中采用在本文中被称为“加强行”位向量的内容。“加强行”位向量是为了减少匹配文档的数目而添加的用于交叉的附加于项目位向量的位向量。作为示例，加强行位向量可以基于文档的静态排名。具体地，位向量可以具有针对具有最高静态排名的文档(例如，基于静态排名的前10％个文档)设置的位。添加这样的静态排名位向量会将匹配文档限制于具有匹配来自搜索查询4402的项目的最高静态排名的文档。可以使用的另一加强行位向量是标识文档中的非主体位置(而非文档中的任何位置)中的项目的位向量(例如，标题或锚点文本)。

位向量选择部件4406在选择位向量时可以使用的另一种技术在本文中被称为行修整/扩充。通常从所接收的搜索查询中可以得到每个项目的若干个位向量，并且可以将位向量存储在不同类型的存储器中(例如，ddr、ssd、hdd等)。位向量选择部件4406可以决定选择可以从搜索查询4402得到的项目的位向量中的哪个位向量以供交叉。选择可以基于某个相关性度量、期望返回的匹配文档的数目的估计、每个位向量所处的存储类型、以及其他考虑。控制选择哪些可用位向量以供交叉，匹配文档的相关性(例如，假阳性的数目)和处理速度可以基于搜索系统4400的设计目标来调整。

由匹配器4404返回的匹配文档4420的集合可能包括太多的匹配文档而不能将它们全部可行地发送到最终排名器4426，其在每个文档所需的处理的数量的这个意义上将可能是昂贵的。附加地，因为位向量搜索索引提供了概率途径，所以在这些文档不包含来自搜索查询的项目的这个意义上，匹配文档4420中的一些匹配文档可能是无效的匹配文档(即，假阳性)。因而，搜索系统4400可以采用匹配器4404与最终排名器4426之间的一个或多个阶段来在到达最终排名器4426之前从考虑中移除匹配文档。

一个或多个初级排名器(诸如初级排名器4422)可以提供较不昂贵的文档排名，以便更快地从考虑中移除一些文档。通常，初级排名器可以采用来自倒排列表的信息。因为搜索系统4400没有采用倒排列表，所以可以采用其他途径。按照本文中所描述的技术的一些方面，得分表4430可以被初级排名器用于基于它们与搜索查询的相关性来对匹配文档进行评分。文档的得分表存储用于得出文档中的项目和其他信息的频率的预先计算的数据。因而，初级排名器4422可以采用每个匹配文档的得分表和来自搜索查询4402的项目以确定每个匹配文档的评分。最低评分的文档可能从进一步考虑中移除。

搜索系统4400还可以采用匹配修正阶段来移除无效的匹配文档。通常，匹配修正部件4424可以采用每个文档的表示来标识有效的匹配文档和无效的匹配文档。该表示可以是比如存储每个文档的项目列表的正向索引。任何无效的匹配文档都可以由匹配修正部件4424移除，使得它们不被最终排名器考虑。

使用位向量的搜索索引

本文中所描述的技术的各方面中的搜索索引采用位向量，而非传统上由搜索索引使用的倒排列表。位向量包括位阵列(即，1和0)。在其最简单的形式中，位向量可以与特定项目相对应，并且每个位与特定文档相对应。为文档设置的位指示该文档包含项目。相反，没有为文档设置的位指示该文档不包含项目。

图1概念性地图示了项目a的位向量100。图1所示的24个框中每个框与阵列中的位相对应，每个位与不同的文档相对应。因而，位向量100对关于24个文档中的每个文档是否包含项目a的信息进行编码。在本示例中，用字母a标记的框102、104、106表示已经设置的位，从而指示与那些位相对应的文档包含项目a。因此，位向量100标识包含项目a的24个文档的集合中的三个文档。在概念上，位向量100被示为行，并且项目“位向量”和“行”在本文中可以互换使用。

实际上，对于索引庞大的文档集合的搜索引擎，使用位向量来表示单个项目是不切实际的。具体地，位向量将包括与庞大的文档集合相对应的非常大量的位，并且需要扫描整个位阵列以找到已经设置的位。对于许多项目来说，位向量可能是非常稀疏的(即，只有小的百分比的位被设置)，由于只有小部分的所索引的文档包含该项目。结果，位向量可能不会呈现紧凑的解决方案，并且因此需要大量存储器来存储索引，并且处理搜索查询可能花费无法接受的时间数量。

为了解决这个稀疏性问题，使用在本文中被称为“行共享”的技术，其中多个项目被包括在位向量中以增加位向量的位密度(即，针对位向量设置的位的百分比)。在概念上，这可以通过对项目中的每个项目取位向量并且创建那些位向量的联合来完成。比如，图2图示了用于项目a的位向量202，用于项目b的位向量204以及用于项目c的位向量206。包含项目a、b和c的位向量208可以被生成为位向量202、204和206的联合。可以从图2中看出，位向量202、204，206中的每个位向量仅设置有三个位，并且与设置有九个位的位向量208相比较而言是稀疏的。如此，将三个项目组合在单个位向量中增加了位密度。位向量208设置有九个位，而非如在位向量202、204和206中的每个位向量中那样设置三个位。

在位向量中包括多个项目的一个后果在于单个位向量没有提供足够的信息而基于该文档的位向量中设置的位来确定文档包含哪个项目。在其中位向量包括项目a、b和c的图2的示例中，为文档设置位指示文档包含a、b或c或那些项目的某个组合。然而，不能从位向量中的单个位来确定文档包含项目中的哪个项目。因此，需要一种机构来确定文档包含哪个项目。

本文中所描述的技术的各方面通过在具有不同项目的多个位向量中包括项目来解决由于在位向量中具有多个项目而产生的这个问题。这种技术在这里被称为“项目副本”。图3图示了项目副本的概念。如图3所图示的，三个位向量302、304和306均包括项目a。然而，其他包括的项目在三个位向量302、304和306中是不同的。具体地，附加于项目a，位向量302还包括项目b和项目c，位向量304包括项目d和项目e，位向量306包括项目f和项目g。

可以通过其中包含项目的位向量被交叉的在本文中被称为“行交叉”的技术来确定哪些文档包含特定项目的标识。交叉位向量会移除噪声(即，基于其他项目的存在来设置的位)以标识哪些文档包含期望的项目。继续图3的示例，图4a是与三个位向量402、404和406中的其他项目一起被包括的项目a的另一表示。如此，存在具有相关信号(即，项目a的存在)和未校正的噪声(其他项目，即，b，c，d，e，f，g的存在)的三个位向量。在图4a的示例中，噪声位用影线来示出。

噪声中的一些噪声可以通过交叉位向量404和位向量406而被移除。交叉的结果是具有仅在其中为位向量404和406设置位的位置中设置的位的图4b所示的位向量408。这包括第四位置、第七位置、第十一位置、第十六位置和第十八位置。将该位向量408与位向量402交叉会产生图4c所示的位向量410，其包括仅在其中为位向量408和402设置位的位置中设置的位。如图4c所表示的，位向量410包括为第四位置、第十一位置和第十八位置设置的位。这些与包含项目a的文档相对应。因而，通过标识包括项目a的位向量并且交叉那些位向量，包含项目a的文档被标识。虽然图4a至图4c提供了简化的示例，其中包含特定项目的文档仅被标识(即，没有假阳性)，但是实际上，行交叉可以被设计成指数级地减少噪声(即，假阳性)，尽管一些假阳性可以在行交叉之后呈现。

如果大量文档被索引并且位向量的每个位与单个文档相对应，则位向量会是长阵列，并且交叉位向量可能过于耗时。为了解决这个问题，可以采用每位包括多个文档的位向量。在每位具有多个文档的位向量中，如果共享位的一个或多个文档包含位向量的项目中的一个项目，则设置该位。

图5图示了每位具有不同数目的文档的位向量的概念。最初，位向量502图示了先前所讨论的位向量，其中每个位与单个文档相对应。其中每位有一个文档的位向量(诸如位向量502)在本文中被称为“长行”位向量。如图5所示，位向量502包括与32个文档相对应的32个位。已经为第四文档、第十九文档、第二十五文档和第二十七文档设置了位。

位向量504、506、508在本文中被称为“短行”位向量，因为每个位包括两个或更多个文档，从而提供较短的位阵列。位向量504每位包括两个文档(总共16位)，位向量506每位包括四个文档(总共八个位)，并且位向量508每位包括八个文档(总共四个位)。图5中所示的位向量504、506、508中的每个位向量与来自位向量502的项目和文档相对应。较短的位向量中的每个位与来自较长位向量的多个位相对应。比如，对于位向量504(每位2个文档)，第一位(位位置0)与位向量502中的位位置0和16相对应，而第二位(位位置1)与位向量502中的位位置1和17相对应等。对于位向量506(每位4个文档)，第一位(位位置0)与位向量502中的位位置0、8、16和24相对应，而第二位(位位置1)与位向量502中的位位置1、9、17和25相对应等。对于位向量508(每位8个文档)，第一位(位位置1)与位向量502中的位位置0、4、8、12、16、20、24和28相对应，而第二位(位位置0)与位向量502中的位位置1、5、9、13、17、21、25和29相对应等。

如果在位向量502中设置了对应位中的一个位，则设置位向量504、506、508中的每个位向量中的位。以下是用于说明这点的示例。因为在位向量502中既没有设置位0也没有设置位16，所以位向量504中的位0未被设置。然而，因为在位向量502中设置位2和位18中的至少一个位(即，设置位18)，所以在位向量504中设置位2。在位向量506中设置位3，因为在位向量502中设置位3、11、19和27中的至少一个位(即，设置位3)。位向量508中的位2被设置，因为在位向量502中设置位2、6、10、14、18、22、26和30中的至少一个位(即，设置位18和26)。

如本文中所使用的，如果位向量每位具有2ⁿ个文档，则短行位向量可以被称为“秩-n”位向量。例如，位向量502可以被称为排名-0位向量(因为它每位包含2⁰＝1个文档)，所以位向量504可以被称为排名-1位向量(因为它每位包含2¹＝2个文档)，位向量506可以被称为排名-2位向量(因为它每位包含2²＝4个文档)，并且位向量508可以被称为排名-3位向量(因为它每位包含2³＝8个文档)。

现在转到图6，提供了图示了使用位向量来生成搜索索引的方法600的流程图。方法600可以至少部分地比如使用图44的索引器4418来执行。如框602所示，项目被指派给位向量。如上文所讨论的，可以将每个项目指派给多个位向量。附加地，多个项目被指派给位向量中的至少一些位向量；尽管一些位向量可能仅指派单个项目。位向量中的一些位向量被建立为长行位向量，其中每个位与单个文档相对应，并且位向量中的一些位向量被建立为短行位向量，其中每个位与多个文档相对应。

如框604所示，文档被指派给位向量中的位位置。在长行位向量中，每个文档与位向量中的单个位位置相对应。在短行位向量中，多个文档与每个位位置相对应。文档被指派给短行位向量中的位位置，其与被指派给长行位向量中的文档的位位置相对应。应该理解，可以采用多种不同途径中的任一种途径来定义排名之间的位对应关系。在一些配置中，排名之间的位对应关系基于以下等式：

等式1：排名r的行中的四倍字j的第i位映射到排名r+1的行中的四倍字中的第i位。

等式2：排名r的行中的四倍字j的第i位映射到排名r-1的行中的四倍字2j和2j+1中的第i位。

如框606所示，基于文档中存在项目，在位向量中设置位。对于每个文档，包含在文档中的项目被标识，与每个项目相对应的位向量被标识，并且在那些位向量中的每个位向量中标识并且设置指派给文档的位。在一些实例中，当处理不同的项目和/或文档时，可能已经设置位。

图7图示了使用位向量的非常简单的搜索索引700的示例。搜索索引700存储16个位向量，每个位向量包括位阵列。位向量包括四个长行位向量702，其中每个位与单个文档相对应。从图7中可以看出，每个长行位向量702包括32个位，使得搜索索引700索引用于32个文档的信息。搜索索引700还存储若干个短行位向量。具体地，搜索索引700存储四个排名-1位向量704(即，每位两个文档)，四个排名-2位向量706(即，每位四个文档)和四个排名-3位向量708(即，每位八个文档)。

每个位向量可以与多个项目相对应。附加地，每个项目可以被包括在至少一个长行位向量和至少一个短行位向量中。因而，长行位向量中的每个位表示特定文档是否包含与位向量相对应的来自项目集合的至少一个项目。短行位向量中的每个位表示文档集合中的至少一个文档是否包含与位向量相对应的来自项目集合的至少一个项目。从图7和上述讨论中可以看出，每个位向量包括在存储器中连续的位，以表示哪些文档包含由位向量表示的项目中的一个或多个项目。相比之下，指示文档包含哪些项目的文档的位被散布在位向量之中，并且因此在存储器中是不连续的。由于与来自查询的项目相对应的位向量的位在存储器中是连续的，并且因此可以被快速取回，所以这种途径支持服务搜索查询。

搜索索引中的项目分布

使用位向量的搜索索引中的项目的分布可以基于搜索索引的期望的设计优化来配置，其包括存储要求(例如，可以存储在每个机器上的文档的数目)和处理速度(例如，每秒可以执行的查询的数目)。通常，降低存储要求和提高处理速度是期望的。然而，如下文进一步所详细讨论的，存储要求和处理速度与各种项目分布方面存在权衡。

一个项目分布方面牵涉到要包括在每个位向量中的项目的数目。每个位向量的更多项目允许每台机器存储更多的文档，从而减少整体存储要求。然而，每个位向量更多的项目通常会增加噪声，从而由于当执行搜索查询时需要附加的处理来消除噪声，所以降低处理速度。

另一项目分布方面是要包括在搜索索引中的每个项目的副本的数目(即，有多少位向量包含关于特定项目的信息)。如果项目被存储在多个位向量中，那么通过在位向量中包含多个项目创建的噪声可以稍后被移除。然而，增加包括特定项目的位向量的数目会增加存储要求。附加地，由于必须执行更多的交叉，所以增加包括特定项目的位向量的数目会降低处理速度。

又一项目分布设计方面是长行位向量(即，每位一个文档)与短行位向量(即，每位多个文档)的混合。由于当执行行交叉时，要扫描的存储器较少，所以较短的位向量会增加处理速度。然而，因为对于给定的设定位，不知道哪个文档实际上包含项目，所以较短的位向量会增加噪声。长行位向量和短行位向量的混合不影响存储要求。

以下提供了按照一个实现方式的项目分布的示例性拇指规则。按照本示例，如果期望10％的位密度和10：1的信噪比，则交叉的数目等于项目(除了idf为1的项目，其中信噪比为1.0)的逆文档频率(idf)。项目的idf可以通过将文档的总数的对数除以包含该项目的文档的数目来确定。比如，每10000个文档中出现一次的项目的idf为4。当设置有10％的位的位向量被交叉在一起时，这些位相对靠近在一起——通常/经常在相同的字节中。然而，当那些行中有四行已经被交叉在一起时，这些位相距足够远以至于比处理器/cpu缓存行更远(即，64字节＝512位；尽管这在不同的cpu中可能不同)。因此，对于一定数目的交叉(例如，在该示例中为4个)，扫描整个位向量，并且访问每个位以便执行交叉。然而，在完成足够的交叉之后，这些位足够分开，使得可以对感兴趣的剩余的位向量中的随机位置进行探测(即，不必扫描所有的高速缓存行，尽管探测缓存行中的单个位仍然会导致整个缓存行从存储器中读取)。一定最小数目的位向量必须全部被交叉，但是在交叉该一定数目的位向量之后，附加交叉的成本会急剧下降(至每个设定位一个缓存未命中vs读取整个行所需的缓存未命中)。人们没有注意到这是任意长度的交叉序列与简单的查询具有大约相同的处理成本。这是因为每个查询的成本都是由其中来自位向量中的所有位被访问的前n个交叉来支配。在那些n个交叉之后，因为很少缓存行在那些行中被读取，所以被交叉的附加位向量的数目不会增加很多成本。由于需要读取全部位向量和项目的这些前n个交叉可以被存储在长位向量和短位向量的组合中，所以由于扫描较短的位向量的成本很少，因此可能期望使用对于那些前n个交叉可能最短的位向量。因此，搜索索引的设计可以最大化其中包括项目的短位向量的数目。然而，至少一个长位向量(即，排名-0)位向量可以用于降低到单个文档的分辨率。

举个示例来说明，假设项目“snoqualmie”的idf为4(意味着在大约每10000个文档中出现一次)。idf为4的1000个项目(如项目“snoqualmie”)可以被组合成单个位向量以获得10％的位密度。为了将假阳性率提高到信号的10％，需要5个位向量的4个交叉来将噪声降低到1/100000。因此，项目“snoqualmie”可以被存储在5行中。由于短行扫描速度较快，但需要至少一个长行，因此该项目可能会映射到4个短位向量和一个长位向量。

匹配器算法

当采用基于位向量的搜索索引的搜索引擎接收到搜索查询时，匹配器可以采用位向量来标识包含来自搜索查询的项目的文档集合。在通常场景下，与包含在搜索查询中和/或从搜索查询中得出的项目相对应的位向量被交叉以标识匹配文档(联合和否定也是可能的，但可能不太常见)。基于搜索查询来开发匹配器计划或查询计划(在本文中可互换使用)，以便确定如何标识用于交叉的位向量和/或确定执行位向量交叉的次序，如下文将更详细地描述的。随后可以在对匹配文档进行排名的一个或多个后续过程中分析从匹配过程标识的匹配文档。

转到图8，提供了流程图，其图示了用于匹配器来标识匹配来自搜索查询的项目的文档的方法800。方法800可以至少部分地比如使用图44的匹配器4404来执行。最初，如框802所示，接收搜索查询。如框804所示，从搜索查询中标识一个或多个项目。应当理解，在整个说明书中，当从搜索查询中标识项目时，项目可以包括包含在所接收的搜索查询中的确切项目。可替代地或附加地，项目可以包括从查询扩充中标识的其他项目。其他项目可能包括比如拼错项目的正确拼写、项目的替代形式、以及同义词。

如框806所示，标识与来自搜索查询的一个或多个项目相对应的位向量。每个项目可以被包括在多个位向量中，并且每个位向量或者包含每个项目的位向量的一部分可以被标识。如框808所示，位向量被交叉以标识匹配文档。与单个项目相关联的位向量被交叉以标识与该项目匹配的文档。与不同项目相关联的位向量使用查询所指定的交叉、联合和否定的组合进行组合。

在一些实例中，可以通过将所有标识的位向量进行交叉来标识匹配文档。在其他实例中，匹配文档可以通过将所标识的位向量的不同子集进行交叉来标识。这取决于查询如何由匹配器制定。比如，如果查询只包含“与”运算符，则所有的位向量都被交叉。作为具体示例，假设执行查询来标识包含“大型(large)”和“集合(collection)”的文档。在这种情况下，包含项目“大型”的位向量将与包含项目“集合”的位向量交叉。与在那些位向量中的每个位向量中设置的位相对应的文档被确定为匹配文档。如果执行包含“或”运算符的查询，则可以通过将位向量的不同子集进行交叉来标识匹配文档。例如，假设执行查询以标识包含“大型”或“更大型”连同“集合”的文档。可以从包含项目“大型”的位向量与包含项目“集合”的位向量的交叉、以及从包含项目“更大型”的位向量与包含项目“集合”的位向量的交叉中标识匹配文档。

在一些配置中，针对搜索查询标识的位向量可以在图8的框808处以任何次序被交叉。然而，在其他配置中，位向量被交叉的次序可以被配置成提供更有效的处理。如先前所讨论的，每个项目的位向量可以包括短行位向量和长行位向量。附加地，如上文所讨论的，对于初始交叉，处理所交叉的位向量中的每个位。然而，在一定数目的交叉之后，当执行附加交叉时，不需要扫描整个位向量。相反，比如可以通过探测位向量中的随机位置来执行那些附加交叉。因而，一些配置可以通过初始交叉短行来提高交叉过程的效率。图9提供了流程图，其示出了用于首先使用短位向量来交叉位向量的方法900。方法900可以至少部分地比如使用图44的匹配器4404来执行。如框902所示，从要被交叉的位向量集合中标识短行位向量。如框904所示，短行位向量的至少一部分在交叉任意长行位向量之前被交叉。在一些配置中，所有短行位向量在交叉长行位向量之前被交叉。在其他配置中，可以在一些短行位向量之前处理一些长行位向量。当随后执行需要处理每个位的交叉时，短行位向量和长行位向量可以以任何次序被交叉。设想任何和所有这样的变型都在本文中所描述的技术的各方面的范围之内。

首先，举个示例来说明交叉短行位向量的处理，假设对项目“大型(large)”、“强子(hadron)”和“对撞机(collider)”执行查询。如图10所示，项目“大型”的idf为1.16，并且被包括在两个短行位向量1002、1004和一个长行位向量1006中。项目“强子”的idf为3.71并且被包括在四个短行位向量1008、1010、1012、1014和一个长行位向量1016中。项目“对撞机”的idf为3.57，并且被包括在四个短行位向量1018、1020、1022、1024和一个长行位向量1026中。

如图11所示，匹配器可以在逻辑上排列位向量以供首先与短位向量交叉，然后再与长行位向量交叉。在图11的示例中，来自三个项目的短行位向量已经被交替。然而，应该理解，短行位向量可以以任何方式排序。比如，项目“大型”的短行位向量可以首先被排列，接着是项目“强子”的短行位向量，随后是项目“对撞机”的短行位向量。

在图11所示的示例中，匹配器交叉短行位向量中的每个短行位向量，然后将结果与长行位向量交叉。当交叉相同长度的位向量时，来自第一位向量的位与第二位向量中的对应位进行交叉(例如，第一位被交叉，第二位被交叉，第三位被交叉等)。比如，这些交叉可以由cpu一次执行64位。然而，当交叉不同长度的位向量时，来自较短位向量的位与较长位向量中的多个位相对应。比如，当将每位具有四个文档的短行位向量与每位具有一个文档的长行位向量交叉时，来自短行位向量的位分别与长行位向量中的四个对应位中的每个位进行交叉。

如先前所指出的，一些查询可能被处理，其需要位向量的不同子集被交叉。例如，假设搜索查询“大型强子对撞机”被扩充以形成查询“(大型或者更大型)与强子与(对撞机或者对撞)”。这个查询可能牵涉到以下位向量交叉的组合：(1)大型、强子与对撞机；(2)大型与强子与对撞；(3)更大型与强子与对撞机；以及(4)更大型与强子与对撞。当执行这样的查询时，位向量交叉可以被排序，使得首先执行多个位向量交叉组合共同的交叉，并且这些公共交叉的结果被保存以便它们可以被重新使用。

图12图示了排序位向量交叉使得首先执行多位向量组合共同的交叉并且重新使用结果的概念。如图12所示，搜索查询“大型强子对撞机”1202被处理以形成查询“(大型或者更大型)与强子与(对撞机或者对撞)”1204。在本示例中，每个项目包括两个短行和一个长行。如此，扩充查询1204可以用表达式1206所示的每个项目的位向量来表示，其中：“a”和“a”与项目“大型”相对应；“b”和“b”与项目“更大型”相对应；“c”和“c”与项目“强子”相对应；“d”和“d”与项目“对撞机”相对应；以及“e”和“e”与项目“对撞”相对应。短行位向量由小写表示，而长行位向量由大写表示。比如，a1和a2与项目“大型”的两个短行位向量相对应，而a1与项目“大型”的长行位向量相对应。

可以编写表达式1206以通过将短行位向量和组合共同的项目的那些位向量拉向左侧来形成表达式1208。比如，项目“强子”(由表达式1208中的“c”表示)被包括在所有组合中，而项目“大型”和“更大型”(由表达式1208中的“a”和“b”表示)每个都被包含在两个组合中。注意，项目“对撞机”和“对撞”(由表达式1208中的“d”和“e”表示)也分别被包括在两个组合中，使得在备选公式化中，表达式1208中的“a”和“b”的位置可以与“c”和“d”交换，反之亦然。

表达式1208可以使用树1210来表示，该树1210还可以如图13中的树1300所示，其中每个框与位向量相对应。如树1300中那样表示表达式1208图示了交叉被执行的次序。如图14所示，项目“强子”(c1和c2)的两个短行位向量被初始交叉，并且结果可以被保存。这允许来自该交叉的结果如下文所讨论的被重新使用。结果与项目“大型”(a1和a2)的两个短行位向量进一步交叉，并且结果可以被保存。这允许来自这四个位向量的交叉的结果如下文所讨论的被重新使用。这些结果进一步与项目“对撞机”(d1和d2)的短行位向量以及那三个项目(a3、c3和d3)中的每个项目的长行位向量交叉。从这些交叉找到与“大型”，“强子”和“对撞机”相匹配的文档集合。

如图15所示，如以上文参考图14所讨论的那样生成的项目“强子”和“大型”(c1、c2、a1和a2)的短行位向量的交叉的结果可以被重新使用，并且与项目“对撞”(e1和e2)的短行位向量以及三个项目(a3、c3和e3)的长行位向量交叉。从这些交叉找到与项目“大型”、“强子”和“对撞机”相匹配的文档集合。

如图16所示，如上文参考图16所讨论的那样生成的项目“强子”(c1和c2)的短行位向量的交叉的结果可以被重新使用并且与项目“更大型”(b1和b2)的短行位向量交叉，并且结果可以被保存，使得它们可以如下文所讨论的被重新使用。那些结果还可能与项目“对撞机”(d1和d2)的短行位向量和三个项目(b3、c3和d3)的长行位向量交叉。从这些交叉找到与项目“更大型”、“强子”和“对撞机”相匹配的文档集合。

如图17所示，如上文参考图16所讨论的那样生成的项目“强子”和“更大型”(c1、c2、b1和b2)的短行位向量的交叉的结果可以被重新使用，并且与项目“对撞”(e1和e2)的短行位向量以及三个项目(b3、c3和e3)的长行位向量交叉。从这些交叉找到与项目“更大型”、“强子”和“对撞”相匹配的文档集合。

图18提供了流程图，其图示了用于生成匹配器计划的匹配器(诸如图4的匹配器4404)的方法1800，该匹配器计划提供了用于交叉位向量的有效次序。最初，如框1802所示，接收搜索查询。如框1804所示，从搜索查询中标识项目。

如框1806所示，标识与来自搜索查询的一个或多个项目相对应的可用位向量。每个项目可以被包括在多个位向量中，并且每个位向量或者包含每个项目的位向量的子集可以被标识。这可能牵涉到比如标识每个项目有多少个短位向量可用、每个短位向量的长度、以及每个项目有多少个长位向量可用。

在框1808处，生成匹配器计划，以提供交叉项目中的每个项目的位向量的次序。如上文所描述的，可以生成匹配器计划的次序以提供有效匹配。比如，短位向量可以在长位向量之前被交叉。作为另一示例，可以对位向量交叉进行排序，其中首先执行多个位向量交集组合共同的交叉，并且保存交叉的结果，以便它们可以被重新使用。在框1810处，位向量被交叉，以标识匹配文档。

将查询计划编译为机器代码

针对给定搜索查询生成的匹配器计划(或查询计划)可以提供具有各种操作(诸如“与”，“或”，“非”操作)的节点树，并且标识要交叉的位向量。运行这样的匹配器计划可能牵涉到将所有那些操作应用于标识的位向量。处理匹配器计划的一种途径可能是解释树，从而意味着树可能被遍历并且每个节点被评估。然而，遍历该树并且评估每个节点会有很大的开销。考虑树被解释的假设示例。在这样的示例中，可能会有一些与确定每个节点被访问时它的类型相关联的成本，其是理解如何评估节点所必须的步骤。可能会有一些与存储和枚举与每个节点相关联的子节点的集合相关联的成本。这些动作中的每个动作都需要时间来处理并且产生开销。

在节点处进行实际工作以交叉位向量的成本相对较小。比如，工作可能仅由两个指令组成——将值与到累加器中以及分支，以使如果累加器为零则终止评估。确定节点类型和节点有多少子节点的成本实际上高于位向量交叉的成本。因此，这提出了解释开销大于实际工作(即，交叉位向量)的情形。更进一步地，为了处理匹配器计划，可以多次(例如，数千甚至数百万次)评估树，使得在处理期间可以重复分析每个节点，从而产生附加开销。

为了解决这个问题，匹配器计划可能被编译成机器语言。具体是，可以使用jit(准时制)编译器来处理匹配器计划以生成机器代码。例如，在采用基于x64的处理器(例如，xeon处理器)的搜索系统中，jit编译器可以将匹配器计划编译为x64代码。jit编译器在从用户接收到搜索查询时完成。在这样的配置中执行查询的过程可以包括：接收搜索查询，基于搜索查询来生成匹配器计划，以及将匹配器计划转换为机器代码。

当匹配器计划进行jit编译时，这个过程可能包括类似于解释器那样的方式遍历匹配器计划。但是，根本的区别在于，jit编译器只检查每个节点一次，因为它输出了过程应当在遍历树时应当完成的代码。然后可以重复运行该代码(例如，数千甚至数百万次)并且运行代码没有由解释器使用的评估方法的开销。

处理器具有多种可供它们使用的资源(例如，处理器和存储器之间的总线，用于保持从存储器带入的数据的处理器内部的固定大小的缓存，具有可以完成一定工作量的晶体管的一定数目的处理器内核等)。通常，对于任何给定程序，速度都受到资源中的一个资源的限制。资源中的一个资源受到限制的原因是，一旦受到这种资源的限制，它就不足够快以受到下一最宝贵的资源的限制。不同的程序被不同的事物所限制。大索引搜索的基本限制是访问大量数据。一般而言，在当今存在的处理器的情况下，基本限制是数据可以通过存储器总线在处理器中移动有多快。通过倒排列表，算法的复杂性导致cpu在存储器总线之前变得饱和的情形。本文中所描述的技术的一些方面的价值在于代码足够简单，使得cpu能够比可以供应数据的存储器总线更快地处理数据，并且因此存储器总线可以是饱和的。

因此，在本文中所描述的技术的一些方面中，一个设计目标可能是使存储器总线饱和，其意味着存在一定量的信息以引入算法，并且该目标是使系统受到信息量以及存储器总线将信息带入处理器的能力的限制。这个设计目标可能避免受到处理器指令的开销的限制。换句话说，目标是让处理器在存储器上等待，而不是周围的其他路径。尽管处理器的内核越来越多，但是在存储器总线越快越宽时，存储器总线仍然很难保持饱和。因此，每个存储器总线访问之间的指令的数目可以被限制为少至两个指令或三个指令，以使存储器总线饱和。jit编译匹配器计划提供机器代码，其限制了指令的数目以帮助实现这个目标。

应该指出，使用jit编译来帮助实现使存储器总线饱和的设计目标在采用某些现有处理器(诸如xeonx64处理器)的系统中可能是有用的。然而，可以采用其他硬件设计，诸如现场可编程门阵列。因为其他硬件设计的成本结构可能不同，所以jit编译可能对那些设计不太有用。

查询idf增强

如先前所讨论的，搜索系统通常采用匹配器，该匹配器标识包含查询项目的文档(即，“匹配文档”)，然后是对匹配文档中的至少一些文档进行排名的排名器。影响由这种搜索系统执行的搜索的运行时间的变量中的一个变量是匹配器所返回的匹配文档的数目。如果返回大量匹配文档，则可能花费无法接受的时间量来对这些文档进行排名。

因而，针对给定查询的搜索系统的性能可以被视为由匹配器针对查询可以返回的匹配文档的数目的函数。查看这个的一种方式是通过引用查询的idf。查询的idf可以通过将索引文档的总数的对数除以查询的匹配文档的数目来确定。比如，idf为4的查询将从语料库中的每10000个文档中返回一个匹配文档。对于给定搜索查询，查询的idf表示来自文档语料库的可能匹配文档的数目。

采用按照本文中所描述的技术的各方面的具有位向量的搜索索引的搜索系统可以很好地执行产生可接受数目或百分比的匹配文档的搜索查询。基于搜索系统的设计优化，可以配置什么被认为是可接受的数目或百分比的匹配文档。在一些配置中，这与idf大约为4或更大的查询相对应(即，10000个文档中的1个文档或更少的文档匹配查询)。对于这样的搜索查询，排名可能足够便宜以至于匹配器可以处理搜索查询并且返回匹配文档，而无需对匹配处理进行任何修改。

对于可能返回无法接受的数目或百分比的匹配文档的搜索查询(例如，idf小于4的查询)，一些配置采用技术来减少若干个匹配文档。这些技术在本文中被称为“查询idf增强”，因为针对搜索查询的匹配文档的减少导致查询的更高idf。可以由一些配置采用以减少用于搜索查询的若干个匹配文档的一般技术是在搜索查询的匹配过程期间与一个或多个附加的位向量进行交叉。这些附加的位向量在本文中被称为“加强行”位向量，由于附加的位向量通过减少匹配文档的数量(即，增强查询的idf)来加强匹配过程。

在本文中所描述的技术的一些方面，加强行位向量可以基于文档的静态排名。如本领域已知的，静态排名是指与搜索查询无关的文档排名特征。比如，搜索引擎经常使用的一个静态排名特征是基于包含到文档的超链接的其他文档的数目来对文档进行排名。到文档的链接越多可以被视为指示重要性越高，并且因此排名更高。因为文档的静态排名与查询无关，所以当正在添加关于文档的信息时，可以在索引生成时间确定该静态排名。

为了支持查询idf增强，可以向搜索索引添加位向量以标识文档语料库中具有最高静态排名的文档。这个静态排名位向量可以通过确定语料库中文档的静态排名来生成。基于静态排名，可以标识具有最高静态排名的特定数目或百分比的文档。比如，可以标识排名前10％的静态排名文档或具有高于所选择的静态排名评分阈值的静态排名评分的文档。生成位向量，其中为最高静态排名文档中的每个最高静态排名文档(例如，排名前10％的静态排名文档)设置位，而清除其他文档(例如，剩余90％的文档)的位。如此，当执行搜索查询时，如果匹配器确定将返回无法接受数目的匹配文档，则匹配器还可以交叉静态排名位向量。由于仅设置静态排名位向量中的最高静态排名文档的位，所以交叉该位向量将导致仅匹配搜索查询中的项目的来自最高静态排名文档的文档被返回作为匹配文档。实质上，使用静态排名位向量将可能的文档池限制到最高的静态排名文档。

另一查询idf增强途径是使用用于非主体信息的加强行。通常，文档的项目可以在多种不同的位置中被标识。项目可以从文档的主体中标识，但是项目也可以从其他非主体位置而被标识。比如，文档的非主体位置可以包含锚点文本(即，链接到文档的另一文档内的超链接的文本)、文档的url、文档的标题(即，呈现在浏览器的标题栏中的字)以及搜索信息(诸如导致从用户的搜索结果中选择文档的搜索查询的项目以及包括在文档的摘录(即，摘要/大纲)中的项目)。

非主体信息通常被视为提供比主体信息更好的相关性指示符。因而，将匹配器仅限于非主体信息会减少结果集合，同时得出文档可能更相关。按照本文中所描述的技术的一些方面，可以在位向量中对非主体信息进行索引。这可以通过标识出现在非主体位置中的项目以及用将那些项目标识为非主体项目(即，出现在非主体位置中的项目)的信息对那些项目进行索引来完成。因此，位向量索引信息通常不仅标识项目(即，来自主体位置和非主体位置的项目)，而且标识非主体项目(即，仅在非主体位置中的项目)。通用项目和非主体项目可以分布在整个搜索索引中。比如，特定的位向量可能包括通用项目和非主体项目。

按照本文中所描述的技术的一些方面，当执行搜索查询时，匹配器初始交叉与来自查询的项目相对应的通用项目(即，来自主体位置和非主体位置的项目)的位向量，以估计将被返回的匹配文档的数目。如果匹配器估计将返回无法接受数目的匹配文档，则匹配器标识并且交叉与来自查询的项目相对应的非主体项目的位向量。实质上，这将匹配文档限制到在非主体位置中包含查询项目的文档。

参照图19，提供了流程图，其图示了用于使用加强行来匹配文档的方法1900。方法1900可以至少部分地比如使用图44的匹配器4404来执行。如框1902所示，接收搜索查询。如框1904所示，基于搜索查询来确定一个或多个项目。一个或多个项目可以包括在搜索查询中明确阐述的项目和/或基于搜索查询中的项目而确定的项目(例如，拼写错误、备选形式、同义词等)。

在框1906处，做出关于匹配器是否可能返回用于搜索查询的无法接受数目的匹配文档的确定。该确定可以基于按照本文中所描述的技术的不同方面的方法的任何组合。在一些配置中，该确定是基于来自搜索查询的项目的idf。在一些配置中，该确定是基于采样。作为示例来说明，可以通过开始匹配过程来做出确定，该匹配过程通过标识在框1904处标识的项目的位向量并且交叉那些位向量来开始。在该点标识和交叉的位向量可以包括位向量，其中通用项目与在框1904处标识的项目(即，来自主体位置和非主体位置的项目)相对应。在匹配过程期间，可能被返回的匹配文档的数目可以基于作为匹配返回的文档的百分比来估计。这牵涉到在索引的一部分上运行整个计划，然后使用观察到的匹配率来预测如果在整个索引上运行则可能被返回的匹配的总数。

如框1910所示，如果在框1908处确定可能返回可接受数目的匹配文档，则可以在不使用任何加强行位向量的情况下执行匹配过程，以减少匹配文档的数目。可替代地，如果在框1908处确定可能返回无法接受数目的匹配文档，则一个或多个加强行位向量可以在框1912处被选择，并且如框1914所示被交叉以减少匹配文档的数目。

任何数目和类型的加强行位向量可以被选择和交叉。比如，可以选择并且交叉静态排名位向量，以将可能的匹配文档限制到排名靠前的静态排名文档。作为另一示例，具有与在框1904处标识的项目相对应的非主体项目的位向量可以被交叉，以将可能的匹配文档限制到在非主体位置中包含项目的文档。这可以针对在框1904处标识的所有项目或仅项目的子集来完成。应该理解，在匹配过程期间可以选择和交叉其他类型的加强行位向量，以减少匹配文档的数目。

在本文中所描述的技术的一些方面中，可以基于所估计的匹配文档的数目来选择加强行位向量以便交叉的数目和/或类型。还有，与搜索查询中的其他项目相比较，不同的项目可能具有更多或更少的加强行。不同的加强行途径可以在匹配文档中提供不同的减少。对于可能产生数目更多的匹配文档的查询，可以选择加强行，其提供匹配文档的更多减少。比如，基于所估计的匹配文档数目，可以选择并且交叉静态排名位向量、具有非主体项目的一个或多个位向量、或静态排名位向量和具有非主体项目的一个或多个位向量这两者。

虽然图19的方法1900仅示出关于匹配文档的数目是否可能无法接受的单个确定，但是随着匹配过程继续，可以重复做出确定。比如，初始确定可以指示可能返回可接受的数目。然而，在进一步匹配时，可以确定现在可能无法接受，并且可以基于该重新确定来选择加强行。

一些搜索查询可能具有如此低的idf(即，返回特别大量的匹配文档)，使得加强行途径可能不足以限制匹配文档的数目。对于这样的搜索查询，搜索引擎可以缓存那些搜索查询的搜索结果。因此，当接收到被缓存的搜索查询时，所缓存的搜索结果被简单地检索。

因而，在匹配过程期间可以采用多种不同的技术来控制所返回的匹配文档的数目。可以基于针对给定搜索查询而确定的估计数目的匹配文档来选择技术。仅通过示例而非限制，一个具体配置基于idf的不同范围来针对搜索查询而采用不同的技术。在该示例配置中，使用idf小于2的搜索查询，使用所缓存的结果。对于idf介于2和3之间的搜索查询，静态行位向量和具有非主体项目的一个或多个位向量被交叉。对于idf介于3和4之间的搜索查询，具有非主体项目的位向量被交叉。最后，对于idf大于4的搜索查询，执行匹配过程而无需添加任何加强行位向量以减少匹配文档的数目。

搜索索引中的短语

一些搜索查询包括特定短语。短语是搜索引擎的重要概念，因为在文档的不同位置中具有项目集合的文档可能与包含该短语的文档不相关。比如，考虑短语：“thethe”(频带)和“是(tobe)或不是(nottobe)”。虽然这些短语中包括的项目是常见的，但是这些短语本身相当罕见。

通常，如果允许标识文档中的短语的信息未被索引，那么匹配器可以标识包含短语的项目而非短语的文档。如果排名器也不考虑短语，那么没有短语的文档可能会比包含该短语的其他文档排名更高，尽管从用户的角度看，包含该短语的文档可以被认为是更好的结果。附加地，如果不限于最大数目，则由匹配器发送给排名器的文档的数目可能很大，从而导致对所有文档进行排名的时间量无法接受。可替代地，如果对发送给排名器的文档的数目进行限制，则匹配器可以选择在不同位置中包含项目的文档，同时排除包含该短语的文档。

一个倒排列表系统可以选择使用位置倒排列表，其存储不仅关于文档中项目的存在而且还关于项目在文档中的位置的信息。因此，可以通过使用位置信息来标识短语以确定字相邻，并且因此形成短语。然而，需要大量的存储器来存储位置信息，并且其是cpu密集型的以整理项目的位置来发现短语。

本文中所描述的技术的各方面所采用的位向量途径没有存储索引中的位置信息，并且因此不能使用与位置倒排列表系统中相同的途径来标识短语。因此，本文中所描述的技术的各方面可以替代地将短语存储在位向量中，以允许标识包含在搜索查询中阐述的短语的文档。如本文中所使用的，短语是指两个或更多个字的任何组合，诸如n-元语法(n-gram)、n-元组(n-tuple)、k-近邻(k-near)n-元组等。n-元语法是“n”个连续或几乎连续的项目的序列。如果n-元语法与一连串的连续项目相对应，则它被认为是“紧密的”，以及如果它包含了采用它们在文档中出现的次序的项目，则它被认为是“松散的”，但是这些项目不一定是连续的。松散的n-元语法通常被用来表示一类等同短语，其因不显著字(例如，“如果下雨，我会被淋湿”以及“如果下雨，那么我会被淋湿”)而不同。如本文中所使用的n-元组是在文档中共同出现(以次序无关)的“n”项目的集合。进一步地，如本文中所使用的k-邻近n-元组是指在文档中的“k”项目的窗口内共同出现的“n”项目的集合。

与上文针对项目的讨论类似，短语可以被存储在位向量中。因此，索引中的每个位向量可以存储项目和短语的任何组合。但是，短语和项目之间的区别在于短语不需要像项目那样被存储在多个位向量中。相反，比如，短语可以被存储在单个短行位向量中。因为短语包含与短语中的项目显著重叠的信息，所以交叉项目的位向量和短语的位向量可以允许标识包含短语的文档。这是基于上文参考查询idf增强讨论的加强行位向量的概念。对于短语来说，较弱的查询将简单地交叉各个项目的位向量。然而，查询还可以通过交叉该短语的一个或多个位向量来加强。这使得短语便宜以使用位向量来存储在搜索索引中，并且提供优于其他途径(诸如位置倒排列表)的优点，这些途径需要大量的存储器来对短语做出解释。

图20a提供了示例来说明使用包含短语的位向量作为加强行位向量的概念。本示例说明了对“简单街道(easystreet)”这个短语的查询。项目“简单”和“街道”在idf分别为1.27和1.14时都很常见。因为这些项目是常见的，所以它们不需要许多位向量来对项目的信息进行编码。在本示例中，已经使用其中项目的位向量的数目是四舍五入的idf的拇指规则，使得项目“简单”和“街道”各自被包括在两个位向量中。附加地，每个项目被包括在一个短行位向量和一个长行位向量中。

短语“简单街道”在idf为4.07时较罕见。如果使用相同的拇指规则，则该短语将被包括在由四个短行位向量和一个长行位向量组成的五个位向量中。如果多个位向量被用于短语，则短语将需要相当多的存储器。然而，“简单街道”的位向量与“简单”的位向量和“街道”的位向量有很多相同之处。

如图20b所示，如果对“简单街道”执行查询，则使用“简单”和“街道”的位向量，这是由于至少匹配查询的文档必须包含那些项目。从图20b中可以看出，来自那些项目的位向量提供了四个位向量的交叉，其足以移除噪声。因此，“简单街道”的五个位向量不需要标识匹配文档。相反，只有两个位向量被用来标识包含短语“简单街道”的匹配文档。因此，搜索索引不需要存储短语“简单街道”的三个位向量2006、2008、2010。相反，搜索索引只存储两个短行位向量2002、2004。

搜索索引中的分片

由搜索引擎索引的文档通常在长度上差别很大，其中文档的长度由文档中的独特字的数目来测量。在频谱的一端上，文档可能仅包含单个字；而在频谱的另一端上，可以想象地，文档(例如，字典)几乎可以具有每个字。在使用位向量来索引文档的情景中，短文档在位向量中设置有小百分比的位，而长文档设置有大百分比的位。为位向量创建的一个问题是在处理长度足够变化的文档时效率会丢失。只能实现一个长度的所需的位密度。文档长度差异过大会导致某些地方的位密度过高，而其他地方的位密度过低。

通过说明，图21图示了搜索索引的一部分，其仅示出了长行位向量(即，每位一个文档)。突出显示的列2102与长文档相对应。从图21中可以看出，几乎所有的位都基于出现在文档中的加下划线的项目来设置。尽管大部分位针对长文档而被设置，但是文档中不存在许多项目(即，图21中没有下划线的项目)。因此，包括不在文档中的项目(即，图21中的没有下划线的项目)但是与文档中的项目共享位向量的搜索查询将与长文档相匹配，即使长文档不是项目的真正匹配。可以理解的是，假阳性的可能性会随着创建大于目标位密度的文档而增加。

一些配置通过将索引分解/划分成搜索索引的不同段或“分片”来解决这个文档长度变化的问题。每个分片索引长度与不同文档长度范围相对应的文档。比如，具有0至100个项目的文档可以被指派给第一分片，具有101至200个项目的文档可以被指派给第二分片，具有201至300个项目的文档可以被指派给第三分片等。

通过提供不同的分片，每个分片内的文档都在文档长度的范围内，其防止文档长度差异很大所造成的效率低下。每个分片可以具有对位向量的不同的项目指派，以控制每列中的位密度(即，每列中设置的位的百分比)。在较长文档的分片上，可以在位向量中共享较少的项目以控制列位密度。换句话说，较长的分片每个位向量可能具有较少的项目。相反，在具有较短文档的分片上，可以在位向量中共享更多的项目(即，每个位向量更多项目)。

图22图示了用于使用位向量来生成搜索索引的分片的方法2200。方法2200可以至少部分地比如使用图44的索引器4418来执行。如框2202所示，确定要使用的分片的数目。附加地，如框2204所示，确定用于每个分片的文档长度的范围。尽管在图22中确定分片的数目和每个分片的文档长度的范围被示为单独的框，但是应该理解，那些设计参数可以在单个过程中进行确定。基于文档长度范围，如框2206所示，文档根据其长度被指派给每个分片。如框2208所示，通过在计算机存储介质上存储每个分片的位向量来生成搜索索引。每个分片存储位向量，其索引文档长度在每个分片的文档长度范围内的文档的项目。

在一些配置中，确定要采用的分片的数目和每个分片的文档长度范围可以基于两个考虑。首先考虑的是每个分片都有固定开销，因为需要对每个分片执行每个查询。如此，不希望有太多的分片。

其次考虑的是存在与由于有不同长度的文档而造成的浪费的存储量相关联的成本。具体地，给定期望的列位密度(例如，10％)，如果分片中最长文档产生期望的列位密度(即，10％)，则较短文档将具有较低的列位密度。列位密度低于期望的列位密度的任何文档表示存储浪费。分片中文档长度的变化越大，存储浪费量就越大。

成本函数可以作为上述两个考虑的函数而生成。具体地，成本函数被计算为将分片的数目乘以一些权重因子加上基于每个分片中不同文档长度而创建的存储浪费成本。应用于分片数目的加权可以基于附加分片所需的处理成本(即，速度成本)相对于由于分片中文档长度变化较大而导致的存储浪费成本(即，存储成本)的相对重要性来配置。存储浪费成本可以被计算为比如基于所消耗的总存储器(最长长度·文档的数目)的或更具体地使用以下等式的近似值：

等式3：最长长度·文档的数目-σ文档长度

解成本函数可能被视为优化问题。如此，可以采用多种不同的算法来解成本函数，以优化分片的数目和每个分片的文档长度范围。在一些配置中，成本函数被解为所有配对最短路径问题。

当接收到搜索时，可以对每个分片执行查询。每个分片上的查询返回文档集合，这些文档集合被组合起来以提供匹配文档集合。

在一些配置中，准备每个分片的查询的一些工作可以被共享。通常，对于分片中的每个分片，相同项目的位向量被交叉。分片之中的主要区别在于项目到位向量的映射。比如，一个分片中的项目可以被包括在三个位向量中。对于另一分片，该项目可以被包括在与第一分片中的位向量完全不同的七个位向量中。因为查询不同分片的主要区别在于项目到位向量的映射，所以在将项目转换为实际位向量之前，查询的结构和查询处理可能在整个分片上被重新使用。

图23图示了用于使用多个分片执行搜索的方法2300。方法2300可以至少部分地比如使用图44的匹配器4404来执行。如框2302所示，接收搜索查询。如框2304所示，标识用于搜索查询的一个或多个项目。一个或多个项目可以包括在搜索查询中明确阐述的项目和/或基于搜索查询中的项目而确定的项目(例如，拼写错误、备选形式、同义词等)。

如框2306所示，基于所标识的项目来生成通用查询计划。通用查询计划一般可以阐述用于交叉包含来自搜索查询的项目的位向量的过程。如框2308所示，通用查询计划被转换为用于每个分片的分片特定查询计划。然后，如框2310所示，对每个对应的分片执行每个分片特定查询计划以标识用于搜索查询的匹配文档。

将通用查询计划转换为每个分片特定查询计划在每个分片上的大部分阶段都是相似的。通常，在查询被解析之后，项目集合被标识，并且这些项目被映射到每个分片的位向量集合。分片之间的主要差别在于从项目到位向量的映射不同。例如，一个分片中的项目可以是在三个位向量(例如，第7行、第10行以及第15行)中。在另一分片中，该项目可能出现在10个位向量中，其可能与第一分片完全不同。将项目转换为行之前的所有内容都可以在所有分片中重新使用。即使从项目到行的映射在分片之间不同，查询的结构也可能保持不变。换句话说，对于每个项目来说，均存在短行和长行的集合，短行被拉到左侧而长行被拉到右侧的方式在分片之间是相同的，尽管行数和行标识符不同。

在一些配置中，通用查询计划可以包括每个项目的最大数目的短行和每个项目的最大数目的长行。计划器最初可以在项目和行之间没有特定映射的情况下运行(行本质上是虚拟行，而没有映射到索引中的物理行)。特定分片的计划可以通过将这些虚拟行中的每个虚拟行替换为特定于该分片的物理行来生成。在每个不同的分片上，可能会使用不同的物理行集合。当通用查询计划具有最大数目的短行和长行时，并非所有分片都可以使用所有这些虚拟行(即，计划行)。为了解决这个问题，当虚拟行被替换为物理行时，未使用的虚拟行被替换为不影响查询的布尔表达式的语义的物理行并且可以被用作填充行。例如，具有已经被包括的物理行中的一个或多个物理行的全部或者复制的物理行可以用于那些额外的行。

因此，可以很快地为每个分片定制通用查询计划。在一些配置中，匹配引擎得到两个输入：运行的已经被编译的代码、以及指向应该用于给定分片的所有行的指针的表。因此，为每个分片“定制”通用计划可以简单地牵涉到为每个分片提供不同的行表(即，每个分片使用相同的代码)。这样，相对于分片，整个查询流水线一直到匹配器可以是通用的，其中分片之间的区别被表达为具有指向行的指针的表。因此，大部分的计划工作都被重新使用。

上述重新使用分片的查询计划的途径的一个成本是通用查询计划可能引用比一些分片实际需要的更多的行，这是由于通用查询计划旨在容纳分片可能需要的最大数目的行，其对于一些分片来说意指一些浪费努力来交叉占位符或填充行，它们全是1或者是先前使用的行的复制。然而，由于若干种原因，所以这可能是可接受的。匹配器的成本主要是扫描前几个(例如，四个)行，使得附加的行扫描/交叉不会增加显著成本。附加地，如果途径简单地重新使用了最后使用的行，则交叉该行的成本很小，因为该行已经在处理器缓存中。

条带表

每个项目在文档语料库中出现的频率可能差别很大。有些项目非常常见，而其他项目非常罕见，甚至到在文档语料库中出现一次的程度。如先前所讨论，对于给定项目将噪声降低到可接受水平所需的位向量交叉的数目随着项目频率而变化。通常，常用项目(即，文档语料库中具有高频率的项目)需要较少的位向量交叉，而罕见项目(即，文档语料库中具有低频率的项目)需要更多的位向量交叉。

当构建位向量搜索索引时，按照本文中所描述的技术的各种方面，可以采取若干种不同的途径来确定用于项目的位向量配置。如本文中所使用的，项目的“位向量配置”阐述了用于该项目的位向量的数目和长度。位向量配置还可以标识在配置中在其上存储每个位向量的存储器(例如，ram、ssd和/或hdd)的(多个)类别。

可以采用的一种途径是“一刀切”途径，其中所有的项目具有相同的位向量配置。然而，这种途径具有一些缺点。具体地，如果“一刀切”位向量配置指定较高数目的位向量来对低频项目进行解释，则由于较高频率项目不需要较高数目的位向量，所以浪费了存储器。比如，假设索引中最稀有的项目需要10个位向量来充分降低该项目的噪声，因此索引中的每个项目使用10个位向量。如果更常见项目所需的位向量的数目要小得多，则对那些常见项目中的每个常见项目使用10个位向量会浪费存储器。

可替代地，如果“一刀切”位向量配置指定较少数目的位向量，则较低频率项目可能不具有足够数目的位向量以充分降低噪声。比如，假设最常见项目只需要两个位向量。对于较不常见项目，只使用两个位向量将不足以降低噪声，并且那些项目可能会存在无法接受数目的假阳性。

另一途径是使用用于每个项目的自定义位向量配置。换句话说，每个项目在将位向量配置指派给项目时被单独对待。虽然这是可能的并且可以在本文中所描述的技术的一些方面中采用，特别是当对具有较少不同项目的小文档语料库进行索引时，但是对于具有大量不同项目的非常大的文档集合来说可能是不实际的。比如，当处理非常大量的项目时，将每个项目映射到其自定义位向量配置所需的数据结构将是巨大的。

又一途径是基于项目特点将位向量配置指派给集群成不同频带(即，等价类别)的项目组，并且将特定位向量配置指派给每个频带。换句话说，“频带”是项目组，它们具有足够类似的项目特点，以被指派相同的位向量配置。比如，一个频带的位向量配置可以指定两个排名-6位向量，一个排名-3位向量和一个排名-0位向量。特点与该频段的那些特点匹配的每个项目将使用该位向量配置。如本文中所使用的，“条带表”可以用来存储项目特点到由搜索索引采用的每个频带的位向量配置的映射。搜索索引可以采用任何数目的条带表。附加地，任何数据结构可以用来存储条带表的映射。

影响用于存储每个项目的位向量的的位向量的数目和/或长度和/或存储器类别的任何项目特点都可以用于定义频带。在本文中所描述的技术的一些方面中，当执行查询时，项目特点还可以在运行时间使用，因此项目特点可以被限制到可以被快速确定的特点。

仅作为示例而非限制，频带可以由以下项目特点来定义：排序、语法大小、idf、idf总和以及层提示。排序是指项目在文档中的位置(有时被称为“流”)。比如，这些可能包括主体、非主体和元字(字未被显示，但被添加到文档/用该文档索引，以提供关于文档的元数据，诸如文档的语言)。语法大小是指项目的字的数目(例如，单个字项目一个，短语两个或更多个)。idf是指项目的频率。因为每个分片索引不同的文档集合，所以特定项目的频率可能在分片之间变化。在一些配置中，确定精确的项目频率是唯一可行的或仅仅确定最常见项目的项目频率的良好近似。对于其他项目，假定项目频率低于某个阈值项目频率，并且该阈值项目频率被用作项目频率的代表。idf总和用于短语来近似短语的频率。确定所有短语的实际频率可能是不切实际的。相反，一些配置可能会组合短语中各个项目的频率，以提供短语的idf总和。这是用来帮助将短语分成组的近似。层提示用于表示搜索查询中项目出现有多频繁。这可能有助于确定要使用的存储器的类别。比如，一些项目在文档中常见，但在搜索查询中很少使用。这些项目的行可能被存储在较慢的存储器上。还应该指出，在使用分片的配置中，每个分片可以具有不同的项目分布，因此给定项目在分片中的每个分片中可以具有不同的位向量配置。

指派给每个频带的位向量配置可以基于搜索索引的各种设计目标来配置。在一些配置中，设计目标可以包括：平衡索引存储消耗与相关性。通常，增加频带中的位向量的数目通过允许更多个位向量交叉来降低噪声而增加了相关性，但增加了搜索索引的存储要求。相反，减少频带的位向量的数目减少了存储器，但也降低了相关性。

给定存储器和相关性之间的这些折衷，将位向量配置指派给频带的一种途径是尝试最小化总存储消耗，同时确保相关性不低于某个阈值。这可以被视为成本/收益优化问题，其中成本是所消耗的存储量，而收益是所提供的相关性。虽然存储额外位向量的成本是相当线性的，但额外的收益是在某一点之后提供快速递减的回报。

对于给带宽的给定位向量配置指派，对于语料库而言，所消耗的存储量相对容易计算。频带中的项目的数目可以基于与频带相关联的项目的频率来近似。附加地，倒排项目贡献的数目可以基于项目的频率(例如，idf)来确定。给定给频带的特定位向量配置指派，可以基于每个频带中的倒排的数目和每个频带中的位向量配置来确定存储量。

相关性度量可以在本文中所描述的技术的各个方面中以若干种不同的方式来确定。相关性可以被确定为在统计上显著的语料库和统计上显著的查询日志的情景中观察到的聚集值，诸如平均值。然而，相关性还可以考虑最小值、方差、第n百分比值、甚至是完全分布。

在本文中所描述的技术的一些方面中，相关性度量可以基于对带宽的给定位向量配置指派所期望的假阳性率。假阳性率反映了预期由匹配器返回的匹配文档的数目或百分比，其在文档没有包含来自查询的一个或多个项目的这个意义上实际上没有与查询相匹配。比如，如果查询的位向量交叉产生100个匹配文档(即，来自交叉的100个1位)并且那些匹配文档中的20个匹配文档不是实际匹配，则假阳性率为0.2或20％。真实匹配的匹配文档在本文中被称为有效匹配文档，而不是真实匹配的匹配文档在本文中被称为无效匹配文档。

虽然在一些配置中假阳性率可能被用作相关性度量，但是假阳性率具有一些缺陷。通常，假阳性率仅适用于匹配器，并且可能不足以预测端到端流水线相关性。例如，假阳性率并不考虑匹配器设计，其限制了为每个查询返回的匹配文档的数目。在查询语料库中可用的匹配文档的数目低于匹配器所返回的最大数目的文档的实例中，尽管匹配文档结果适当，但是假阳性率仍然较高。比如，假设匹配器被设计成每个查询返回不超过五个匹配文档。在其中查询包含一个或多个罕见项目的实例中，整个语料库中可能只有一个匹配文档。然而，因为匹配器被设计成返回五个匹配文档，所以那些文档中的四个文档必然是无效匹配。因此，假阳性率可能是80％，尽管匹配器不能返回更好的匹配文档集合。

假阳性率也不考虑被无效匹配文档所替换的有效匹配文档。比如，再次假设匹配器被设计成为每个查询返回五个匹配文档。在一个实例中，假设语料库对于第一查询具有五个匹配文档，并且匹配器为第一查询返回四个有效匹配文档和一个无效匹配文档。在另一实例中，假设语料库对于第二查询具有四个匹配文档，并且匹配器为第二查询返回四个有效匹配文档和一个无效匹配文档。在这两种实例中，假阳性率是相同的(20％)。然而，对于第一查询，一个有效匹配文档被无效匹配文档替换；而对于第二查询，则没有有效匹配文档被替换。尽管假阳性率相同，但是来自第二查询的匹配文档集合比第一查询的匹配文档集合呈现更好的相关性。

因而，一些配置采用基于匹配器可能已经返回但被无效匹配文档替换的有效匹配文档的一部分的误差率。这个误差率可以用作比假阳性率更好的用于预测总体流水线相关性的代表。比如，在其中在语料库中只有一个有效匹配文档并且匹配器必须返回五个匹配文档的上文示例中，假阳性率为80％。然而，基于替换的有效匹配文档的误差率可能为零，其更准确地反映了相关性。在其中第一查询具有一个有效匹配文档被替换而第二查询没有被替换的有效匹配文档的上文示例中，两个查询的假阳性率都是20％。然而，基于所替换的有效匹配文档的误差率可能对于第一查询而言为20％，对于第二查询而言为零，其更准确地反映了相关性。

在本文中所描述的技术的一些方面中，搜索系统可以被配置成使得执行附加的验证步骤，其中保留有效匹配文档并且移除无效匹配文档。这将移除匹配器返回的假阳性。比如，匹配器可以被配置成允许将更多数目的匹配文档提供给附加验证步骤。如果验证步骤不消耗太多附加的存储器和/或需要太多附加处理时间，则这可能是可接受的。在这样的配置中，相关性度量可以基于“修正成本”，其是标识和移除无效匹配文档所需的附加存储器和/或处理时间中的成本。

为了优化对频带的位向量配置指派，可以采用作为相关性度量(例如，假阳性率、误差率、修正成本或其他度量)和存储要求的加权和的成本函数。所应用的加权可以基于相关性和存储器对搜索系统的设计的相对重要性来配置。可以采用多种优化算法，其使用成本函数来优化指派给每个频带的位向量配置。比如，在一些配置中，可以采用梯度下降算法来在给频带的合理的/局部最优的位向量配置指派的集合上快速收敛。

图24提供了流程图，其示出了用于生成将项目特点映射到位向量配置的数据结构(诸如条带表)的方法2400。如框2402所示，项目特点被指派给若干个频带中的每个频带。附加地，如框2404所示，位向量配置被指派给每个频带。如上文所讨论的，项目特点和/或位向量配置可以被指派给每个频带。比如，可以采用成本函数来以针对用相关性度量平衡存储器消耗的设计目标而优化的方式将位向量配置指派给每个频带。在框2406处，生成数据结构，其将项目特点映射到每个频带的位向量配置。数据结构可以用于标识项目的位向量配置以用于若干个目的，诸如比如，生成基于位向量的搜索索引，索引关于搜索索引中的文档的信息，以及在搜索查询的匹配过程期间访问项目的位向量。

项目表

除了给项目指派位向量配置之外，存储器中的位向量位置被映射到项目以允许按照本文中所描述的技术的各方面来索引文档并且执行查询。当索引文档时，在文档中标识项目，并且需要标识那些项目的位向量位置以设置文档的列中的位。当执行搜索查询时，从查询中标识项目，并且需要标识那些项目的位向量位置以取回位向量来执行位向量交叉。因而，在任一情况下，给定项目，该项目的位向量的存储器位置需要被标识。

虽然用于项目的位向量配置标识了用于该项目的位向量的数目和长度(以及可能要使用的存储器的类别)，但是可以使用标识那些位向量的实际/特定存储器位置的映射。比如，项目的位向量配置可以指示使用三个排名-6位向量，1个排名-3位向量和1个排名-0位向量。该映射将项目(或其散列)与那五个位向量的每个位向量的存储器位置相关联。项目的存储器位置的映射在本文中被称为“项目表”。搜索索引可以采用任意数目的项目表。附加地，任何数据结构可以用来存储项目表的映射。

一种用于映射用于项目的存储器位置的途径是提供显式映射，其标识存储器中的每个索引项目的特定位向量位置。对于给定项目，显式映射将项目(或其散列)与位向量标识符相关联，该位向量标识符可以是指向该项目的位向量在存储器中的位置的指针。如果显式映射被用于项目，那么当索引文档或执行查询时，标识用于项目的位向量位置牵涉到查找用于项目的映射并且取回由映射标识的特定位向量位置。

虽然可以提供用于所有项目(尤其是用于具有较少数目的项目的较小文档集合的搜索索引)的显式映射，但是在包含大量项目的较大搜索索引中包括用于所有项目的显式映射可能是不切实际的。因而，在一些配置中的另一种途径是不包括用于至少一些项目的显式映射，而是使用“adhoc”途径，其中算法被用来得出用于项目的位向量位置。按照本文中所描述的技术的一些方面，为每个频带提供了用于基于项目散列的导数来确定位向量位置的算法。比如，如果用于频带的位向量配置指定了三个位向量，则可以提供三种算法，每种算法都是项目的散列的函数。因而，为了使用用于项目的adhoc途径来找到位向量位置，基于项目的特点来确定项目的频带，然后针对该频带指定的算法可以用来确定用于该项目的位向量位置。用于每个频带的算法可以被存储在条带表、项目表或某个其他数据结构中。用于频带的算法可以简单地是不同的散列函数，其在如果各种散列函数被应用于相同的输入值(即，相同的项目)，则存在散列函数中的每个散列函数的不同结果将被返回的高概率的这个意义上讲是不相关联的。

一些配置针对搜索索引中的不同项目采用显式映射和adhoc途径。具体地，显式映射可以用于搜索索引中最常见项目，而adhoc途径可以用于剩余项目。

转到图25，提供了流程图，其图示了用于使用显式映射和adhoc信息来确定位向量存储位置的方法2500。最初，如框2502所示，接收搜索查询。方法2500可以至少部分地比如使用图44的匹配器4404来执行。如框2504所示，从搜索查询中标识一个或多个项目。

在框2506处访问一个或多个数据结构以确定在框2504处标识的项目的位向量的存储位置。数据结构可以包括上文所讨论的条带表和/或项目表。具体地，数据结构提供用于一些项目的显式映射，其中用于那些项目的位向量的存储位置被显式标识。数据结构还存储adhoc信息，其用于得出未提供显式映射的其他项目的位向量的存储位置。adhoc信息可以提供用于确定位向量的存储位置的映射算法。可以提供用于不同频带的不同的映射算法。如此，adhoc信息可以将项目特点映射到映射算法。换句话说，可以将不同的项目特点集合映射到不同的映射算法。

在框2508处做出关于显式映射信息或adhoc信息是否可以用来标识在框2504处标识的项目的位向量的存储位置的确定。比如，项目表可以存储显式映射。可以检查项目表来看它是否包含该项目。如框2510所示，如果是，则显式提供的位向量存储位置被标识。如框2512所示，如果显式映射信息不可用，则adhoc信息被用来得出用于该项目的位向量存储位置。这可能牵涉到确定用于项目的项目特点并且查找用于那些项目特点的映射算法。比如，映射算法可以由其中针对不同的频带阐述不同的映射算法的条带表来存储。用于该项目的频带可以基于针对该频带标识的项目特点和映射算法来确定。然后，映射算法用来得出位向量存储位置。

如框2514所示，访问用于该项目的位向量。如果在框2504处标识了多个项目，则对每个项目执行在框2506、框2508、框2510、框2512以及框2514处访问位向量的过程。然后，如框2516所示，所访问的位向量被交叉以标识用于搜索查询的匹配文档。

项目表可以按照本文中所描述的技术的各个方面以若干种方式填充数据。比如，给定正在被索引的文档的静态语料库，可以通过扫描文档并且计算项目来确定关于那些文档中项目频率的统计数据，以及基于该信息来构建用于该文档集合的项目表。然而，web上文档的特点总体上是相当稳定的，因此可以选择随机数目的文档(例如，一千万个文档)，可以计算该文档集合的项目频率，可以构建项目表，其相当优化地存储来自那些文档的倒排，然后可以使用该项目表用于其他文档。

当生成用于项目表的显式映射时，一些配置针对在某个期望位密度周围维持位向量密度(即，在每个位向量中设置的位的百分比)。比如，算法可以用来生成显式映射，其选择用于项目的位向量以基于文档中的项目的频率来实现期望的位密度。位向量的位密度不需要精确地等于期望的位密度；但是相反，该途径试图保持接近期望的位密度(例如，一些位向量可能具有稍高的位密度，而一些位向量可能具有稍低的位密度)。

行修剪/扩充

当使用位向量来设计和构建搜索系统时，被存储在搜索索引中的信息量可以基于最坏情况的查询。存在一些查询，其仅用少量的索引信息进行处理。在频谱的另一端上，有些查询需要存储大量的信息来很好地处理查询。

有趣的是，从信息存储角度来看，最难处理的查询是由单个字组成的查询，其中查询可用的唯一位向量信息是该单个字的位向量。相反，作为多个字的连接词的查询(例如，3个字或4个字，其是更典型的)，每个附加字需要较少的信息来处理查询。如果查询具有大量字并且系统取回每个字的所有位向量，则执行查询可能需要引入大量信息，并且查询可能变得效率低下。然而，并非所有这些信息都被需要以执行查询。

本文中所描述的技术的一些方面采用在本文中被称为行修整和行扩充的方面，其针对在对查询执行匹配时使用查询得每个项目的可用位向量的更少(修剪)或更多(扩充)位向量。比如，假设查询包括每个字的idf为四的三个字，使得每个字被存储在五个位向量中(基于其中字的行交叉的数目与其idf相对应的示例拇指规则)。因而，这个查询存在交叉可用的15个位向量。然而，15位向量的14个位向量交叉比所需要的交叉更多。

可以使用可用位向量的一部分，而非使用可用于三个字的所有位向量。通常，查询的idf可以用于确定要交叉的位向量的数目。比如，在具有三个字的查询的先前示例中，10000个中1个的目标假阳性率可能只需要五个位向量的四个交叉。可以从可用于三个字(例如，来自第一字的两个位向量；来自第二字的两个位向量；以及来自第三字的一个位向量)的15个位向量中选择五个位向量。

用于项目的位向量可以分布在不同类型的存储介质(例如，ddrram、ssd和hdd)上。对于具有多个项目的更典型的查询，行修整仅允许取回更快的存储介质(例如，ddrram和/或ssd)中的位向量。对于需要项目的更多信息的查询(例如，单个项目查询)，除了更快的存储介质中的行以外，行扩充还从较慢的存储介质(例如，ssd或hdd)中取回位向量。因为需要更多信息的查询通常比较罕见，所以将附加位向量存储在较慢的存储介质中是可接受的。例如，假设项目具有七个位向量，其中五个位向量被存储在ddrram中，而两个位向量被存储在hdd中。一些查询可能只需要位于ddrram中的位向量中的两个或三个位向量。更典型的查询可能需要位于ddrram中的四个或五个位向量。一些罕见查询可能需要全部七个位向量。

在建造项目到行映射(例如，在项目表中)时，一个考虑是确定每个项目使用多少个位向量，以及每个项目在哪个存储介质上存储位向量。项目的位向量的数目的确定可以基于项目在语料库中的频率。罕见项目需要更多的位向量。确定哪个存储介质存储项目的位向量可以基于项目在查询中的频率。在查询中出现频率较低的项目可以驻留在较慢的介质上。这权衡了在处理查询时存储项目的位向量的成本与使用该项目的位向量的似然性/频率。通常，各种存储介质上的位向量的数目及其位置可以被编码在条带表中。

接收查询时的一个考虑是确定在匹配器计划中每个项目要包括多少个位向量。该确定可以被视为优化问题，其权衡了来自附加位向量的降低噪声的益处与从较慢存储介质中取回那些位向量的成本。附加位向量的益处可以通过相关性度量(例如，假阳性率、误差率、修正成本或其他度量)来量化。

转到图26，提供了流程图，其图示了用于搜索查询的行修整/扩充的方法2600。方法2600可以至少部分地比如使用图44的匹配器4404来执行。最初，如框2602所示，接收搜索查询。如框2604所示，从搜索查询中标识一个或多个项目。

如框2606所示，确定用于每个项目的位向量的数目。如上文所描述的，这可以基于诸如来自附加位向量的噪声减少的益处、以及取回附加位向量的成本(其可以考虑存储位向量的存储介质的类型)之类的因素。该确定可以采用启发式和/或可以基于交叉初始数目的位向量来估计匹配文档的数目或百分比，然后使用基于估计的不同数目的位向量来重新运行交叉。在一些实例中，可以将优先级设置为可用位向量，并且可以按照该优先级来选择位向量。位向量在框2608处被交叉以标识匹配文档。

另一途径可能是基于在执行位向量交叉时观察到的位密度来动态地调整位向量的数目(尽管这种途径不能提供查询稳定性)。这种途径与确定位向量的初始数目、然后使用新数目的位向量重新运行的不同之处在于没有重新运行匹配过程。相反，当匹配过程继续时，位向量被添加或移除。该途径在图27中示出，其提供了流程图，其图示了用于搜索查询的行修整/扩充的另一方法2700。方法2700可以至少部分地使用比如图44的匹配器4404来执行。最初，如框2702所示，接收搜索查询。如框2704所示，从搜索查询中标识一个或多个项目。

如框2706所示，确定每个项目的位向量的初始数目。比如，可以使用启发式来确定该初始数目。该确定可以考虑预期将返回多少个匹配文档、相关性度量、和/或从存储器中取回位向量的成本。

如框2708所示，初始数目的位向量用于通过交叉位向量来开始匹配过程。如框2710所示，虽然执行匹配过程，但是正在被使用的位向量的数目被调整。这可以包括：增加附加位向量和/或移除位向量。位向量的数目可以在匹配过程期间被调整任意次数。该调整可以基于不同的考虑，诸如正在被返回的匹配文档的数目或百分比、和/或从存储器中取回更多/更少的位向量的成本/成本节省。在一些实例中，优先级可以被指派给可用的位向量，并且可以按照该优先级来添加或移除位向量。

更新搜索索引

因为新文档变得可用，并且先前索引的文档被修改或变得陈旧(并且因此可能被移除)，所以搜索索引需要被更新。更新使用倒排列表构建的搜索索引传统上是有问题的。通常对倒排列表进行排序(例如，通过文档id或静态排名)，其使得难以添加和移除文档。将文档添加到倒排列表牵涉到确定倒排列表中的位置以添加文档id，然后移动其他文档id以允许添加文档id。如果需要从倒排列表中移除文档，则文档id被移除，然后需要基于移除来移动其他文档id。基于添加和移除来移动文档id会影响搜索系统所使用的跳过列表和/或其他机构，并且需要基于文档id的移动来更新跳过列表和/或其他机构。因此，更新基于倒排列表的搜索索引可能需要使服务器脱机，从而重建搜索索引，然后使服务器重新联机。如果服务器对庞大文档集合进行索引，则重建搜索索引的过程可能非常耗时，从而导致服务器长时间处于脱机。如果时间长度足够长，则搜索索引可能被更新得更不频繁，从而导致搜索索引变得陈旧。

使用基于位向量的搜索索引(诸如图44的位向量搜索索引4410)的优点在于，搜索索引可以递增地更新，而无需在任何时间段内停止服务器，其是一些搜索系统的情况。因为在表示相同数目的文档的情景中，位向量的宽度全部可以是恒定的，使得新文档的空间被预先分配，所以可以通过简单地设置和清除位来执行添加和移除文档，如下文将更详细地讨论的。

与倒排列表相比，位向量不会遇到与按排序次序维护文档相关联的问题。当更新倒排列表时，可能不需要移位文档id或更新指针。即使系统正在运行，也可以添加或移除文档。如果当执行更新时，接收到搜索查询，则根据更新的进度可能会有两个后果中的一个后果。第一可能后果是在更新之前已经标识的匹配集合。也就是说，搜索查询是在以可能影响结果的方式改变位之前执行的。第二可能后果是在更新之后可能会被标识的结果。也就是说，搜索查询是在位被充分改变以影响后果之后执行的。没有可以提供任何其他结果集合的时间点。因为更新位向量可以在停机时间最短或者没有停机时间的情况下快速完成，所以数据中心设计得以简化，这是由于它不需要考虑实质性的停机时间，并且由于不频繁更新而不必关心搜索索引变得陈旧。

转到图28，提供了流程图，其图示了用于将文档添加到基于位向量的搜索索引的方法2800。比如，该方法2800可以由索引器4418执行以更新图44中所示的搜索系统4400中的位向量搜索索引4410。如框2802所示，标识文档中的项目。每个项目的位置(例如，主体、非主体、元)还可以被标识。如框2804所示，选择要添加文档的列。

通过示例来说明列的标识，图29图示了具有长度变化的位向量的集合的简化搜索索引2900。突出显示部分2902是被分配用于索引特定文档的列，包括与该文档相对应的每个位向量中的位。可以理解，短行位向量中的列的位与其他文档共享。

在一些配置中，搜索索引中的位向量可以包括若干个“空”列以允许添加文档。这些列在其位被设置为零的这个意义上是空的。注意，空列可能会基于共享那些位的其他文档的存在而在一些短行位向量中设置位。

如框2806所示，标识与在文档中找到的项目相对应的位向量，如框2808所示，标识与针对文档而选择的列相对应的所标识的位向量中的每个所标识的位向量中的位，以及如框2810所示，设置所标识的位(即，通过将位中的每个位设置为“1”)。

现在参考图30，提供了流程图，其图示了用于移除文档的方法3000。该方法3000可以至少部分地使用比如图44的索引器4418来执行。如框3002所示，标识与要被移除的文档相对应的列。如上文所指出的，列是指与特定文档相对应的每个位向量中的位。通过示例，图31a图示了具有长度变化的位向量集合的简化搜索索引3100(较短的位向量被展开以示出对应的位)。通过区域3102突出显示与要被移除的文档相对应的列(即，位的集合)。

如框3004所示，所标识的列中的位中的每个位被设置为零。将列中的所有位设置为零被在图31b中表示。因为较短位向量中的位被其他文档共享，其中一些将保留在索引中，所以用于那些文档的较短位向量中的位可能需要修正。因而，如框3006所示，共享较短位向量中的位的文档的集合被标识。这些是与图31c所示的列3104、3106、3108、3110、3112、3114、3166相对应的文档。如框3008所示，与包含在那些标识的文档中的项目相对应的较短位向量中的位被重置。这可以比如通过以下各项来完成：标识与包含在文档中的项目相对应的位向量，标识与文档相对应的那些位向量，以及设置那些位(类似于上文参照图28讨论的用于添加文档的途径)。图31d图示了基于与列3104、3106、3108、3110、3112、3114、3166相对应的文档已经在搜索索引3100中被重置的位。

用于移除特定文档的上述途径的操作可能是昂贵的，这是由于它需要文档与被移除以被重新索引的文档共享位。因此，这种途径可以在有限的情形下被采用，比如，当出于法律原因而需要将文档从搜索索引中移除时。

从搜索索引中移除文档的另一途径是批量移除文档，其可能移除需要重新索引与移除的文档共享位的文档的复杂性。这样，通过将所有位设置为零，共享位的所有文档被同时移除，并且不需要重新索引文档。比如，可以采用期满途径，其中策略规定时常(例如，每24小时、每周、每月等)移除文档。根据该策略，比设定时间阈值更老的所有文档将通过将那些文档的位设置为零来移除。时间阈值可以与文档被索引有多频繁相一致。通过示例来说明，文档可以每隔24小时进行索引。如此，24小时前被索引的文档将大约在文档再次被爬取并且重新索引的同时从搜索索引中移除(即，通过将在文档的列中的位设置为零)。当文档被再次爬取时，可能会使用先前所采用的同一列进行索引。然而，更简单的途径可能是简单地将先前列中的位归零，并且在搜索索引中的新列中索引文档。这有助于在文档基于它们被爬取的时间来被添加到搜索索引中的连续位置时批量删除文档。

从搜索索引中移除文档的另一途径为不是真正地移除索引信息，而是防止响应于搜索查询而返回某些文档。具体地，长位向量可以被存储在搜索索引中并且在对所有搜索查询进行匹配期间交叉。长位向量中的位可以被初始设置为1，并且如果文档要被移除，则该文档的位被设置为零。如此，当接收到搜索查询并且该长位向量被交叉时，位被设置为零的任何文档被有效地移除。虽然这种途径提供了一种相对简单的方式来“移除”文档，但是由于“移除”的文档在搜索索引中占据了空间，所以它具有成本。然而，因为随机访问删除的实例可能相对罕见，所以这对于随机访问删除可能是可接受的(例如，出于法律原因而需要移除文档)。

当索引被完全存储在ram中时，对索引的更新相对直接。比如，如果采用期满策略，则ram中的搜索索引在概念上可以被认为是位的2d阵列，其中文档被添加到右手侧，而左手侧上的文档被移除。然而，更大的搜索索引实际上可能不完全适合于ram，并且可以采用其他存储设备(诸如ssd和/或hdd)来存储搜索索引的各部分。具体地，ssd和hdd的存储容量较大，成本相对较低。然而，ssd和hdd通常比ram慢，无论是每秒每个可以处理的请求(即，iops-每秒输入/输出操作)的数目极限还是数据可以被传送的速率(即比如每秒以字节或每秒以mb测量的吞吐量)。

增量索引更新的性能考虑包括但不限于将列添加到二维阵列中的成本、以及由于数据存储设备(如ram、ssd和hdd)的面向块的性质而导致的效率低下。通过示例来说明这样的考虑，图32a示出了按照行优先次序布置的4×4阵列。当阵列以行优先次序排列时，行内的连续列位置驻留在连续的存储位置中。作为示例，列a至d驻留在第1行的位置0至3和第2行的位置4至7。按照本文中所描述的配置，倒排被按行优先次序进行布置，其中列与文档集合相对应，而行与项目集合相对应。这种布置用于优化查询处理期间行扫描的速度。

在文档摄入过程期间，可能有必要将另一列添加到阵列中。图32b示出了在添加第五列之后来自原始阵列的数据的布局。为了维持行优先布局，有必要移动原来在存储位置4至15中的数据。作为示例，考虑位置b2。在图32a中的原始4×4阵列中，位置b2与存储位置5相对应。在图32b中的新4×5阵列中，位置b2与存储位置6相对应。

因为这些数据移动，所以添加单个列的工作量与复制整个阵列的工作量类似。避免与添加列相关联的成本的一种方式是从更大的阵列开始，该列保留用于附加列的空间。图33a示出了这种阵列的示例。在这个特定示例中，该阵列具有用于6个列的空间，但只有两个正在使用。图33b示出了添加第三列牵涉到仅写入与该列相关联的存储位置。其他存储位置保持不变。如图33c所示，在添加另外三个列之后，该阵列将变满。

此时，如图34a所示，阵列可以被复制到更大的缓冲器。可替代地，如图34b所示，可以开始新的缓冲器。如图34a所示，复制阵列成本高昂，但是具有以下优点：每一行映射到可以被有效地扫描的连续存储块。如图34b所示，开始新缓冲器成本低下，但是具有以下缺点：现在每一行都映射到一对块。每个块内的存储器是连续的，但是块本身不在相邻的存储器位置。一些设备(如ssd和hdd)对所访问的每个连续存储块导致产生显著的设置成本。对于这些设备，图34b中的布置的设置成本是图34a的布置的设置成本的两倍。

为了在读取行的同时提供可接受的性能，需要限制索引中存储块的数目。同时，为了在摄入文档的同时提供可接受的性能，需要限制块被复制的次数。本文中所描述的配置使用阵列的层级来最小化块复制操作的数目，同时对组成行的块的数目施加限制。作为示例，如图35a所示，一些配置可以采用两个小阵列、两个中等阵列和两个大阵列的空间。在这个示例中，小阵列的列数是中等阵列的列数的一半。大型阵列的列数是小阵列的列数的五倍。

最初，如图35a所示，该系统是空的。如图35b所示，在文档到达时，它们被索引到新创建的小阵列中。如图33a所示，小阵列由包含已经被索引的文档的列集合以及为未来将被索引的文档保留的列集合组成。此时，可以通过单个块读取来访问行。

此时，如图35c所示，第一小阵列变满，并且创建新小阵列来接受附加文档。此时，访问行需要两个块读取操作。最终，如图35d所示，第二小阵列变满。此时，如图35e所示，创建中等大小的阵列并且用两个小阵列的内容的副本进行初始化。然后，清除两个较小阵列，并且在第一小阵列中继续文档摄入。在该配置中，行访问需要两个块读取操作。最终，如图35f所示，小阵列将再次填满，并且将创建第二中等块。此时，行访问需要三个块读取操作。此时，如图35g所示，两个小阵列将再次变满，但是这时这两个中等阵列也将是满的。在这种情形下，没有介质阵列可用来保持小阵列的内容。行访问现在需要四个块读取操作。此时，创建新的大阵列，并且用两个小阵列和两个中等阵列的内容进行初始化。然后，如图35h所示，清除小阵列和中等阵列，并且在第一小阵列中继续摄入。行访问现在需要两个块读取操作。

数据存储设备通常以大于单个位的粒度向数据提供读取/写入访问。这些设备上的位被分组为块，这些块表示可以在单个操作中被读取或写入的最小量的数据。作为示例，ddr3存储器协议将数据布置成512位的块。从ddr3存储器中读取单个位需要读取包含该位的块中的所有512位。同样，写入单个位需要在该块中写入全部512位。ssd和hdd具有更大的块大小。例如，典型的ssd可以将数据布置成4096字节或32768位的块。在这样的ssd上读取或写入单个位可能牵涉到读取或写入32768位。典型的hdd块甚至更大。

如上文所指出的，本文中所描述的配置将倒排数据布置为二维位阵列，其中行与项目的集合相对应，而列与文档集合相对应。位的2d阵列按行优先次序进行排列。也就是说，单个行内的位占用连续的存储位置，并且组成该阵列的行占用连续的存储位置。这种布局的结果是对单个行的操作牵涉到访问一系列连续的存储位置，而对列上的操作需要访问一系列不连续的存储位置。添加、更新或移除文档的动作牵涉到写入单个列内的位，因此需要访问非连续的存储位置。

该操作效率低下，因为读取或写入单个位牵涉到读取或写入完整的位块。在对ddr存储器进行更新的情况下，读取或写入单个位牵涉到对512位的操作。因此，与读取或写入512个连续位的操作相比较，511/512的存储设备吞吐量被浪费了。这种低效率对于存储在ddr存储器中的倒排是可以接受的，因为相对于ddr存储器的高吞吐率，文档摄入率相当较低。

然而，当倒排被放置在ssd或hdd上时，出于两种原因，由于块访问而导致的效率低下变得不可接受。第一原因是ssd和hdd通常具有更大的块大小。比如，ssd可以使用4kb(32k位)的块，而hdd可以使用16kb(132k位)的块。这些块分别比典型的ddr3块大64和256倍。其结果是，读取或写入存储在ssd或hdd上的单个位比读取或写入存储在ddr3存储器中的单个位低64至256倍。第二个原因是读取或写入ssd或hdd上的块的时间远远大于读取或写入ddr3存储器的块的时间。例如，典型的ssd操作可能花费20ms，而典型的ddr3操作可能花费10ns。换句话说，读取或写入ssd的块可能比访问ddr3存储器中的数据块慢200万倍。hdd甚至更慢。

如图36所示，通过被布置为如图35a至图35h所示的阵列层级的索引，通过将小阵列放置在ddr存储装置中以及将中等阵列和大阵列放置在ssd和hdd上，可以减轻与离线存储设备相关联的效率低下。这样做的原因是各个列写入操作只发生在最小的阵列中。由于最小的阵列被存储在ddr中，所以列写入的成本很低。较大的阵列只能通过复制较小阵列集合的全部内容来初始化。这些大型复制操作对离线存储设备是有效的。在一些配置中(诸如在图35a至图35h的示例中)，可以将数据从阵列集合写入到更大的阵列(例如，从小到中等、或从中等到大)，使得写入到更大型阵列的数据填充该阵列，从而限制到更大型阵列的写入的数目。

阵列中的每个阵列在本文中可以被称为累积缓冲器，因为每个阵列用来累加文档，直到达到某个点为止，然后内容被写入更大的阵列。现在转到图37，提供了流程图，其图示了用于使用累积缓冲器来索引位向量搜索索引中的文档的方法3700。方法3700可以至少部分地使用比如图44的索引器4418来执行。如框3702所示，最初，在累积缓冲器存储设备中索引文档。累积缓冲器存储设备将文档信息存储为位向量，其中每个位向量包括位阵列，其中每个位指示一个或多个文档中的至少一个文档是否包括包含与位向量相对应的一个或多个项目中的至少一个项目。在累积缓冲器存储设备是初始存储设备的情况下，每个文档可以通过设置每个文档的位而一次一个地在累积缓冲器存储设备中进行索引。比如，用于文档的位可以在爬取文档之后在累积缓冲器存储设备中进行设置。在其他实例中，在框3702处索引文档的累积缓冲器存储设备之前可以有一个或多个先前累积缓冲器。在这样的实例中，可以基于在先前累积缓冲器中设置的位来在累积缓冲器存储设备中集中索引文档。

在框3704处，做出关于是否已经满足阈值的确定。如果没有，则如通过返回到框3702表示的，继续在累积缓冲器存储设备中索引文档的过程。可替代地，如框3706所示，如果阈值已经满足，则从累积缓冲器存储设备索引的文档信息在后续存储设备中被集中索引。可以理解，当后续存储设备大于累积缓冲器存储设备时，数据可以从累积缓冲器存储设备中的连续位移动到后续存储设备中的非连续位。

在不同的配置中可以采用不同的阈值。在一些实例中，阈值是一定数目的文档，使得当在累积缓冲器存储设备中索引了一定数目的文档时，阈值被满足并且信息从累积缓冲器存储设备被索引到最终存储设备。在其他实例中，阈值是某个时间段(例如，一小时、一天等)，使得当该时间段已经过去时，信息从累积缓冲器存储设备被索引到最终存储设备。在其他实例中，阈值可以是某个存储量(例如，为累积缓冲器存储设备或者累加缓冲其存储设备的集合设置的存储容量)，使得当存储量已经满足时，信息从累积缓冲器存储设备被索引到最终存储设备。

如框3708所示，做出关于后续存储设备是否已满的确定。如框3710所示，如果没有，则可以重复在累积缓冲器存储设备中索引文档(例如，通过清空累积缓冲器存储设备并且索引新文档)直到满足阈值为止以及将信息从累积缓冲器存储设备索引到后续存储设备的过程。这个过程可以继续，直到后续存储设备已满为止，此时过程结束。除了最终存储设备是否满之外，其他阈值可以用于确定是否重复该过程。比如，可以替代地使用基于时间的阈值(例如，最终存储设备可以被配置成保持一天的文档)或文档阈值(例如，最终存储设备可以被配置成保持阈值数目的文档)。

应当理解，累积缓冲器的数目和大小可以基于设计目标来配置。通常，更多的累积缓冲器对于其他成本使其具有附加累积缓冲器不太理想的某个点可能是期望的。具体地，累积缓冲器可以用于服务搜索查询(即，搜索查询可能基于不仅在最终存储设备(即，大型存储设备)中索引的文档而且还基于尚未被提供给最终存储设备的当前存储在累积缓冲器中的文档来服务)。如此，当每个累积缓冲器被访问以服务于搜索查询时，更多的累积缓冲器可能减慢查询处理速度。根据设计目标，可以选择最佳数目的累积缓冲器。例如，如果搜索索引将经历大量查询，但是数据没有经常被更新，则最佳设计可能是更少的累积缓冲器。作为另一示例，如果搜索索引将经历不频繁的搜索查询，但是数据经常被更新，则最佳设计可以是更多的累积缓冲器。附加地，在一定数目的写入之后，ssd容易被烧坏。因此，ssd上的累积缓冲器的数目会影响烧坏，并且当在设计中选择采用ssd累积缓冲器的数目时，可能要考虑ssd的烧坏率。

初级排名器算法

如本文中所讨论的，搜索系统可以使用匹配器(诸如图44的匹配器4404)以初始标识用于搜索查询的匹配文档组。由于该文档组在大多数情况下太大而不能作为搜索结果集合被返回，所以可以利用一个或多个排名器来进一步缩小文档组的范围，以使响应于搜索查询仅返回最相关的文档。在一种配置中，使用至少两个排名器，包括初级排名器，诸如图44的初级排名器4422。虽然初级排名器能够近似地估计后续排名器(诸如图44的最终排名器4426)将依据评分文档和排名文档做什么，但是初级排名器操作起来更便宜。例如，在本文中所描述的技术的一个方面中，初级排名器消除了对后续排名器的所有文档的考虑(后续排名器也会消除该文档)。如此，由初级排名器使用的算法被设计成消除(例如，将低评分指派给)也将被后续排名器所使用的算法(诸如图44的最终排名器4426)所消除的所有文档。这可以大大减少初级排名器处的候选文档集合，而不必消除与查询特别相关的并且应该被包括在最终后续排名器或其他后续排名器处的候选文档集合中的文档。

现在，参考图38，图示了用于执行本文中所描述的技术的各方面的示例性系统3800。提供了匹配器3802(其可以与图44的匹配器4404相对应)、得分表服务器3804和初级排名器3610(其可以与图44的初级排名器4422相对应)，并且可以通过网络3608进行通信。匹配器3802先前已经在本文中进行了描述，并且因此没有关于系统3800进行描述。被发现通过匹配器3802相关的文档的标识被返回给初级排名器3810。对于被指示为可能与特定搜索查询有关的每个文档，得分表服务器3804访问与每个文档相关联的得分表。在一种配置中，得分表被存储在得分表数据存储装置(诸如数据存储库3806)中。

初级排名器3810具有许多功能，如本文中更详细描述的。比如，除了图38中未示出的其他部件之外，初级排名器3810还包括得分表构建部件3812、得分表查找部件3814、评分部件3816、键比较部件3818和点击表查找部件3820。下文将这些部件中的每个部件的功能性进行详细描述。

虽然传统排名器可以利用与倒排列表中的每个项目相关联的数据的有效载荷来对文档进行评分和排名，但是本文中所描述的技术的各方面使用具有预先计算的数据的表格。倒排列表可以利用倒排索引，其可以表示整个文档语料库。例如，倒排列表可以首先按文档进行布置，然后按文档中的每个项目的出现进行布置。该列表还可以包括指针，该指针可以用于从项目的第一次出现移动到同一项目的后续出现。虽然倒排列表可能有助于减少候选文档的数目，但是它们也消耗大量的存储器，并且比本文中所描述的得分表使用更慢。

如上文所描述的，代替使用倒排列表，一些配置利用散列表，也被称为得分表。在一个方面中，每个文档具有其自身的得分表，其包括预先计算的数据，诸如频率数据。如所提及的，这些得分表可以被存储在数据存储库3806中。得分表还可以包括其他数据，其已经被预先计算。关于频率，频率可以是预先计算的，但是可以不是作为文档中的项目的实际频率而是作为例如idf被存储在得分表中。idf与文档中项目出现的次数成比例地增加，但被语料库中字的频率所抵消。以不同的方式陈述，存储在表中的值可以反映文档中的特定项目的频率与语料库中该项目的相对低频率的关系。还设想了表示得分表中的项目的预先计算的频率的其他方式。如此，存储在得分表中的关于项目的频率的数据可以指示文档中项目的频率，但是可以以需要某种类型的计算来确定实际频率的这样的方式被存储。初级排名器使用的算法可以使用指示每个文档的评分计算中的频率的数据，并且因此可能不需要计算该项目的实际频率。甚至进一步地，出于效率的目的，诸如为了减少所需的存储器，频率数据可以针对得分表中的项目以最大频率被裁剪，使得频率数据可以在得分表中用较少的位来表示。

如所提及的，每个文档可以具有相关联的得分表，该得分表存储用于由初级排名器对文档进行评分和排名的预先计算的分量的数据。为了产生有效排名器，得分表构建部件3812可以不包括得分表中的文档中的所有项目。比如，只有在特定文档的主体中出现不止一次的那些项目的数据才可以被存储在该文档的得分表中。文档中大约85％的项目可能只在文档的主体中找到一次，因此消除与这些项目相关联的各种分量的预先计算节省了存储器，并且使得初级排名器的操作速度比其他方式快得多。因此，在文档的主体中仅出现一次的项目以及根本不在文档中出现的项目可以被视为相同，并且因此可以被赋予相同的得分，这是因为初级排名器可能不能够区分这些。因为系统知道在文档主体中仅出现一次的项目不被包括在每个文档的得分表中，所以系统在一个配置中将未在特定得分表中发现的所有项目视为在主体中出现一次。这意味着文档中未包含的项目将被视为在主体中出现一次。这是可以接受的，由于它不会显著影响排名。即使这些项目在这些其他位置仅出现一次，也可以对来自其他位置(例如，非主体和元字)的项目评分更高并且存储信息。

通过示例来说明，如果特定搜索查询包括项目“猫”和“狗”两者，则可以返回被发现具有项目“猫”的文档。初级排名器可以访问该特定文档的得分表，以发现“狗”没有在得分表中列出，并且可以假设“狗”在文档的主体中仅被提及一次。在这种场景中，初级排名器可能给予文档一个“1”而不是“0”的得分，该得分通常被给予文档，在这个文档中，根本不会出现项目。如此，在一个配置中，对于在得分表中没有找到的特定项目，没有文档被给予“0”的得分。

虽然已经讨论了文档中每个项目的频率，但是其他预先计算的数据也可以被存储在得分表中。比如，文档中每个项目出现在哪里的指示可以在得分表中进行编码。比如，在文档的一种类型中，项目可以位于标题流、主体流、锚点流、url流等中。位于文档的标题中的项目可以指示例如文档很有可能与该项目相关，并且因此与用户的意图相关，该用户的意图与搜索查询相关联。进一步地，在文档的单个段落或特定章节中多次出现的特定项目可以指示该文档与搜索查询的特定相关性。

除了上文所讨论的预先计算的分量之外(诸如文档中的项目的频率以及项目所在的文档的哪个部分)，当(诸如通过评分部件3616)计算与搜索查询相关的文档的最终得分时，还可以考虑一个或多个实时分量。实时分量是一旦录入和接收到搜索查询就计算出的那些分量，因为它们通常不能被预先计算。例如，搜索查询中特定项目的位置直到运行时间才能被计算出来，这是因为直到那个时候查询才是已知的。进一步地，文档的地理本地与查询起源的地理本地的匹配程度直到运行时间才能确定，并且如此，是实时计算的。另一示例是文档的语言与查询语言的匹配有多好。在录入搜索查询之前，这也不会被计算，并且初级排名器运行算法以确定文档集合与搜索查询有多相关。

如评分部件3816所计算的，与搜索查询相关的文档的最终评分可以取决于一个或多个预先计算的分量和一个或多个实时分量这两者。比如，每个分量(无论是否预先计算的分量)都可以通过初级排名器使用的算法来指派各个评分。诸如评分部件3816之类的算法然后考虑各个得分以计算与特定搜索查询相关的每个文档的最终得分。最终得分可以用来对文档进行排名，或者用来以其他方式消除后续排名器对一些文档的考虑。在一种配置中，最终得分是指示特定文档与搜索查询有多相对应的数字。

初级排名器还可以使用点击表来确定每个文档的得分。如上文所描述的，点击表的功能可能与得分表相同。数据被存储在文档的每个项目的点击表的空隙中。在一种配置中，在文档中找到的所有项目都被包括在点击表中，但在另一种配置中，只有不止一次出现的那些项目才会被包括在点击表中。对于每个项目，点击表存储数据，其指示提交相同或相似搜索查询的用户选择文档有多频繁。提交相同或相似搜索查询的其他用户选择特定文档有多频繁可能是关于确定该文档是否应该被认为与当前搜索查询相关的有价值的指示符。如此，可以通过例如作为可以有助于用于特定搜索查询的文档的最终得分的一个部件的点击表查找部件3820来访问点击表。

图39图示了比如使用图38的初级排名器3810以基于与搜索查询的相关性来对多个文档进行评分的方法3900的流程图。最初在框3902处，访问与被发现可能与所接收的搜索查询的至少一部分相关的文档相关联的表。该表可以存储用于得出文档中的项目的子集的每个项目的频率的数据。在一种配置中，项目的子集中的每个项目在文档中不止一次出现。在一个实例中，文档中所有项目的不到一半的项目都被包括在项目的子集中。该文档可以是比如已经由图44的匹配器4404找到以基于键匹配来具有与搜索查询相关的潜力的多个文档中的一个文档。在框3904处，确定与搜索查询相对应的至少一个项目的频率。在一种配置中，频率的确定可以简单地是指来自正在被访问和取回的表的频率数据。如何处理数据取决于算法。比如，该算法可能需要将表中的数据变换成频率的不同表示，诸如从idf到文档中项目的频率。可替代地，算法可以在计算文档的评分中使用idf。如先前所描述的，指示频率的数据可以被预先计算，并且可以被存储在表中，并且如此，在框3904处，表中的数据被用于通过由初级排名器使用的算法来确定频率。存储在表中的这个频率数据可以不仅提供文档中项目的频率的指示、还能提供文档中的项目在文档语料库中相对于该项目的相对低频率的频率的指示。

在框3906处，计算文档相对于搜索查询的得分。这至少基于文档中的至少一个项目的频率、以及与文档和搜索查询的项目相关联的其他数据。频率是预先计算的分量。其他预先计算的分量包括项目在文档中的位置，诸如在标题、主体、摘要、锚点、url等中是否找到该项目。得分的至少一部分可以基于实时(诸如在运行时间)计算的一个或多个实时分量。这些可以包括例如至少一个项目在搜索查询中的位置、每个项目相对于彼此的位置、文档的语言与搜索查询的语言的比较、以及将与文档相关联的地理本地和与搜索查询相关联的地理本地的比较。在本文中所描述的技术的一个方面中，可以使用预先计算的分量和在接收到搜索查询之后计算的实时分量两者的许多各个分量得分来计算最终得分。

现在参照图40，提供了流程图，其图示了比如使用图38的初级排名器3810以基于与搜索查询的相关性来对多个文档进行评分的另一方法4000。在框4002处，访问存储与文档相对应的数据的表。尽管所存储的数据可能不是实际频率，而可以是例如idf，但是数据被预先计算为指示项目在文档中的频率。该频率数据有助于文档相对于搜索查询的得分。仅出于示例性的目的，预先计算的分量可以包括项目在文档中的频率、项目所在的文档的一部分(诸如标题、主体、锚点、url、摘要等)、以及项目在文档的那些部分中出现有多频繁。在框4004处，计算预先计算的分量中的每个预先计算的分量的得分，并且在框4006处，实时或在运行时间计算实时分量中的每个实时分量的得分。在框4008处，基于预先计算的分量和实时分量的得分来计算文档相对于搜索查询的最终得分。如所提及的，最终得分还可以考虑点击表中的点击数据。该点击数据指示其他用户针对与搜索查询相关联的项目选择文档有多频繁。

除了将数据存储在用于仅在文档中找到的项目的一部分(诸如在文档中出现两次或更多次的那些项目)的得分表中之外，初级排名器还适于通过当得分表被构建和访问时允许发生冲突而使用比典型的排名器更少的存储器。例如，当在文档中找到的一个项目的数据被写在另一项目的数据上时，可能发生冲突。如此，按照本文中所描述的技术的各方面使用的得分表以若干种方式与其他得分表非常不同地操作。最初，得分表通常具有空隙，每个空隙具有与其相关联的键。在一个配置中，来自文档的每个项目都有其自己的键，其当其他项目的数据被添加到表时，被使用。通常，当空隙在其中已经存储有数据时，该空隙不会用于存储另一项目的数据，而是利用另一空隙，诸如空的空隙。然而，在本文中的配置中使用的得分表允许发生这些冲突。当得分表正被构建时(诸如通过得分表构建部件3812)以及当查找发生时(诸如当得分表查找部件3814访问得分表以确定文档中的特定项目的频率和其他预先计算的信息时)，可能发生冲突。

虽然通常键可以被存储为64位，但是本文中所描述的技术的各方面提供了要被存储的少得多的量的位。例如，在一种配置中，可以针对得分表的空隙仅存储64位键的五个位。当较大键的五个位被存储并且与另一五个位键进行比较(诸如由键比较部件3818)时，键匹配的机会比存储大量位并且与其他键进行比较时的机会更大。虽然在上文的示例中使用了5个位，但是应当指出，可以使用比位的总数目更小的位的任何数目。比如，即使使用65位键中的60位也可能允许发生冲突，这是因为可能发生两个不同的键可能具有相同的60位部分，并且如此，在这种情况下，会发生冲突。

虽然允许发生冲突，但是如上文所描述的，采取防范以确保与搜索查询无关的文档(诸如最终排名器可能丢弃的文档)从初级排名器发送到最终排名器的文档集合中排除。例如，当针对特定文档构建得分表时，以及当已经确定将在文档中找到的第二项目的数据要被添加到已经与不同于第二项目的第一项目相关联的空隙中(例如，空隙已经存储了与不同项目相关联的数据)时，可以确定文档中第二项目的频率是否大于文档中第一项目的频率。如果第二项目的频率更高，则该更大的频率将被存储在空隙中，但是这两个项目将保持与相同的空隙相关联。这里，第一项目的频率正在用第二项目的频率进行重写。

然而，如果第二项目被添加到空隙的频率小于已经与空隙相关联的第一项目的频率，则第一项目的较高频率将保持存储在该空隙中，尽管第二项目可能被添加到该空隙。这里，虽然第二项目将与该空隙相关联，但是其频率不会被存储在得分表中，因为它低于已存储的频率。如果较低的频率被存储在较高的频率上，则即使与该得分表相关联的文档可能是搜索查询的相关文档，它也可能因特定搜索查询而被错误地排除。通过仅存储两个项目的较高频率，针对项目中的一个项目而被返回或计算的频率可能高于应当的频率(例如，如果返回的频率针对不同的项目)，但是当应当已经返回被发送到后续排名器以供后续处理的相关文档集合中的文档时，该文档将被排除。相反，文档的排名可能应该高于应当的排名，并且如此，即使相关文档集合中的文档与其他文档不相关，该文档也可能被返回。如此，被认为是相关的所有文档(诸如得分高于特定阈值的那些文档)将被返回，但还可能包括可能不相关的一些文档。

转到图41，提供了流程图，其图示了比如使用图38的初级排名器3810将项目的数据添加到得分表的空隙的方法4100。最初在框4102处，访问具有空隙的表，其中该表存储与文档相关联的数据。在框4104处，对于表的第一空隙，将与第一项目相关联的第一散列键的一部分和与要添加到第一空隙的第二项目相关联的第二散列键的一部分进行比较。如本文中所提及的，本文中所描述的技术的各方面允许多于一个项目与相同空隙相关联，而只有指示项目中的一个项目的频率的数据被存储在其中。在框4106处，确定第一散列键的部分是否匹配第二散列键的部分。如框4112所示，如果散列键的各部分不匹配，则与第二项目相对应的数据(例如，指示频率的数据)不被存储在得分表的第一空隙中。然而，如果散列键的各部分确实匹配，则在框4108处确定文档中第二项目的频率大于文档中第一项目的频率。在框4110处，与表的第一空隙相关联地存储与第二项目的频率相关联的数据。在一种配置中，该频率数据重写与第一项目的频率数据相对应的现有数据，该频率数据也与第一空隙相关联。

按照本文中所描述的技术的各方面，如果第一散列键的部分不匹配第二散列键的部分，则考虑第二空隙，并且因此将第二散列键的部分和与第三项目相关联的第三散列键的部分进行比较，第二散列键的部分的对应的数据被存储在表的第二空隙中。如果这些散列键的各部分匹配，则确定文档中第三项目的频率是否大于第二项目的频率。如果第二项目的频率较大，则将与第二项目相关联的频率数据被存储在表的第二空隙中，从而重写与第三项目相关联的频率数据。然而，如果第二散列键的部分不匹配第三散列键的部分，则与第二项目相对应的数据不被存储在表的第二空隙中。该过程可以继续，直到空隙位于散列键的各部分匹配的地方。

即使只有与在文档中找到的项目子集相关联的数据被存储在得分表中，并且即使允许发生冲突，但是初级排名器的结果意外地比传统排序系统更好，从而提供了更相关的文档集合。比如，当初级排名器与搜索系统(诸如本文中关于图44所描述的搜索系统)结合使用时，通过初级排名器发现相关的文档出乎意料地比通过其他排序系统发现相关的文档更为相关，而且发现速度更快。在一些配置中，初级排名器以比其他排序系统快两倍、五倍、七倍或甚至十倍的速度运转，使得本文中所描述的整个搜索系统以比传统搜索系统快得多的速率操作。

在本文中所描述的技术的各方面中，初级排名器可以由机器学习算法教导以标识用于特定搜索查询的最相关文档。通常，向初级排名器提供输入，其可以包括搜索查询、文档以及人类发现哪些文档与每个搜索查询最相关。根据这个输入，初级排名器被训练以提出与人类所提出的一样的相关文档。在一种配置中，机器学习算法使用奇异值分解，但还可以使用其他。

匹配修正

在搜索系统(诸如图44的搜索系统4400)中，匹配器(诸如匹配器4404)可以被用作搜索流水线中的早期步骤，以基于来自搜索查询的项目来标识匹配文档。如先前所解释的，由匹配器标识的文档集合通常太大而不能返回搜索结果或发送到昂贵的(即，从对每个文档进行排名所需的处理量的角度来看是昂贵的)排名器，诸如图44的最终排名器4426，这是由于排名器处理大量文档可能花费很长的时间。附加地，如果匹配器采用概率途径(诸如采用如上文所描述的基于位向量的搜索索引)，则匹配文档集合实际上可能包括一个或多个无效匹配文档，这些文档不是用于搜索查询的真实匹配。换句话说，无效匹配文档可能是假阳性，这是由于那些文档不包含来自搜索查询的一个或多个项目。将无效匹配文档发送到昂贵的排名器(诸如图44的最终排名器4426)将会因为处理这样的排名器所需要的每个文档的费用而浪费资源。

为了移除无效匹配文档并且由此减少发送到下游排名器的匹配文档的数目，本文中所描述的技术的一些方面采用在本文中被称为匹配修正阶段的内容。通常，匹配修正部件(诸如匹配修正部件4424)可以从匹配器(诸如图44的匹配器4404)接收包括无效匹配文档在内的匹配文档集合的至少一部分，并且基于所存储的标识每个文档中包含的项目的信息来评估每个文档，以移除无效匹配文档中的至少一些无效匹配文档。所存储的信息可以是比如正向索引。

按照本文中所描述的技术的各方面，匹配修正部件可以被用在匹配器和最终排名器之间的多种不同位置中。作为示例，图44图示了其中匹配器4404提供匹配文档4420的集合的流水线，这些匹配文档4420使用初级排名器4422进行评估以移除一些不相关文档，使用匹配修正部件4424进行评估以移除无效匹配文档的至少一部分，然后使用最终排名器4426进行评估以提供搜索结果集合。然而，搜索系统可能在使用任何数目的排名器的其他位置处采用匹配修正。比如，来自匹配器4404的匹配文档可以被直接提供给匹配修正部件4424，而无需任何初级排名器首先移除文档。附加地，可以在最终排名器4426之前将来自匹配修正部件4424的文档提供给一个或多个初级排名器。任何和所有这样的变型都被设想是在本文中所描述的技术的范围之内。

在搜索中使用的资源(例如，成本、处理时间、存储器等)可以与以有效方式提供准确和相关的搜索结果的需求相平衡。匹配修正部件的使用可以进一步优化搜索结果过程，而不添加对附加资源的需要，并且可以最终减少当前使用的资源。简而言之，匹配修正部件旨在成为进一步细化潜在搜索结果的部件。匹配修正部件对于过滤潜在搜索结果而言可以提供更好的性能；但是匹配修正部件可能需要附加存储器，并且可能比初级排名器稍慢。然而，匹配修正部件可能使用的任何附加资源(例如，更昂贵的)可以被抵消或小于后续昂贵的排名器(诸如图44的最终排名器4426)所备用的资源。例如，通过花费稍微更多的时间来细化匹配修正部件处的文档集合，后续排名器将需要更少的时间。进一步地，如果后续排名器接收和细化的文档比在可能没有匹配修正的情况下接收到的文档更窄，则后续排名器可以使用较少的存储器。

在应用中，匹配修正部件(诸如图44的匹配修正部件4426)可以接收匹配器(诸如匹配器4404)下游的文档集合(没有或没有使用匹配器和匹配修正部件之间的初级排名器(诸如初级排名器4420)的任何过滤器)。如所提及的，文档集合可能包括无效匹配文档。此时包括无效匹配文档在系统中是适当的，这是由于即使结果稍微偏离，目标当适当时要尽快移动，并且当适当时花费更多的时间来纠正结果，从而优化系统和结果。通过添加匹配修正部件，可以减少发送到后续排名器上的文档集合，并且初级排名器能够稍微更快地执行其任务，但是不太完美，这是由于匹配修正部件可能会进一步细化潜在搜索结果。如果潜在搜索结果是从初级排名器直接进入最终排名器而不使用匹配修正，则需要花费附加资源以确保发送给最终排名器的潜在搜索结果非常准确(例如，在10％的准确度之内)。添加匹配修正部件允许初级排名器不够准确，并且执行速度更快。

如所指出的，当先前阶段(例如，匹配器)是基于基于信息论的压缩时，匹配修正部件特别有用。由于使用倒排列表的匹配器可能是确定性的(因此不存在无效匹配文档)，所以在没有基于信息论的压缩引擎的系统(诸如例如，倒排列表)中，匹配修正部件可能不是那么有价值；这意味着资源被用来获得完美结果，所以没有机会进行匹配修正。

匹配修正部件可以执行无损修复或有损修正。如本文中所使用的，无损修正通常是指当可以从压缩数据完美重建原始数据的情形。另一方面，有损修正在本文中是指使用不精确的近似来表示内容的情形。因此，匹配修正部件可以完美地或不太理想地修正。任一种选择都可以在另一区域中得到补偿。比如，如果匹配修正部件执行得不太理想(例如，相对于原本而言，数目更高的无效匹配文档被发送到后续排名器)，则可以在匹配器阶段中添加附加位向量以减少首先被发送到匹配修正部件的假阳性(无效匹配文档)的数目。可替代地，完美修正可能允许系统在匹配器阶段使用较少的位向量，同时也意识到不会向匹配修正部件发送太多的文档，其可能在该阶段导致太多的成本。因此，在这种情形中，最大成本可以与阈值数目的文档相关联，使得匹配器阶段可以具有与可能允许最大数目的文档(直到阈值数目的文档)被发送到匹配修正部件上的阶段一样少的位向量。这可能允许匹配修理部件处的成本低于所指定的成本，并且由于可以发送的最大数目的文档被发送，所以在匹配器阶段允许时间量和成本量最少。

一旦接收到文档集合，匹配修正部件就可以访问每个文档在文档集合内的表示。该表示可以是数据结构。该表示可以包括文档的正向索引。正向索引存储存在的或与每个文档相关联的一个或多个项目的列表。匹配修正部件然后可以将正向索引与搜索查询进行比较以确定文档是有效匹配文档还是无效匹配文档。有效匹配文档是与搜索查询的真实匹配，而无效匹配文档不是真实匹配。因此，匹配修正部件可以检查正向索引以确定文档的正向索引是否指示文档匹配搜索查询(例如，文档的正向索引是包含第一项目还是包含第二项目等)。在确定与搜索查询相关联的一个或多个项目不存在于文档中时，匹配修正部件可以将文档标识为无效匹配文档。无效匹配文档可能会被匹配修正部件丢弃，而不会被发送到后续排名器上。同样，当与搜索查询相关联的一个或多个项目存在于正向索引中时，与正向索引相关联的文档可以被标识为有效匹配文档并且被发送到后续排名器上。

通常，评估每个文档的数据结构以确定它是有效匹配还是无效匹配是不合理的。然而，在本申请中使用匹配器和初级排名器将可能文档的数目减少到可接受以各自评估的数目。比如，假设在匹配修正部件上发送了100个文档，50个是好的，50个是坏的。匹配修正部件可以访问比如文档表示(例如，ssd)的存储位置并且评估每个文档的表示。整个文档可以被存储在ssd中，或者作为备选方案，每n个字可以被存储在ssd(其中n是任何数字)中。所存储的文档的数量可基于例如设计目标、匹配器和匹配修正部件之间的权衡等来配置。

匹配修正部件的引入通过允许匹配修正之前的阶段(例如，匹配器和初级排名器)比它们在没有匹配修正的情况下执行得更差来提供使系统更为高效的机会。附加地，还存在优化系统的机会，诸如评估误差率的成本与存储器成本。例如，如果对于特定系统，标识出10％误差率的成本是1gb并且20％误差率的成本是2gb，那么可以优化系统以在仍然有效的误差率下执行，但是利用最佳存储器以使存储器/资源使用总量低于未压缩值。

现在转到图42，提供了流程图，其图示了用于采用匹配修正以从概率匹配器的下游移除无效匹配文档的方法4200。该方法4200可以至少部分地使用比如图44的匹配修正部件4424来执行。最初，在框4202处，接收多个文档，其被发现与搜索查询的至少一部分相关。该多个文档可以包括一个或多个无效匹配文档。在框4204处，访问每个文档的表示。文档的表示包括存在于文档内的项目。在框4206处，将存在于每个文档内的项目和与搜索查询相关联的一个或多个项目进行比较。在框4208处，确定一个或多个无效匹配文档不包含与查询相关联的一个或多个项目。在框4210处，在确定一个或多个无效匹配文档不包含与该查询相关联的一个或多个项目时，从被发现与搜索查询的至少一部分相关的多个文档中移除一个或多个无效匹配文档。

现在转到图43，提供了流程图，其图示了用于采用匹配修正以从概率匹配器的下游移除无效匹配文档的另一方法4300。该方法4300可以至少部分地使用比如图44的匹配修正部件4424来执行。最初，在框4302处，接收第一多个文档，其被发现与搜索查询的至少一部分相关。该第一多个文档可以包括一个或多个无效匹配文档。在框4304处，访问第一多个文档中的每个文档的正向索引。该正向索引可以存储包含在每个文档中的一个或多个项目的列表。在框4306处，使用第一多个文档中的每个文档的正向索引，标识包含与搜索查询相关联的一个或多个项目的一个或多个有效匹配文档，而在框4308处，使用第一多个文档中的每个文档的正向索引，标识没有包含与搜索查询相关联的一个或多个项目的一个或多个无效匹配文档。在框4310处，从第一多个文档中移除一个或多个无效匹配文档，以创建被发现与搜索查询的至少一部分相关的一个或多个文档的经过滤的集合。在框4312处，传达被发现与搜索查询的至少一部分相关的一个或多个文档的经过滤的集合，以用于对搜索查询的一个或多个文档的经过滤的集合中的每个文档进行排名。

位向量搜索系统配置

如上文所讨论的基于位向量的搜索索引、初级排名器和匹配修正的使用会允许根据设计目标进行各种配置。为了减小文档的数目以供后续考虑，需要每个阶段使用的数据，所以由匹配器使用的位向量数据被优化，以便廉价地减少所有可能的文档的集合。然而，这些位向量基于信息值来进行填充，所以对位向量存储器的大小的压缩仅仅增加了假阳性率。通过将缓冲器增加固定大小(对数线性)，假阳性率减半。假阳性结果最终在匹配修正阶段被移除，并且每个假阳性被移除的成本固定。初级排名是每个所评分的项目的固定成本(例如，如果初级排名器所使用的得分驻留在存储器中，则每个线程每个文档大约150ns)。

以下是基于不同设计目标的五种不同配置的示例，以说明基于位向量的搜索系统的弹性。如先前所讨论的，“d”是指存储消耗(例如，每台机器可以被索引的文档的数目)，“q”是指处理速度(例如，每秒查询(qps))。表1提供了配置的摘要。

表1-配置

1.高dq-高效web搜索

高dq配置使得总效率最大化。该配置受ddr总线吞吐率的限制。这种途径在180kdq下运行，其中每台机器在v13机器上在18kqps下为1000万个文档。具有ssd的版本仍然受到ddr总线的限制，但是使用ssd来移除ddr容量的压力，从而允许以五分之一的速度实现五倍的文档计数。流水线中存在许多性能改进，其牵涉到更严格地控制查询计划以及更为积极的早期终止。这些改变可能会使性能再提高25％。早期终止用于以最小化对结果集合的相关性的损害的方式限制查询的成本。

2.深dq-尾部web搜索

深dq可以在与高dq相同的盒子上操作，而不会对头部搜索能力产生重大影响，尽管当速度更快的ssd可用时，这个自变量会更强。深dq主要使用hdd，尽管它在ssd中确实使用非常窄的位向量来寻找要扫描的hdd的区域。它使用元组和短语来避免低idf项目(相当于长倒排列表)。对于每个结果，都会发生hdd查找。通过1t网站索引，1000台机器可以保持互联网。这种途径旨在用于不太可能找到许多结果的查询，或者需要许多深dq位向量。

3.高q-subsql

高q配置类似于高dq配置，除了它不使用ssd之外。在没有ssd的情况下，则引擎被配置成始终具有较低等待时间。甚至像“列出麦当娜的所有朋友”这样的困难图表查询将在10ms内完成，并且大部分将在500usec内完成。

这种配置可以被设计成在对象存储装置内本地地工作，使得所组合的实体具有nosql的能力中的许多能力(尤其是文档存储像mongodb这样的最流行的nosql软件)。

通过向数据提供低级别的高性能原语而非通用接口，subsql更远离典型sql。例如，subsq不执行join操作；然而，复杂的join类似能力可以被构建到索引中，以提供低等待时间和高性能云操作。在subsql中，更细粒度排名和排序操作被主要用作以低成本发现大型结果集合内的项目的方式。

4.高d-数字生活和数字工作。

个人文档和个人电子邮件的世界将与图表交叉，这些图表不仅将沿着图表分享更多的内容，而且还可以帮助我们每个人在没有询问的情况下找到我们需要的东西。这种配置可以将图表(由subsql服务的)与由高d搜索引擎服务的文档整合在一起。每台机器都保持大量文档，但不能很快地提供服务。这对非共享的个人文档非常好，因为单个机器可以保持所有单个人的文档，并且查询只需要访问该单个机器。每个人每天执行很少的查询，并且100000个人可以是单个机器上的共享租户。

当人们彼此共享文档时，就会发生重大突破。当人查询文档时，搜索通常需要查看可能与我共享文档的任何人的文档。人们通过与他们的图表的关联性被划分，并且非常广泛地共享文档的人们被复制到许多分区上。

一般操作环境

在简要描述了本文中所描述的技术的各方面的概述之后，下文对其中可以实现本文中所描述的技术的各方面的示例性操作环境进行描述，以便为本文中所描述的技术的各方面提供一般情景。具体地，首先参考图45，示出了用于实现本文中所描述的技术的各方面的示例性操作环境，并且将其一般性地指定为计算设备4300。计算设备4300仅仅是合适计算环境的一个示例，并不旨在对范围本文中所描述的技术的各方面的使用或功能性提出任何限制。计算设备100也不应该被解释为具有与所图示的部件的任一个或组合有关的任何依赖性或要求。

本文中所提供的技术的各方面可以在计算机代码或机器可用指令的一般情景中进行描述，该计算机代码或机器可用指令包括由计算机或其他机器(诸如个人数据助理或其他手持式设备)执行的计算机可执行指令(诸如程序模块)。通常，包括例程、程序、对象、部件、数据结构等的程序模块是指执行特定任务或实现特定抽象数据类型的代码。本文中所描述的技术的各方面可以在多种系统配置中实践，包括手持式设备、消费电子装置、通用计算机、更专业的计算设备等。本文中所描述的技术的各方面也可以在分布式计算环境中实践，其中任务由通过通信网络链接的远程处理设备执行。

参照图45，计算设备4500包括总线4510，其直接或间接耦合以下设备：存储器4512、一个或多个处理器4514、一个或多个呈现部件4516、输入/输出(i/o)端口4518、输入/输出部件4520以及说明性的电源4522。总线4510表示可以是一个或多个总线(诸如地址总线、数据总线或其组合)的内容。尽管图45的各个框为了清楚起见用线条示出，但是实际上，描画各种部件并不那么清楚，并且比喻性地，线条更准确地是灰色和模糊的。例如，可以将呈现部件(诸如显示设备)看作是i/o部件。还有，处理器具有存储器。发明人认识到这是本领域的性质，并且重申，图45的图仅仅说明了可以结合本文中所描述的技术的一个或多个方面使用的示例性计算设备。在诸如“工作站”、“服务器”、“膝上型计算机”、“手持式设备”等之类的类别之间没有进行区分，因为所有都在图45的范围内并且参考“计算设备”得以设想。

计算设备4500通常包括多种计算机可读介质。计算机可读介质可以是可由计算设备4500访问的任何可用介质，并且包括易失性介质和非易失性介质，可移除介质和不可移除介质。通过示例而非限制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术实现的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram、rom、eeprom、闪存或其他存储器技术、cd-rom、数字多功能光盘(dvd)或其他光盘存储装置、磁带盒、磁带、磁盘存储器或其他磁性存储设备、或可以用于存储所需信息并且可以由计算设备4500访问的任何其他介质。计算机存储介质本身不包含信号。通信介质通常包含计算机可读指令、数据结构、程序模块、或经调制的数据信号中的其他数据(诸如载波或其他传输机构)，并且包括任何信息递送介质。项目“经调制的数据信号”意指信号，其使特点中的一个或多个特点以在该信号中编码信息的方式设置或改变。通过示例而非限制，通信介质包括有线介质(诸如有线网络或直接有线连接)以及无线介质(诸如声学、rf、红外和其他无线介质)。上述任何组合还应当被包括在计算机可读介质的范围之内。

存储器4512包括易失性存储器和/或非易失性存储器形式的计算机存储介质。存储器可以是可移除的、不可移除的或其组合。示例性硬件设备包括固态存储器、硬盘驱动器、光盘驱动器等。计算设备4500包括从各种实体(诸如存储器4512或i/o部件4520)读取数据的一个或多个处理器。呈现部件4516将数据指示呈现给用户或其他设备。示例性呈现部件包括显示设备、扬声器、打印部件、振动部件等。

i/o端口4518允许计算设备4500逻辑地耦合至包括i/o部件4520的其他设备，其中一些可以内置在其中。示例性部件包括麦克风、操纵杆、游戏垫、圆盘式卫星天线、扫描仪、打印机、无线设备等。i/o部件4520可以提供处理由用户生成的空中手势、话音或其他生理输入的自然用户接口(nui)。在一些情形中，可以将输入传送到适当的网络元件以供进一步处理。nui可以实现以下各项的组合：语音识别、触摸和触笔识别、面部识别、生物计量识别、屏幕上和屏幕附近的手势识别、空中手势、头和眼睛跟踪、以及与计算设备4500上的显示相关联的触摸识别。计算设备4500可以配备有用于手势检测和识别的深度相机，诸如立体相机系统、红外相机系统、rgb相机系统以及这些的组合。附加地，计算设备4500可以配备有能够检测运动的加速度计或陀螺仪。加速度计或陀螺仪的输出可以被提供给计算设备4500的显示器以再现沉浸式增强现实或虚拟现实。

该技术已经关于特定方面进行了描述，这些方面在所有方面中均旨在是说明性的而非限制性的。在不背离本发明的范围的情况下，备选配置对于本文中所描述的技术所属领域的普通技术人员而言将变得明显。

从上文可以看出，本文中所描述的技术非常适于获得上文所陈述的所有目标和目的，以及系统和方法明显且固有的其他优点。应当理解，某些特征和子组合具有实用性并且可以在不参考其他特征和子组合的情况下使用。这在权利要求的范围之内得以设想并且在其范围之内。