Search 为5000万个文档推荐一个有效的搜索引擎？

我们有50000000（和不断增长）的文件，我们希望能够搜索

每个“文档”实际上都是一个较大文档的页面，但所需的粒度是在页面级别

因此，每个文档都有一些元数据（例如，它属于哪个较大的文档）

我们最初是使用Sphinx构建的，Sphinx运行得很好，但速度越来越慢，尽管有大量的硬件投入（通过Amazon AWS）

有新的要求，这意味着我们必须能够在搜索之前对数据库进行预过滤，即根据元数据的某些方面只搜索5000万份文档中的一个子集（例如，“仅搜索在过去6个月内添加的文档”，或“仅搜索属于此任意父文档列表的文档”)

一个重要的要求是，我们按父文档对搜索结果进行分组，例如，只返回父文档中的第一个匹配项，以便向用户显示在结果第一页中匹配的更广泛的父文档，而不是在第一个父文档中加载匹配项，然后在第二个父文档中加载匹配项，等等。然后，我们将为用户提供仅在一个特定父文档中搜索页面的选项

解决方案不必是“免费”的，而且有一点预算可以花

内容是敏感的，需要加以保护，因此我们不能简单地让谷歌为我们编制索引，至少不能以任何方式让公众看到它

我考虑过将Sphinx与更多资源结合使用（遗憾的是，将5000万个文档的索引放入内存不是我们预算内的一个选项），我也考虑过Amazon CloudSearch，但似乎我们每月必须花费超过4000美元，这超出了预算

---

有什么建议吗？AWS中可以部署的东西是一个额外的优势。我知道我们可能会要求不可实现的东西，但如果你认为是这样的话，请说出来（并给出理由！）

5000万份文件对斯芬克斯来说似乎是一项相当可行的任务

我们最初是使用Sphinx构建的，Sphinx运行得很好，但速度越来越慢，尽管有大量的硬件投入（通过Amazon AWS）

我支持上面建议切分的评论。Sphinx允许您将一个大索引拆分为多个碎片，每个碎片由自己的代理提供服务。您可以在同一台服务器上运行代理，也可以跨多个AWS实例分发代理

有新的要求，这意味着我们必须能够在搜索之前对数据库进行预过滤，即根据元数据的某些方面只搜索5000万个文档中的一个子集

假设这些元字段作为属性索引，您可以向每个搜索查询添加类似SQL的过滤器（例如，（1,2,3,4）中的文档id和创建日期>'2014-01-01'）

一个重要的要求是我们按父文档对搜索结果进行分组

---

您可以通过任何属性进行操作。

50M文档对于Sphinx来说都不是什么大东西。你的指数有多大？事情可以优化（索引的制作方式和/或搜索方式）。目前索引的大小为160GB。我想继续使用Sphinx，但它似乎不够灵活，无法满足要求，而且目前的性能并不令人满意（我承认可能存在一些我不知道的优化），我认为主要的好处将是切分。与其说是一个大的整体索引，不如把它分成几位。比如说分成四部分。即使在一个虚拟机上（只要有多个虚拟核），也能真正受益。但使用多个虚拟机也可能是有益的（每个虚拟机越小成本就越低！）。