MongoDB實戰經驗分享
本文來自去年整理髮布的“十天掌握MongoDB”系列PPT。該系列PPT的內容則來自當時的《MongoDB權威指南（英文版）》，個人翻譯能力有限，不能保證PPT的內容完全符合該書的內容。而且，我還加入了大量的自己的看法。今天分享給大家的便是其中的第十課，主要是我個人當時的觀點，這些觀點在現在看來不一定都是正確的，請大家多多批評指正！
對NoSQL的理解
NoSQL並不是No-SQL，而是指Not Only SQL。
NoSQL的出現是爲了彌補SQL數據庫因爲事務等機制帶來的對海量數據、高併發請求的處理的性能上的欠缺。
NoSQL不是爲了替代SQL而出現的，它是一種替補方案，而不是解決方案的首選。
絕大多數的NoSQL產品都是基於大內存和高性能隨機讀寫的（比如具有更高性能的固態硬盤陣列），一般的小型企業在選擇NoSQL時一定要慎重！不要爲了NoSQL而NoSQL，可能會導致花了冤枉錢又耽擱了項目進程。
NoSQL不是萬能的，但在大型項目中，你往往需要它！
爲什麼是MongoDB？
- 基於BSON，兼容JSON
- 有廣泛的驅動支持
- 高性能、開源、面向文檔
- 全文索引支持
- 自動複製分片
- 內置分佈式文件系統
- 內置MapReduce支持
- ……
不要被老陳騙了，我只是想羅列一下MongoDB的優點，如果想了解其他NoSQL產品，不妨看看http://cloud.csdn.net/a/20110610/299526.html
文檔結構設計
在SQL時代，我們可以任意設計自己的表結構，僅僅需要注意數據類型的選擇，只是無法直接使用樹形設計而已。
在MongoDB就沒這麼幸運了，MongoDB內置的查詢機制非常有限，它無法讓"你的原來的設計"那麼輕鬆的就能遷移過來。
其實，MongoDB這樣的"不給力"，都是"故意"的！通過核心算法的約束，強迫開發者大量的使用冗餘數據來提升計算效率。
這個做法，好！也不好！好的是，的確可以解決很多問題，不好的是，因此我們需要改變之前一貫的思路，甚至是之前認爲非常一般般的做法，還會給維護帶來很多"看起來不必要"的麻煩。
MongoDB宣稱自己佔用的處理器資源是很低的——其實是因爲它的架構就直接繞開了很多運算！！！
在這裏我沒有太多想說的，總結起來就一句話——不要吝嗇存儲空間，要將冗餘數據的優點發揮到極致！
索引及查詢優化
傳統的用於優化SQL的技巧，在MongoDB中同樣適用；
不要爲所有鍵都創建索引，也不要一個索引也不用；
如果需要，請優先考慮複合索引，但請注意鍵的順序；
如果發現即使創建索引也無法很有效的提升，此時應該考慮將數據分片；
設計查詢時，應當將能夠過濾掉大量記錄的條件放在前面，除非這樣的改動影響了業務需求。
無論什麼業務，請儘量避免在數據庫端處理各種排序，如果可以，請儘量減少這樣的設計，以提升數據庫服務器的吞吐量。老陳的經驗是：用戶其實並不討厭多點幾次鼠標，討厭的是點了N多次鼠標之後，找不到合適的內容。試想一下，爲什麼baidu不提供用戶主動排序的功能？
複製分片及副本集
複製是指將數據完完整整的複製到其他MongoDB實例上；
分片是將一塊數據很多小塊並分發到不同的集合或MongoDB實例；
副本集帶有故障轉移的特性
而實際上，在生產環境中，我們應當將如上三個概念混合使用，並發揮到極致。
數據安全、運算效率以及負載分流、故障轉移等等，每一個特性都需要做的很強壯！
還記得前面說過的嗎，NoSQL不是誰都可以玩的，也不是誰都可以玩好的！一個強壯的MongoDB集羣可能需要至少十幾臺服務器，光硬件就是不小的投入！
關於數據安全——不要迷信任何設備，應當經常備份重要的業務數據。
是的，使用複製可以對MongoDB的數據執行熱備份。而不需要停掉主數據庫引擎。
其他
儘量少用嵌套文檔，它會讓你的數據庫膨脹的非常快，且不利於擴展；
當然，我不是說不要用，如果沒有對子文檔的深層查詢、排序，或者根本就是記錄一下而已，這種情況用子文檔是最爽不過了！
MongoDB不適合存儲高精度的數字，比如你需要精度非常高的財務數據存儲，此時建議使用其他持久化方案，或者你乾脆就存成字符串或者創建一個字符串格式的副本進行存儲。
MongoDB沒有內聯查詢機制，全靠手工外鍵；
MongoDB沒有自增標識，未來的規劃中也沒有跡象表明要支持，實際上，這是MongoDB故意的！我們建議使用隨機標識，而不是遞增標識。
標識，讀作biaozhi4，而不是biaoshi2，記好了哈！