Amazon EC2 + S3 + Python + Scraping - 最便宜的方法？

Question

我利用了亚马逊的 AWS 产品，如果我想得对，请从高层次解释这一点。

所以我的本地机器上几乎没有 Python 抓取脚本。我想使用 AWS 实现超快速的互联网连接和更便宜的价格 - 赢/赢！

• 我知道我可以在 EC2 上部署 centOS/Ubuntu 实例。安装必要的 Python 库。使用 boto (Python) 启动和停止实例以节省成本。到目前为止我的想法正确吗？（可行吗？）

• 我将 CRON 一些脚本，这些脚本将开始获取（抓取）HTML 文件以供稍后解析。所以这些 HTML 文件被复制到 S3 进行存储（或者我应该将它们转储到我的本地机器，因为这是我将在 MySQL 中解析和存储的方式？）。

请告知我的假设和我对 AWS 的几小时阅读/谷歌搜索的了解是否有意义。

Answer 1

您设置的基本前提似乎很好，但是，您可能需要考虑一些项目。

首先，EC2 网络（和 I/O）带宽取决于实例类型。如果您希望使用 t1.micro 实例，请不要期望“超快速互联网连接”——即使使用 m1.small，您也可能看不到您想要的性能。此外，请记住，您需要为 EC2 上使用的带宽（而不仅仅是时间）付费。

关于您的第一点，在 EC2 实例上设置 Python 应该没有真正的困难。但是，潜在的困难来自于协调您的实例。例如，如果您有 2 个实例在运行，您将如何在它们之间拆分任务？每个实例如何“知道”另一个实例做了什么（假设您不打算手动划分 URL 列表）。此外，如果您正在启动一个实例，EC2 实例之一将负责处理该实例还是您的本地机器会处理它（如果它是 EC2 实例之一，您如何确定哪个实例将负责该任务？ （即防止“发射” 每个实例正在执行的任务）以及如何重新分配任务以包括新实例？您如何确定要自动终止哪些实例？

毫无疑问，以上所有这些都是可能的（corosync/心跳、起搏器、自动缩放等），但最初很容易被忽视。无论如何，如果您正在寻找“最优惠的价格”，您可能希望使用现货实例（而不是按需实例），但是，要使其发挥作用，您确实需要一个相当强大的架构。（值得注意的是，现货价格波动很大 - 有时会超过按需价格；根据您工作的时间范围，您要么想要设置较低的现货价格上限，要么确定最佳方法（现场/按需）定期（每小时）以最大限度地降低您的成本。）虽然，我目前无法确认，但最简单（也是最便宜）的选项可能是 AWS 的自动扩展。

鉴于我真的不知道你的工作范围，我可能会问为什么不简单地使用 EC2 进行解析和处理。特别是如果解析很复杂，获取页面的速度比处理它们的速度要快，并且您有大量的页面（推测，否则您将不会通过设置 AWS 的努力），它可能是更有效地简单地处理 EC2 上的页面，当一切都完成后，下载数据库的转储。可以说，这可能会稍微简化一些事情——让一个实例运行 MySQL（数据存储在 EBS 卷上），每个实例查询 MySQL 实例以获取下一组记录（并且可能将这些记录标记为保留），获取和处理，并将数据保存到 MySQL。

如果您不打算在 EC2 上运行 MySQL，您可以将您的 HTML 文件存储在 S3 上，正如您所提到的，或者可以将它们保存在 EBS 卷上。S3 的优点是你不需要预先分配存储（如果你不知道你正在处理的数据的大小特别有用）——你为 PUT/GET 和存储付费；缺点是速度 - S3 并不打算用作文件系统，并且（即使您可以将其作为文件系统挂载）将每个单独的文件保存到 S3 的效率相当低（因为您会想要累积一个几个页面，然后他们将它们上传到 S3）。此外，如果您有大量文件（数以万计），则获取所有文件名等的处理速度可能会很慢。EBS 卷旨在用作附加到实例的存储 - 优势在于速度 - 传输速率和它具有“文件系统”的事实（因此读取文件列表等很快） - EBS 卷持续存在实例终止（EBS 根卷除外，默认情况下不会终止（但可以进行））。EBS 卷的缺点是您必须预先分配一定数量的存储（不能即时修改） - 您需要为该数量的存储付费（无论是否全部都在使用中）；您还需要为 I/O 操作付费（此外，EBS 卷的性能取决于网络速度 - 因此更大的实例可以获得更好的 EBS 性能）。EBS 的另一个优点是，作为一个文件系统，

我不会真正推测可能性（请记住，在非常大的范围内，将使用诸如 map-reduce/hadoop 之类的东西来管理此类任务），但只要您有一种方法来划分任务（例如 MySQL 实例）和管理实例的扩展（例如自动扩展），您的想法应该可以正常工作。