【问题标题】:good data structure for finding intersections of out-of-order value arrays in an inverted index?用于在倒排索引中查找无序值数组交集的良好数据结构?
【发布时间】:2017-11-30 00:26:19
【问题描述】:

我有一个倒排索引,其中每个标记都映射到一对(document_id, score) 的列表。每个令牌的值列表按分数降序排序,因此排名最高的文档排在第一位。

不幸的是,对于我的应用程序,无法保证同时对所有令牌进行按分数排序,因为分数是根据令牌在文档中的上下文进行调整的。例如,如果我的“文档”是字符串“wine-red iPhone”和(id, score) = (1, 105) 和“red wine”和(id, score) = (2, 100),“red”和“wine”在“red wine”中具有同等重要性,但“wine” "

"red"    -> [(2, 100), (1, 95)]
"wine"   -> [(1, 105), (2, 100)]
"iPhone" -> [(1, 115)]

我需要在 id 上找到这些列表的交集,以返回文档 id 的排序列表,其中都包含一组标记(标准搜索问题)。在上面的例子中,假设有另一个文档“white wine”,id=3,score=50,那么倒排索引现在是这样的:

"red"    -> [(2, 100), (1, 95)]
"wine"   -> [(1, 105), (2, 100), (3, 50)]
"white"  -> [(3, 50)]
"iPhone" -> [(1, 115)]

那么,如果搜索标记是{"red", "wine"},问题本质上是拉取两个标记的值,在这种情况下[(2, 100), (1, 95)][(1, 105), (2, 100), (3, 50)]在文档id上相交,所以结果是喜欢[(2, f(100, 100)), (1, f(95, 105))]f 是一些平均函数,没关系。

它需要速度快,并且消耗尽可能少的内存(但是磁盘空间不是问题)。在某些情况下,它将存储数百万个映射到数千万个唯一文档 ID 的唯一令牌。

到目前为止,为了满足我的限制,我最终将数据存储在一个经过修改为键值存储的 trie 中(其中每个 (id, score) 对是一个值),主要用于内存中的压缩。 inverted_index.get(token) 遍历数组并返回 id -> score 的哈希映射,get 也可以将这样的哈希映射作为参数,以便在遍历数组并组装下一个映射时完成交集。围绕将列表划分为主列表和备用列表、序列化/反序列化、等等等等,还有一些其他小的优化。它们都是无法解决更大问题的创可贴,我并没有真正使用正确的数据结构和算法来解决问题。目前,我最大的用例有大约 20m 的唯一文档 ID,完全加载到内存时大约需要 400mb。

目前,这是我的应用程序性能的最大瓶颈,尤其是当一组标记包含一些具有大量值的标记时。我愿意使用现有的库,从头开始编写一些东西,对当前方法进行优化等。我的主要堆栈是在 python 中,但这部分是用 C++ 和 Cython 编写的。如果您知道现有的源代码,我对任何语言都持开放态度,只要我可以围绕它编写 Python 包装器。

感谢您的帮助!

【问题讨论】:

  • 你能解释清楚一点吗?写一个清晰的输入和输出示例。我不明白“这些列表的交集”是什么意思。
  • @robertking 完成,希望现在更清楚了吗?感谢您的反馈。
  • 如果无法保证按分数排序也将按 id 排序,您能否假装它们是有序的并使用乱序的哈希表来做即时更正?
  • 通常倒排索引的倒排列表是排序的。然后,您可以通过不同的算法轻松计算这些列表之间的交集。例如,一种简单的 zipper 方法,它在两个列表中前进并比较元素。接下来是二分搜索较长列表中较小列表中的元素。然后,您可以将此搜索与 指数搜索 结合起来,从而产生所谓的 驰骋搜索 等等。许多大学开设了信息检索课程来教授这些内容,有些甚至还公开了他们的录音。
  • @Zabuza 是的,我知道这些方法,但正如我在问题中所说,我不能保证这些项目是按 id 排序的,因为我需要它们按我的应用程序的降序排序。跨度>

标签: algorithm data-structures inverted-index


【解决方案1】:

通常,在存储倒排索引时,令牌的文档列表存储在一个按文档 ID 排序的简单数组中,并以某种方式压缩该数组以确保文档 ID 占用尽可能少的空间。然后可以通过解码、扫描和合并排序的数组来快速完成交集,其中大部分工作发生在 CPU 缓存中。例如。查看这个库https://github.com/lemire/JavaFastPFOR - 我建议从这里开始探索并阅读那里引用的相关论文。

【讨论】:

  • 我想也许我最好的选择是找出一种方法来解决当前不允许我按文档 ID 排序的约束,然后让我使用这些久经考验的方法之一真实的方法。我担心这会是答案:) 感谢您提供有用的链接。
  • 我认为按分数降序排序也很好——只要所有文档都按相同的顺序排序,您就可以应用排序合并。只需使用 concatenation(score, document id) 作为排序键。
  • "只要所有文档按相同顺序排序"。他们不是。分数是文档分数和文档中令牌上下文的函数。请参阅我的问题中的第一个示例。这就是问题的难点。
  • 哦,我明白了。那么听起来你的程序已经按照每个标记的上下文相关分数对文档进行了排序,最好不要这样做,保持文档按 id 排序以实现快速交叉,然后按分数排序: )
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-01-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-25
相关资源
最近更新 更多