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...