MongoDB数据建模小案例

MongoDB数据建模小案例

朋友圈评论内容管理

需求

社交类的APP需求，一般都会引入“朋友圈”功能，这个产品特性有一个非常重要的功能就是评论体系。

先整理下需求：

• 这个APP希望点赞和评论信息都要包含头像信息：
  1. 点赞列表，点赞用户的昵称，头像；
  2. 评论列表，评论用户的昵称，头像；

• 数据查询则相对简单：
  1. 根据分享ID，批量的查询出10条分享里的所有评论内容；

建模

不好的设计

跟据上面的内容，先来一个非常非常"朴素"的设计：

{

  "_id": 41,

  "username": "小白",

  "uid": "100000",

  "headurl": "http://xxx.yyy.cnd.com/123456ABCDE",

  "praise_list": [

    "100010",

    "100011",

    "100012"

  ],

  "praise_ref_obj": {

    "100010": {

      "username": "小一",

      "headurl": "http://xxx.yyy.cnd.com/8087041AAA",

      "uid": "100010"

    },

    "100011": {

      "username": "mayun",

      "headurl": "http://xxx.yyy.cnd.com/8087041AAB",

      "uid": "100011"

    },

    "100012": {

      "username": "penglei",

      "headurl": "http://xxx.yyy.cnd.com/809999041AAA",

      "uid": "100012"

    }

  },

  "comment_list": [

    "100013",

    "100014"

  ],

  "comment_ref_obj": {

    "100013": {

      "username": "小二",

      "headurl": "http://xxx.yyy.cnd.com/80232041AAA",

      "uid": "100013",

      "msg": "good"

    },

    "100014": {

      "username": "小三",

      "headurl": "http://xxx.yyy.cnd.com/11117041AAB",

      "uid": "100014",

      "msg": "bad"

    }

  }

}

可以看到，comment_ref_obj与praise_ref_obj两个字段，有非常重的关系型数据库痕迹，猜测，这个系统之前应该是放在了普通的关系型数据库上，或者设计者被关系型数据库的影响较深。而在MongoDB这种文档型数据库里，实际上是没有必要这样去设计，这种建模只造成了多于的数据冗余。

另外一个问题是，url占用了非常多的信息空间，这点在压测的时候会有体现，带宽会过早的成为瓶颈。同样username信息也是如此，此类信息相对来说是全局稳定的，基本不会做变化。并且这类信息跟随评论一起在整个APP中流转，也无法处理”用户名修改“的需求。

根据这几个问题，重新做了优化的设计建议。

推荐的设计

{

  "_id": 41,