Google App Engine MapReduce的速度有多快？

Question

GAE MapReduce可以獲得多少計算密集型增益？我感興趣的場景是計算密集型的，例如：將單個線程單核應用程序中的萬億個隨機浮點數相乘。然後，想象一下，1000名MapReduce工作人員每人增加10億個隨機數字，並在所有員工完成時宣佈「完成」。如果重要，假設計費已啓用。 （它可能不會）。

編輯：一位評論者要求澄清。標題已修改。如果任務需要50000秒單線程，並且在另一個實現中，則使用1000個MapReduce工作人員，並在500秒後完成任務，則性能增益爲100倍。 1000名工人：增加100倍，只是稍微令人失望，但對於這個例子也是如此。 我怎樣才能早日康復？我可以要求10,000名工人嗎？這個問題可能與限制和配額有關。假設有足夠的預算。 MapReduce的計算密集型性能增益是否接近漸近線，如果是這樣，那麼漸近線的性能增益是多少？有關MapReduce的評論中還有一些信息適合面向URL的用戶生成的大量數據，但是，我的問題不是關於Datastore密集型應用程序的性能而是針對MapReduce重寫的同一應用程序。在這種計算密集型的情況下，數據存儲活動將會很少。我意識到任何MapReduce應用程序中總會有一些數據存儲區活動，但由於這是一個計算密集型方案，因此數據存儲區活動和數據存儲區實體的大小對計算的性能增益影響不大。任務將使用數據存儲的時間少於所用時間的1％。這種情況也不涉及大量的通信帶寬（除了達到MapReduce使用的任務排隊URL所需的最低限度）。問題在於將計算密集型單線程非MapReduce任務的已用時間與MapReduce上相同任務的已用時間進行比較，因爲MapReduce具有多線程，因爲它有多個工作線程。我一般使用「任務」一詞，換句話說，「任務就是工作」。收益可能（但不一定）是工人數量的函數，因此我在例子中提到了1000名工人。

Answer 1

現在還不清楚你在這裏問什麼。你問這是多高效？它有多便宜？它有多快？

一般來說，App Engine專爲面向用戶的站點而設計，並且存在App Engine mapreduce API以協助處理面向用戶的站點生成的大量數據。如果您有大量數據駐留在App Engine之外，並且您想對其進行某種大規模數據處理，則App Engine可能不是您的工具。

關於性能，您可以期望每個工作人員以連續執行任務的速度執行任務，因此您的每秒物品數大致等於工作人員數乘以常規費率 - 這裏相對較少高架。儘管如此，當不同的工作人員在不同的時間完成工作時，這可能會有一些延遲，這取決於工作映射減少對分割數據的影響程度。有了數據存儲輸入，這個過去相當糟糕，但現在好多了。

至於您可以擁有多少個映射器，取決於許多事情：您的應用是否啓用了計費，您的應用獲得了多少其他流量，以及您的映射器任務每個元素需要多長時間。確定這一點的唯一真正方法是試驗一下。