用于产品Feed的AWS架构

Question

作为一个快速简历，我需要构建一个基于人们在网站上搜索的不断更新的产品Feed。要记住的重要事项：

• 相同ID的价格变化，所以我需要始终保持最低（给定月份）
• 每天都会将此Feed上传到不同的营销提供商，以生成自定义广告。

考虑到所有这一点，我直接解释我认为可能的架构（我打开并鼓励新的架构）：

在两者中，我将获得产品信息，使人们在现场向API网关请求产品的参数和思想代理实现到Lambda，我已经解析了所有数据。之后我可以：

1. 在S3上按天存储并运行每日EC2，该EC2从前一天检索所有寄存器并跨越到红移群集上的查询。检测到需要更新的所有行后，请更新redshift表。
2. 使用elasticache并实时评估行（通过id）是否需要直接从lambda更新（并更新）。

我最关心的是节约成本。思考？我应该考虑的任何其他变量？我应该研究其他任何解决方案吗？

Answer 1

要降低成本，请尝试以下操作：

1. 您可以使用由CloudWatch预定事件触发的Lambda函数替换每日EC2任务。免费！
2. 而不是Elasticache，使用DynamoDB。免费。
3. 我不知道你为什么使用Redshift。如果可以用RDS，ElasticSearch甚至DynamoDB替换它，我认为这会使它更便宜。

Answer 2

您可能想要评估的一些考虑因素可能是：

- 处理后的数据需要多久才能提供？

- 处理后的数据需要哪种格式？

- 处理后的数据需要哪些颗粒可用？

- 您对每个拉取请求的Web层有多大的数据量？

- 您已经提到了弹性缓存，您的应用程序可承受的延迟（以秒为单位）？除了数据的内存分期外，还有其他原因使用弹性缓存吗？在大多数情况下，像Dynamo DB这样的无Sql服务是一个不错的选择。

- 解决方案是否需要实时写入红移。 （经常随机插入红移是反模式！）

- 当您将要更新的记录标记为“旧”并插入新记录时，更新最佳红移工作。

- 关于Lambda（你可能已经知道）的处理上限时间为300秒，因此如果Lambda Transformation可以达到上限，你可能想要试用。

- 像Aurora这样的AWS RDS服务比redshift便宜，可以存储高达64 TB的数据，因此可以成为一个良好的Data Store解决方案，提供OLTP系统的灵活性。