CouchDB slow List-Function

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)); 
} 

複数のドキュメントmap-functionにマッチしている場合は、リスト関数を使って処理するのに時間がかかります。制限要因はcouchjsビューサーバーです。最初に、map関数の結果をシリアル化しなければならない。その後、リスト関数が作業を行うことができる。

私が書いたように、少量のドキュメントでは処理時間が劇的ではなく、ドキュメントの量が増加するにつれてリスト関数による処理時間も増加するため、

結果をフォーマットする方法を改善するアイデアはありますか？ クライアントに作業をさせる方が良いですか？

Answer 1

_list機能を高速化するいくつかのトリックがあります。

1. リストとマップ関数を2つの異なるデザインドキュメントにして、異なるSpiderMonkeyインスタンスで実行できるようにします。
2. 大きなチャンク、数十または数百キロバイトで応答を送信します。最適なチャンクサイズを見つける：TTFBとメモリ消費の点で大きすぎるチャンクは悪く、小さなチャンクはSMとErlangの間のIOオーバーヘッドを生成します。
3. Storage-> Erlang-> JSのシリアライズ/デシリアライズのオーバーヘッドを最小限に抑えます。マップ関数がシリアル化されたJSONである文字列を生成し、リストfn内の各行のJSONを単純な文字列から解析します。 Erlangに渡すシンプルな構造であれば、Erlang側でそれを処理してSMに渡す時間が少なくなります。

キャッシュアプ​​ローチを使用することもできますが、自分が行っていることをはっきりと理解する必要があります。詳細を読むhere。

Answer 2

リスト機能は実行時に実行されます。つまり、処理時間はビューから返されるドキュメントの数に比例します。リスト機能を使用してブログの最後の20件の投稿を表示することはできますが、それを使用して100.000個のドキュメントを作成することはできません。マップ関数の中で何かを行う必要があります。あなたのところでは、リスト関数の中でやっている操作を実行するためにマップ関数を修正するか、あるいは文書を保存する前にそれらを実行します。