面向拥有共享内容库的大型用户群的云搜索解决方案
Cloud search solution for a large user base with libraries of shared content
我正在寻找一种云搜索解决方案，最好是基于 AWS（例如 Elasticsearch 或 CloudSearch），用于维护项目目录的服务，并且每个用户都可以在他们的图书馆中拥有这些项目的一个子集。
用户应该只能搜索自己的图书馆。他们无权访问整个项目目录。
该解决方案应该能够支持大约 20,000 个具有元数据的独特项目和数百万用户，每个用户都有自己的图书馆，平均包含其中的 10,000 个项目。
支持这个的合理配置是什么？ Elasticsearch 或 CloudSearch 会满足这些要求吗？
编辑：
我最关心的是如何以一种用户可以只有效搜索他们自己的图书馆而无需添加超过十亿条记录的方式对其进行索引。一种想法是在用户和他们图书馆中的项目之间使用 Elasticsearch 父子关系。父文档是用户文档，子文档是其库中的项目文档。
这行得通吗？
我认为任何一个都可以处理项目的数量。在确定搜索集群的大小时，您还应该考虑每秒的请求数。
任何一个引擎都将支持它并提供快速的相关结果。 Elasticsearch 由 Apache Lucene 提供支持，而 Cloudsearch 基于 Solr（而后者又由 Lucene 提供支持！）
我认为最终的考虑归结为维护问题。根据我收集到的 here, here, and here，Cloudsearch 更容易一些，因为缩放是自动的。我认为此功能或服务不会从第一天起就为数百万用户提供服务，因此我建议您从小处着手，并随着您的成长按需扩展。 Cloudsearch 让这一切变得更容易。 Elasticsearch 涉及更多的人工干预。
为了限制用户搜索他们自己的库，我会编写一个后端服务来处理 authentication/authorization，然后再将搜索代理到 Cloudsearch。您可以将用户的唯一 ID 作为搜索引擎记录中的索引字段包含在内，搜索请求将包含用户 ID。
后端服务可以通过多种方式构建，但我建议查看 API Gateway + Lambda。
因此，在进一步研究之后，我得出的结论是 CloudSearch 或 Elasticsearch 都不能很好地支持它。
我探索的一个选项是将库项目作为 Elasticsearch 中用户项目的 children。不幸的是，这不起作用，因为 children 不能超过一个 parent。我所希望的是 many-to-many 映射支持，这两个搜索引擎都不支持。
添加userID作为索引也是有问题的。因为每个用户在他们的图书馆中几乎都有相同的项目，所以对 userID 建立索引会导致文档大小增加到数百亿（100 万用户 * 10,000 个图书馆项目）。
最后我决定加入 application-side。我将搜索整个目录并将 return 结果提供给服务，然后服务将计算客户图书馆与整个目录的搜索结果的交集。