我正在为一家小型在线文档管理公司编写 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，但集成起来也是相当多的工作......我几乎觉得自己做这件事的工作量是一样的，但当然，作为一名编码人员，我知道这种假设经常是错误的...... .
请大家思考！！！