问题背景
大家好，我正在做一个项目，根据提供的查询在一堆文档中搜索相关文档。由于这是一个小型项目并且我有一个典型的内存架构，我假设我没有超过 100 个文档并且每个文档包含不超过 1000 个单词(一个单词不超过 10 个字符)。我收到很多查询，我必须尽可能快地处理查询(绝对不超过一秒)。
我的第一种方法(朴素且不可扩展):
由于允许用户上传文档，每当我收到文档时，我都会寻找“潜在”关键字并将关键字存储为键，将文档存储为值对或存储在 MYSQL 表中。显然，这必须手动完成，看起来不像程序员会做的事情。
我的第二种方法(稍微好一点):
我获取每个文档，扫描它的每个词并将这个词添加到 Trie 数据结构中，因此对于 100 个文档我必须搜索 100 次尝试并且如果查询的长度为 l，这种方法将采用最差的 O(所有文档中的单词数 * 最大单词的长度)以构建 trie 和查询 O(查询长度)。这是很合理的。 为了实现这一点，我会为每个文档保留一个 Trie 根节点向量，并遍历每个 trie 节点并在每个 trie 中进行搜索。如果我得到至少一半的查询词匹配，我将该文档存储为潜在结果。作为结果，我不会提供超过一些截止数量的文件。
我对社区的问题:
请问您如何看待我的方法？我如何优化它们，我可以在现有方法中做哪些其他改进？这可以通过使用其他算法或数据结构更有效地完成吗？ 在网上冲浪时，我遇到了像 Boyer-Moore 和 Aho-Corasick 这样的算法，以及一些调整 Lucene Apache 实现的算法等的建议。你在这里有什么建议？
最佳答案
实现全文搜索的最基本方法是构建一个 inverted index并使用 TF-IDF 等指标对匹配文档进行排名
随着新文档的到来，您提取文档中的单词并将文档添加到倒排索引中。
当查询进来时，您会从索引中找到匹配的文档，并根据 TF-IDF(或您关心的其他指标)执行一些排序。然后，您返回 k 个排名靠前的文档作为查询结果。
除此之外，Information Retrieval 中还有大量研究使操作更高效并使结果(top-k 文档)更好的字段。
关于algorithm - 实现文档搜索引擎，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44687910/