磊哥評測之數據庫:騰訊雲MongoDB vs自建

本文由雲+社區發表redis

做者:磊哥sql

上期文章咱們聊到了redis。這期咱們來講說另外一個網紅nosql數據庫:MongoDB。有這麼一個介紹MongoDB的說法是:MongoDB是非關係數據庫當中功能最豐富,最像關係數據庫的。這麼說是由於做爲一個面向文檔存儲型、數據結構很是鬆散自由的的數據庫,卻擁有着豐富的功能特性如強大靈活的查詢語言、支持二級索引等特性,新版本的MongDB甚至還支持事務。聽小夥伴說MongoDB不只功能豐富,並且讀性能強大到遠遠把MySQL甩在後面,今天我就代替你們來動手進行一下數據庫測試,揭開MongoDB的神祕「面紗」。mongodb

爲了進行數據庫對比測試,此次我購買了騰訊雲MongoDB的主從版(1主2從),同時在一樣配置的雲主機自建MongoDB做爲對比。數據庫

img

下面給出CentOS7 64位上安裝MongoDB 3.6的實踐以下:vim

vim /etc/yum.repos.d/mongod-org.repo安全

編輯內容以下:服務器

[mongodb-org]網絡

name=MongoDB Repository數據結構

baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.6/x86_64/架構

gpgcheck=1

enabled=1

gpgkey=https://www.mongodb.org/static/pgp/server-3.6.asc

執行指令yum install mongodb-org -y安裝

vim /etc/mongod.conf

此處根據本身需求修改bindIp: 0.0.0.0 #監聽地址 port: 27017 #監聽端口

systemctl start mongod.service #開啓服務

netstat -anpt | grep 27017 #檢查是否啓動

服務開啓後可使用上面的指令測試服務是否啓動,若是成功啓動的話會看到結果以下圖所示:

img

若是沒法啓動,須要根據日誌分析具體緣由。根據筆者的實踐,大部分的緣由會落在配置和權限上。若是排除錯誤太難,建議從新安裝來的快一點。

接下來須要安裝數據庫測試工具,此次咱們使用YCSB,雅虎開發的一個很強大的測試工具。

在安裝YCSB前須要安裝Java和Maven,測試前須要在workloads文件夾中建立配置文件,配置以下圖所示:

img

考慮到購買的mongoDB是副本集配置,一個主節點帶兩個從節點,咱們在本地也配置好副本集羣,使用用 ./mongod --replSet amymongo --dbpath /data/27019 --port 27019 --logpath /var/log/mongodb/27019.log --fork 配置從節點,具體配置和初始化方法參考https://cloud.tencent.com/developer/article/1379231(固然部署在本機的方案不能保證高可用)

在workloads中防止配置文件,咱們選擇插入1千萬條記錄,執行1千萬次操做,測試兩種場景:read/update 9:1和純insert場景。

廢話少說,下面就一塊兒來看看測試結果吧。

場景讀更新read/update 9:1,單位ops/sec:

img

場景純寫入insert,單位ops/sec:

img

場景讀更新read/update 9:1,單位us(延時):

img

場景純寫入insert,單位us(延時):

img

看來mongodb真的是一個高性能的數據庫,爲啥呢,由於mongo的延時單位竟然是us微秒、微秒、微秒。。。16GB的內存基本上20線程以後延時就會大大增長,在100線程的時候基本上延時基本在1000us以上,而讀多場景跟寫入場景相比,寫入場景的性能略差一點,隨着線程數的增大,寫入場景的吞吐量和延時表現和讀更新場景的差距會擴大。

有讀者可能會有疑惑,既然數據庫測試是比較雲和自建,看起來差距也沒有那麼大,用自建好像也能夠接受啊。這裏我要把測試中的發現講給你們聽,聽完以後你們就明白了。

第一點,筆者買的是16G內存的機器(流下了沒有錢的淚水),測試的時候發現cvm的內存佔用基本到了百分之60左右,筆者在創建副本集和加大測試數據量(購買數據量的百分之80)以後發現,內存佔用基本到了百分之80以上。看來mongo的第一個缺點,就是對內存的消耗真的很是可怕!!若是遇到高併發大數據量讀寫,恐怕分分鐘就存在着存在着OOM的風險。

因此這裏奉勸各位同窗,若是要自建MongoDB,仍是儘可能購買超大內存知足業務需求,避免在業務高峯的時候被「幹掉」。若是由於跟筆者同樣貧窮不想買那麼大的內存,能夠考慮使用雲數據庫,雲MongoDB具有動態伸縮能力,即便沒有買夠大的內存,也徹底來得及在業務高峯擴容, 即便發生故障,也有完善的數據自動備份和無損恢復機制來恢復數據,在可用性上保障就高多了。

第二點,筆者在後續測試本地副本集的時候,嘗試讀secondary節點的數據,結果遇到了讀延遲很高的狀況。在網上研究了一下發現是由於,MongoDB 複製集裏 Secondary 不斷從主上批量拉取 oplog,而後在本地重放,以保證數據與 Primary 一致。這裏爲了防止髒讀,會加一個鎖阻塞全部的讀請求。

因此若是遇到 Secondary 重放 oplog 佔用鎖時間長,讀取的延時也會對應變長。這個鎖最高能鎖多久呢,看到有個案例鎖了接近一個小時。。。看到的人心裏必定是崩潰的,而在雲Mongo測試的時候沒有遇到這個狀況,我想這必定是針對這個缺陷作了很大的改進,使用了其餘方法實現同步。

總的來講,MongoDB確實能夠不借助其餘第三方工具實現高可用和分片功能,具有的高可用的故障切換,分片能夠實現數據的分部均衡,大數據量的時候經過路由實現了服務器的負載均衡。因此MongoDB自身的可用性較高,也難怪會在短短期內成爲流行的nosql數據庫。

可是MongoDB也存在着一些坑:如對內存的佔用太高、對網絡的佔用太高、存在從節點鎖致使讀幾乎不可用的狀況,這些狀況在實際業務使用的時候會致使很嚴重的問題,集羣宕機、服務癱瘓、數據丟失無時不刻不是覆蓋在運維同窗心頭的陰影。這個時候雲MongoDB幾乎就是救星,彈性伸縮、隨時擴容、真正安全的數據熱備以及強大的專業運維架構師團隊,才能真的確保業務安全無端障的運行下去。

寫到這裏,筆者也在思考,雲數據庫究竟是什麼,它僅僅是把數據庫封裝一下,改改內核,提供給使用者嗎?不,雲數據庫應當是一整套專業服務,除了數據庫以外,還有監控、安全、遷移、災備、運維等一系列的服務提供。能讓業務開發專一於業務自己,把專業的交給專業的人去作。

此文已由騰訊雲+社區在各渠道發佈

獲取更多新鮮技術乾貨,能夠關注咱們騰訊雲技術社區-雲加社區官方號及知乎機構號

相關文章
相關標籤/搜索