8

私は CouchDB で Map Reduce をいじっています。一部の例では、map reduce 関数内の重いロジックを示しています。ある特定のケースでは、マップ内で for ループを実行していました。

選択したドキュメントを出力する前に、可能なすべてのドキュメントで map reduce を実行していますか?

もしそうなら、map reduce 関数内であらゆる種類の反復処理を実行すると、処理負荷が少なくとも 1 桁増加することを意味すると思います。

基本的に、それは次の質問に要約されます: map reduce 内で実行できるロジックの量は、不当に高価なクエリになる前ですか?

4

2 に答える 2

8

CouchDB map-reduce では、多くの高価な処理が許容されます。

CouchDB ビュー (map-reduce) は、CREATE INDEX実際よりも似ていますSELECT FROM

具体的には、CouchDB は、map 関数がドキュメントごとに 1回だけ実行されることを保証します。(まあ、実際にはドキュメントの変更ごとに 1 回です。) それが「反復的な map-reduce」です。

したがって、10,000 個のドキュメントがあり、それぞれの処理に 1かかるとします (これは、私がこれまでに見たことがないほどの速さです)。ビューを完全に構築するには、10,000 秒または 2.8 時間かかります。ただし、ビューが完成すると、任意の行 ( ?key=...) または行スライス ( ?startkey=...&endkey=...) をクエリすると、ドキュメントを直接クエリするのと同じ時間がかかります。文書数の検索時間は O(log n) です。

つまり、マップの実行にドキュメントあたり 1 秒かかっても、結果を取得するのに数ミリ秒かかります。(もちろん、ビューは実際にはインデックスであるため、最初に作成する必要があります。)

于 2012-04-07T05:32:07.293 に答える
2

dbのクエリは、ドキュメントのmap/reduceからの無関係なアクティビティです。したがって、クエリコストはmap/reduceの複雑さの影響を受けません。

couchdbでは、インデックスをクエリしています。これは、クエリ速度に最適化された形式のデータのコピーであることを意味します。クエリは、SQLのテーブルスキャンとは異なります。レコードをループしません。

では、このインデックスをどのように作成しますか?これは、マップ関数を介して行われます。map関数は、キーと値を発行します。キーはインデックスに入れられます。あなたが言及するいくつかの複雑なマップ関数は、ループして多くのキーと値を出力する可能性があります。Couchdbはスマートで、必要な場合にのみ、通常は作成、更新、削除時にドキュメントを実行します。これがインクリメンタルmap/reduceである理由です。

ご覧のとおり、複雑なマップ関数は、作成、更新、および削除の速度に影響を与える可能性があります。ただし、couchdbは、インデックスをクエリするときにデータがどの程度古くなるかを指定できるという点で優れています。

于 2012-04-07T05:42:03.857 に答える