本文由雲+社區發表 作者：磊哥 上期文章我們聊到了redis。這期我們來說說另一個網紅nosql資料庫：MongoDB。有這麼一個介紹MongoDB的說法是：MongoDB是非關係資料庫當中功能最豐富，最像關係資料庫的。這麼說是因為作為一個面向文檔存儲型、數據結構非常鬆散自由的的資料庫，卻擁有著豐富 ...
本文由雲+社區發表
作者：磊哥
上期文章我們聊到了redis。這期我們來說說另一個網紅nosql資料庫：MongoDB。有這麼一個介紹MongoDB的說法是：MongoDB是非關係資料庫當中功能最豐富，最像關係資料庫的。這麼說是因為作為一個面向文檔存儲型、數據結構非常鬆散自由的的資料庫，卻擁有著豐富的功能特性如強大靈活的查詢語言、支持二級索引等特性，新版本的MongDB甚至還支持事務。聽小伙伴說MongoDB不僅功能豐富，而且讀性能強大到遠遠把MySQL甩在後面，今天我就代替大家來動手進行一下資料庫測試，揭開MongoDB的神秘“面紗”。
為了進行資料庫對比測試，這次我購買了騰訊雲MongoDB的主從版（1主2從），同時在同樣配置的雲主機自建MongoDB作為對比。
下麵給出CentOS7 64位上安裝MongoDB 3.6的實踐如下：
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 #檢查是否啟動
服務開啟後可以使用上面的指令測試服務是否啟動，如果成功啟動的話會看到結果如下圖所示：
如果無法啟動，需要根據日誌分析具體原因。根據筆者的實踐，大部分的原因會落在配置和許可權上。如果排除錯誤太難，建議重新安裝來的快一點。
接下來需要安裝資料庫測試工具，這次我們使用YCSB，雅虎開發的一個很強大的測試工具。
在安裝YCSB前需要安裝Java和Maven，測試前需要在workloads文件夾中創建配置文件，配置如下圖所示：
考慮到購買的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:
場景純寫入insert，單位ops/sec:
場景讀更新read/update 9:1，單位us(延時)：
場景純寫入insert，單位us(延時):
看來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幾乎就是救星，彈性伸縮、隨時擴容、真正安全的數據熱備以及強大的專業運維架構師團隊，才能真的確保業務安全無故障的運行下去。
寫到這裡，筆者也在思考，雲資料庫到底是什麼，它僅僅是把資料庫封裝一下，改改內核，提供給使用者嗎？不，雲資料庫應當是一整套專業服務，除了資料庫之外，還有監控、安全、遷移、災備、運維等一系列的服務提供。能讓業務開發專註於業務本身，把專業的交給專業的人去做。
此文已由騰訊雲+社區在各渠道發佈
獲取更多新鮮技術乾貨，可以關註我們騰訊雲技術社區-雲加社區官方號及知乎機構號
