今天聊一下类似微信朋友圈这样的业务该怎么设计数据库的表结构，纯个人观点，希望能够提供一点参考价值。
数据库使用 MongoDB，因为 MongoDB 比较灵活，支持属性层级较复杂的数据存储，并且可以为这些属性设置索引，有些情况使用 mysql 可能要创建不少关联表然后联表查询，使用 MongoDB 程序能更简洁一些。此外 MongoDB 支持分片集群，对于数据量大的业务承载能力更好一些，下面涉及创建集合（相当于mysql中的表）的部分也会有分区键。
约定
为了直观易读，所有的集合中的数据结构都使用 TypeScript 的接口定义来表示。由于习惯问题，后面出现的 mongo 的集合，统一称作为表。
联系人
联系人表记录自己有哪些好友。
interface contact {
_id: string /**
* 用户id.
*/
userId: string /**
* 好友id.
*/
contactId: string // 其它属省略，不会出现在后面的查询中}创建唯一索引：
db.contact.createIndex({userId: 1, contactId: 1}, {unique: true})联系人标签
微信中有个给联系人打标签的功能，朋友圈动态可以使用标签来设置权限，所以我们要创建一个联系人标签表。
interface contactTag { _id: string; /**
* 创建人ID.
*/ creatorId:string; /**
* 用户ID.
*/ userId: string; /**
* 标签ID.
*/ tagId: string;
}创建唯一索引，将 userId 放在前面，方便使用 userId 查询自己被好友打上了哪些标签。
db.contactTag.createIndex({userId: 1, tagId: 1}, {unique: true})联系人权限
微信中可以对联系人设置朋友圈权限：不看他（她）、不让他（她）看我。所以我们增加一个权限设置表。
interface momentSetting { /**
* 与用户id一对一关联.
*/
_id: string /**
* 被排除的用户ID，不看他（她）.
*/
excludedUserIds: string[] /**
* 反向排除的用户ID，不让他（她）看我.
*/
reverseExcludedUserIds: string[]
}为 reverseExcludedUserIds 创建索引，用于查询自己被哪些好友屏蔽。
db.momentSetting.createIndex({reverseExcludedUserIds: 1})群
朋友圈的动态可以设置根据群设置权限，所以必须得得增加群用户这个表。
interface groupUser {
_id: string /**
* 微信群id.
*/
groupId: string /**
* 用户id.
*/
userId: string}创建唯一索引，将 userId 放在前面，方便查询自己所在的群。
db.groupUser.createIndex({userId: 1, groupId: 1}, {unique: true})朋友圈动态
微信朋友圈在发动态时，可以设置谁可以看：公共（所有人）、私密（仅自己）、部分可见（可设置人、群和标签）、不给谁看（可设置人、群和标签）。这些设置是单选的，只能选择一个。
下面是动态表的数据结构：
interface moment { /**
* 带有时间顺序的id，由时间戮加随机数生成.
*/
_id: string /**
* 作者id.
*/
creatorId: string /**
* 开放类型，公开、私密，部分人等. public 表示公开，private 表示私密，
* partly-visible 表示部分可见，partly-invisible 表示部分人不可见（不让谁看）.
* 当值为 partly-visible 或 partly-invisible，下面的几个属性才有效.
*/
openType: 'public' | 'private' | 'partly-visible' | 'partly-invisible', /**
* 受限或开放的群组id列表.
*/
groupIds: string[] /**
* 受限或开放的标签id列表.
*/
tagIds: string[] /**
* 受限或开放的用户id列表.
*/
userIds: string[] // 其它的属性，如内容、创建时间等字段此处省略，这些字段不出现在查询语句中}本文主要说明如何做查询，内容等字段不出现在查询语句中，此处省略，不做相关的介绍。然后我们为创建人id和_id创建索引，以方便后面按时间顺序查询记录。
db.moment.createIndex({creatorId: 1, _id: -1})动态表可以将 creatorId 设置为分区键，这样不同的用户的数据会分布在不同的节点上，在写入数据时能避免热片问题。
sh.shardCollection( "库名.moment", { "creatorId" : "hashed" } )查询流程
相关的表都已经创建好了，现在可以开始做查询逻辑了。
获取朋友圈可见的好友ID列表
从联系人集合中查询当前用户所有好友的ID，在程序中存为 contactIds 。
db.contact.find({userId:'当前用户ID'},{contactId:1})从动态设置集合中查询当前用户被哪些好友屏蔽，得到这些好友的ID，在程序中存为 unfriendlyContactIds 。
db.momentSetting.find({reverseExcludedUserIds:'当前用户ID'},{_id:1})从动态设置表中查询当前用户屏蔽了哪些好友，得到这些好友的ID，在程序中存为 excludedUserIds 。
db.momentSetting.find({_id:'当前用户ID'},{excludedUserIds:1})然后从 contactIds 删除掉 unfriendlyContactIds 和 excludedUserIds 中包含的用户ID，得到所有可以查看朋友圈的好友ID，在程序中记为 friendlyContactIds。
获取所有标签ID
从联系人标签集合中查询当前用户被好友打上的所有标签的ID，在程序中存为 tagIds 。
db.contactTag.find({userId:'当前用户ID'},{tagId:1})获取所有群组ID
从君用户集合中查询当前用户所在的所有群ID，在程序中记为 groupIds 。
db.groupUser.find({userId:'当前用户ID'},{groupId:1})查询动态表
经过前面的几次查询，我们得到以下数据：
变量名称 | 说明 |
friendlyContactIds | 朋友圈可见的好友id列表 |
tagIds | 被所有好友打上的标签id列表 |
groupIds | 加入的所有群组id列表 |
有了这些信息，就可以从动态集合（表）中查询记录了。上面的信息不需要每次都重新查询一次，可以查询后缓存一段时间，一般情况下很少会有改动，加载新动态时可直接复用。
db.moment.find({
creatorId: {$in: '插入 friendlyContactIds'}
_id: {$gt: '上次查询最后一条记录的ID'}, $or: [
{openType: 'public'},
{
openType: 'partly-visible', $or: [
{groupIds: {$in: '插入 groupIds'}},
{tagIds: {$in: '插入 tagIds'}},
{userIds: '当前用户ID'}
]
},
{
openType: 'partly-invisible', $and: [
{groupIds: {$nin: '插入 groupIds'}},
{tagIds: {$nin: '插入 tagIds'}},
{userIds: {$ne: '当前用户ID'}}
]
}
]
}).sort({_id: -1}).limit(20)上面的查询语句中需要程序中动态插入前面查询到的数据记录，_id 的过虑条件用于翻页，首次查询不需要。查询主要依赖于动态表的字段 creatorId 和 _id 联合索引，群组ID、标签ID和用户ID没有必要创建索引，意义不大。
总结
整个流程没有什么复杂的查询，仅最后查询动态表稍微麻烦一点点。随着好友数量的增加，查询的效率会有所降低，所以业务上需要限制好友的数量。
