couchdb設定でreduce_limit = false configを設定しても構いませんか？

Question

map/reduceレビューを行っていますが、ビューを実行するたびにreduce_overflow_errorがあります。couchdb設定でreduce_limit = falseを設定していれば、動作しています。これを変更すると悪影響があるかどうかを知りたい設定をしますか？ありがとう

Answer 1

設定reduce_limit=trueは、削減の各段階でCouchDBが縮小出力のサイズを制御するように強制します。縮小ステップの文字列化されたJSON出力がとの2倍以上長い場合、CouchDBのクエリー・サーバーはエラーをスローします。 2つの数字と2つの数字の両方がハードコードされています。

64MbのRAMしか使用できないSpiderMonkeyインスタンス内でreduce関数が実行されるため、デフォルトで設定された制限はいくらか妥当に見えます。理論的には、減らす必要があります与えられたデータを爆破しないでください。

しかし実際の生活では、すべての場合に制限の下で飛行するのはかなり難しいです。 （再）削減ステップのチャンク数を制御することはできません。特定のチャンクの出力が文字数で2倍以上長くなっても、他のチャンクはかなり短くなっていますが、状況に応じて実行できることを意味します。この場合、reduce_limitが設定されていると、1つの不快なチャンクでも全体の削減が中断されます。

reduce_limitを設定しないと、レデューサーが受信したデータよりも多くのデータを出力することがあります。

一般的なケース - オブジェクトを配列に展開する。入力行として[[1,2,3...70], [5,6,7...], ...]のような配列のリストを受け取ったとします。 {key0:(sum of 0th elts), key1:(sum of 1st elts)...}のようにリストを集計したいとします。

CouchDBが1行または2行のチャンクを送信することを決定した場合、エラーが発生します。理由は簡単です - オブジェクトキーは結果の長さを計算することも考慮されます。

SpiderMonkeyのインスタンスは、リダクションステップまたは完全な削減を処理しようとすると、RAMオーバークォータを常に再起動/低下させるという悪影響があります。 SMを再起動すると、CPUとRAMが集中し、一般に数百ミリ秒かかります。