39

私は、MongoDB インスタンスに 100,000,000 個のサンプル レコードをロードすることを目的とした、Scala で書かれた小さなスクリプトを持っています。アイデアは、DB をすべてロードしてから、いくつかのパフォーマンス テストを行うことです (必要に応じて調整/再ロードします)。

問題は、100,000 レコードあたりの読み込み時間がかなり直線的に増加することです。ロード プロセスの開始時には、これらのレコードをロードするのに 4 秒しかかかりませんでした。現在、約 6,000,000 レコードで、同じ量 (100,000) をロードするのに 300 ～ 400 秒かかります! それは2桁遅いです！クエリはまだきびきびしていますが、この速度では、必要な量のデータをロードすることはできません。

すべてのレコード (すべて 100,000,000!) を含むファイルを書き出してから、mongoimportを使用してすべてをインポートすると、これはより速く動作しますか? それとも、私の期待が高すぎて、本来の処理範囲を超えて DB を使用しているのでしょうか?

何かご意見は？ありがとう！

これが私のスクリプトです：

import java.util.Date

import com.mongodb.casbah.Imports._
import com.mongodb.casbah.commons.MongoDBObject

object MongoPopulateTest {
  val ONE_HUNDRED_THOUSAND = 100000
  val ONE_MILLION          = ONE_HUNDRED_THOUSAND * 10

  val random     = new scala.util.Random(12345)
  val connection = MongoConnection()
  val db         = connection("mongoVolumeTest")
  val collection = db("testData")

  val INDEX_KEYS = List("A", "G", "E", "F")

  def main(args: Array[String]) {
    populateCoacs(ONE_MILLION * 100)
  }

  def populateCoacs(count: Int) {
    println("Creating indexes: " + INDEX_KEYS.mkString(", "))
    INDEX_KEYS.map(key => collection.ensureIndex(MongoDBObject(key -> 1)))

    println("Adding " + count + " records to DB.")

    val start     = (new Date()).getTime()
    var lastBatch = start

    for(i <- 0 until count) {
      collection.save(makeCoac())
      if(i % 100000 == 0 && i != 0) {
        println(i + ": " + (((new Date()).getTime() - lastBatch) / 1000.0) + " seconds (" +  (new Date()).toString() + ")")
        lastBatch = (new Date()).getTime()
      }
    }

    val elapsedSeconds = ((new Date).getTime() - start) / 1000

    println("Done. " + count + " COAC rows inserted in " + elapsedSeconds + " seconds.")
  }

  def makeCoac(): MongoDBObject = {
    MongoDBObject(
      "A" -> random.nextPrintableChar().toString(),
      "B" -> scala.math.abs(random.nextInt()),
      "C" -> makeRandomPrintableString(50),
      "D" -> (if(random.nextBoolean()) { "Cd" } else { "Cc" }),
      "E" -> makeRandomPrintableString(15),
      "F" -> makeRandomPrintableString(15),
      "G" -> scala.math.abs(random.nextInt()),
      "H" -> random.nextBoolean(),
      "I" -> (if(random.nextBoolean()) { 41 } else { 31 }),
      "J" -> (if(random.nextBoolean()) { "A" } else { "B" }),
      "K" -> random.nextFloat(),
      "L" -> makeRandomPrintableString(15),
      "M" -> makeRandomPrintableString(15),
      "N" -> scala.math.abs(random.nextInt()),
      "O" -> random.nextFloat(),
      "P" -> (if(random.nextBoolean()) { "USD" } else { "GBP" }),
      "Q" -> (if(random.nextBoolean()) { "PROCESSED" } else { "UNPROCESSED" }),
      "R" -> scala.math.abs(random.nextInt())
    )
  }

  def makeRandomPrintableString(length: Int): String = {
    var result = ""
    for(i <- 0 until length) {
      result += random.nextPrintableChar().toString()
    }
    result
  }
}

私のスクリプトからの出力は次のとおりです。

Creating indexes: A, G, E, F
Adding 100000000 records to DB.
100000: 4.456 seconds (Thu Jul 21 15:18:57 EDT 2011)
200000: 4.155 seconds (Thu Jul 21 15:19:01 EDT 2011)
300000: 4.284 seconds (Thu Jul 21 15:19:05 EDT 2011)
400000: 4.32 seconds (Thu Jul 21 15:19:10 EDT 2011)
500000: 4.597 seconds (Thu Jul 21 15:19:14 EDT 2011)
600000: 4.412 seconds (Thu Jul 21 15:19:19 EDT 2011)
700000: 4.435 seconds (Thu Jul 21 15:19:23 EDT 2011)
800000: 5.919 seconds (Thu Jul 21 15:19:29 EDT 2011)
900000: 4.517 seconds (Thu Jul 21 15:19:33 EDT 2011)
1000000: 4.483 seconds (Thu Jul 21 15:19:38 EDT 2011)
1100000: 4.78 seconds (Thu Jul 21 15:19:43 EDT 2011)
1200000: 9.643 seconds (Thu Jul 21 15:19:52 EDT 2011)
1300000: 25.479 seconds (Thu Jul 21 15:20:18 EDT 2011)
1400000: 30.028 seconds (Thu Jul 21 15:20:48 EDT 2011)
1500000: 24.531 seconds (Thu Jul 21 15:21:12 EDT 2011)
1600000: 18.562 seconds (Thu Jul 21 15:21:31 EDT 2011)
1700000: 28.48 seconds (Thu Jul 21 15:21:59 EDT 2011)
1800000: 29.127 seconds (Thu Jul 21 15:22:29 EDT 2011)
1900000: 25.814 seconds (Thu Jul 21 15:22:54 EDT 2011)
2000000: 16.658 seconds (Thu Jul 21 15:23:11 EDT 2011)
2100000: 24.564 seconds (Thu Jul 21 15:23:36 EDT 2011)
2200000: 32.542 seconds (Thu Jul 21 15:24:08 EDT 2011)
2300000: 30.378 seconds (Thu Jul 21 15:24:39 EDT 2011)
2400000: 21.188 seconds (Thu Jul 21 15:25:00 EDT 2011)
2500000: 23.923 seconds (Thu Jul 21 15:25:24 EDT 2011)
2600000: 46.077 seconds (Thu Jul 21 15:26:10 EDT 2011)
2700000: 104.434 seconds (Thu Jul 21 15:27:54 EDT 2011)
2800000: 23.344 seconds (Thu Jul 21 15:28:17 EDT 2011)
2900000: 17.206 seconds (Thu Jul 21 15:28:35 EDT 2011)
3000000: 19.15 seconds (Thu Jul 21 15:28:54 EDT 2011)
3100000: 14.488 seconds (Thu Jul 21 15:29:08 EDT 2011)
3200000: 20.916 seconds (Thu Jul 21 15:29:29 EDT 2011)
3300000: 69.93 seconds (Thu Jul 21 15:30:39 EDT 2011)
3400000: 81.178 seconds (Thu Jul 21 15:32:00 EDT 2011)
3500000: 93.058 seconds (Thu Jul 21 15:33:33 EDT 2011)
3600000: 168.613 seconds (Thu Jul 21 15:36:22 EDT 2011)
3700000: 189.917 seconds (Thu Jul 21 15:39:32 EDT 2011)
3800000: 200.971 seconds (Thu Jul 21 15:42:53 EDT 2011)
3900000: 207.728 seconds (Thu Jul 21 15:46:21 EDT 2011)
4000000: 213.778 seconds (Thu Jul 21 15:49:54 EDT 2011)
4100000: 219.32 seconds (Thu Jul 21 15:53:34 EDT 2011)
4200000: 241.545 seconds (Thu Jul 21 15:57:35 EDT 2011)
4300000: 193.555 seconds (Thu Jul 21 16:00:49 EDT 2011)
4400000: 190.949 seconds (Thu Jul 21 16:04:00 EDT 2011)
4500000: 184.433 seconds (Thu Jul 21 16:07:04 EDT 2011)
4600000: 231.709 seconds (Thu Jul 21 16:10:56 EDT 2011)
4700000: 243.0 seconds (Thu Jul 21 16:14:59 EDT 2011)
4800000: 310.156 seconds (Thu Jul 21 16:20:09 EDT 2011)
4900000: 318.421 seconds (Thu Jul 21 16:25:28 EDT 2011)
5000000: 378.112 seconds (Thu Jul 21 16:31:46 EDT 2011)
5100000: 265.648 seconds (Thu Jul 21 16:36:11 EDT 2011)
5200000: 295.086 seconds (Thu Jul 21 16:41:06 EDT 2011)
5300000: 297.678 seconds (Thu Jul 21 16:46:04 EDT 2011)
5400000: 329.256 seconds (Thu Jul 21 16:51:33 EDT 2011)
5500000: 336.571 seconds (Thu Jul 21 16:57:10 EDT 2011)
5600000: 398.64 seconds (Thu Jul 21 17:03:49 EDT 2011)
5700000: 351.158 seconds (Thu Jul 21 17:09:40 EDT 2011)
5800000: 410.561 seconds (Thu Jul 21 17:16:30 EDT 2011)
5900000: 689.369 seconds (Thu Jul 21 17:28:00 EDT 2011)
4

4 に答える 4

53

いくつかのヒント ：

  1. 挿入はオーバーヘッドであるインデックスを変更するため、挿入する前にコレクションにインデックスを付けないでください。すべてを挿入してから、 index を作成します。

  2. "save" の代わりに、1 回の操作で多くのレコードを挿入できるmongoDB "batchinsert" を使用します。したがって、バッチごとに約 5000 のドキュメントが挿入されます。顕著なパフォーマンスの向上が見られます。

    insert hereのメソッド#2を参照してください。単一のドキュメントではなく、挿入するドキュメントの配列を取ります。このスレッドの議論も参照してください

    さらにベンチマークを行いたい場合は、

  3. これは単なる推測です。すべてのデータを格納するために、あらかじめ定義された大きなサイズの制限付きコレクションを使用してみてください。インデックスのない上限付きコレクションは、挿入パフォーマンスが非常に優れています。

于 2011-07-22T07:28:16.243 に答える
6

私も同じことをしました。私の知る限り、それはインデックス値のランダム性に帰着します。新しいドキュメントが挿入されるたびに、基礎となるすべてのインデックスも更新する必要があることは明らかです。これらのインデックスには、シーケンシャルではなくランダムな値を挿入するため、常にインデックス全体にアクセスして、新しい値を配置する場所を見つけます。

これは、すべてのインデックスがメモリ内に適切に配置されている場合は最初は問題ありませんが、インデックスが大きくなりすぎるとすぐに、インデックスの挿入を行うためにディスクをヒットし始める必要があります。そうすると、ディスクがスラッシングを開始し、書き込みパフォーマンスが低下します。

データをロードしているときに、使用可能なメモリと比較db.collection.totalIndexSize()してみてください。おそらくこれが発生することがわかります。

最善の策は、データをロードした後にインデックスを作成することです。ただし、ランダムな値（GUID、ハッシュなど）を含む必要な_idインデックスの場合、これでも問題は解決しません。その場合、シャーディングまたはRAMの追加を検討するのが最善の方法です。

于 2011-07-22T07:19:00.013 に答える
4

私が自分のプロジェクトで行ったことは、マルチスレッドを少し追加することでした (プロジェクトは C# ですが、コードが一目瞭然であることを願っています)。必要な数のスレッドで遊んだ後、スレッド数をコア数に設定するとパフォーマンスがわずかに向上することがわかりました (10-20%) が、このブーストはハードウェア固有のものであると思います。コードは次のとおりです。

    public virtual void SaveBatch(IEnumerable<object> entities)
    {
        if (entities == null)
            throw new ArgumentNullException("entities");

        _repository.SaveBatch(entities);
    }


    public void ParallelSaveBatch(IEnumerable<IEnumerable<object>> batchPortions)
    {
        if (batchPortions == null)
            throw new ArgumentNullException("batchPortions");
        var po = new ParallelOptions
                 {
                     MaxDegreeOfParallelism = Environment.ProcessorCount
                 };
        Parallel.ForEach(batchPortions, po, SaveBatch);
    }
于 2011-10-21T09:34:53.547 に答える
0

もう 1 つの方法は、TokuMXを試すことです。彼らはフラクタル インデックスを使用しているため、データベースが大きくなっても時間の経過とともに速度が低下しません。

TokuMX は、MongoDB の今後のバージョンにカスタム ストレージ ドライバーとして含まれる予定です。

現在のバージョンの MongoDB は Linux で動作します。私はVagrantを使用して、Windows ですぐに稼働するようになりました。

于 2015-01-03T13:00:07.377 に答える