Amazon EC2 + S3 + Python + Scraping - 最便宜的方法？
我利用了亞馬遜的 AWS 產品，如果我認為正確的話，請高層次地解釋一下。
所以我的本地機器上幾乎沒有 Python 抓取腳本。我想使用 AWS 獲得超快的網際網路連接和更便宜的價格 - 雙贏！
- 我知道我可以在 EC2 上部署 centOS/Ubuntu 實例。安裝必要的 Python 庫。使用 boto (Python) 啟動和停止實例以節省成本。到目前為止我的想法正確嗎？（可行嗎？）
- 我將 CRON 一些腳本，這些腳本將開始獲取（抓取）HTML 文件以供稍後解析。所以這些 HTML 文件被複製到 S3 進行儲存（或者我應該將它們轉儲到我的本地機器，因為這就是我在 MySQL 中解析和儲存的方式？）。
請告知我是否對我的假設有任何意義，以及我對 AWS 的了解很少，我花了幾個小時閱讀/Google搜尋該服務。
您的設置的基本前提似乎很好，但是，您可能需要考慮一些項目。
首先，EC2 網路（和 I/O）頻寬取決於實例類型。如果您希望使用 t1.micro 實例，不要期望“超快速的網際網路連接” - 即使使用 m1.small，您也可能看不到您正在尋找的性能。另外，請記住，您需要為 EC2 上使用的頻寬付費（而不僅僅是實例時間）。
關於您的第一點，在 EC2 實例上設置 Python 應該沒有真正的困難。但是，潛在的困難來自協調您的實例。例如，如果您有 2 個實例正在執行，您將如何在它們之間拆分任務？每個實例如何“知道”另一個實例做了什麼（假設您不打算手動劃分 URL 列表）。此外，如果您要啟動一個實例，將由其中一個 EC2 實例負責處理，還是由您的本地機器處理（如果它是其中一個 EC2 實例，您如何確定哪個實例將負責該任務？ （即防止“發射” 每個實例都在執行任務）以及如何重新分配任務以包含新實例？您如何確定要自動終止的實例？
毫無疑問，以上所有這些都是可能的（corosync/heartbeat、pacemaker、auto-scaling 等），但最初很容易被忽視。無論如何，如果您正在尋找“最優惠的價格”，您可能會想要使用現場實例（而不是按需實例），但是，要使其工作，您確實需要一個相當強大的架構。（值得注意的是，現貨價格波動很大 - 有時超過按需價格；根據您工作的時間範圍，您可能希望設置較低的現貨價格上限，或確定最佳方法（現場/按需）定期（每小時）以最小化您的成本。）雖然，我目前無法確認，但最簡單（也是最便宜）的選項可能是 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 實例）和管理實例的縮放（例如自動縮放），您的想法應該可以正常工作。