初創公司MongoDB最佳實踐策略和躲坑祕笈

極牛技術實踐分享活動
極牛技術實踐分享系列活動是極聯合頂級VC、技術專家，爲企業、技術人提供的一種系統的線上技術分享活動。
每期不一樣的技術主題，和行業專家深度探討，專一解決技術實踐難點，推進技術創新，每兩週的週三20點正式開課。歡迎各個機構、企業、行業專家、技術人報名參加。

本期大綱
MongoDB是啥？特色及適用場合？
高可用如何作？
性能調優？
監控與排錯？

嘉賓介紹
魏佳，前後就任於IBM創新技術研究院、新浪微博平臺架構部及新浪微博技術評審委員會、Mico聯合創始人及CTO，現任LinkedIn中國技術主管。對企業級應用技術、虛擬化技術以及分佈式消息中間件有深刻的研究。對大規模分佈式系統、高併發Web系統，主流通訊系統的技術棧和協議有豐富的工程經驗。 同時具有紮實的計算機科研技能，著有多篇中外技術專利。從技術架構層面支撐其從0到千萬級註冊用戶，日均百萬級活躍用戶，日均千萬級消息量的發展和演進。

MongoDB的話題
今天的話題主要圍繞如下幾個方面吧：1. What? 2. Why? 3. How?

首先MongoDB做爲NoSQL興起時的一個表明，最近這些年發展很是迅速，同時使用也很普遍。一兩句來講MongoDB是什麼？有10gen公司來開發和維護，由C++開發，支持衆多的語言。feature層面，它是document-based，同時是DDL free的，不說schema free是由於不少場景中仍是須要schema的。重要的是它easy tounderstand/learn and use，同時支持server-side script。此外，spatial index，GridFS以及有限度的MR的支持，也拓寬了它的使用場景。

爲何選擇MongoDB呢？
首先說到選型問題，我認爲技術決策和選型的過程首先要拋棄先入爲主的狹隘思惟。沒有萬能的工具，只有最合適的工具。「不考慮場景的惟XX論」的觀點我我的很不認同。

具體到幾方面：
社區活躍和支持程度。MongoDB的mailing list和community很是得活躍，同時響應很迅速。
生態完善程度，包括文檔、輔助工具，以及是否方便得與既有基礎設施或工具集成。
這些方面使得學習和掌握的過程變得容易。

場景方面：
對於大部分startup，須要的是快速的業務迭代，這每每意味着需求的不穩定性，映射到產品和技術層面，可能就是模型的頻繁變化，因此DDL(schema)-free是個誘人的優點。
非強事務的場景，對於ACID要求嚴格的場景那確定是傳統的RDBMS更爲合適。
對spatialindex的支持很好，適合如今不少流行的空間查詢場景，好比相似「周圍的XX」，「多邊形關係」等。

開箱即用的一些分佈式能力支持，這個對於startup初期，儘可能減小devops的時間和精力仍是頗有必要的。

高可用如何作？
MongoDB具有開箱即用的複製集能力，經過典型的Primary＋Secondary＋Arbiter拓撲來構建複製集。
基本的結構就如這幅圖：

搭建很是容易，參考官方的手冊便可。複製集經過preference的設置，便可以達到讀寫分離的要求。MongoDB的選舉依賴bully算法，相似其餘分佈式算法，這方面須要注意的是「奇數實例數」、複製集最多12節點，其中7節點參與選舉在3.x版本變化比較大，後面講到。複製過程依賴oplog，相似MySQL裏的binlog，因此設置大小合適的oplog很重要，特別是在複製延遲比較高的場景裏。容易產生複製失敗而不得不進行全量的resync。

性能調優方面

先來講index相關的。
由於MongoDB查詢時先掃index再掃數據，因此查詢時若是隻要個別字段，而字段又偏偏有index的話，那就能夠直接返回這些字段，而省去掃數據的過程。

複合索引的次序問題，這個問題相似用多個漏斗篩東西，儘量將小漏斗放在前面（左側），極大地減小後續掃索引的量，能夠提升查詢的效率。除此以外，插入數據時，也可減小去更新索引樹的變化程度。
生產環境建議不要使用sparse index，浪費空間。

對已有數據作建立索引操做，若是是複製集環境，建議離線來作，避免因爲建索引的長耗時致使追不上而產生resync過程。

對於索引字段的數據類型的選擇，string類型的>>int類型的，因此儘量減少index的size，確保儘量將index都放入內存，應該選擇合適的索引數據類型。

對於document層面：在知足業務場景的狀況下，儘可能使用nested document，也就是說建模時儘量的反範式。一方面減小doc的總數量，同時減小查詢時磁盤IO的次數。

此外，doc中field的名字用盡量短的，這也是爲了減少doc的size大小若是業務場景中，doc內有不少text內容同時不會作文本內容的檢索，那建議都使用bindata來存。
對於statement方面：用好explain很重要，它是作進一步優化的指導數據。
好比這樣的事例：

這部分能夠進一步參考官方手冊，系統層面，因爲是per connection的粒度來建立線程，因此也要關注連接數，和對應操做系統的stacksize。

監控和排錯

監控和排錯監控的重要性不言而喻，若是已有各種監控基礎設施，那集成很是簡單。若是暫時沒有，推薦munin，或者也可以使用官方的mms服務（須要部署agent）。

MongoDB自帶的一些監控命令很是有用，好比mongostat和mongoshell中的db.stats。這裏須要重點關注pagefault %和lock %，這兩者，若是page率高，那須要關注讀場景的效率以及數據量和內存的狀況。若是lock率高，則要關注寫場景。好比合並寫，或者異步寫的方式。

IO繁忙的時候，數據文件（xyz.n）預分配會堵塞其餘操做，這種狀況下很是容易形成雪崩效應，因此能夠pretouch的方式去建立數據文件。

對於數據碎片化的狀況，建議離線的去repair database。經過profile，須要重點關注運行時full scan和update的場景，進而進行進一步的優化，特別是update，若是大部分狀況產生了moved，則須要經過填充佔位數據的方式去避免。經過explain，須要關注covered indexes和index usage的狀況，有針對性的建立或修改索引。

3.x版本是MongoDB很是重要的里程碑，其中有些feature很是有價值。好比提供更高壓縮率的壓縮方式，zlib和snappy，能有30%～50%的提升，至關於用壓榨cpu來換取內存中數據的使用率。

此外，是複製集的改進，明顯縮短選舉的過程。同時對於心跳檢測的過程複用複製的通道，並且能夠單獨控制選取的超時，這個有利於網絡環境差時的選舉過程。

對index的改進主要時支持partial index，特別適合索引中目標數據的值在所有數據中佔比很小的狀況，能極大的減少index的size。

最前面說到有些場景須要schema，因此3.x中支持schemavalidator能夠增強schema校驗拒絕無效數據。

Q&A
Q1：MongoDB如今的存儲引擎是否還存在斷電等極端狀況的數據安全性沒法保障問題 ？
A1：若是是複製集的環境，當前primarycrash了寫請求會路由到新的primary上，若是是shard的環境，影響得是局部shard，可是沒shard也應是HA的結構。除此以外，對於這種極端狀況，應用層也是須要作容錯，換作其餘組件這種場景也同樣。
Q2：創業初期業務多變，選型了MongoDB，隨着公司發展，業務也漸趨穩定，也在考慮從MongoDB遷往MySQL，什麼階段遷移比較合適，再者遷移的過程有什麼坑沒？
A2：首先遷移數據是折騰人的事兒，先想清楚遷移的目的和收益。從性價比角度來講是僞命題，從運維經驗掌控程度角度說，也是事在人爲的。最後回答你的問題，一般就是應用層雙寫，以後異步遷老數據，數據對其後，tcpcopy重放的方式來校驗數據，都沒問題了，就完事兒了。

＊此分享由LinkedIn中國技術主管魏佳在極牛線上技術分享羣裏所分享

【下期重磅預告】<主題>【如何守護企業核心數據安全】<講師>陳宇森，北京長亭科技有限公司聯合創始人、總裁。<大綱>1.介紹黑客入侵的常見思路、手段、目的。2.經過大量案例分析企業是在哪些關鍵環節出了疏漏致使發生了入侵事件。<時間>下週三（10月26日）晚8:00有意加入的技術朋友，請在極牛公衆號(ji-niu)裏回覆「技術分享」