Amazon EC2 + S3 + Python + Scraping – 最简单的方法呢？

您的设置的基本前提似乎很好，但是，有几个项目，你可能要考虑。

首先，EC2networking（和I / O）带宽取决于实例types。 如果您希望使用t1.micro实例，不要期待“超级快速的互联网连接” – 即使使用m1.small，您也可能看不到您正在寻找的性能。 另外，请记住，您支付EC2上使用的带宽（而不仅仅是时间）。

关于你的第一点，在EC2实例上设置Python应该没有什么困难。 但是，协调您的实例会产生潜在的困难。 例如，如果您有两个实例正在运行，您将如何分配它们之间的任务？ 每个实例如何“知道”对方做了什么（假定你不打算手动分割URL列表）。 而且，如果你正在启动一个实例，其中一个EC2实例负责处理这个实例，或者你的本地机器会处理这个实例（如果它是EC2实例之一，那么你如何确定哪个实例负责该任务（即阻止每个实例执行“启动”任务）以及如何重新分配任务以包含新实例？如何确定自动终止哪个实例？

毫无疑问，所有上述都是可能的（corosync /心跳，起搏器，自动缩放等），但最初容易忽略。 无论如何，如果你正在寻找“最好的价格”，你可能会想要现货实例（而不是按需），但是，为了工作，你需要一个相当强大的架构。 （值得注意的是，现货价格波动很大 – 有时超过按需定价;根据您工作的时间规模，您要么设定较低的现货价格，要么确定最佳方法（即时/按需），以最大限度地降低您的成本。）尽pipe目前我无法确认，但最简单（也是最便宜的）选项可能是AWS的自动缩放。 您需要设置Cloudwatch警报（但Cloudwatch确实提供了10个免费警报），并且自动扩展本身没有与其相关的成本（除了新实例的成本和Cloudwatch成本）。

鉴于我真的不知道你的承诺的范围，我可能会问为什么不简单地使用EC2进行parsing和处理。 特别是如果parsing是复杂的，页面可以被抓取的速度比他们可以处理的快，并且你有大量的页面（可以推测，否则你不会通过设置AWS的努力），它可能是更简单地处理EC2上的页面，并且一切完成后，下载数据库转储。 可以说，这可能会简化一些事情 – 有一个运行MySQL的实例（数据存储在EBS卷上），每个实例向MySQL实例查询下一组logging（也可能标记为保留），提取和处理，并将数据保存到MySQL。

如果你不打算在EC2上运行MySQL，那么你可以把你的HTML文件存储在S3上，就像你刚刚提到的那样，或者把它们保存在EBS卷上。 S3的好处是你不需要预先分配存储空间（如果你不知道你正在处理的数据的大小，那么特别有用） – 你支付PUT / GET和存储空间; 缺点是速度–S3并不意味着被用作文件系统，并且（即使你可以将它挂载为文件系统），将每个单独的文件保存到S3是相当低效的（因为在你想要积累几页，他们上传到S3）。 另外，如果你有大量的文件（成千上万），所有文件名等的处理可能会很慢。 EBS卷旨在用作附加到实例的存储 – 优点是速度快 – 无论是传输速率还是具有“文件系统”的事实（因此读取文件列表等都很快） – EBS卷持续超越实例终止（EBS根卷除外，默认情况下（但可以设置））。 EBS卷的缺点是您必须预先分配一定数量的存储空间（无法在运行中修改），并支付该存储空间的数量（不pipe是否全部使用）; 您还需要支付I / O操作（另外，EBS卷的性能取决于networking速度 – 因此较大的实例可以获得更好的EBS性能）。 EBS的另一个优点是，作为一个文件系统，你可以很容易地执行一个任务，比如gzip文件（我想如果你下载了很多的html页面，你不想在以后获取S3的单个文件）。

我并不是真的在猜测这个可能性（记住，在一个非常大的范围内，像map-reduce / hadoop这样的东西可以用来pipe理这种任务），但是只要你有一个分区的方法任务（例如MySQL实例）和pipe理实例的缩放比例（例如自动缩放），你的想法应该工作得很好。

您可以通过SQS与不同的实例进行交互。 它是一个排队服务。 您可以将input的URL排队到SQS。 每个实例将依次从SQS获取URL。 但SQS不会给多个实例提供相同的input。 这是这里的主要优点..