CouchDB 慢列表函数

Question

总的来说我知道问题出在哪里，但我不知道如何解决。

我有一个简单的映射函数：

function(doc) {
   if(doc.Type === 'Mission'){
      for(var i in doc.Sections){
         emit(doc._id, {_id:doc.Sections[i].id});
      }
   }
}

基于映射函数的结果，我使用列表函数进行一些格式化：

function(head,req){

   var result=[];
   var row;

   topo = require('lib/topojson');

   while(row=getRow()){
      if (row !== null) {
         if(row.value._id){
            row.doc.Geometry.properties.IDs.Section_ID = row.value._id;
         }else{
            row.doc.Geometry.properties.IDs.Section_ID = row.value;
         }

         geojson = {
            type: "Feature",
            geometry: row.doc.Geometry.geometry,
            properties: row.doc.Geometry.properties
         };

         result.push(geojson);
      }else{
         send(JSON.stringify({
            status_code: 404
         }));
      }

   }
   send(JSON.stringify(result));
}

与映射函数匹配的文档越多，使用列表函数进行处理所需的时间就越长。限制因素是 couchjs 视图服务器。首先必须序列化 map-function 的结果，然后 list-function 才能完成这项工作。

如我所写，对于少量文档，处理时间并不显着，但随着文档数量的增加，列表函数处理的时间也会增加。

有人有想法改进我格式化结果的方式吗？是不是让客户来做比较好？

Answer 1

列表函数在运行时执行，这意味着处理时间与视图的文档数成正比returns。您可以使用列表功能来显示博客的最后 20 篇文章，但不能使用它来详细说明 100,000 个文档。这是必须在 map 函数中完成的事情。在您的位置，我会修改 map 函数以执行您在 list 函数中执行的操作，或者更好的是，我会在保存文档之前执行它们。

Answer 2

有几个技巧可以加速 _list 函数。

让您的列表和地图功能存在于两个不同的设计文档中，以确保它们运行在不同的 SpiderMonkey 实例中。
以数十甚至数百千字节的大块发送响应。找出最佳块大小：就 TTFB 和内存消耗而言，太大的块是不好的，小块会在 SM 和 Erlang 之间产生 IO 开销。
最小化存储->Erlang->JS 的开销serialize/deserialize。使您的 map 函数发出序列化 JSON 的字符串，并从纯字符串解析列表 fn 中每一行的 JSON。传递给 Erlang 的结构越简单，在 Erlang 端处理它并传递给 SM 的时间就越少。

你也可以使用缓存的方式，但是你必须清楚你在做什么。阅读更多详情 here。

CouchDB 慢列表函数

CouchDB slow List-Function

couchdb