使用外部API和智能内容建议设置移动应用程序的体系结构

Question

我和我的一些同事已经开始研究为用户提供社交购买体验的iPhone应用程序。目标是为数百万产品提供扩展的搜索功能（全文，模糊搜索，基于过滤器等），这些产品不断从几个产品列表API（如eBay和亚马逊）中获取，然后进行标准化（即转换为字段，类别和关系），应用了一些业务逻辑，以便用户能够根据几个标准获得自定义内容（独特的配置文件，例如年龄/性别，搜索历史记录，我的朋友购买的内容等）。 该应用程序还具有社交功能，如关于产品的帖子，喜欢和评论，跟随其他用户等。

所以现在我们正在尝试设计支持这些需求的服务器架构，除此之外还有性能注意事项（“给我所有与我的搜索词匹配的产品并按顺序排序相关性“应该运行得非常快~1到10秒”和可扩展性考虑（10个结果用户将获得与100,000个用户相同的时间结果，假设我可以投入更多机器来解决问题）。

我们假设我们将拥有〜数千万的产品

我们想到的是（基于AWS）：

1. 设置Elastic Beanstalk以支持可伸缩性，方法是在流量增加时抛出更多EC2实例，并在流量减少时将其删除
2. 使用MySQL设置RDS作为应用程序的RDBMS（管理具有多个可用区的用户，配置文件，规范化产品等）
3. 在不同的服务器上设置后台“代理”进程，以便不断从API获取产品数据（具有可自定义的提取队列）
4. 将上述“原始数据”存储在某些NoSQL中作为临时数据
5. 设置另一个“代理”以规范数据，对其进行分析并将其插入RDBMS中，以便能够非常快速地搜索已经基于用户不同的配置文件
6. 设置缓存机制以减少RDBMS上的负载
7. 建立一个好的全文搜索引擎（即Lucene）

我们的主要考虑因素是：

1. Linux环境
2. 主要是PHP和MySQL
3. 效果是一个问题
4. 可扩展性将在不久的将来（6-12个月）成为一个问题（希望如此:)）

现在有几个问题：

1. 架构是否有意义？
2. 关于数据存储 - RDBMS是正确的选择还是我们应该考虑使用NoSQL引擎（即MongoDB）？
3. 在解决这个问题时，我们应该考虑哪些技巧/方法？

顺便说一下，战争故事会非常感激：）

Answer 1

1. 是
2. 取决于您希望在存储级别表示数据的结构。如果您在内存中构建该结构，或使用Lucene进行搜索，请查看NoSQL选项（Dynamo for AWS）。
3. 使用Hadoop集群及时规范化数据。

Answer 2

我认为对于您所描述的内容，您可能希望避免使用Elastic Bean Stalk，并将其部署到您控制的EC2实例上。

前端将运行Web加载，并且主要从缓存中查询。这可以在弹性负载均衡器后面，您可以使用自动调节规则来确保始终有足够的资源来处理负载。

我可能会看看solr的全文搜索，但我不是这方面的专家 - 我认为solr会有一些可扩展性，复制等，以便管理您的搜索基础架构更容易管理。有一些很好的AWS Solr参考体系结构可以扩展。

听起来你需要一些后端服务层 - 一个用于提取数据，另一个用于规范化数据。如果您要提交AWS，您可以构建这些，以便中央控制流程将工作分配给您通过现货市场获得的实例 - 这有助于降低总体成本。如果现货市场飙升，您可以选择减慢导入/处理速度，或者使用按需实例并稍微增加成本。

我可能会将其设计为使用mysql和no-sql存储的组合。 Mysql用于核心功能 - 帐户，用户首选项等，但NoSQL用于产品信息。您可能希望以一种可以由UI直接使用而且处理最少的格式存储它。正确设计，这应该允许分割NoSQL存储，这将有助于扩展，尽管如果节点出现故障，你需要一种方法来重现数据。

要处理产品和相关数据（评论，帖子等）之间的关系，您需要将它们与用于从NoSQL存储中检索它们的任何密钥相关联。如果您打算处理数以百万计的产品记录，您可能需要确定数据保留要求 - 您是否真的需要保留已过时和/或不可用多年的产品的详细信息？

如果搜索将成为数据的主要接口，您可能不需要NoSQL解决方案 - 只需从solr中提取您需要的内容即可。

您可以将缓存放在大多数这些图层的前面。

Answer 3

两条评论，并非假装到目前为止的完整答案。

RDBMS与NoSQL

• NoSQL对我来说似乎是一个更好的选择，因为您不需要一直严格控制数据完整性。

• 您也不在乎产品X在过去5-10分钟内是否在排名中发生了变化，也没有关注用于搜索的用户首选项。

• 无论如何你都会拥有NoSQL数据库。

这就是为什么RDBMS看起来有点太多了。

性能。

• 您可能需要多台数据准备服务器来分配工作量。

• 您可以根据使用模式不良偏好对用户进行分组并在不同服务器之间进行分区。你可以事先想到这一点。

• 设计服务用户请求的理想模型。知道每个实例/机器/ CPU可以提供多少查询，想一想它是如何工作的。您可以稍后修改它，看看您的预期和真实用户行为之间的差异。