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可能不是您的工具。

关于性能，您可以期望每个工作人员以连续执行任务的速度执行任务，因此您的每秒物品数大致等于工作人员数乘以常规费率 - 这里相对较少高架。尽管如此，当不同的工作人员在不同的时间完成工作时，这可能会有一些延迟，这取决于工作映射减少对分割数据的影响程度。有了数据存储输入，这个过去相当糟糕，但现在好多了。

至于您可以拥有多少个映射器，取决于许多事情：您的应用是否启用了计费，您的应用获得了多少其他流量，以及您的映射器任务每个元素需要多长时间。确定这一点的唯一真正方法是试验一下。