lesismal
2021-11-20 16:21:35 +08:00
### 选型
因为楼主希望不要用 mysql ,所以选择 mongodb ,能支持的数据量足够大,并且 nosql 方便扩展
### 信件存储方案(按类型分别处理,广播类信件去重)
1. 系统发给用户,多个用户收到的是相同内容:只插入一条到 letter 集合中
2. 系统发给用户,多个用户收到的是不同内容:一个用户一条插入到 letter 集合中,类似用户发给用户
3. 用户发给用户:每个一条插入到 letter 集合中
### mongodb 集合( collection )和 文档( document )设计
mongodb 的 collection 相当于 mysql 的 table
collection 里的 document 相当于 table 的一条数据 collection 设计:
1. collection name: letter
document struct:
{
"_id": xxx, //mongodb 自带的就行
typ: system/p2p/...,
time: xxx,
from: userid:name, //用户之间的会有这个字段,系统发的看功能设计是否需要
content: xxx,
...
}
2. collection name: letter_list
document struct:
{
userid: xxx,
letters: [
{
id: letter_id_xxx, // 根据信件 id 去 letter 里查
time: xxx,
readed: 0,
},
......
],
}
优化:上面的 1 、2 中的 document 是为了方便展示,直接是用展开的结构字段,实际使用中,应该把各个字段合并编码、减少字段数量、从而减少相应的计算消耗和存储空间占用等成本,比如冒号分隔符分割多个字段,取出后 splitN 得到各个字段内容
letter 可以优化成:
{
"_id": xxx, //mongodb 自带的就行
info: "type:time:from:content", // 例如: "0:1637396101::您的超级 VIP 已经开通!", "1:1637396101:用户 B:您的回复太棒了,非常感谢!"
// content 应该放在最后,以面 content 中有冒号时放在中间 splitN 无法正常解析
}
letter_list 可以优化成:
{
"_id": xxx, //mongodb 自带的就行
info: "id:time:readed", // 如:"aaaa:1637396101:0"
}
### 其他
具体细节以及 mongo 的一些优化,请根据自己实际情况进行