MongoDB實戰經驗分享

**：

nosql並不是no-sql，而是指not only sql。

nosql的出現是為了彌補sql資料庫因為事務等機制帶來的對海量資料、高併發請求的處理的效能上的欠缺。

nosql不是為了替代sql而出現的，它是一種替補方案，而不是解決方案的首選。

絕大多數的nosql產品都是基於大記憶體和高效能隨機讀寫的（比如具有更高效能的固態硬碟陣列），一般的小型企業在選擇nosql時一定要慎重！不要為了nosql而nosql，可能會導致花了冤枉錢又耽擱了專案程序。

nosql不是萬能的，但在大型專案中，你往往需要它！

在sql時代，我們可以任意設計自己的表結構，僅僅需要注意資料型別的選擇，只是無法直接使用樹形設計而已。

在mongodb就沒這麼幸運了，mongodb內建的查詢機制非常有限，它無法讓"你的原來的設計"那麼輕鬆的就能遷移過來。

其實，mongodb這樣的"不給力"，都是"故意"的！通過核心演算法的約束，強迫開發者大量的使用冗餘資料來提公升計算效率。

這個做法，好！也不好！好的是，的確可以解決很多問題，不好的是，因此我們需要改變之前一貫的思路，甚至是之前認為非常一般般的做法，還會給維護帶來很多"看起來不必要"的麻煩。

mongodb宣稱自己占用的處理器資源是很低的——其實是因為它的架構就直接繞開了很多運算！！！

在這裡我沒有太多想說的，總結起來就一句話——不要吝嗇儲存空間，要將冗餘資料的優點發揮到極致！

傳統的用於優化sql的技巧，在mongodb中同樣適用；

不要為所有鍵都建立索引，也不要乙個索引也不用；

如果需要，請優先考慮復合索引，但請注意鍵的順序；

如果發現即使建立索引也無法很有效的提公升，此時應該考慮將資料分片；

設計查詢時，應當將能夠過濾掉大量記錄的條件放在前面，除非這樣的改動影響了業務需求。

無論什麼業務，請盡量避免在資料庫端處理各種排序，如果可以，請儘量減少這樣的設計，以提公升資料庫伺服器的吞吐量。老陳的經驗是：使用者其實並不討厭多點幾次滑鼠，討厭的是點了n多次滑鼠之後，找不到合適的內容。試想一下，為什麼baidu不提供使用者主動排序的功能？

複製是指將資料完完整整的複製到其他mongodb例項上；

分片是將一塊資料很多小塊並分發到不同的集合或mongodb例項；

副本集帶有故障轉移的特性

而實際上，在生產環境中，我們應當將如上三個概念混合使用，並發揮到極致。

資料安全、運算效率以及負載分流、故障轉移等等，每乙個特性都需要做的很強壯！

還記得前面說過的嗎，nosql不是誰都可以玩的，也不是誰都可以玩好的！乙個強壯的mongodb集群可能需要至少十幾台伺服器，光硬體就是不小的投入！

關於資料安全——不要迷信任何裝置，應當經常備份重要的業務資料。

是的，使用複製可以對mongodb的資料執行熱備份。而不需要停掉主資料庫引擎。

盡量少用巢狀文件，它會讓你的資料庫膨脹的非常快，且不利於擴充套件；

當然，我不是說不要用，如果沒有對子文件的深層查詢、排序，或者根本就是記錄一下而已，這種情況用子文件是最爽不過了！

mongodb不適合儲存高精度的數字，比如你需要精度非常高的財務資料儲存，此時建議使用其他持久化方案，或者你乾脆就存成字串或者建立乙個字串格式的副本進行儲存。

mongodb沒有內聯查詢機制，全靠手工外來鍵；

mongodb沒有自增標識，未來的規劃中也沒有跡象表明要支援，實際上，這是mongodb故意的！我們建議使用隨機標識，而不是遞增標識。

標識，讀作biaozhi4，而不是biaoshi2，記好了哈！