互联云天

前几年Google的廉价服务器组成的强大数据中心、MapReduce编程模型是IT界讨论的热点，它家的Bigtable、GFS等也是被广为研究。我看过一点点相关的资料，说一点自己的理解。传统上在软件级别解决并行问题的时候有两种基本的并行形式：data parallelism和task parallelism。 Google的搜索应用中会综合运用这两种形式，因为搜索需要支持很多同时使用的人，而每个人的每次搜索也需要大量计算，每个人的每次搜索的响应时间又需要压缩到最短。

Google的MapReduce编程模型恰恰利用Bigtable、GFS把data parallelism的优势发挥的淋漓精致。在搜索的时候，整个搜索任务被根据输入和实际的data分布切割成一个个小的计算单位，在数据中心的一个个node上并行的执行。虽然说所有node加起来的执行时间可能比串行执行起来要长，但是用户响应时间却被极大的缩短了。在这里，事实上会根据data分布去调度计算，而每个node处理的数据集是不大的，可以使用大量使用缓存。

Google App Engine（GAE）的Datastore底层是基于Bigtable和GFS（来源在这里） 的，它应该具有Bigtable和GFS的优势，但现在我却没有在公开的API里看到data parallelism能力的体现。

GAE虽没有显式的暴露data parallelism的并行模型，我还是想探讨下可能性。Model的构造函数里有个parent参数，根据这里所述，parent参数可以用来形成Entity Group，而每个Entity Group则一定会分布在Datastore的同一个Node上。官方是鼓励只在需要对一个Entity Group中的entity进行transaction操作的时候才做成一个Entity Group，否则尽量做成多个Entity Group，方便数据的分布式存储。但假设我们切割好Entity Group，然后根据Entity Group来做data parallelism，是不是可行呢。现在语言层面解决data parallelism问题也开始起来了，比如Parallel LINQ，不过这跟在应用层面解决data parallelism仍然不是一个层面的问题。但如果GAE的Datastore提供一个类似的接口，则GAE中data parallelism这盘棋就活了。

另一方面来讲，GAE提供了一种理论上几乎可以无限扩展的task parallelism的能力，具体是什么意思呢，就是当你的网站在线人说从100增长到100万的时候，你不用去关注计算能力哪里来，Google自动给你提供，当然，这是要付费的。实际情况要复杂些，要自己设置各种quota，Google并不会给你提供超出quota的计算能力。Google对GAE的收费计划按他们的roadmap会在2009年前期给出来。

罗哩罗嗦说了很多，这些东西我只懂一点皮毛，很多都是我在揣测，还要继续看。