4

有一个有趣的问题，正在寻找正确的解决方案。我们有大约 100,000 个不同大小的 PDF 文档，平均大小为 150 页。它当前位于 RAID6 服务器上，并且也在异地备份。我们需要索引总共 6.5TB 的 PDF。

我们目前正在将 PDF 转换为文本文件，并将它们存储在服务器上类似的文件夹结构中。然后需要对这些内容进行索引并使其可搜索，包括指向原始文件夹的反向链接。文本文件使用与 PDF 相同的名称，并添加了额外的命名约定。如果我的估计是正确的，这意味着需要索引的词接近 40 亿个。

索引这些文件的合适解决方案是什么？

4

4 回答 4

1

我会看看SOLR。我们目前正在研究将其用作文档的全文搜索引擎。它被广泛使用并得到很好的支持。

于 2012-08-04T01:01:24.657 回答
1

如果我的数学计算正确，那么每页就有 400K。那是一个很大的页面大小。

您需要使用索引做什么？

如果您需要接近度和短语，则需要将它们全部索引以及 SOLR 之类的产品。通过 TIKI，我认为您可以索引 PDF。

另一种选择是使用 SQL 全文。但是您需要构建一个前端应用程序。SOLR 和应用程序和引擎在哪里。

您需要索引每个单词还是只索引唯一的单词？如果只需要基本搜索，那么英语中只有大约 200,000 个唯一词。如果你像搬运工一样对它们进行词干，这个数字会下降。然后扔掉像“the”这样的停用词。然后你需要和正确的名称电子邮件和字典中没有的其他单词。我手动索引文档，甚至一个非常大的集合也达到 300,000 个（如果它是真实的单词 - ocr 会杀死这个数字）。如果一个文档有 2,000 个唯一词，则交叉索引只有 20,0000,000。您可以使用 REGEX 解析出单词。我知道这看起来很难看，但我在 SQL 和 .NET 中手动执行此操作。没有邻近或短语搜索，但它占用空间小且速度快。（SQL Azure 没有全文）

于 2012-08-04T14:02:40.770 回答
0

查看Google Search Appliance。为什么要重新发明轮子？

于 2012-08-04T01:00:27.810 回答
0

如果没有令人信服的理由为此使用 SQL 数据库，我会考虑使用专门的搜索引擎。

大多数全文搜索软件都可以读取 PDF 文件，而无需您将它们转换为文本文件。我过去曾成功使用过dtSearch。

于 2012-08-04T15:19:45.617 回答