我在某处读到，当你有一个倒排索引时（例如，你有一个 brutus 页面的排序列表、一个 caesar 页面的排序列表和一个 calpurnia 页面的排序列表），当你做 caesar 和brutus AND calpurnia，如果 calpurnia 和 brutus 的页数小于 caesar 的页数，那么你应该做 caesar AND (brutus and calpurnia)，这意味着你应该先评估后者。一般来说，每当你有一系列的 AND 时，你总是首先评估具有最少页数的对。这背后的原因是什么？为什么这么高效？
【问题讨论】：
标签： database document web-crawler inverted-index web-search
倒排索引的每一种情况都不是这样。如果您需要顺序扫描整个倒排索引，那么您首先执行哪个帖子列表交集无关紧要。
但是，假设倒排列表存储在索引关系中。然后评估具有较少文档出现次数的对将等于加入具有较高选择性的关系，从而提高评估效率。
直观地说，当我们与较小的列表相交时，我们会创建一个更强大的过滤器，用作索引的提要以查找匹配项。
假设我们有兴趣评估关键字查询a b c，其中a、b 和c 是文档中的单词。还假设匹配的文档数如下：
a --> 20
b --> 100
c --> 1000
a+b --> 10
a+c --> 15
b+c --> 50
a+b+c --> 5
请注意，(a JOIN b) 的大小为 10，(b JOIN c) 的大小为 50。因此，第一个需要10 访问c 上的索引，而第二个需要50 访问a 上的索引。但是使用基于哈希或基于树的索引，对索引的这种访问在成本上并没有太大差异，并且通常在单个 I/O 中完成。
【讨论】：
需要意识到的重要一点是，由于您已经提到的排序，可以非常有效地搜索任何给定文档 ID 的倒排列表（通常以对数时间），例如使用二分查找。
要查看其效果，假设查询 caesar AND brutus，并假设 caesar 有 occcaesar 页面，@987654323 有 occbrutus 页面@（即 occX 表示术语 X 的页面列表的 长度）。现在假设，为了示例，occcaesar > occbrutus，即caesar在内容中的出现频率高于brutus。
然后您要做的是迭代在所有页面中查找brutusfirst，然后在页面列表中搜索为caesar。如果确实可以在对数时间内搜索列表，这意味着您需要
occbrutus * log(occcaesar)
识别包含这两个术语的所有页面的计算步骤。
如果您反向操作（即遍历caesar 列表并在brutus 列表中搜索其每个页面），较小的数字将以对数结束，并且更大的数字会成为一个因素，因此评估所需的总时间会更长。
话虽如此，同样重要的是要意识到实际上事情比这更复杂，因为 (a) 列表不仅是排序的，而且是压缩的，这使得搜索更加困难，并且 (b) 部分列表可能存储在磁盘上而不是内存中，这意味着磁盘访问的总数比计算步骤的总数重要得多。因此，上述算法可能不适用于其最纯粹的形式，但原理如前所述。
【讨论】：