摘要：在处理来自数据库的数据集合时，MapReduce 是一个好主意，而不是为一个有点复杂（或只是大）问题找到一些答案？
我想同步一组联合源（例如http://xkcd.com/rss.xml之类的 url ），它们作为集合/表存储在 GAE 的数据存储中。我看到两种选择，一种是直截了当的。制作您放入队列中的简单任务，其中每个任务句柄的 100 或 1000 或任何自然数似乎适合每个任务。另一个选项是 MapReduce。
在后一种情况下，Map 做所有事情，而 Reduce 什么都不做。此外，地图没有结果，它只是改变了（数据存储的）“状态”。
@Override public void map(Entity entity) {
String url = (String)entity.getProperty("url");
for(Post p : www.fetchPostsFromFeed(url)) {
p.save();
}
}
如您所见，一个来源可以映射到许多帖子，所以我的地图还不如称为“爆炸”。
所以没有排放，也没有什么可以减少的。我喜欢这种地图方法的原因是我告诉谷歌：在这里，拿我的收藏/表格，按照你认为适合不同的映射器的方式将其拆分，然后将帖子存储在你喜欢的任何地方。数据存储使用“高复制”。因此，数据的可用性很高，并且是“计算单元”做什么实体并没有真正减少网络通信的最佳选择。保存帖子也是如此，因为它们需要转到所有数据存储单元。我喜欢的是，mapreduce 对卡住的地图计算有某种故障恢复方式，并且它知道有多少任务要发送到哪个节点，而不是在某处排队一些实体，希望它有意义。
可能我这里的思路不对，请指正。无论如何，由于缺少 reduce 和 map 是“爆炸”，这种方法是否“错误”？