【发布时间】：2017-11-25 01:19:09
【问题描述】：
问题的背景
大家好，我正在做一个项目，根据提供的查询在一堆文档中搜索相关文档。由于这是一个迷你项目并且我有一个典型的内存架构，我假设我没有超过 100 个文档，每个文档包含不超过 1000 个单词（一个单词不超过 10 个字符）。我收到很多查询，我必须尽可能快地处理查询（绝对不超过一秒）。
我的第一种方法（幼稚且不可扩展）：
由于允许用户上传文档，每当我收到文档时，我都会寻找“潜在”关键字并将关键字存储为键，将文档存储为值对或 MYSQL 表中。显然，这必须手动完成，不像程序员那样做。
我的第二种方法（稍微好一点）：
我获取每个文档，扫描其中的每个单词并将该单词添加到 Trie 数据结构中，因此对于 100 个文档，我必须搜索 100 个尝试，如果查询的长度为 l，这种方法将采用最坏的 O(所有文档中的单词数* 最大单词的长度）来构建特里树并查询 O（查询长度）。这是相当合理的。 为了实现这一点，我将为每个文档保留一个 Trie 根节点的向量，并遍历每个 trie 节点并在每个 trie 中搜索。如果我得到至少一半的查询词匹配，我将该文档存储为潜在结果。作为结果，我不会给出超过一定数量的文档。
我的社区问题：
我想问你对我的方法有什么看法？我该如何优化它们，在现有方法中我还能做哪些其他改进？这可以通过使用其他算法或数据结构更有效地完成吗？ 在网上冲浪时，我遇到了 Boyer-Moore 和 Aho-Corasick 等算法，以及一些调整 Lucene Apache 实现的算法等的建议。您在这里有什么建议？
【问题讨论】：
-
看看elasticsearch。它具有极强的可扩展性，应该非常适合您的项目。
-
@CaptainTrunky，拜托我不想使用这个库，这个项目的重点是我自己做。如果您能说出 elasticsearch 的核心是什么，这对我很有用。
-
对于 100 个文档，每个文档 1000 字，每秒 1 个请求，grep 就足够了。如果您坚持某种索引策略，请维护一个按单词排序的（单词，文档集）对列表并对其进行二进制搜索。这可能只是一个文件。
-
对于真正的企业级索引，您可以使用任何您喜欢的二叉搜索树。
-
@ReinHenrichs 由于我系统的内存限制，这些限制不一定是每秒一个请求。我的目标是从头开始构建它。
标签： algorithm search data-structures full-text-search search-engine