我们希望能够搜索50,000,000（并且正在增长）的文档。
每个＆＃34;文件＆＃34;实际上是一个较大文档的页面，但所需的粒度是在页面级别。
因此，每个文档都有一些元数据（例如，它属于哪个更大的文档）
我们最初使用Sphinx构建了这个版本，它已经运行得很好，但是速度很慢，尽管它有相当慷慨的硬件（通过亚马逊AWS）。
有新的要求即表示我们必须能够在搜索之前预先过滤数据库，即仅根据元数据的某些方面搜索50M文档的子集（例如，＆＃34;搜索只有在过去6个月内添加的文件＆＃34;或者＆＃34;只搜索属于这个任意父文件列表的这些文件＆＃34;）
一个重要的要求是我们按父文档对搜索结果进行分组，例如：返回父文档中的第一个匹配项，以便向用户显示在结果的第一页中匹配的更多范围的父文档，而不是第一个父文档中的匹配加载，后面是第二个匹配项的匹配，然后，我们将为用户提供仅在一个特定父文档中搜索页面的选项。
解决方案不必是免费的＆＃34;并且有一些预算可以花。
内容非常敏感，需要加以保护，因此我们不能让谷歌为我们编制索引，至少不会以任何方式让公众接触它。
我已经看过使用更多资源的Sphinx（将50M文档的索引放入内存中，遗憾的是我们的预算中没有选项）我已经查看了Amazon CloudSearch，但似乎我们＆＃ 39; d必须每月花费> 4,000美元，这超出了预算。
有什么建议吗？在AWS内部署的东西是一个奖励。我知道我们可能会要求无法获得，但如果您认为是这样，请说出来（并说明原因！）
答案 0 :(得分：1)
对于Sphinx来说，50M文档听起来是一项非常可行的任务。
我们最初使用Sphinx构建了这个版本，它已经运行得很好，但是速度很慢，尽管它有相当慷慨的硬件（通过亚马逊AWS）。
我在上面的评论中提出了分片。 Sphinx allows您可以将一个大索引拆分为多个分片，每个分片都由自己的代理服务。您可以在同一服务器上运行代理，也可以跨多个AWS实例分发代理。
有新的要求即表示我们必须能够在搜索之前对数据库进行预过滤，即仅根据元数据的某些方面搜索50M文档的子集
假设这些元字段被索引为属性，您可以为每个搜索查询添加类似SQL的过滤器（例如doc_id IN (1,2,3,4) AND date_created > '2014-01-01'）。
一个重要的要求是我们按父文档对搜索结果进行分组
您可以通过任何属性group。