Mongodb百億級數據添加，修改，刪除，查詢等性能測試【四】

 集羣的結構，你們能夠查看個人另外一遍文章，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大規模寫入的性能仍是能夠的。查詢的話，仍是很慢。主要是搜索的數據體變大了。