mysql - 搜索文档内容的建议 - Windows Search 好用吗？简单的MySQL？

Question

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

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

你有什么建议？

这是我正在考虑的一些选项:

1) 我正在考虑使用 Windows Search 来实现此目的 - 无论是命令行工具还是使用 API。但是每个服务器实际上可以有 10 亿个文件，并且应该立即交付前 3 个结果。 Windows 搜索可以吗？或者这会产生挫败感？

2)自定义:制作一个简单的开源MySQL数据库程序来保存索引信息。英语中有大约 100,000 个单词...然后还有自定义单词和首字母缩写词...因此，为了快速查找，基于单词和用户帐户进行索引是有意义的。我将进行预处理，使“慢跑”变成“慢跑”，“摆弄”变成“ fiddle ”，以降低数据库大小。考虑到每台服务器有 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 = 表示它不是完全匹配，而是单词的一种形式。例如:文件中的单词最初在文档中是“jogging”或“dancing”，但以缩写形式“jog”或“dance”归档。 (如果查询也是单词形式，那么它有助于提高相关性。)IsWordForm 的可能性很高。Top = 单词位于文档的前 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，但集成起来也需要相当多的工作……我几乎觉得自己做同样的工作量，但当然，作为一名编码员，我知道这种假设经常是错误的。 .

请思考!

Answer 1

4) I've also looked at SolR but I think it's overkill. Is that a bad assumption? While it supports PDF and DOC, it's also a fair bit of work to integrate... I almost feel it will be the same amount of work to do it myself, but of course as a coder I know that assumption's wrong too often...

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

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

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

如果您假设用户可能对 grep 感到满意，无论是性能方面、可扩展性方面还是结果方面，SolR 都是“杀伤力过大”。相信我，他们不会。

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