存储倒排索引

Question

我知道反向索引是一种索引单词的好方法，但我感到困惑的是搜索引擎实际存储它们的方式？例如，如果一个单词＆＃34; google＆＃34;出现在文件-2,4,6,8中的频率不同，应该在哪里存储？具有一对多关系的数据库表是否可以用于存储它们？

Answer 1

完全类似SQL的数据库不太可能用于此目的。首先，它被称为倒置索引，因为它只是一个索引。每个条目只是一个参考。非关系数据库和键值存储作为与Web技术相关的最受欢迎的主题。

• 您只有一种访问数据的方式（通过查询字）。这就是为什么它被称为索引。
• 每个条目都是文档引用的列表/数组/向量，因此该列表的每个元素都非常小。除了存储documentID之外，唯一的其他信息是存储每个元素的tf-idf分数。

如何使用它：

如果您有一个查询字（＆＃34; google＆＃34;），那么您可以在倒置索引中查找此单词出现的文档（在您的示例中为2,4,6,8）。如果您有tf-idf分数，则可以对结果进行排序以首先报告最佳匹配文档。然后，您可以查看文档ID 2,4,6,8所引用的文档，并报告其URL以及片段等.URL，片段等可能最好存储在另一个表或键值存储中。< / p>

如果您有多个查询字词（＆＃34; google＆＃34;以及＆＃34; altavista＆＃34;），您可以查看两个查询字词的II，并获得两个文档ID列表（2,4 ，6,8和3,7,8,11,19）。您获取两个列表的交集，在本例中为（8），这是两个查询词出现的文档列表。

Answer 2

可以肯定的是，每个主要搜索引擎都有自己的处理倒排索引的技术。这也是一个中等偏好的赌注，它们不是基于标准的关系数据库技术。

在Google的特定情况下，可以合理地猜测当前使用的技术源自Fay Chang等人在BigTable中描述的2006年Bigtable: A Distributed Storage System for Structured Data技术。毫无疑问，从那时起，该系统已经发生了变化。

Answer 3

传统上，反向索引直接写入文件并存储在某个磁盘上。如果你想做布尔检索查询（一个文件包含查询中的所有单词），帖子可能看起来像是连续存储在文件中。

Term_ID_1：Frequency_N：Doc_ID_1，Doc_ID_2，Doc_ID_N.Term_ID_2：Frequency_N：Doc_ID_1，Doc_ID_2，Doc_ID_N.Term_ID_N：Frequency_N：Doc_ID_1，Doc_ID_2，Doc_ID_N

术语id是术语的id，频率是术语出现的文档数（换句话说，帖子列表有多长），doc id是包含术语的文档。

除索引外，您还需要知道文件的所在位置，因此映射也必须存储在另一个文件的某个位置。例如，给定term_id，映射需要返回包含该索引的文件位置，然后可以寻找该位置。由于frequency_id记录在过帐中，因此您知道要从文件中读取多少doc_id。此外，还需要从ID到实际术语/ doc名称的映射。

如果你有一个小用例，你可以通过使用blob作为发布列表并在查询时自己处理交集来使用SQL。

非常小的用例的另一个策略是使用术语文档矩阵。

Answer 4

可能的解决方案

一种可能的解决方案是使用位置索引。它基本上是一个倒排索引，但我们通过添加更多信息来扩充它。您可以在Stanford NLP了解更多相关信息。

示例

说一句话＆＃34;你好＆＃34;出现在文档1和3中，分别位于（3,5,6,200）和（9,10）位置。

• 基本倒置索引（请注意，无法找到单词频率，也无法找到位置）

"hello" => [1,3]

• 位置索引（请注意，我们不会为每个文档提供频率，但我们也确切知道该字词在文档中的位置）

"hello" => [1:<3,5,6,200> , 3:<9,10>]

抬头

您的索引现在会占用更多大小吗？你敢打赌！

这就是压缩索引的好主意。使用间隙编码压缩贴图列表有多种选择，使用通用字符串压缩算法压缩字典的选项更多。

相关阅读材料

Index compression

Postings file compression

Dictionary compression