我一直在使用CouchDB进行Map Reduce。一些示例显示了map reduce函数中的一些可能很重的逻辑。在一个特定情况下，他们在地图中执行循环。
是否会在每个可能的文档发出所选文档之前运行map reduce吗？
如果是这样，我认为这意味着在地图缩减功能中运行任何类型的迭代处理会使处理负担增加一个数量级，至少。
基本上它归结为以下问题：在地图减少之前可以执行多少逻辑，然后才能进行不合理的昂贵查询？
答案 0 :(得分：8)
CouchDB map-reduce中可以接受大量昂贵的处理。
CouchDB视图（map-reduce）更像CREATE INDEX而不是SELECT FROM。
具体来说，CouchDB保证每个文档的映射函数只运行一次。 （好吧，实际上每个文档更改一次。）这就是“迭代map-reduce”。
因此，假设您有10,000个文档并且每个文档需要1 秒进行处理（这比我见过的要高）。完全构建视图需要10,000秒或2.8小时。但是，一旦视图完成，查询任何行（?key=...）或行切片（?startkey=...&endkey=...）的时间与直接查询文档的时间相同。查找时间为文档计数的O（log n）。
换句话说，即使每个文档需要1秒来执行映射，也需要几毫秒才能获取结果。 （当然，视图必须首先构建，因为它实际上是一个索引。）
答案 1 :(得分：2)
查询数据库是与文档的map / reduce无关的活动。因此，查询成本不受map / reduce复杂性的影响。
在couchdb中，您正在查询索引。这意味着它是以针对查询速度优化的格式的数据副本。查询不像sql中的tablescan。它不会循环记录。
那么你如何制作这个指数呢？它是通过map函数完成的。 map函数发出键和值。密钥放在索引中。您提到的一些复杂的地图函数可能会循环并发出许多键和值。 Couchdb非常智能，只在需要时才运行文档，通常是在创建，更新和删除时。这就是为什么它是增量map / reduce。
您可能会看到，复杂的地图功能可能会影响创建，更新和删除速度。但是，couchdb很聪明，因为您可以指定查询索引时数据的可能性。