我有一些基本的视图和一些带逻辑的map / reduce视图。没有什么太复杂的了。没有太多文件。我尝试过250k，75k和10k文档。好像我总是在等待视图索引。
视图中更好，更高效的代码是否有帮助？我假设它基本上处理所有聚合级别的视图。所以必须有一些改进。
emit（） - 更少的数据有用吗？发出（doc.id，doc）vs指定更少的字段？
或多或少复杂的密钥会影响视图索引吗？
或者是关于内存，CPU内核和处理器速度的全部内容？
必须有一些文档，但我找不到任何引用提高性能的方法。
答案 0 :(得分：2)
您在视图中编写的代码更像CREATE INDEX而不是SELECT。只要视图构建与文档更改率保持一致，它应该无关需要多长时间。构建视图是沉没（一次性）成本。
当您查询视图时，它始终是二进制树扫描，它以对数时间对静态数据集进行操作。这通常是人们关心的表现（在制作中）。
如果您没有看到我描述的行为，也许我们可以讨论您的查看功能以及您解决问题的一般方法。 CouchDB与关系数据库非常不同。在后者中，您具有高度结构化的数据和自由格式查询。在CouchDB中，您具有自由格式数据，但具有高度结构化的索引定义（视图）。除了在开发过程中，改变和重建视图应该是罕见的。
答案 1 :(得分：2)
我会深入研究一下reduce函数。尝试使用内置的Erlang函数，例如_sum，_count，而不是编写Javascript。
复杂的观点可能需要数小时甚至更多，这是正常的。
也许发布这样不太复杂的map / reduce。
不要忘记：索引所有文档只能在更改视图（或推送一大堆新文档）后完成一次。随后的新文档将逐步编制索引。
使用&stale=ok的视图即时检索“旧”数据，因此您无需等待。 （但请注意：您必须至少调用一次没有stale=ok的视图来触发索引过程）。或者更好：使用stale=update_after。
答案 2 :(得分：0)
不发射任何东西都会有所帮助，但是以较小的批次创建视图（有自动执行此操作的脚本）除了根本不发射任何东西之外还有其他任何东西，这有时无法帮助。
答案 3 :(得分：-1)
如果磁盘速度是您的瓶颈，您可以尝试直接在具有零延迟和高吞吐量的固态磁盘之上运行CouchDB。
Couchappy是一款免费的高性能Couchdb hosting，可让您在SSD磁盘上尝试最新版本的Apache CouchDB。