如何使用Scala將1億條記錄加載到MongoDB中進行性能測試？

我有一個寫在Scala中的小腳本，用於加載MongoDB實例，最多有100,000,000個樣本記錄。這個想法是讓數據庫全部加載，然後進行一些性能測試（並在必要時調整/重新加載）。如何使用Scala將1億條記錄加載到MongoDB中進行性能測試？

問題是，每100,000條記錄的加載時間幾乎線性增加。在我的加載過程開始時，只需要4秒就可以加載這些記錄。現在，在近6,000,000條記錄中，加載相同數量（100,000）需要300到400秒！這慢了兩個數量級！查詢仍然很快，但以這樣的速度，我永遠無法加載我想要的數據量。

如果我用我的所有記錄（全部100,000,000！）寫出一個文件，然後用mongoimport來導入整個文件，這樣會更快嗎？或者我的期望值太高，我使用的數據庫超出了它應該處理的範圍？

有什麼想法？謝謝！

這裏是我的腳本：

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)

來源

2011-07-21 Mike Cialowicz

您的數據至少應該使用8 GB的內存。即使該指數應該至少需要半個千兆字節。你確定數據庫可以裝入RAM嗎？我不是任何方式的MongoDB專家，但我會認爲它可能因交換而變得緩慢。 – Madoc

嘗試在*插入數據後添加索引*，這應該會提高插入性能。 – pingw33n

一些提示：

做插入，如插入修改這是一個開銷索引之前不會索引您的收藏。插入一切，然後創建索引。
而不是「保存」，使用mongoDB「batchinsert」它可以在1操作中插入許多記錄。因此每批次大約有5000個文檔。你會看到顯着的性能增益。

請參閱插入here的方法＃2，它需要插入一組文檔來代替單個文檔。另請參閱this thread

的討論，如果你想要更多的基準 -
這只是一個猜測，嘗試使用預定義的大尺寸的上限集合來存儲所有數據。無索引的封蓋集合具有非常好的插入性能。

來源

2011-07-22 07:28:16 DhruvPathak

不錯。每個100k對象使用casbah collection.insert（List [MongoDBObject]（...）），每個插入（並且沒有索引）的批量爲5000，每秒約5秒。在短短几分鐘內完成了超過1500萬的工作。爲了達到同樣的數字，我必須在一夜之間運行它。謝謝！ –

1小時20分鐘裝載1億。四個指標中的每一個似乎需要大約一個小時才能創建，所以總共需要大約5個小時。不錯。再次感謝。 –

聽起來不錯。別客氣。 – DhruvPathak

我有過同樣的事情。據我所知，這歸結於索引值的隨機性。每當插入新文檔時，顯然還需要更新所有基礎索引。因爲您要隨機插入這些索引中的值，而不是順序值，所以您將不斷訪問整個索引以查找放置新值的位置。

當所有索引都坐在內存中時，這一切都很好，但是一旦它們變得太大，您需要開始敲擊磁盤以執行索引插入，然後磁盤開始抖動並寫入性能死亡。

當您加載數據時，請嘗試將db.collection.totalIndexSize()與可用內存進行比較，您可能會看到這種情況。

最好的辦法是在之後創建索引，您已加載數據。但是，當它是包含隨機值（GUID，Hash等）的必需_id索引時，這仍然不能解決問題，那麼最佳方法可能是考慮分片或獲取更多RAM。

來源

2011-07-22 07:19:00

我在我的項目中做了一些多線程（項目是用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-21 09:34:53

另一種替代方法是嘗試TokuMX。他們使用分形索引，這意味着it does not slow down over time as the database gets bigger。

TokuMX將在即將推出的MongoDB版本中作爲自定義存儲驅動程序提供。

當前版本的MongoDB在Linux下運行。我使用Vagrant相當快地啓動並運行在Windows上。

來源

2015-01-03 13:00:07 Contango

如何使用Scala將1億條記錄加載到MongoDB中進行性能測試？

回答

相關問題