私はむしろ尋ねたいですmapreduceが適切な選択ではない場合？意図したとおりに使用していれば、不利になることはないと思います。そうは言っても、mapreduceが適切な選択ではない場合があります：
- リアルタイム処理中。
- それはそうではありません常に MRプログラムとしてすべてを実装するのは非常に簡単です。
- 中間プロセスが相互に通信する必要がある場合（ジョブは分離して実行されます）。
- 処理で大量のデータをネットワーク経由でシャッフルする必要がある場合。
- ストリーミングデータを処理する必要がある場合。 MRはバッチプロセスすでに持っている膨大な量のデータに最適です。
- スタンドアロンシステムで目的の結果が得られる場合。分散システムと比較して、スタンドアロンシステムを構成および管理する方が明らかに苦痛が少ないです。
- [〜＃〜] oltp [〜＃〜]ニーズがある場合。 MRは、多数の短いオンライントランザクションには適していません。
他にもいくつかの場合があります。しかし、ここで重要なことは、それをどれだけうまく使っているかということです。たとえば、MRジョブが数ミリ秒で結果を出すことを期待することはできません。あなたもそれをその不利な点として数えることはできません。間違った場所で使用しているだけです。そして、それはどのテクノロジーにも当てはまります、IMHO。簡単に言えば、行動する前によく考えてください。
それでも必要な場合は、mapreduceの欠点として上記の点を考慮することができます:)
HTH
MapReduceがうまく機能しないいくつかのユースケースを次に示します。
- 迅速な対応が必要な場合。例えば<数秒と言う（代わりにストリーム処理、CEPなどを使用）
- グラフの処理
- 複雑なアルゴリズム（例： SVMのようないくつかの機械学習アルゴリズム、および13のdrawfsも参照してください（並列コンピューティング研究の展望：バークレーからの眺め）
- 反復-データを何度も処理する必要がある場合。例えばKMeans-Sparkを使用する
- マップフェーズで生成されるキーが多すぎる場合。その後、並べ替えは永遠にかかります。
- 複雑な条件で2つの大きなデータセットを結合する（等しい場合はハッシュなどで処理できます）
- ステートフルオペレーション-例：ステートマシンのカスケードタスクを次々に評価します。Hiveを使用すると、Bigが役立つ場合がありますが、データの再読み取りと解析に多くのオーバーヘッドが発生します。
- Map/reduce/Key/valueパターンで実現するには、Joins、Filterなどの簡単な操作を再考/書き直す必要があります
- MapReduceは、ジョブを並列化できることを前提としています。ただし、すべてのデータ処理ジョブに当てはまるとは限りません。
- これはJavaと密接に関連しています。もちろん、レスキュー用のPigとHiveがありますが、柔軟性が失われます。
まず第一に、それはマップ出力をストリーミングします、それをメモリに保持することが可能であれば、これはより効率的です。私はもともとMPIを使用してアルゴリズムをデプロイしましたが、スケールアップすると一部のノードがスワッピングを開始したため、移行を行いました。
Namenodeはメタデータを追跡します分散ファイルシステム内のすべてのファイル。私はHadoopの本（Hadoopの動作中）を読んでいますが、Yahooはメタデータをファイルあたり約600バイトと推定していると述べています。これは、ファイルが多すぎると、Namenodeで問題が発生する可能性があることを意味します。
ストリーミングAPIを使用したくない場合は、Java言語でプログラムを作成する必要があります。たとえば、C++からの翻訳を行いました。これにはいくつかの副作用があります。たとえば、JavaはCに比べて文字列のオーバーヘッドが大きいです。私のソフトウェアはすべて文字列に関するものなので、これはある種の欠点です。
正直なところ、不利な点を見つけるのは本当に難しいと思いました。 mapreduceが解決した問題は、mapreduceが導入した問題よりもはるかに大きかった。 このリストは完全ではありません、最初のいくつかのコメントです。明らかに、それはビッグデータに向けられていることを覚えておく必要があり、それが最高のパフォーマンスを発揮する場所です。独自の特性を持つ他の配布フレームワークがたくさんあります。