GAE MapReduce可以获得多少计算密集型增益？ 我感兴趣的场景是计算密集型，因此例如：在单线程单核应用程序中乘以一万亿随机浮点数。 然后想象1000个MapReduce工作者每个乘以10亿个随机数，并在所有工人完成时宣布“完成”。 如果重要，则假设已启用结算。 （可能不会）。
编辑：一位评论者要求澄清。 标题已经修改。 如果任务需要50000秒单线程，并且在替代实现中使用了1000个MapReduce工作器并且它们在500秒后完成，则性能增益为100倍。 1000名工人：获得100倍，只是略微令人失望，但对于这个例子也是如此。 我怎样才能早点完成？ 我可以要求10,000名工人吗？ 这个问题可能与限制和配额有关。 假设有足够的预算。 MapReduce的计算密集型性能是否会增加到渐近线，如果是这样，该渐近线的性能增益是多少？ 关于MapReduce的评论中还有适用于面向用户URL生成的大量数据的信息，但是，我的问题与数据存储密集型应用程序的性能相比，与MapReduce重写的相同应用程序无关。 在此计算密集型方案中，数据存储区活动将是最小的。 我意识到在任何MapReduce应用程序中总会有一些数据存储活动，但由于这是一个计算密集型场景，因此数据存储区活动和数据存储区实体的大小不会对计算的性能增益产生很大影响。 该任务将使用数据存储的时间少于经过时间的1％。 该方案也不涉及大量通信带宽（除了达到MapReduce使用的任务排队URL所需的最小值）。 问题在于将计算密集型单线程非MapReduce任务的已用时间与MapReduce上相同任务的已用时间进行比较，因为有多个工作者，MapReduce本身就是多线程的。 我一般使用“任务”一词，换句话说，“任务就是工作”。 收益可能（但不一定）是工人数量的函数，因此我在示例中提到了1000名工人。
目前尚不清楚你在这里问什么。 你在问它效率如何？ 它有多便宜？ 它有多快？
通常，App Engine旨在为面向用户的站点提供服务，并且App Engine mapreduce API可用于协助处理 - 处理面向用户的站点生成的大量数据。 如果您在App Engine外部托管了大量数据，并且您希望对其进行某种大规模数据处理，那么App Engine可能不适合您。
关于性能，您可以期望每个工作人员以连续执行任务的速度执行任务，因此您的每秒项数大致是工作人员数乘以常规速率 - 开销相对较小。 但是，当不同的工作人员在不同的时间完成时，最终可能会有一些延迟，这取决于作业mapreduce对分片数据的好坏程度。 对于数据存储区输入，这曾经相当差，但现在好多了。
至于你可以拥有多少个地图制作器，这取决于很多事情：你的应用程序是否启用了计费，你的应用程序获得了多少其他流量，以及你的映射器任务占用每个元素的时间。 确定这一点的唯一真正方法是尝试一下。