[轉]Mongodb億級資料量的效能測試
（所有插入都是單執行緒進行，所有讀取都是多執行緒進行）
1） 普通插入效能 （插入的資料每條大約在1KB左右）
2） 批量插入效能 （使用的是官方C#客戶端的InsertBatch），這個測的是批量插入效能能有多少提高
3） 安全插入功能 （確保插入成功，使用的是SafeMode.True開關），這個測的是安全插入效能會差多少
4） 查詢一個索引後的數字列，返回10條記錄（也就是10KB）的效能，這個測的是索引查詢的效能
5） 查詢兩個索引後的數字列，返回10條記錄（每條記錄只返回20位元組左右的2個小欄位）的效能，這個測的是返回小資料量以及多一個查詢條件對效能的影響
6） 查詢一個索引後的數字列，按照另一個索引的日期欄位排序（索引建立的時候是倒序，排序也是倒序），並且Skip100條記錄後返回10條記錄的效能，這個測的是Skip和Order對效能的影響
7） 查詢100條記錄（也就是100KB）的效能（沒有排序，沒有條件），這個測的是大資料量的查詢結果對效能的影響
8） 統計隨著測試的進行，總磁碟佔用，索引磁碟佔用以及資料磁碟佔用的數量
並且每一種測試都使用單程序的Mongodb和同一臺伺服器開三個Mongodb程序作為Sharding（每一個程序大概只能用7GB左右的記憶體）兩種方案
其實對於Sharding，雖然是一臺機器放3個程序，但是在查詢的時候每一個並行程序查詢部分資料，再有運行於另外一個機器的mongos來彙總資料，理論上來說在某些情況下效能會有點提高
基於以上的種種假設，猜測某些情況效能會下降，某些情況效能會提高，那麼來看一下最後的測試結果怎麼樣？
備註：測試的儲存伺服器是 E5620 @ 2.40GHz，24GB記憶體，CentOs作業系統，打壓機器是E5504 @ 2.0GHz，4GB記憶體，Windows Server 2003作業系統，兩者千兆網絡卡直連。
從這個測試可以看出，對於單程序的方式：
1） Mongodb的非安全插入方式，在一開始插入效能是非常高的，但是在達到了兩千萬條資料之後效能驟減，這個時候恰巧是伺服器24G記憶體基本佔滿的時候（隨著測試的進行mongodb不斷佔據記憶體，一直到作業系統的記憶體全部佔滿），也就是說Mongodb的記憶體對映方式，使得資料全部在記憶體中的時候速度飛快，當部分資料需要換出到磁碟上之後，效能下降很厲害。（這個效能其實也不算太差，因為我們對三個列的資料做了索引，即使在記憶體滿了之後每秒也能插入2MB的資料，在一開始更是每秒插入25MB資料）。Foursquare其實也是把Mongodb當作帶持久化的記憶體資料庫使用的，只是在查不到達到記憶體瓶頸的時候Sharding沒處理好。
2） 對於批量插入功能，其實是一次提交一批資料，但是相比一次一條插入效能並沒有提高多少，一來是因為網路頻寬已經成為了瓶頸，二來我想寫鎖也會是一個原因。
3） 對於安全插入功能，相對來說比較穩定，不會波動很大，我想可能是因為安全插入是確保資料直接持久化到磁碟的，而不是插入記憶體就完事。
4） 對於一列條件的查詢，效能一直比較穩定，別小看，每秒能有8000-9000的查詢次數，每次返回10KB，相當於每秒查詢80MB資料，而且資料庫記錄是2億之後還能維持這個水平，效能驚人。
5） 對於二列條件返回小資料的查詢，總體上效能會比4）好一點，可能返回的資料量小對效能提高比較大，但是相對來說效能波動也厲害一點，可能多了一個條件就多了一個從磁碟換頁的機會。
6） 對於一列資料外加Sort和Skip的查詢，在資料量大了之後效能明顯就變差了（此時是索引資料量超過記憶體大小的時候，不知道是否有聯絡），我猜想是Skip比較消耗效能，不過和4）相比效能也不是差距特別大。
7） 對於返回大資料的查詢，一秒瓶頸也有800次左右，也就是80M資料，這就進一步說明了在有索引的情況下，順序查詢和按條件搜尋效能是相差無幾的，這個時候是IO和網路的瓶頸。
8） 在整個過程中索引佔的資料量已經佔到了總資料量的相當大比例，在達到1億4千萬資料量的時候，光索引就可以佔據整個記憶體，此時查詢效能還是非常高，插入效能也不算太差，mongodb的效能確實很牛。
那麼在來看看Sharding模式有什麼亮點：
1） 非安全插入和單程序的配置一樣，在記憶體滿了之後效能急劇下降。安全插入效能和單程序相比慢不少，但是非常穩定。
2） 對於一個條件和兩個條件的查詢，效能都比較穩定，但條件查詢效能相當於單程序的一半，但是在多條件下有的時候甚至會比單程序高一點。我想這可能是某些時候資料塊位於兩個Sharding，這樣Mongos會並行在兩個Sharding查詢，然後在把資料進行合併彙總，由於查詢返回的資料量小，網路不太可能成為瓶頸了，使得Sharding才有出頭的機會。
3） 對於Order和Skip的查詢，Sharding方式的差距就出來了，我想主要效能損失可能在Order，因為我們並沒有按照排序欄位作為Sharding的Key，使用的是_id作為Key，這樣排序就比較難進行。
4） 對於返回大資料量的查詢，Sharding方式其實和單程序差距不是很大，我想資料的轉發可能是一個性能損耗的原因（雖然mongos位於打壓機本機，但是資料始終是轉手了一次）。
5） 對於磁碟空間的佔用，兩者其實是差不多的，其中的一些差距可能是因為多個程序都會多分配一點空間，加起來有的時候會比單程序多佔用點磁碟（而那些佔用比單程序少的地方其實是開始的編碼錯誤，把實際資料大小和磁碟檔案佔用大小搞錯了）。
測試最後的各個Sharding分佈情況如下：
{
"sharded" : true,
"ns" : "testdb.test",
"count" : 209766143,
"size" : 214800530672,
"avgObjSize" : 1024.0000011441311,
"storageSize" : 222462757776,
"nindexes" : 4,
"nchunks" : 823,
"shards" : {
"shard0000" : {
"ns" : "testdb.test",
"count" : 69474248,
"size" : 71141630032,
"avgObjSize" : 1024.0000011515058,
"storageSize" : 74154252592,
"numExtents" : 65,
"nindexes" : 4,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1,
"flags" : 1,
"totalIndexSize" : 11294125824,
"indexSizes" : {
"_id_" : 2928157632,
"Number_1" : 2832745408,
"Number1_1" : 2833974208,
"Date_-1" : 2699248576
},
"ok" : 1
},
"shard0001" : {
"ns" : "testdb.test",
"count" : 70446092,
"size" : 72136798288,
"avgObjSize" : 1024.00000113562,
"storageSize" : 74154252592,
"numExtents" : 65,
"nindexes" : 4,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1,
"flags" : 1,
"totalIndexSize" : 11394068224,
"indexSizes" : {
"_id_" : 2969355200,
"Number_1" : 2826453952,
"Number1_1" : 2828403648,
"Date_-1" : 2769855424
},
"ok" : 1
},
"shard0002" : {
"ns" : "testdb.test",
"count" : 69845803,
"size" : 71522102352,
"avgObjSize" : 1024.00000114538,
"storageSize" : 74154252592,
"numExtents" : 65,
"nindexes" : 4,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1,
"flags" : 1,
"totalIndexSize" : 11300515584,
"indexSizes" : {
"_id_" : 2930942912,
"Number_1" : 2835243968,
"Number1_1" : 2835907520,
"Date_-1" : 2698421184
},
"ok" : 1
}
},
"ok" : 1
}
雖然在最後由於時間的關係，沒有測到10億級別的資料量，但是通過這些資料已經可以證明Mongodb的效能是多麼強勁了。另外一個原因是，在很多時候可能資料只達到千萬我們就會對庫進行拆分，不會讓一個庫的索引非常龐大。在測試的過程中還發現幾個問題需要值得注意：
1） 在資料量很大的情況下，對服務進行重啟，那麼服務啟動的初始化階段，雖然可以接受資料的查詢和修改，但是此時效能很差，因為mongodb會不斷把資料從磁碟換入記憶體，此時的IO壓力非常大。
2） 在資料量很大的情況下，如果服務沒有正常關閉，那麼Mongodb啟動修復資料庫的時間非常可觀，在1.8中退出的-dur貌似可以解決這個問題，據官方說對讀取沒影響，寫入速度會稍稍降低，有空我也會再進行下測試。
3） 在使用Sharding的時候，Mongodb時不時會對資料拆分搬遷，這個時候效能下降很厲害，雖然從測試圖中看不出（因為我每一次測試都會測試比較多的迭代次數），但是我在實際觀察中可以發現，在搬遷資料的時候每秒插入效能可能會低到幾百條。其實我覺得能手動切分資料庫就手動切分或者手動做歷史庫，不要依賴這種自動化的Sharding，因為一開始資料就放到正確的位置比分隔再搬遷效率不知道高多少。個人認為Mongodb單資料庫儲存不超過1億的資料比較合適，再大還是手動分庫吧。
4） 對於資料的插入，如果使用多執行緒並不會帶來效能的提高，反而還會下降一點效能（並且可以在http介面上看到，有大量的執行緒處於等待）。
5） 在整個測試過程中，批量插入的時候遇到過幾次連線被遠端計算機關閉的錯誤，懷疑是有的時候Mongodb不穩定關閉了連線，或是官方的C#客戶端有BUG，但是也僅僅是在資料量特別大的時候遇到幾次。
最新補充：在之後我又進行了幾天測試，把測試資料量進一步加大到5億，總磁碟佔用超過500G，發現和2億資料量相比，所有效能都差不多，只是測試6和測試7在超過2億級別資料之後，每400萬記錄作為一個迴圈，上下波動30%的效能，非常有規律。