搜索文档内容的建议 - Windows搜索有什么用?简单的MySQL?

时间:2012-10-19 09:12:20

标签: mysql command-line solr full-text-indexing windows-search

我正在为一家小型在线文档管理公司编写一个Web脚本,该公司希望允许用户在线快速搜索其文件内容。 虽然许多帐户非常小(不到100个2MB文件),但有少数帐户有1,000,000个或更多文件。需要支持PDF和DOC / DOCX。二进制文件不会被编入索引。

我们正在寻找一种提供基本搜索结果的简单解决方案。没什么太花哨的。 每个用户都有一个主文件夹(搜索只搜索他的子文件夹),所以请记住,搜索系统应该是最佳的。为了说明,如果一个拥有100 MB帐户的人搜索他的主文件夹,它将使感觉不搜索其他4 TB的文件。

你有什么建议?

以下是我看到的一些选项:

1)我正在考虑使用Windows搜索 - 命令行工具或使用API​​ ..但每个服务器可以拥有10亿个文件,前3个结果应该立即交付。 Windows搜索会吗?或者这会让人感到沮丧吗?

2)自定义:创建一个简单的开源MySQL数据库程序来保存索引信息。 英语中大约有100,000个单词...然后是自定义单词和缩写词。因此,对于快速查找,基于单词和用户帐户进行索引是有意义的。 我将进行预处理,以便“慢跑”变成“慢跑”,“摆弄”变成“小提琴”,以降低数据库大小。 每个服务器有150个客户帐户,拥有一个大数据库是否合理,或者可以取消UserID字段并为每个用户分配一个数据库?

Tables:
Table WorldTable
EnglishWord (pk) | WordID (fk)

Table FileTable
FileID (pk) | FilePath

Table WordIndex
WordID (pk) | FileID (fk) | UserID | SettingsPatternID

Table Settings
SettingsPatternID | Top (bool) | IsWordForm (bool)

IsWordForm =表示它不是完全匹配,而是单词的一种形式。例如:文件中的单词最初是在文档中“慢跑”或“跳舞”,但是以“jog”或“dance”的简短形式提交。 (如果查询也是一个字形,那么它有助于相关性。)IsWordForm的可能性很高。 Top = Word位于文档的前50个单词(表示标题)

我想要一个5-15%的小存储开销。 CPU非常珍贵...... 但是,对于每个文件,这是很多开销,因为每个文件将在WordIndex中生成数千条记录。即:

WordID, FileID, UserID, SettingsPatternID
WordID, FileID, UserID, SettingsPatternID
WordID, FileID, UserID, SettingsPatternID

... 这是最长的表,WordID不必要地重复。

3)使用MySQL进行哈希处理 既然我们知道这将是对单词的搜索,那么纯粹的关系数据库可能不是最好的模型...

将每个单词“哈希”到匹配文件列表可能更有效。 例如:对于每个单词,制作一个2列表。您不需要在表格中“查找”该单词,因为我们知道它是什么。 此列表可以是每个单词的2列表:

Table *The Word*
FileID | UserID | SettingsPatternID
(There would be 100,000 of these. One for each unique word.)

Table Settings
SettingsPatternID | Top (bool) | IsWordForm (bool)

4)我也看过SolR,但我认为这太过分了。这是一个不好的假设吗?虽然它支持PDF和DOC,但整合它也是一项相当多的工作...我几乎觉得自己做同样的工作量,但当然作为一个编码器,我知道这个假设经常是错的.. 。

请注意!!!

1 个答案:

答案 0 :(得分:2)

  

4)我也看过SolR,但我认为这太过分了。这是不好的   假设呢?虽然它支持PDF和DOC,但它也是相当的   努力整合...我几乎觉得这将是相同的工作量   自己做,但当然作为一个程序员我知道这个假设   经常出错...

绝对选择SolR 集成成本更高,但设置更容易,维护更容易。

此外,它已经拥有许多您必须自己实现(以及调试和维护......)的功能。

然而,我建议回顾一下SolR的功能,设计围绕这些功能的基本界面,并以书面形式批准。 “文本搜索”经常变成一个未说出口的“我希望系统能够读懂我的想法”。另外,解释有效的文本搜索不是“简单的脚本”;有数千名博士学位。涉及语义,词干,相关性,接近度等的论文。其中许多论文已经进入SolR / Lucene。

如果假设用户可能会grep满意,那么SolR就是“过度杀戮”,无论是在性能方面,还是在可扩展性和结果方面。相信我,他们不会

您可以尝试建议Google Machine。它还有助于建立与成本相关的基准:即,“如果你想要谷歌的表现,这是谷歌的价格。没有谷歌的规模经济的任何其他临时实施将花费更多来实现相同的表现水平“。