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中流转，也无法处理”用户名修改“的需求。

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