集群的結構，大家可以查看我的另一遍文章，Mongodb的三種集群 在最后一種集群中，介紹到。
目前使用的數據就是最后一個測試集群，留下的數據。
簡單介紹一下，四個分片的配置
192.168.99.6 雙核 2G 500G(機械硬盤) 192.168.99.7 雙核 4G 500G(機械硬盤) 192.168.99.8 雙核 4G 500G（機械硬盤） 192.168.99.11 雙核 4G 500G（機械硬盤）
mongos和conf服務器的配置也是差不多，就不貼出來了，不是很重要。
很遺憾的是，片健當初只選擇了ID主健，當時一時沖動，沒想好，這可能給查詢給不方便。
首先，看看單條數據文檔大小
{ "_id" : ObjectId("5a39d1541b5bd02374f0844a"), "OrderNo" : "636493641800005836", "ShipperID" : 8427, "CarOwnerID" : 3625, "SendProvince" : "福建省", "SendCity" : "莆田市", "DestProvince" : "福建省", "DestCity" : "莆田市", "TranPrice" : "1014", "CancelStatus" : 3, "Status" : 100, "SettlementDate" : null, "SettleTranPrice" : "2279", "SafePrice" : "528", "TotalPrice" : "6036", "CarryPrice" : "845", "CreateTime" : ISODate("2017-12-20T02:56:20.000Z") }
四個分片服務器，各自數據量和文件大小，一共100億
192.168.99.6 數量量：2603773123 數據庫大小：158G 日志Log大小：67M
192.168.99.7 數量量：2602259209 數據庫大小：158G 日志Log大小：1.5G
192.168.99.8 數量量：2534980799 數據庫大小：154G 日志Log大小：47G
192.168.99.11 數量量：2601317529 數據庫大小：158G 日志Log大小：68M
數據量四個分片，比較均衡，數據庫大小差不多，就是這個日志，差距很大哎,我去下載來看看，都什么梗 在內面。46G內網的速度10M/S，下載都要一個小時，不查看了
查詢總行數，第一次查詢大概花費7-9秒，第二次有緩存，只需0.039秒，應該是緩存的原因。現在問題，我來加一個有條件的總行數查詢。
db.getCollection('Order').count({'Status':100})
這下就不行了吧，可以看到各個分片的CPU和內存都漲上去了。然后，查詢界面一直轉,出事了，整整過去了15分鍾，還在轉，這鐵定是要出事了。
除了根據ID查詢之外，只要加搜索條件，都卡到不行。到此為止，我不得，不刪除這100億條數據。因為數據過多，很多查詢都要費很大的時間，甚至無法獲取結果。
我們刪除數據先寫入小部分數據，比如10億，進行數據分析。性能比較吧。
看來 “_Id” 並不是一件很好片健，在這個100億的數據寫入中，四個分片服務器，只要一個比較忙，原因就是片健 "_Id"（遞增值）,使得集群出一個“熱點” 分片，然后集群再通過均衡器（mongos）遷移到其它分片。
在這里，小小普及一下片健和工作原理。
片健的選取很關健，會直接影響集群的效率，並且很難再重選片健，特別是大數據。
相關資料我也懶得說，直接你們就去看文檔我貼點資料給你們看
我這里重新測試數據，就選擇哈希片健吧，比較簡單有效。就是查詢的也是隨機的，這樣的話，效率會低。
//模擬數據寫入服務器 192.168.99.5 //mongos服務器 192.168.99.9 //分片服務器 192.168.99.6 192.168.99.7 192.168.99.8 192.168.99.10 192.168.99.11 192.168.99.15 192.168.99.16 //配置服務器 192.168.99.12 192.168.99.13 192.168.99.14
sh.shardCollection("shop.Order", { _id : "hashed" } ) //哈希片鍵
具體怎么搭建，大伙參考頭上的鏈接的文章。相比前一篇，這回測試服務器，又增加了三台。
搭建好了。
雖然選擇了哈希片鍵，但是不知道為什么，還是出現熱點服務器
七個分片服務器，只有這一台，比較忙，這台也是主分片。其它的分片的CPU和內存都閑的很啊。頭痛。這又是為什么。
准備下班了，留模擬服務器，寫一宿吧。明天使用MapReduce 進行大數據分析。就不深入研究了，沒有太多時間。
寫了一宿，寫了五億條數據。
但是，不旦出現熱點分片，還出出數據不平均的情況。熱點分片儲存達2億條，其它分片儲存5千萬條
先查查，這是什么原因吧。終於查出原因，因為昨晚加入的三台測試服務器，有二台時間不同。所以出現這個問題。這個問題在集群搭建中也出現。
昨天我己同步過時間的了。不知道為什么，這二台真的差十幾秒時間。可能昨晚眼花了。
時間完全同步之后。集群也恢復了正常。使用哈希片健之后，集群的七個分片都開始工作。CPU和內存都占用。
只能把昨晚的五億數據，全部刪除，現在重新生成，大概10萬/秒的速度。
網卡的工作效率，己達峰值，辦公室的交換機，路由器都是百M級的，也就是11M左右的速度，就是峰值了。
雖然七台分片器的還是使用率不高。但是mongos的服務器網卡和交換機，路由器，的工作狀態，已達峰值。在目前的情況，置換新設備的可能性，大概接近零。
先這樣吧，連續寫兩個小時間，下午使用MapReduce 進行大數據分析，性能估計看不出來了。因為下午，估計也就1億條數據。
目前測試發現一個現象mongos 網卡不到峰值，8-9M的時候，工作最正常，各個分片，CPU和內存都正常。一旦把mongos的網卡扛到峰值，雖然輸入速度每秒提升了2W條。但是各個分片的CPU和內存，明顯不按比例快速增長。
好吧，大概寫了二到三個小時，寫了5千萬條。就這樣測試吧
頭痛，1000條的分片服務器，條件查詢要11秒。當然沒有索引
在mongos上面，查詢，看看性能如何吧,一共5千萬條。除了主健，都沒有索引
find()加上條件，響應還是很快的。
limit的查詢
sort排序
直接就查不出來，換一個小數據的分片查查吧,五百分的數據分片。這么就有6秒
行吧，又有正經事要辦了。先筆記一下。以后再測吧。mongodb大規模寫入的性能還是可以的。查詢的話，還是很慢。主要是搜索的數據體變大了。