MongoDb/C＃同時読み取りパフォーマンスが悪い

Question

NoSQLソリューションをいくつかテストしていますが、主に読み取りパフォーマンスに焦点を当てています。今日はMongoDbの日でした。 テストマシンは、Quad Core Xeon @ 2.93GHzと8GBのRAMを搭載したVMです。

私は、データベースと1つのコレクションで〜100.000個のドキュメントでテストしています。 BSONの文書サイズはおよそ20KBくらいです。私が働いている

管理対象オブジェクトは、次のとおりです。

private class Job 
{ 
    public int Id { get; set; } 
    public string OrganizationName { get; set; } 
    public List<string> Categories { get; set; } 
    public List<string> Industries { get; set; } 
    public int Identifier { get; set; } 
    public string Description { get; set; } 
} 

テストプロセス：

-Create 100件のスレッド。

- すべてのスレッドを開始します。

- 各スレッドは、コレクションから20個のランダムなドキュメントを読み取ります。

ここで私が使用しているselectメソッドです：

private static void TestSelectWithCursor(object state) 
{ 
    resetEvent.WaitOne(); 

    MongoCollection jobs = (state as MongoCollection); 
    var q = jobs.AsQueryable<Job>(); 
    Random r = new Random(938432094); 
    List<int> ids = new List<int>(); 
    for (int i = 0; i != 20; ++i) 
    { 
     ids.Add(r.Next(1000, 100000)); 
    } 
    Stopwatch sw = Stopwatch.StartNew(); 
    var subset = from j in q 
       where j.Id.In(ids) 
       select j; 

    int count = 0; 
    foreach (Job job in subset) 
    { 
     count++; 
    } 
    Console.WriteLine("Retrieved {0} documents in {1} ms.", count, sw.ElapsedMilliseconds); 
    ThreadsCount++; 
} 

は「カウント++」のものはちょうど私がカーソルを取得した後に何かをやっているふりをするので、それを無視してください。

とにかく、私は読書の時間が非常に遅いと思うのです。これは典型的なテスト結果です。

> 100 threads created. 
> 
> Retrieved 20 documents in 272 ms. Retrieved 20 documents in 522 ms. 
> Retrieved 20 documents in 681 ms. Retrieved 20 documents in 732 ms. 
> Retrieved 20 documents in 769 ms. Retrieved 20 documents in 843 ms. 
> Retrieved 20 documents in 1038 ms. Retrieved 20 documents in 1139 ms. 
> Retrieved 20 documents in 1163 ms. Retrieved 20 documents in 1170 ms. 
> Retrieved 20 documents in 1206 ms. Retrieved 20 documents in 1243 ms. 
> Retrieved 20 documents in 1322 ms. Retrieved 20 documents in 1378 ms. 
> Retrieved 20 documents in 1463 ms. Retrieved 20 documents in 1507 ms. 
> Retrieved 20 documents in 1530 ms. Retrieved 20 documents in 1557 ms. 
> Retrieved 20 documents in 1567 ms. Retrieved 20 documents in 1617 ms. 
> Retrieved 20 documents in 1626 ms. Retrieved 20 documents in 1659 ms. 
> Retrieved 20 documents in 1666 ms. Retrieved 20 documents in 1687 ms. 
> Retrieved 20 documents in 1711 ms. Retrieved 20 documents in 1731 ms. 
> Retrieved 20 documents in 1763 ms. Retrieved 20 documents in 1839 ms. 
> Retrieved 20 documents in 1854 ms. Retrieved 20 documents in 1887 ms. 
> Retrieved 20 documents in 1906 ms. Retrieved 20 documents in 1946 ms. 
> Retrieved 20 documents in 1962 ms. Retrieved 20 documents in 1967 ms. 
> Retrieved 20 documents in 1969 ms. Retrieved 20 documents in 1977 ms. 
> Retrieved 20 documents in 1996 ms. Retrieved 20 documents in 2005 ms. 
> Retrieved 20 documents in 2009 ms. Retrieved 20 documents in 2025 ms. 
> Retrieved 20 documents in 2035 ms. Retrieved 20 documents in 2066 ms. 
> Retrieved 20 documents in 2093 ms. Retrieved 20 documents in 2111 ms. 
> Retrieved 20 documents in 2133 ms. Retrieved 20 documents in 2147 ms. 
> Retrieved 20 documents in 2150 ms. Retrieved 20 documents in 2152 ms. 
> Retrieved 20 documents in 2155 ms. Retrieved 20 documents in 2160 ms. 
> Retrieved 20 documents in 2166 ms. Retrieved 20 documents in 2196 ms. 
> Retrieved 20 documents in 2202 ms. Retrieved 20 documents in 2254 ms. 
> Retrieved 20 documents in 2256 ms. Retrieved 20 documents in 2262 ms. 
> Retrieved 20 documents in 2263 ms. Retrieved 20 documents in 2285 ms. 
> Retrieved 20 documents in 2326 ms. Retrieved 20 documents in 2336 ms. 
> Retrieved 20 documents in 2337 ms. Retrieved 20 documents in 2350 ms. 
> Retrieved 20 documents in 2372 ms. Retrieved 20 documents in 2384 ms. 
> Retrieved 20 documents in 2412 ms. Retrieved 20 documents in 2426 ms. 
> Retrieved 20 documents in 2457 ms. Retrieved 20 documents in 2473 ms. 
> Retrieved 20 documents in 2521 ms. Retrieved 20 documents in 2528 ms. 
> Retrieved 20 documents in 2604 ms. Retrieved 20 documents in 2659 ms. 
> Retrieved 20 documents in 2670 ms. Retrieved 20 documents in 2687 ms. 
> Retrieved 20 documents in 2961 ms. Retrieved 20 documents in 3234 ms. 
> Retrieved 20 documents in 3434 ms. Retrieved 20 documents in 3440 ms. 
> Retrieved 20 documents in 3452 ms. Retrieved 20 documents in 3466 ms. 
> Retrieved 20 documents in 3502 ms. Retrieved 20 documents in 3524 ms. 
> Retrieved 20 documents in 3561 ms. Retrieved 20 documents in 3611 ms. 
> Retrieved 20 documents in 3652 ms. Retrieved 20 documents in 3655 ms. 
> Retrieved 20 documents in 3666 ms. Retrieved 20 documents in 3711 ms. 
> Retrieved 20 documents in 3742 ms. Retrieved 20 documents in 3821 ms. 
> Retrieved 20 documents in 3850 ms. Retrieved 20 documents in 4020 ms. 
> Retrieved 20 documents in 5143 ms. Retrieved 20 documents in 6607 ms. 
> Retrieved 20 documents in 6630 ms. Retrieved 20 documents in 6633 ms. 
> Retrieved 20 documents in 6637 ms. Retrieved 20 documents in 6639 ms. 
> Retrieved 20 documents in 6801 ms. Retrieved 20 documents in 9302 ms. 

結論は、これよりもはるかに高速な読み込み時間を期待していたことです。私はまだ私が何か間違っていると思っています。 私が今提供できるその他の情報は不明ですが、何かが紛失した場合はお知らせください。私も含め、それは、テストで実行されるクエリのいずれかに）（トレースを説明するのに役立つだろうと期待しています

：

{ 
     "cursor" : "BtreeCursor _id_ multi", 
     "nscanned" : 39, 
     "nscannedObjects" : 20, 
     "n" : 20, 
     "millis" : 0, 
     "nYields" : 0, 
     "nChunkSkips" : 0, 
     "isMultiKey" : false, 
     "indexOnly" : false, 
     "indexBounds" : { 
       "_id" : [ 
         [ 
           3276, 
           3276 
         ], 
         [ 
           8257, 
           8257 
         ], 
         [ 
           11189, 
           11189 
         ], 
         [ 
           21779, 
           21779 
         ], 
         [ 
           22293, 
           22293 
         ], 
         [ 
           23376, 
           23376 
         ], 
         [ 
           28656, 
           28656 
         ], 
         [ 
           29557, 
           29557 
         ], 
         [ 
           32160, 
           32160 
         ], 
         [ 
           34833, 
           34833 
         ], 
         [ 
           35922, 
           35922 
         ], 
         [ 
           39141, 
           39141 
         ], 
         [ 
           49094, 
           49094 
         ], 
         [ 
           54554, 
           54554 
         ], 
         [ 
           67684, 
           67684 
         ], 
         [ 
           76384, 
           76384 
         ], 
         [ 
           85612, 
           85612 
         ], 
         [ 
           85838, 
           85838 
         ], 
         [ 
           91634, 
           91634 
         ], 
         [ 
           99891, 
           99891 
         ] 
       ] 
     } 
} 

あなたがどんな考えを持っている場合は、その後、私はよそれを読むのが最も心配です。 ありがとうございます！

マルセル

Answer 1

Iは「中」（ジェネリック修飾子）は_idインデックスの利用効率をバイパスし、WHERE句を確認するために、各文書の完全な抽出と順次走査を強制されると思われます。乱数がかなり分散されているとすれば、私の推測では、各スレッド/クエリは本質的に完全なデータベースをスキャンしているということです。

私はいくつかのことを試してみることをお勧めします。 （1）クエリを個別に20のドキュメントのそれぞれについて、個々の単一のIDで （2）はMongoCursorを使用して検討し

祝福、

-Gary

クエリのインデックスの使用に関する情報を取得するために説明を使用

PSスレッド時間は、作業中にスレッドスケジューリングの効果があることを示しているようです。