Mongo設計原則

Collection 的單個 doc 有大小上限，現在是 16MB，這就使得你不可能把所有東西都揉到一個 collection 裏。而且如果 collection 結構過於複雜，既會影響查詢、更新效率，也會造成維護困難和操作風險。你有嘗試過手一抖就把一個 doc 不小心存成 null 的麼，反正我做過，要是一個人所有信息都在這個 collection 裏面，那感覺一定相當酸爽吧。

一般的原則是：

    按照查詢方式來聚類

        需要經常一起讀取的數據放一起.
        在邏輯上關係緊密的信息放在一起。
        有 map-reduce/aggregation 需求的數據放在一起，這些操作都只能操作單個 collection。
    按照數據量來拆分

        如果發現要在 collection 裏面用數組，數組長度還會不斷增加，那麼應該把數據內容放到一個專門的 collection，每條數據都引用當前這個 doc 的主鍵（就像 mysql 的 1..N 外鍵依賴一樣）。
        如果發現某個 doc 層次過深（超過 2 層），八成得考慮要拆分了，要不然性能和可維護性都會有問題。
    按照有表結構的方式來設計

        MongoDB 是沒有表結構這個概念的，但是實際使用的時候，很少說一個 collection 裏面存在各式各樣結構的 doc，如果發現 doc 的結構差別越來越大了，那麼應該考慮怎麼抽象成類似結構，把變化的東西扔到其他 collection 去，用外鍵依賴的方式互相引用。

比如設計一個用戶系統，user collection 應該放 name 等常用的信息，也應該放 lastLoginAt 這些僅跟 user 相關的東西，或許應該把用戶有哪些訪問權限的信息也放進來，但是不要放用戶的登錄日誌這種信息會不斷增加的信息。

至於 user 之間的關係是否存在 user collection 則需要討論。假如僅僅需要存儲用戶間的關係，記錄下好友的 uid 就行，而且好友數量也不太大，幾百個最多了，那麼我傾向於放在一個 collection 裏。如果關係數據本身就比較複雜，或者好友數會上千，那我傾向於拆分。

另外，Mongodb 官方的 數據模型設計範式 很值得一讀，推薦去好好看看。

轉自：MongoDB傾向於將數據都放在一個Collection下嗎？