轻量级文档索引，可处理少于25万条潜在记录

最近，我发现自己对文档索引引擎的局限感到恼火。我正在开发一个小型网站，需要一些相当强大的搜索功能，但是由于它们的硬件限制，我无法部署Lucene式的解决方案（例如Solr或ElasticSearch，就像我通常那样）来满足这种需求。

即便如此，尽管我需要处理一些数据库密集型的复杂数据和计算，但我并不需要处理超过25万条潜在记录。仅仅部署一个Solr或ES实例来解决这个问题似乎是一种浪费。

经过考虑，这似乎是一个相当大的问题。大多数人仅使用SQL处理搜索需求。他们只是对数据运行SQL查询，仅此而已。他们的搜索能力最终也很糟糕。

• 在某些系统（尤其是共享主机）上进行全面的通配符全文搜索可能会非常缓慢，并且会使数据库陷入瘫痪，特别是在您具有复杂的查询和大量联接的情况下。

• 您最终只能对用户的单个请求执行多个查询。您可能会通过越来越复杂的查询来解决此问题，但请参阅上一点。

• 全文引擎中通常缺少功能。

数据库具有需要部署为服务器的相同问题，然后出现SQLite，突然我们可以部署一个独立包含在单个文件中的数据库。我的Google搜索没有任何结果-想知道是否存在类似这样的内容用于全文索引/搜索。

在决定是否实现轻量级文档索引（例如，如对另一个问题的回答中所述）或在这些情况下继续使用SQL 时应考虑哪些因素？

您知道，我不得不说考虑使用redis。

• 使用上下文的概念。如果不进一步了解文档，将很难深入。通常，您可以从文档标题中识别出很多东西。像进行网络爬网一样，对每个文档进行概要分析是基本的第一步。

• 对关键字词典中的每个单词文档进行计数。跟踪每个单词在整个项目中的受欢迎程度。如果您恰巧能够检测到文档或集合中的高相关性，则为该计数增加迭代器的权重。
  
  这样做的第一件事是为您提供整套单词的全包列表。该列表中未找到任何内容，将自动返回“无结果”。我建议结果排名低于受欢迎程度的最低5-20％（当对索引运行搜索查询时）也只是说没有结果。

• 如果您确实使用了redis之类的东西，甚至只是建立了自己的内存结构，则可以将文档与描述符文件或mini-db文件和页面对象配对，这些对象描述了每个特定文档在内存中的来回关系。通过让普通搜索竞争席位，或者给它们一个生存时间（随每次搜索增长）而将普通搜索保留在内存中。

• 要走得更远，请开始保存将链接/引用/指针/索引/两个或多个文档以及一组关键字或短语组合在一起的参考数据。基本上，您会获得一个标签云。

• 更进一步，通过跟踪字典中的单词何时在相似元数据/标题的文档中通常在确切的字符串之后或前面，来进行短语检测。这很费力，但是只需要传递一次即可呈现数据。

• 分离数据并使组在实际使用中彼此相关的方式越多，效果越好。

• 通过跟踪用户每次单击不是前三名的结果来连接正确性的可能性。通过查看未提供理想结果的用户搜索来改善短语检测。强制您的查询相对于客户的搜索。

• 您是否需要注意文档更新？Chronjobs / shell脚本或计划任务/批处理脚本可以提供帮助。尽管显然有许多用于计划和脚本的选项。

• 浪费磁盘，提高速度，失去复杂性。保存文档的多棵树和/或文档的链接树。在大多数情况下，仅搜索符合条件的树，或者至少希望它们可以更快地得到结果。

• 制作您自己的轻量级排列引擎，或者找到一个使用快速字符检测且不使用正则表达式的引擎。或者只是在几个小时内使用正则表达式制作一个，但是对于足够的搜索，此处的性能差异会很明显。

• 这么多的事情。

这些是实现强大的文档索引和搜索的可能解决方案。它并不全包。这样一来，您可能最好抓住一个备用盒，在上面放一个神经网络，并花几天时间为该神经网络创建一个不错的Web界面。