?集群的結構，大家可以查看我的另一遍文章，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大規模寫入的性能還是可以的。查詢的話，還是很慢。主要是搜索的數據體變大了。

?

轉載于:https://www.cnblogs.com/NET-BLOG/p/8242825.html

總結

以上是生活随笔為你收集整理的Mongodb百亿级数据添加，修改，删除，查询等性能测试【四】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。