從這個測試可以看出，對于單進程的方式：
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，但是也僅僅是在數據量特別大的時候遇到幾次。