目前我正在使用ec2+sqs+s3实现一个大数据解决方案。我的想法是，我有一个巨大的文件数据库托管在s3上。使用我的应用程序的客户机将提交一个规则匹配，它将尝试匹配s3上可用的所有相关文件，然后计算一个条件语句，向用户返回显示哪些文件匹配条件语句的输出。
很明显，我不能直接在s3文件上执行规则匹配，因为这样就不能防止ec2示例上的重复作业了，我需要启动来执行规则匹配。也不会有分工。
我最初的解决方案是合并amazonsqs：当客户机发出请求时，s3中的所有文件都将加载到队列中。这将允许我的ec2示例执行分工+无重复，因为sqs负责这一点。
但是，使用上述解决方案，每次客户机请求时，我都会将所有文件加载到sqs队列中，这显然是浪费（更不用说飙升的sqs成本）。理想情况下，我希望有一个持久队列，一次加载我的所有文件（另外，在s3中添加更多文件时加载更多文件）。
关于如何创建大数据队列结构有什么想法吗？？我应该抛弃sqs，还是应该调整sqs，使其像持久队列一样运行，在处理消息之后不删除它们，并保持保留的sqs示例始终运行？
谢谢。
1条答案
按热度按时间7ajki6be1#
假设您的规则匹配是基于文件元数据而不是文件内容的，那么您可以将关于您的文件的元数据存储在实际的数据库中，比如amazondynamiodb，并这样进行匹配。
将数据“永久”存储在sqs中（而不是删除消息）不是一个好主意—消息的大小有限，如果不删除消息，它们将再次可用于后续请求—这样会得到更多的重复。此外，sqs不提供任何关于复制的保证—实际上它是“至少一次”的交付。
如果您正在对文件内容（可能除了元数据之外）运行规则匹配，这听起来是您真正想要的，那么您可以使用amazon simpleworkflow和在其上构建的flow api：
swf有两个主要组件-工作流（维护状态）和活动（执行工作的无状态代码）。对于您的情况，工作流会将每个请求分成许多工作块，并将活动提交给swf服务。您的活动工作人员将在许多ec2示例上运行—他们的工作本质上是提取作业（即：在指定的s3文件子集上运行规则匹配代码）并返回结果。然后，工作流将合并活动结果并对结果执行某些操作。
flow framework recipies文档提供了一些很好的代码模式示例，这些代码模式是并发执行许多活动和合并结果所需的。
总之，要具体回答您的问题：抛弃sqs，使用swf，它是为这种使用模式设计的。