CouchDB延迟生成索引（Windows Server 2008 R2上的CouchDB 1.5.0）

我知道CouchDB将每个设计文档的源代码与索引文件的名称进行散列。每当我更改源代码时，都需要重新生成索引。CouchDB在第一次请求文档时执行此操作

我期望和希望发生的事情

每次我更改设计文档时，对视图的第一次调用都会比平时花费更长的时间，并且可能会超时。索引将继续建立。完成后，视图将只处理更改，并且速度非常快

实际发生的情况

第一次运行修改后的视图时，我在状态窗口中看到该过程，慢慢达到100%。这大约需要2个小时。在此期间，所有CPU都得到充分利用

一旦这个过程达到99%，它会在那里停留大约一个小时，然后消失。CPU利用率下降到只有一个CPU

当进程消失时，视图的数据文件将持续增长约半小时到一小时。CPU利用率接近0%

索引文件突然停止以增大大小 如果在达到状态4）时再次请求查看，则3）的特征将再次开始。我必须重复这个过程5到50次，直到我最终能够检索到视图值

如果视图get在第1或第2阶段被再次请求，它肯定会耗尽内存，我必须重新启动CouchDB服务。尽管我的数据库在运行一个作业时很少使用超过2GB的数据，而在通常的操作中使用超过4GB的空闲数据

我试图调整配置设置，增加更多内存，但似乎没有任何效果

我的问题

我是否误解了运行视图的概念，或者我的设置有问题？ 如果这是预期的，有什么我可以调整，以减少重新运行的次数

上下文

我的文档相当大（1到20兆字节）。它们包含的数据结构良好，通常是web分析报告，在关系数据库中存储为数10k行数据

我的map函数提取这些行。它将维度作为键数组返回。键数组有时超过20列。大多数视图只有不到10列

reduce函数将使用相同的键聚合（求和）行中的所有值。度量值存储在字典中，可能包含不同的键。reduce函数识别一个文档中缺少的键，并将它们作为0添加到聚合中

我在WindowsServer2008R2上使用CouchDB 1.5.0，内存为2CPUs和8GB

这些视图是使用couchjs查询服务器用javascript编写的

---

“我的设计”文档通常由多个视图组成，其中的“_lib”视图不发出任何数据，但包含由实际视图访问的详尽函数库

这是一个已知的问题，但只是以防万一：如果你有千兆字节的文档，你可以忘记reduce函数。只有这样才能足够快地工作。

可以设置为一个超低的值（对于示例，为1秒）。通过这种方式，您可以检测哪些文档需要很长时间才能编制索引，并优化映射功能以提高性能。

您的数据模型是否给出了要求文档如此大的原因？即，这些行之间是否存在需要在视图中表示的关系？为什么不是每行一个文档？您使用javascript reduce函数还是erlang函数？文档非常大，因为它们反映了源数据中的实际文档，例如API调用返回的Omniture或Google Analytics报告。我的视图都是用javascript编写的，每个设计文档都有一个空的“_lib”视图，该视图经过外部单元测试，并对V8引擎下的性能进行了详细分析。实际视图利用这个lib视图，只添加一些用于限制输出中预期的维度、度量和文档格式的配置数据。谢谢。是否有办法确定各个步骤需要多少执行时间，映射/减少/[任何其他值得一提的活动]？我的印象是，reducer运行时间不长，因为我也在禁用它的情况下运行了视图。多亏了，我们删除了用于调试某些数据导入的reduce代码，这将总体运行时间减少到30分钟（从2-3小时），并且我们不需要重新启动最后两个步骤。我对在V8中运行映射所需的时间有了一个很好的了解，因为实际代码被详尽地分析了。我将研究记录reduce调用，因为它们似乎是最耗时的。您可以尝试向map函数添加

log（'View start:'）

，

log（'View end:'）

调用。但是在实践中，这可能没有多大帮助，因为在将大文档传递到视图服务器的过程中，需要花费大量时间对其进行序列化/反序列化。但是，使用这种方法，您可以估计运行视图代码（X）需要多长时间。您还知道http请求总共需要多少时间（Y）。使用这些数字，您可以找到执行代码Z=（Y-X）/Y所花费的时间的百分比。这个数字将告诉您代码中的问题是否在couchdb中。另一个lifehack是将

os\u process\u limit

设置为一个非常低的值（示例为1秒）。通过这种方式，您可以检测哪些文档需要很长时间才能编制索引，并优化代码。