适用于产品源的 AWS 架构

Question

作为快速简历，我需要建立一个产品提要，它会根据网站上的人员搜索不断更新。要记住的重要事项：

• 相同ID更改的价格，因此我需要始终保持最低价格(给定月份)
• 每天，此提要都会上传到不同的营销提供商，以生成自定义广告。

考虑到所有这些，我直接解释我认为可能的架构(我开放并鼓励新的)：

在这两种情况下，我都将获得产品信息，使现场人员使用产品的参数向API网关发出请求，并向Lambda发送思想代理实现，在那里我解析了所有数据。之后，我可以：

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

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

Answer 1

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

1. 您可以将每日 EC2 任务替换为由 CloudWatch 计划事件触发的 Lambda 函数。它是免费的！

2. 使用 DynamoDB 代替 Elasticache。它是免费的。

3. 我不知道你为什么要使用Redshift。如果它可以被RDS，ElasticSearch甚至DynamoDB取代，我认为这将使它更便宜。

Answer 2

您可能想要评估的一些注意事项可能是：

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

-处理后的数据需要提供什么格式？

-处理后的数据需要提供什么粒度？

-每个拉取请求的 Web 层期望有多少数据量？

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

-解决方案是否需要实时写入红移。(频繁随机插入红移是一种反模式！

-当您将要更新的记录标记为"旧"并插入新记录时，对红移的更新效果最佳。

-关于 Lambda(您可能已经知道)的处理上限时间为 300 秒，因此您可能想试用 Lambda 转换是否可以达到上限。

此外，像Aurora这样的AWS RDS服务比Redshift便宜，可以存储高达64 TB的数据，因此可能是一个很好的数据存储解决方案，提供OLTP系统的灵活性。