我一直在玩弄 Map Reduce with CouchDB。一些示例显示了 map reduce 函数中的一些可能很重的逻辑。在一个特定案例中，他们在 map 中执行 for 循环。
map reduce 在发出您选择的文档之前是否在每个可能的文档上运行？
如果是这样，我认为这意味着在 map reduce 函数内运行任何类型的迭代处理至少会增加一个数量级的处理负担。
基本上它可以归结为以下问题:在 map reduce 中可以执行多少逻辑，然后再进行不合理的昂贵查询？
最佳答案
在 CouchDB map-reduce 中，大量昂贵的处理是可以接受的。
CouchDB View (map-reduce)更像是CREATE INDEX 而不是SELECT FROM。
具体来说，CouchDB 保证 map 函数永远只每个文档运行一次。 (好吧，实际上每个文档改变一次。)这就是“迭代 map-reduce”。
因此，假设您有 10,000 个文档，每个文档需要 1 秒 来处理(这比我见过的时间长得多)。完全构建 View 需要 10,000 秒或 2.8 小时。但是，一旦 View 完成，查询任何行 (?key=...) 或行切片 (?startkey=...&endkey=...) 都会采用与直接查询文档的时间相同。文档计数的查找时间为 O(log n)。
换句话说，即使每个文档执行 map 需要 1 秒，但获取结果也需要几毫秒。 (当然， View 必须先构建，因为它实际上是一个索引。)
关于database - CouchDB View : How much processing is acceptable in map reduce?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10046285/