0

Mongo インスタンスに約 700000 個のドキュメントを保存しました。2GBのVPSで動作するため、究極の速度は期待できません. 私はNodeJSとMongooseを使って仕事をしています。

ドキュメントは次のような形式です。

  • 第 1 レベルの鍵
  • 第 1 レベルの鍵
    • 2 レベル キー A
      • 3段階キーA
    • 2 レベル キー B
      • 3 レベル キー 1
        • 4レベルキーA
        • 4レベルキーB
        • 4 レベル キー C
        • ...
      • 3 レベル キー 2
      • 第 3 レベル キー 3
      • ...

avgObjSize は 3191 であるため、最大でも最小でもありません。基本的に短いテキストのリストです。

したがって、すべての第 3 レベル キーの第 4 レベル キー C にあるすべての値に対して特定の値を一致させる必要があります。注意が必要なのは、これらの一致値の XX% が第 4 レベルのキー C で見つかった場合にのみ、ドキュメントが返されることです。

すべてがマップ関数で発生し、前処理されたオブジェクトのみを出力するようにMapReduceを試しました. $all などの Mongo 独自の関数を使用してみました。

問題は、すべてがめちゃくちゃ遅いことです。つまり、1 秒あたり 500 ドキュメント未満です。コレクションは成長するだけなので、私の質問は、Mongo を適切に使用する方法が不足しているだけなのか、それともこのようなタスクで遅いのでしょうか? 以前の質問を読んだところ、Mongo の MR が遅いという問題がいくつかありましたが、これは遅くはありません。これはクローリングです。

4

2 に答える 2

0

avgObjSizeは3191です

したがって、3.1MB*700,000は約2.1GBです。つまり、質問の内容から判断すると、おそらくご存知のとおり、ワーキングセットが現在のRAM容量を超える可能性があります。

ここで考慮すべきもう1つのポイントは、各ドキュメントにかなりの量である3.1MBをRAMにロードしていることです。

また、JSエンジンがJSであり、MongoDBのネイティブC ++コーディングではなく、もちろんシングルスレッドであるため、速度がすでに低下していることも考慮する必要があります。

問題は、すべてがめちゃくちゃ遅いということです。つまり、1秒あたり500未満のドキュメントのようです。

実際、各3レベルキーの4レベルキーがそれぞれのキーのどこに存在するかも探しています。それはあなたの結果に到達しようとしているかなりの量のループと回避です。

ほとんどの場合、再帰の問題に苦しんでいます。

ここにリアクが来る

それが役立つとは思えませんが、このクエリはどこに行っても遅くなります。代わりに、スケーラブルなテクノロジーを設計する場合と同様に、アクセッションパターンに基づいてスキーマを設計する方法を検討する必要があります。

于 2013-03-07T11:54:12.637 に答える
0

あなたの構造を見て、文書をより効率的な形式に再構築することをお勧めします。第 4 レベルのキーを使用したマッチングは遅くなることが予想されます。それらを上に移動するか、独自のドキュメントにします。

于 2013-03-07T06:42:20.757 に答える