【发布时间】：2014-04-09 15:02:49
【问题描述】：
我了解 CouchDB 会根据索引文件的名称对每个设计文档的来源进行哈希处理。每当我更改源代码时，都需要重建索引。 CouchDB 在第一次请求文档时执行此操作。
我期望和希望发生的事情
每次我更改设计文档时，第一次调用视图所需的时间会比平时长得多，并且可能会超时。该指数将继续建立。完成后，视图将只处理更改，并且速度非常快。
实际发生的情况
- 第一次运行修正视图时，我在状态窗口中看到进程，慢慢达到 100%。这大约需要 2 个小时。在此期间，所有 CPU 都被充分利用。
- 一旦进程达到 99%，它会在那里停留大约一个小时，然后消失。 CPU 利用率下降到只有一个 cpu。
- 当进程消失时，视图的数据文件会持续增长大约半小时到一个小时。 CPU 利用率接近 0%
- 索引文件突然停止增大。
如果我在到达状态 4) 时再次请求视图，则 3) 的特性将重新开始。我必须重复这个过程 5 到 50 次，直到我最终可以检索到视图值。
如果在第 1 阶段或第 2 阶段之前再次请求视图获取，它肯定会耗尽内存，我必须重新启动 CouchDB 服务。尽管我的数据库在只运行一项作业时很少使用超过 2 GB 的空间，而在通常的操作中却很少使用超过 4 GB 的空闲空间。
我尝试调整配置设置，添加更多内存，但似乎没有任何影响。
我的问题
是我误解了运行视图的概念还是我的设置有问题？ 如果这是意料之中的，我可以调整什么来减少重播次数吗？
上下文
我的文档非常大（1 到 20 MB）。它们包含的数据结构良好，它们通常是网络分析报告，并且会在关系数据库中存储为数 10k 行数据。
我的地图函数提取这些行。它将维度作为键数组返回。键数组有时会超过 20 列。大多数视图只有不到 10 列。
reduce 函数将聚合（求和）具有相同键的行中的所有值。指标存储在字典中，可能包含不同的键。 reduce 函数识别一个文档中缺失的键，并将它们添加到聚合中作为 0。
我在具有 2 个 CPU 和 8 GB 内存的 Windows Server 2008 R2 上使用 CouchDB 1.5.0。
视图是使用 couchjs 查询服务器以 javascript 编写的。
我的设计文档通常由几个视图组成，其中一个“_lib”视图不发出任何数据，但包含一个由实际视图访问的详尽函数库。
【问题讨论】：
-
您的数据模型是否有理由要求您的文档如此之大？ IE。这些行之间是否存在需要在您的视图中表示的关系？为什么不是每行一个文档？
-
你使用 javascript reduce 函数还是 erlang 函数？
-
文档很大，因为它们反映了来自源数据的实际文档，例如。 API 调用返回的 Omniture 或 Google Analytics 报告。
-
我的视图都是用 Javascript 编写的，每个设计文档都有一个空的“_lib”视图，该视图经过外部单元测试，并针对 V8 引擎下的性能进行了大量分析。实际的视图使用这个库视图，并且仅仅添加了一些配置数据，用于限制输出中预期的维度、指标和文档格式。
标签： couchdb