MongoDb中集合概念就是关系型数据库中的表，本文讨论的内容主要集中在MongoDb数据库库设计集合时关键原则和常见的设计误区。
第一条准则
抛弃关系型数据库设计的范式约束，摒弃关联查询。先考虑内嵌形式，再考虑引用，视使用场景而定。内嵌形式，总体来说是对查询操作友好，对更新操作不友好。
MongoDb的设计原则建议多种对象以关联嵌套的方式组织在一个文档中，方便应用程序一次读取。
注意这里说的是建议，不是【必须】，因为有特定场景下，完全嵌套是不能满足存储需求的。
第二条准则
文档中不是每个字段都必须有值，也就是每行的字段可以不一致。控制字段尽量不插入null值和空值，这样可以节约内存存储，MongoDb中的稀疏索引类型专门为【不是每个文档都有的字段】而设计。
这种特性适合Iot数据采集类似的使用场景，每个文档的字段数目不等，按需插入。
注意这种情况下，切忌文档过宽。那如何避免这种情况，我的方法是预估最大字段数，以20个字段为节点，多于20则采用嵌套document的设计方式组织document。
第三条准则
时间可以直接定义为格式化的时间，便于识别和查询。不必特意存储时间戳，这样方便可视化的工具查询核对。
"create_time" : ISODate("2017-05-10T15:39:58.000+08:00"),
第四条准则
字段长度尽可能的短，不宜过长。也是考虑到内存优化。这样的话，也就是牺牲了数据库字段的语义性，实际开发中，很难评估是否应该真正彻底牺牲语义性，在跨系统的分布式开发模式下，对于同一业务语义字段在不同的业务系统中传递，如果字段长短不一致，来回变换，在开发中也是不小的成本，每次都需要对准文档，才能明确某一个字段的实际意义。
新概念
分桶设计原则
我们知道许多传感器数据都是时间序列数据。例如：风传感器，潮汐监测以及位置追踪等采集数据的无非这种类型： Timestamp，采集器名称/ID，采集值。对于时序类型的数据，我们可以采用一种叫做时间分桶的优化策略。
所谓分桶优化，就是与其对每一条数据创建一个文档，我们可以把某一个时间段内的测量数据聚合到一起放到一个文档内，利用MongoDB提供的内嵌式数组或子文档特性
时间序列数据
时间序列简单的说就是各时间点上形成的数值序列，时间序列分析就是通过观察历史数据预测未来的值。
官方有一篇翻译文章，专门叙述 分桶设计模式
我们的基础数据集如下
{
sensor_id: 12345,
timestamp: ISODate("2019-01-31T10:00:00.000Z"),
temperature: 40
}
{
sensor_id: 12345,
timestamp: ISODate("2019-01-31T10:01:00.000Z"),
temperature: 40
}
{
sensor_id: 12345,
timestamp: ISODate("2019-01-31T10:02:00.000Z"),
temperature: 41
}
改进后的文档集合如下
{
sensor_id: 12345,
start_date: ISODate("2019-01-31T10:00:00.000Z"),
end_date: ISODate("2019-01-31T10:59:59.000Z"),
measurements: [
{
timestamp: ISODate("2019-01-31T10:00:00.000Z"),
temperature: 40
},
{
timestamp: ISODate("2019-01-31T10:01:00.000Z"),
temperature: 40
},
…
{
timestamp: ISODate("2019-01-31T10:42:00.000Z"),
temperature: 42
}
],
transaction_count: 42,
sum_temperature: 2413
}
我们在程序写入文档时，可以做一些简单的计算和整理，按时间分段，根据业务需要，将一个时间断内的大量文档合并，避免数据使用时的随机聚合和查询。这样的时间段，可以理解为桶。
使用场景描述
在处理时间序列数据时，知道2018年7月13日加利福尼亚州康宁市下午2:00至3:00的平均温度通常比知道下午2:03那一时刻的温度更有意义也更重要。通过用桶组织数据并进行预聚合，我们可以更轻松地提供这些信息。
官方有一篇关于Iot使用场景的推荐文章 https://www.mongodb.com/customers/bosch，可以作为参考。
以上是MongoDb数据库关于集合设计的几个原则，实际开发中需要兼顾业务需求，查询友好，更新友好等量化标准做最终的判断。总之，在关系型数据库中的范式约束和联合查询，在MongoDb中基本忽略了。
另外很重要的一点需要明确，MongoDb中的集合也是需要设计的，不是随意写入即可的。
参考资料
http://www.mongoing.com/mongodb-advanced-pattern-design
http://www.tuicool.com/articles/Uv6zYnv
文章中的观点有不严谨之处，欢迎评论沟通。
抱着不确定性思维，学习MongoDb数据库的基本态度：边学习，边实践，边参考，边改进，在问题中成长。
