实际应用：
我需要从一个搜索框中查询几个数据库。其中一些我可以直接访问（他们是SQL Server / MySQL），其他我只能通过API搜索。
在理想的世界中，我会将所有这些数据注入Elasticsearch并使用它来确定相关性。不幸的是，我没有在本地拥有资源来提高效率。 Elastic正在空闲时占用400mb的RAM而不添加任何实际数据或运行查询。看起来大多数在生产中使用Elasticsearch的人都在运行具有32GB-64GB RAM的机器。我的组织无法访问该项目可用的强大功能。
所以我的下一个想法是查询所有数据库并在用户进行搜索时连接到API。然后我需要分析结果，确定相关性，并将它们返回给用户。我认识到这可能是一个糟糕的性能计划。我希望使用memcached来让事情更容易忍受。
在我找到确定相关性的算法的研究中，我遇到了tf-idf。我希望将此应用于我从所有数据库中获取的结果。
实际问题
我对tf-idf的理解是，在对语料库中的每个文档进行标记后，执行术语频率分析，然后将其与单词的逆文档频率相乘。通过将总文档计数除以具有该术语的文档总数来计算逆文档频率。
问题在于，如果我从API中提取文档，我就不知道语料库中文档的真实总数。我只是拉了一个子集，并且根据这些文件被拉出的方式，他们自然会转到其中的所有条款。我是否仍然可以通过将这些不同来源返回的文档池视为单个语料库来应用tf-idf？最好的方法是什么？
加分问题
如果您有关于如何在不将我自己的搜索解决方案混淆或使用Elasticsearch的情况下完成此操作的建议，我会全力以赴......
答案 0 :(得分：0)
正如您所注意到的，Elasticsearch不是为在内存受限的环境中运行而构建的。如果您想使用Elasticsearch，但无法设置专用计算机，则可以考虑使用托管搜索解决方案（例如AWS Elasticsearch，Elastic Cloud，Algolia等）。这些解决方案仍然需要花费！
有两个很好的选择需要更多的工作（但不如编写自己的搜索解决方案）。 Lucene是Elasticsearch编写的实际搜索引擎。它仍然会将相当多的底层数据结构加载到内存中，因此，根据您要索引的基础数据的大小，它仍然可能会耗尽内存。但是，您应该能够在单个Lucene索引中使用比在整个Elasticsearch实例中更多的数据。
我知道的另一种选择是Sphinx。它也是一个搜索引擎。它还允许您指定要为其使用分配的内存量。它将其余数据存储在磁盘上。