Google App Engine MapReduce 有多快？

Question

在 GAE MapReduce 上可以期待多少计算密集型收益？我感兴趣的场景是计算密集型的，例如：在单线程单核应用程序中乘以一万亿个随机浮点数。然后想象一下 1000 个 MapReduce 工作人员每个人乘以十亿个随机数，并在所有工作人员完成后宣布“完成”。如果这很重要，假设启用了计费。 （可能不会）。

编辑：一位评论者要求澄清。标题已被修改。如果任务需要 50000 秒单线程，并且在替代实现中使用了 1000 个 MapReduce 工作人员并且他们在 500 秒后完成，那么性能增益是 100 倍。 1000 工人：100 倍的收益，只是有点令人失望，但对于这个例子来说就是这样。 我怎样才能更快完成？我可以要求 10,000 名工人吗？这个问题可能与限制和配额有关。假设有足够的预算。 MapReduce 的计算密集型性能增益是否趋向于渐近线？如果是，该渐近线的性能增益是多少？ 评论中还有关于 MapReduce 适用于由面向用户的 URL 生成的大量数据的信息，我的问题不在于数据存储密集型应用程序的性能与为 MapReduce 重写的相同应用程序的性能。在这种计算密集型方案中，数据存储活动将最少。我意识到在任何 MapReduce 应用程序中总会有一些 Datastore 活动，但由于这是一个计算密集型场景，Datastore 活动和 Datastore 实体的大小不会对计算的性能增益产生很大影响。该任务将使用数据存储区的时间少于已用时间的 1%。也不是涉及大量通信带宽的场景（除了命中 MapReduce 使用的任务排队 URL 所需的最小值）。问题在于将计算密集型单线程非 MapReduce 任务的运行时间与 MapReduce 上相同任务的运行时间进行比较，MapReduce 本质上是多线程的，因为有多个工作人员。我一般使用“任务”这个词，换句话说，“任务意味着工作”。增益可能（但不一定）是工人数量的函数，因此我在示例中提到了 1000 个工人。

Answer 1

不清楚你在这里问的是什么。你问效率如何？它有多便宜？它有多快？

一般而言，App Engine 旨在为面向用户的网站提供服务，而 App Engine mapreduce API 的存在就是为了帮助实现这一点 - 处理由面向用户的网站生成的大量数据。如果您有大量在 App Engine 外部托管的数据，并且您想对其进行某种大规模数据处理，那么 App Engine 可能不适合您。

关于性能，您可以期望每个工作人员执行任务的速度与您连续执行任务时一样快，因此您的每秒项目数大致是工作人员数量乘以正常速率 - 开销相对较小.但是，当不同的工作人员在不同的时间完成时，最后可能会有一些延迟，这取决于 mapreduce 对数据分片的工作有多好。使用数据存储输入，这在过去相当糟糕，但现在好多了。

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