针对具有共享内容库的大型用户群的云搜索解决方案

Question

我正在寻找一种云搜索解决方案，最好是基于AWS（所以Elasticsearch或CloudSearch），用于维护项目目录的服务，每个用户可以在其库中拥有这些项目的子集。

用户应该只能搜索自己的库。他们无权访问整个项目目录。

该解决方案应该能够支持大约20,000个包含元数据的唯一项目和几百万个用户，每个用户拥有自己的库，平均包含10,000个这些项目。

支持此功能的合理配置是什么？ Elasticsearch或CloudSearch会满足这些要求吗？

编辑：

我最关心的是如何以一种方式对此进行索引，即用户只能有效搜索自己的库，而不会添加超过十亿条记录。一种想法是在用户和库中的项目之间使用Elasticsearch父子关系。父级将是用户文档，子级将是其库中的项目文档。

这会有用吗？

Answer 1

我认为其中任何一个都会处理项目数量。在确定搜索群集的大小时，您还应该考虑每秒的请求数。

任何引擎都会支持它并提供快速相关的结果。 Elasticsearch由Apache Lucene提供支持，而Cloudsearch则基于Solr（由Lucene提供支持！）

我认为考虑因素最终归结为维护问题。根据我收集的内容here，here和here，Cloudsearch更容易，因为缩放是自动的。我假设这个功能或服务从第一天开始就不会为数百万用户提供服务，因此我建议您在成长时从小规模开始并根据需要进行扩展。 Cloudsearch使这更容易。 Elasticsearch涉及更多的人工干预。

为了限制用户搜索他们自己的库，我会编写一个后端服务，在代理搜索到Cloudsearch之前处理身份验证/授权。您可以在搜索引擎记录中包含用户的唯一ID作为索引字段，搜索请求将包含用户ID。

该后端服务可以通过多种方式构建，但我建议您查看API Gateway + Lambda。

Answer 2

因此，经过进一步的研究，我得出结论，这不是CloudSearch或Elasticsearch所支持的。

我探索的一个选项是将库项目作为Elasticsearch中用户项目的子项。不幸的是，这不起作用，因为孩子不能有多个父母。我希望的是多对多映射支持，搜索引擎都不支持。

将userID添加为索引也存在问题。由于每个用户的库中大多数都是相同的项目，因此对userID进行索引会导致文档大小增加到数百亿（1百万用户* 10,000个库项目）。

最后我决定进行应用程序端连接。我将搜索整个目录并将结果返回给服务，然后服务将计算客户库与整个目录中的搜索结果的交集。