搜索文档内容的建议 - Windows 搜索有用吗？简单的MySQL？答案

【问题标题】：Suggestions for Searching Document Content- Is Windows Search Any Good? Simple MySQL?搜索文档内容的建议 - Windows 搜索有用吗？简单的MySQL？
【发布时间】：2012-10-19 09:12:19
【问题描述】：

我正在为一家小型在线文档管理公司编写 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 = 表示它不是完全匹配，而是单词的一种形式。例如：文件中的单词最初在文档中是“慢跑”或“跳舞”，但以缩写形式“慢跑”或“跳舞”归档。（如果查询也是 wordform，那么它有助于提高相关性。） 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，但集成起来也是相当多的工作......我几乎觉得自己做的工作量是一样的，但当然作为编码人员，我知道这种假设经常是错误的...... .

请多多指教！！！

【问题讨论】：

看看 Mysql 函数 metaphone http://www.php.net/manual/en/function.metaphone.php 和 soundex http://php.net/manual/en/function.soundex.php

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

【解决方案1】：

4) 我也看过 SolR，但我认为它有点矫枉过正。那是坏事吗假设？虽然它支持 PDF 和 DOC，但它也是相当多的努力整合......我几乎觉得这将是相同数量的工作自己做，但作为一名编码员，我当然知道这个假设经常出错...

绝对使用 SolR：集成成本更高，但设置更容易，维护也更容易。

此外，它已经具有许多您必须自己实现（以及调试和维护......）的功能。

不过，我建议审查 SolR 的功能，围绕这些功能设计一个基本界面，并获得书面批准。 “文本搜索”常常变成一种不言而喻的“我希望系统能够读懂我的想法”。另外，解释高效的文本搜索不是“简单的脚本”；实际上有成千上万的博士学位。论文涉及语义、词干、相关性、邻近性等。其中许多论文已经进入 SolR/Lucene。

如果您假设用户可能对grep 感到满意，那么SolR 就是“矫枉过正”，无论是性能方面、可扩展性方面还是结果方面。相信我，他们不会。

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

【讨论】：