1

以前の質問 (大規模な分析サーバーをすばやく構築する方法は? ) に関して、分析データを MongoDB にフィードしています。すべてのイベント (メタデータの束) は、ビュー コレクションで独自のドキュメントを取得します。

しかし、ここで次の障害にぶつかりました。挿入が完了し、分析データが流れているので、そのデータに対して実行するための抵抗が最も少ないパスは何でしょうか? そのデータがシャーディングされると、特定のビューが mapReduces を実行するという考え方です (たとえば、1 か月前の特定の ID を持つすべてのイベント)。

だから、私の質問は次のとおりです。私はMongoDBにまったく慣れていないので、これらのmapReducesをできるだけ速く取得するために必要な手順は何ですか? 生データを別の方法で構造化する必要がありますか、それともイベントごとに 1 つのドキュメントが正しいですか? 1 日に何百万もの挿入を取得するデータセットに対して実行するときに、物事の流れを速くするためにできる Mongo 固有のトリックはありますか?

テクノロジー スタックをできるだけシンプルに保ちたいので (Node.js + MongoDB)、追加のテクノロジー (Hadoop など) を導入せずに処理できるようにしたいと考えています。

イベントの文書例:

{
    id: 'abc',
    ip: '1.1.1.1',
    type: 'event1',
    timestamp: 1234,
    metadata: {
        client: 'client1'
    }
}

すべての主要な集計は ID 中心であり、前述の ID のイベントを分析します。最も使用されるのは、先月の前述の ID を持つすべてのイベントを取得することです。マイナーな集計では、メタデータ (client1 と client2 の使用率など) を使用して物事をグループ化します。すべての集計はシステムで定義されるため、少なくとも現時点では、ユーザーが自分で集計を設定することはできません。したがって、私が理解している限り、アグリゲーションの大部分は ID 中心になるため、シャーディングは ID を介して行う必要がありますか? また、これは、Mongo が最新のものをメモリに保持し、オーバーフローをディスクにダンプするだけであるため、特定の ID の最新のイベントが常にメモリにあることを意味するはずです。

また、リアルタイムである必要はありません。ただし、それはいいことです。:P

編集：サンプルデータを追加

編集：タイトルは「...ページごと」ではなく「...日ごと」である必要がありました+集計セットに関する詳細仕様

4

3 に答える 3

2

mapreduce をできるだけ速く取得する手順:

  • データを最適化して、可能な限り多くのインメモリを保持します。ディスクに移動すると、すべてが「殺されます」（非常に遅くなります）！(mapreduce を使用しないことをお勧めする理由については、以下のコメントを参照してください!)

生データを別の方法で構造化する必要がありますか?

  • 集計するディメンションの数が既知であり、制限されている場合、挿入時に集計を保存してインクリメントしないのはなぜですか? それを照会するのではなく？(明らかに、これにより挿​​入時の負荷/処理が増加します)パターンの事前集計に関する MongoDB ドキュメント

1 日に何百万もの挿入を取得するデータセットに対して実行するときに、物事の流れを速くするためにできる Mongo 固有のトリックはありますか?

  • シャーディングは書き込みをスケーリングします。1 つのノードがロードされている場合は、別のノードを追加します。バランスの取れた書き込みを可能にする適切なシャード キーを選択します (1 つのシャードがすべての書き込みを取得するわけではありません)。

その他の考慮事項:

MapReduce は遅く、オンライン操作には適していません。そのバッチ処理フレームワーク。また、JS エンジンと同様にシングルスレッドです。また、JS との間の変換にもオーバーヘッドがあります。私は集約フレームワークを使用してこれらの制限を回避しましたが、mongodb mapreduce コマンドを使用するよりもはるかに高速でスケーラブルであることがわかりました。

mapreduce または集計フレームワーク操作を実行する場合は、アクティブなデータセットをメモリ内でできるだけ多く取得するようにしてください。ディスクに移動すると、どちらのパフォーマンスも低下します。適切にバランスの取れたインデックスに関する mongodb のメモは、ワーキング セットをメモリ内に保持するために非常に貴重であることがわかりました。

于 2012-10-30T06:23:47.740 に答える
1

私自身の味で他の答えを拡張するために; map reduceは、多くの処理にとって確実なオプションです。間違いなく、Map Reduceを完全に実行すると、分析の重要なコアになります。

最良の種類のMRは、特定のイベントや人に関するアーカイブ統計などを構築して、データベース全体のサイズと、古くてほこりっぽいデータをすべて引き出すワーキングセットのサイズを縮小するインクリメンタルなものです。

リアルタイムの使用法については、（GoogleユーザーグループのMongoDBの初期の主題に関する多くの議論から）データを事前に集計して、次のような単純な線形クエリでdb.some_preaggregated_data.find({date: {$gt, $lt}})結果が得られるようにするのが最善の方法であることがわかりました。これにより、ワーキングセットのサイズは言うまでもなく、データのシャーディングとデータ全体の範囲が簡単になります。全体的に、はるかにパフォーマンスの高い操作を提供します。

私は1つのことをお勧めします：-これがリアルタイムで完全にスケーリングすることを本当に期待している場合は、集約フレームワークや複雑なクエリに入らないでください。それは、そのような非常に広大なデータセットに対してあまりにも多くの作業を作成し始めるでしょう。find()通常、大きなテーブル形式全体のニーズを満たすには、単純なクエリを使用して、完全なロック、ワーキングセットなどが必要になります。

于 2012-10-30T15:28:21.940 に答える