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

我和我的一些同事已经开始开发一款iPhone应用程序，为用户提供社交购买体验。目标是为用户提供对数百万产品的扩展搜索功能（全文、模糊搜索、基于过滤器等），这些产品不断从多个产品列表API（如易趣和亚马逊）获取，然后进行规范化（即字段、类别和关系的转换），应用一些业务逻辑，以便用户能够根据多个标准（独特的个人资料，即年龄/性别、搜索历史、朋友购买的物品等）获得定制内容。 该应用程序还具有一些社交功能，如关于产品的帖子、喜好和评论，以及跟踪其他用户等

因此，现在我们正在尝试设计支持这些需求的服务器体系结构，其中包括性能方面的考虑（“给我所有与我的搜索词相匹配的产品，并按相关性排序”应该运行非常快~1到10秒）和可伸缩性方面的考虑（如果我可以扔更多的机器来解决这个问题，那么10个结果用户将在与100000个用户相同的时间内得到结果）

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

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

设置Elastic Beanstalk以支持可伸缩性，在流量增加时抛出更多EC2实例，在流量减少时将其删除

使用MySQL设置RDS作为应用程序（管理用户、配置文件、标准化产品等）的RDBMS，并具有多个可用性区域

在不同的服务器上设置后台“代理”进程，以不断从API获取产品数据（具有可定制的获取功能）

将上述“原始数据”作为临时数据存储在某些NoSQL中

为数据的规范化设置另一个“代理”，对其进行分析，并将其插入RDBMS中，以便能够基于用户不同的配置文件进行非常快速的搜索

设置缓存机制以减少RDBMS上的负载

建立一个好的全文搜索引擎（如Lucene）

我们的主要考虑是：

Linux环境

主要是PHP和MySQL

性能是一个问题

可扩展性将在不久的将来成为一个问题（6-12个月）（希望：）

现在有几个问题：

架构合理吗

对于数据存储，RDBMS是正确的选择，还是我们应该考虑NoSQL引擎（即MunGDB）？。 在解决这个问题时，我们应该考虑什么样的技术/方法？

---

顺便说一句，战争故事会很受欢迎：）

两条评论，到目前为止还没有完整的答案

RDBMS与NoSQL

---

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

• 您也不关心产品X在过去5-10分钟内是否改变了其排名，也不关心用于搜索的用户偏好是否有轻微变化

• 无论如何，您将拥有NoSQL db

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

表演

• 您可能需要几个数据准备服务器来分配工作负载

• 您可以根据用户的使用模式和偏好对用户进行分组并将其划分到不同的服务器上。你可以提前想到这一点

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

对

取决于您希望在存储级别表示数据的结构。如果您在内存中构建该结构，或者使用Lucene进行搜索，请查看NoSQL选项（Dynamo for AWS）

看看如何使用Hadoop集群及时规范化数据

---

我认为对于您所描述的，您可能希望避免使用弹性豆茎，并将其部署到您控制的EC2实例上

前端将运行web加载，主要是从缓存进行查询。这可以在弹性负载平衡器后面进行，您可以使用自动缩放规则来确保始终有足够的资源来处理负载

对于全文搜索，我可能会考虑solr，但我不是这方面的专家-我认为solr将具有一些可扩展性、复制性等，从而使管理搜索基础架构更容易一些。有一些很好的AWS Solr参考体系结构是为扩展而设计的

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

我可能会将其设计为使用mysql和无sql存储的组合。Mysql用于核心功能-帐户、用户首选项等，而NoSQL用于产品信息。您可能希望将其存储为一种可以由UI直接使用的格式，只需最少的处理。如果设计得当，这将允许NoSQL存储的分片，这将有助于可伸缩性，尽管在节点发生故障时需要一种方法来重现数据

要处理产品和相关数据（评论、帖子等）之间的关系，您需要将它们与用于从NoSQL存储检索它们的任何键相关联。如果你要处理数百万和百万