初识MongoDB数据库设计

MongoDB文档模型特点

• 读写效率高：通过文档模型把相关数据集中存储，IO性能上能米便花太多时间定位磁头

• 可扩展性强：关系型数据库难以做分布式的原因在于多节点海量数据关联有性能问题。但是文档模型没有关联，水平扩展方便

• 动态模式：支持可变数据模式

• 模型自然：接近熟悉的对象模型

设计原则

• 优先考虑内：一般的一对一、一对多关系可以通过内嵌放在一个文档中完成

• 引用：单个文档（一条记录）的存储大小在16M，如果内嵌字段超过16M，则考虑引用

最佳实践

• 内嵌：一条记录的项目较少，不会超过16M单条存储限制，即一条文档记录一个用户的购物车信息（tb限制购物车商品不超过99个）

• 关联：微博关注场景。如果使用内嵌，在一个collection中，每条文档记录一个用户的关注人和粉丝，那么因为被关注人和粉丝的量过大会超过16M。解决办法：为关联关系单独建立集合。

  eg.

  collection userInfo:
  { "_id": "tj", "fullname": "TJ Really Works", "age": 10, "tel": "12345",
      "followers": ["oscar", "mandy"],  // maybe too large
      "following": ["mandy", "bert"],   // maybe too large
  }

  --->

  collection userInfo:
  { "_id": "tj", "fullname": "TJ Really Works", "tel": "1234", "follower_count": 2, "following_count": 2}
  { "_id": "oscar", "fullname": "Oscar Really Works", "tel": "12345"}
  collection followRelations:
  { "_id": ObjectId(); "user": "tj", "following": "mandy"}
  { "_id": ObjectId(); "user": "tj", "following": "bert"}
  { "_id": ObjectId(); "user": "oscar", "following": "tj"}
  { "_id": ObjectId(); "user": "mandy", "following": "tj"}

1. 原userInfo集合中记录count，避免大规模计数时再去count占用资源

1. 将大规模的关联关系单独抽成一个集合，分散成不同的文档，随着关系的增加，文档条数增加，单条文档大小基本不变

• 大规模数据读写（数据实体存在关联关系情况下，互相之间的信息感知场景）

• 扇出读---从分布式数据库中各自取数据（微博刷新关注者的微博墙）---时间换存储

• 扇出写---用户发布内容时，向所有粉丝的记录中写内容。（微博刷新关注者的微博墙）---存储换时间（土豪玩法）

• 异构数据与分桶

• IOT场景文档metrics指标定时采集，通过分桶可以减少文档数目

参考文档

https://mongoing.com/mongodb-advanced-pattern-design