MongoDB開發系列：從數據集合的設計開始

MongoDb中集合概念就是關係型數據庫中的表，本文討論的內容主要集中在MongoDb數據庫庫設計集合時關鍵原則和常見的設計誤區。本文約定讀者對MongoDb的基本概念有必定的瞭解。

第一條準則

拋棄關係型數據庫設計的範式約束，摒棄關聯查詢。先考慮內嵌形式，再考慮引用，視使用場景而定。內嵌就是充分利用MongoDb的文檔特定，經過嵌套文檔的形式，將一組數據統一保存在一個文檔下。即一條記錄中，這樣在列表類的需求中，就不須要多表查詢，以及外鍵關聯。

MongoDb的設計原則建議多種對象以關聯嵌套的方式組織在一個文檔中，方便應用程序一次讀取。

注意這裏說的是建議，不是【必須】，由於有特定場景下，徹底嵌套是不能知足存儲需求的。

第二條準則

文檔中不是每一個字段都必須有值，也就是每行的字段能夠不一致。控制字段儘可能不插入null值和空值，這樣能夠節約內存存儲，MongoDb中的稀疏索引類型專門爲【不是每一個文檔都有的字段】而設計。

這種特性適合Iot數據採集相似的使用場景，每一個文檔的字段數目不等，按需插入。

注意這種狀況下，切忌文檔過寬。那如何避免這種狀況，個人方法是預估最大字段數，以20個字段爲節點，多於20則採用嵌套document的設計方式組織document。

第三條準則

時間能夠直接定義爲格式化的時間，便於識別和查詢。沒必要特地存儲時間戳，這樣方即可視化的工具查詢覈對。

"create_time" : ISODate("2017-05-10T15:39:58.000+08:00"),

固然若是系統涉及到不一樣時區的國際化，最好把原始時間戳記錄下來，視狀況是否記錄源時區。

第四條準則

字段長度儘量的短，不宜過長。也是考慮到內存優化。MongoDb存儲原則中會把key也存儲到內存中，因此字段因儘量的短，這樣勢必會減低字段的可讀性，是的，這裏須要犧牲字段的可讀性。

新概念

分桶設計原則

咱們知道許多傳感器數據都是時間序列數據。例如：風傳感器，潮汐監測以及位置追蹤等採集數據的無非這種類型： Timestamp，採集器名稱/ID，採集值。對於時序類型的數據，咱們能夠採用一種叫作時間分桶的優化策略。

所謂分桶優化，就是與其對每一條數據建立一個文檔，咱們能夠把某一個時間段內的測量數據聚合到一塊兒放到一個文檔內，利用MongoDB提供的內嵌式數組或子文檔特性

參考資料

http://www.mongoing.com/mongo...

http://www.tuicool.com/articl...

https://segmentfault.com/q/10...