Mongodb億級數據量的性能測試
進行了一下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數據）
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） 對于磁盤空間的占用，兩者其實是差不多的，其中的一些差距可能是因為多個進程都會多分配一點空間，加起來有的時候會比單進程多占用點磁盤（而那些占用比單進程少的地方其實是開始的編碼錯誤，把實際數據大小和磁盤文件占用大小搞錯了）。
雖然在***由于時間的關系，沒有測到10億級別的數據量，但是通過這些數據已經可以證明Mongodb的性能是多么強勁了。另外一個原因是，在很多時候可能數據只達到千萬我們就會對庫進行拆分，不會讓一個庫的索引非常龐大。在測試的過程中還發現幾個問題需要值得注意：
1） 在數據量很大的情況下，對服務進行重啟，那么服務啟動的初始化階段，雖然可以接受數據的查詢和修改，但是此時性能很差，因為mongodb會不斷把數據從磁盤換入內存，此時的IO壓力非常大。
2） 在數據量很大的情況下，如果服務沒有正常關閉，那么Mongodb啟動修復數據庫的時間非常可觀，在1.8中退出的-dur貌似可以解決這個問題，我簡單測試了一下，開啟dur對插入和查詢性能影響都不是很大。
3） 在使用Sharding的時候，Mongodb時不時會對數據拆分搬遷，這個時候性能下降很厲害，雖然從測試圖中看不出（因為我每一次測試都會測試比較多的迭代次數），但是我在實際觀察中可以發現，在搬遷數據的時候每秒插入性能可能會低到幾百條。
4） 對于數據的插入，如果使用多線程并不會帶來性能的提高，反而還會下降一點性能（并且可以在http接口上看到，有大量的線程處于等待）。
5） 在整個測試過程中，批量插入的時候遇到過幾次連接被遠程計算機關閉的錯誤，懷疑是有的時候Mongodb不穩定關閉了連接，或是官方的C#客戶端有BUG，但是也僅僅是在數據量特別大的時候遇到幾次。
原文鏈接：http://www.cnblogs.com/lovecindywang/archive/2011/03/02/1969324.html
【編輯推薦】
