1

次のように構成されたドキュメントのコレクションがあるとします。

{ username: "jones",
    likes: 20,
    text: "Hello world!"
  }

さらに、構築しているアプリケーションが、ユーザーごとのいいねの総数に関する統計を表示する必要があると想定します。Mongodbのドキュメントは、次のようなMap/Reduce関数を使用してこれを実現できることを示しています。

function() {
    emit( this.username, {count: 1, likes: this.likes} );
  }

ただし、データベースに新しいドキュメントを挿入するたびに「いいね」カウンターをインクリメントする方が直感的です。これには、Map/Reduceのようにコレクション全体をトラバースする必要はありません。次回Map/Reduceプロセスが実行されるときではなく、すぐにカウンターを更新します。そして、アーキテクチャはより単純に見えます。

Map / Reduce関数がより良いソリューションである理由を誰かが答えで説明できますか？

4

2 に答える 2

1

MapReduce は、アドホックなライブ クエリ用には設計されていません。遅いです。これはバッチ処理メカニズムに近いため、提案された設計はパフォーマンス面ではるかに効率的です。

于 2012-10-05T23:03:20.937 に答える
1

MongoDB ドキュメントで提案されている MapReduce ソリューションは、より一般的なものになることを意図していると思います。つまり、各レコードstat(x)の関数に興味があり、データセットをセットアップした時点で興味があるとは知らなかった場合、MapReduce はそのような関数を集約する優れた事後的方法を提供します。レコード全体の統計。stat()xstat

for everyに常に関心があることがすでにわかっている場合は、適切と思われるだけの事前計算とストレージを必ず行ってください。stat(x)x

ただし、統計のインデックス作成と検索にかかる時間と、統計が必要になるたびに計算する時間との間には、ある程度のトレードオフがあると想像できます。データセットが巨大になった場合 (ここでの巨大さの適切な見積もりはわかりません)、理論的には、毎回 MapReduce で計算する方が有利になる可能性があります。

MapReduce がそのトレードオフを勝ち取るデータのサイズは途方もなく大きいと推測していますが、それでも計算後のデータでより多くのことをしたい場合は、実際にはより効率的ではないかもしれません。

于 2012-10-05T17:48:52.463 に答える