如何“玩轉”MongoDB？羅輯思維資料庫效能最佳化之路！

當整個世界由IT走向DT時代，資料庫領域也發生了重大變化，NoSQL成為企業應用常態，這也是MongoDB之所以受歡迎的根本原因。MongoDB介於關聯式資料庫和非關聯式資料庫之間，支援的資料結構非常鬆散，類似json的bson格式，可儲存比較複雜的資料型別。因此，MongoDB可以讓開發人員上手更快、系統更容易擴充套件。

▲羅輯思維首席DBA李丹老師

但是，MongoDB到底適用於哪些場景? 在使用MongoDB的時候，需要注意些什麼?MongoDB和MySQL相比，有何區別?對於一個新手DBA來說，應該從何處入手?可能很多人，都不是特別清楚!在第十屆資料庫技術大會(DTCC 2019)即將到來之際，羅輯思維首席DBA李丹老師，接受了ITPUB專訪，結合羅輯思維的資料庫效能最佳化與實踐經驗，為我們帶了很多幹貨內容。

一切以業務為中心，MongoDB選型之初

“引入MongoDB，主要是為了解決MySQL集中式架構帶來的弊端，包括對海量資料儲存、讀寫分離及彈性擴充套件不夠靈活等問題。” 李丹老師首先介紹了MongoDB選型的初衷。

李丹，有近10年的專職資料庫從業經驗，主要從事MySQL、MongoDB自動化運維及私有云平臺建設，曾專注於開源資料庫MySQL、MongoDB等相關技術領域的學習與研究。

其實，羅輯思維整體的資料庫架構設計思路，和大多數網際網路創業公司的發展脈絡差不多。在早期的時候，羅輯思維的資料庫完全依賴雲廠商，但是隨著業務的發展，之前的過度依賴逐漸暴露出了一些缺陷，比如：故障響應速度不夠迅速、批次管理不夠自動化、資源配置不能按需擴縮容、資料庫與資料倉儲實時資料不能友好同步等等，類似問題變得越來越棘手。而MongoDB適合大部分OLTP場景，比如：需求頻繁變化的遊戲業務、要求實時上報的物聯網資料、外賣類地理位置查詢、TB或PB級別的海量資料儲存及99.999%的高可用要求等。特別是MongoDB4.0，引入了事物概念，這對一些具有資料強一致性需求的業務場景來說，也有了更多的選擇。當然，沒有任何一種資料庫能100%適用於所有應用場景，如果你的業務具有很複雜的關聯查詢，或金融類的業務，那暫時不推薦使用MongoDB。

對於羅輯思維的資料庫選型通常遵從這幾個原則：1、一切以業務為中心，什麼適合業務需求就用什麼; 2、技術社群足夠活躍，生態圈相對完善; 3、資料庫技術被業界認可，與之相對應的市場人才豐富; 4、資料庫相對成熟穩定，案例豐富; 5、DBA和開發人員對資料庫都相對熟悉，運維成本低。

增加資料庫彈性擴充套件能力，MongoDB價值凸顯

現在，我們已開始嘗試混合雲模式，其中資料庫型別主要是MySQL和MongoDB，當然Redis快取資料庫我們也廣泛使用。MySQL主要分普通主從結構，以及讀寫分離架構。MySQL雖然優勢明顯，簡單可依賴，使用者基數大，案例極其豐富，社群非常活躍，周邊工具集完善;但是劣勢也非常明顯，那就是關係表的不靈活性，高可用及讀寫分離依賴第三方外掛，無法做到彈性擴充套件等等。

與MySQL相比，MongoDB有著渾然天成的優勢，靈活的json類文件模型、豐富的資料壓縮模式，可調一致性，基於raft協議的自動高可用等。尤其是mongos分片叢集，能讓資料自動切片及自動資料均衡，為分散式架構的彈性容量及效能擴充套件提供了友好的支撐。大家可能比較關心的是如何在高可用切換的時候，如何能實現對業務的透明化?我們採用了“MongoDB+consul”方案，當然也有人採用lvs+MongoDB等。

MongoDB給羅輯思維帶來了很大的改變：第一， mongos分散式叢集架構，讓我們面在對海量資料和高併發的場景下，也能輕鬆的保證容量及效能的彈性擴、縮容;第二，基於raft協議的自動高可用，給運維帶來了極大的便利，無需引入第三方中介軟體，就能保證業務99.999%的可用性;第三，各語言的MongoDB驅動基本都實現了讀寫分離功能，在無需引入第三方中介軟體情況下，輕鬆實現5種讀策略的控制;第四，提供snappy、zilib壓縮比達2~5倍的多種不同的資料壓縮模式，極大地節約了儲存成本。MongoDB很大程度上降低了我們的運維成本，這也讓我們有更多的時間在業務早期即可與研發工程師深度配合，進行設計最佳化。

把握資料庫發展趨勢，新手DBA需避免“踩坑”

“坦白說，在剛接觸MongoDB的時候，對它的類js語法結構、分散式資料庫的理論及運維方式等，感覺很不習慣” 李丹老師如是說。MongoDB是文件型資料庫，在使用初期會不太習慣，尤其在使用方式及運維思路上，大多數關係型資料庫DBA都會感覺不適應。但是，隨著對MongoDB瞭解的加深，特別是如果經歷過大規模的運維實踐的考驗，你便能切身體會到MongoDB給工作帶來的便利性。

不過，在MongoDB的構建過程中，的確有很多需要注意的關鍵點，需要考慮不同場景下的資料遷移問題，比如叢集間業務拆分的資料遷移、資料庫版本升級的資料遷移、機房間的資料遷移等等。一些不熟悉MongoDB的同行，在做機房遷移的時候，他們認為需要在對應機房搭建一套新叢集。實際上，這種方式利用好MongoDB自動高可用特性，直接在對應機房擴節點後，進行高可用切換，就能輕鬆完成。當然，如果是跨版本資料的遷移一定要注意相容性，MongoDB在有些版本的特性支援上，可能變化較大。

關於MongoDB的運維，也存在很多問題。比如：讀寫一致性問題，預設配置的情況下，主節點故障切換可能會引發資料回滾，建議一般配置”寫大多數”模式。MongoDB3.4版本，SCRAM-SHA-1的認證策略，可能在高併發短連線模型下會出現cpu負載飆高的情況，這個時候需要對認證策略回退。針對效能最佳化，通常要對研發人員進行使用及索引最佳化方面的培訓，核心業務DBA會深入業務層面，指導設計與最佳化。當然我們也會做一些事後的補救措施，如自動分析索引的使用情況、自動慢查詢分析推送等等。對於負載過高的情況，可能引發的因素很多。一般來說可能是因為慢查詢，特定版本高併發短連線問題等等。通常狀態下，如果是阻塞至無法登入，可能需要強制shutdown節點，以rolling的方式快速建立索引。而對特定版本高併發、短連線導致負載高，可降級認證策略，或者業務採用連線池……

針對更多避免採坑的案例，這裡先留個懸念，DTCC2019資料庫技術大會當天會做具體分享。近年來，資料庫的發展可謂日新月異，熟練掌握MongoDB運維知識體系，學習更多關於MongoDB的最佳實踐經驗，可以為DBA或開發人員的職業發展帶來更大的競爭力。

總之，不管是從MongoDB本身成熟度來看，還是從技術人員個人發展的角度考慮，都非常建議大家現在就開始嘗試MongoDB,也期望MongoDB能讓你收穫更多驚喜。

最新的DTCC大會動態，關注 http://dtcc.it168.com/ 或長按並試別下方二維碼即可直達。