基本上,我有一个Web服务,每分钟接收一次小的json有效负载(一个事件),比如60.这个事件必须在1年后才被发送到SQS队列(它已经过去了#1)好吧,迟早会发生几个小时,但月份的日期应该完全一样。)
这意味着在第一个事件发送到SQS队列之前,我必须在某处存储超过3100万个事件。
我考虑过使用SQS消息计时器,但它们只有15分钟的限制,正如@Charlie Fish所指出的那样,让一个元素在队列中潜伏这么长时间是很奇怪的
更好的可能性是为每个事件使用Cron表达式安排lambda函数(如果我之前没有达到AWS限制,我可能会在一年内结束数百万或数十亿的预定lambda函数这一点)。
或者我可以将这些事件存储在DynamoDB或RDS上。
使用AWS服务处理此问题的建议/最具成本效益的方法是什么?预定的lambda功能? DynamoDB? RDS上的PostgreSQL?还是完全不同的东西?
如果我每年有310亿个活动而不是3100万个活动怎么办?
我不能放松任何这些事件。
答案 0 :(得分:2)
我的意思是你可以在DynamoDB中存储某种形式的数据,并运行一些每日Lambda任务来查询超过一年的所有项目,从DynamoDB中删除它们并将其导入SQS。
正如您所提到的,SQS没有内置此功能。因此您需要使用其他技术存储数据。根据您上面提到的内容,DynamoDB似乎是一个负责任的选择。
当然,你还必须考虑每天做一次cron任务是否足以完成你的任务。 1年后你需要完全吗?一年零几天可以接受吗?还是一年零几个星期?导入SQS的窗口是什么?
最后,您需要考虑的另一个问题是SQS是否适用于您的应用程序。拥有1年延迟的队列似乎有点奇怪。我可能是错的,但你可能想要考虑SQS以外的东西,因为SQS意味着更多的即时任务。请参阅this page上的示例(Decouple live user requests from intensive background work: let users upload media while resizing or encoding it
,Allocate tasks to multiple worker nodes: process a high number of credit card validation requests
等)。这些例子中没有一个真正意味着在执行前一年的等待时间。在一天结束时它取决于你的用例,但是我无法想到延迟进入SQS队列一年的情况。似乎有更好的方法来解决这个问题,但我不知道你的具体用例。
编辑另一个问题是您的数据是否一致?您需要存储的数据量是否一致?格式怎么样?每秒事件的数量怎么样?你提到你不想丢失任何数据。确保构建错误处理和备份系统。但是对于DynamoDB而言,如果您存储5个项目,那么下一刻您要存储500万个项目时,它不会扩展到最佳。如果您将容量设置为500万,则可以。但问题是数据量和频率是否一致?
答案 1 :(得分:2)
DynamoDB是一个合理的选择,因为RDS-SQS对于长期存储不是一个好选择。但是 - 如果你想降低你的成本,我可能会建议另一个:在一个24小时的时间段内累积事件(如果需要的话,可以累积更小的时间间隔),并将这组数据写成S3对象,而不是保持它在DynamoDB中。您可以使用dynamodb或rds(或其他任何东西)作为累积当天(或小时)事件的地方,然后将该数据作为间隔的单个数据集写入S3。
每个S3对象都可以正确命名,指示它创建的日期/时间,或者需要使用的数据/时间,即20190317-1400,表示在2019年3月17日下午2点这个文件需要使用。
我想象一个lambda函数,由每60分钟触发一次的cloudwatch事件调用,扫描你的s3存储桶,查找将要使用的文件,然后读入json数据并将它们放入SQS队列进行进一步处理并将已处理的s3对象移动到另一个“已处理”的存储桶
您的存储成本将是最低的(特别是如果您按天或小时批量处理),S3具有11 9的耐久性,如果您想要将旧事件存档到Glacier,即使在处理后也可以将它们存档
DynamoDB是一款出色的产品,它提供了冗余存储和超高性能 - 但我认为您的要求中没有任何内容可以保证产生成本或需要DynamoDB的性能;当你提前知道在一年之后不需要使用或查看记录时,为什么要将数百万条数据记录保存在“永远在线”数据库中。