0

考虑在 MySQL 数据库中存储位置记录的倒排索引：

  Word (VARCHAR)  |    Documents (LONGTEXT)
-------------------------------------------------------------
     Hello        | {id: 11, freq: 4, pos: [18, 37, 43, 119]}, 
                  | {id: 19, freq: 2, pos: [17, 32]}
-------------------------------------------------------------

现在，一个新文档来了，它的大部分单词已经被索引了。现在应该进行什么索引操作？基本方法似乎是，如果该单词已经存在于数据库中，则获取其文档并将当前文档添加到其中并更新记录。

随着文件数量的增加达到数百万，这是否可持续？Solr、Xapain、Google、Bing 等现实世界的搜索引擎如何处理这个问题？

4

1 回答 1

0

将新文档添加到您的集合时，操作将是：

  1. 为文档分配一个 id，比如 20，它唯一地标识文档。对于添加到集合中的每个新文档，此 id 通常会增加 1。

  2. 列出新文档中的所有单词，以及它们出现的位置。

    对于文档Hi Hello Hello Bye，这将是：

    再见：{id：20，频率：1，位置：[15]}
你好：{id: 20, freq: 2, pos: [3, 9]}
嗨：{id：20，频率：1，位置：[0]}

  3. 对于任何新词（再见，嗨），为该词添加一个条目到数据库中。对于数据库中的任何现有单词 (Hello)，将新数据添加到该值。

    以下是添加文档后数据库的外观。

    Word (VARCHAR)  |    Documents (LONGTEXT)
    -------------------------------------------------------------
       Bye          | {id: 20, freq: 1, pos: [15]}
       Hello        | {id: 11, freq: 4, pos: [18, 37, 43, 119]}, 
                    | {id: 19, freq: 2, pos: [17, 32]}
                    | {id: 20, freq: 2, pos: [3, 9]}
       Hi           | {id: 20, freq: 1, pos: [0]}
    -------------------------------------------------------------

对您的另一个问题的快速回答是：是的，这对于大型索引是可持续的。倒排索引通常针对查找进行优化，使用哈希表或二叉树，使得检索实际上与文档集合的大小无关。

对于大型搜索引擎如何处理这个问题：我不知道细节（尽管我想知道）。他们显然使用数据集群将负载分散到多个服务器上（是的，我说分散负载。这不是故意的）。我敢打赌他们已经预处理了一堆东西，并缓存了诸如“堆栈溢出”之类的常见查询，因此已经有一个解决方案页面。

于 2013-05-20T22:14:40.430 回答