網(wǎng)易云音樂的評(píng)論回帖是怎么存的？

僅從MongoDB的角度說明這種東西可以怎么存。至于別人到底是怎么存，我們是不知道的。

關(guān)系模型存法

不多介紹，可以按照范式設(shè)計(jì)成跟關(guān)系數(shù)據(jù)庫(kù)一樣的表結(jié)構(gòu)來存儲(chǔ)，大概是：

{
    _id: ObjectId(...),
    comment: "...",
    time: ISODate(...),
    user: "...",
    musicId: "...",
    ...
}

如果用慣關(guān)系數(shù)據(jù)庫(kù)的用戶，這樣的做法簡(jiǎn)單自然。在現(xiàn)在討論的場(chǎng)景下，這樣沒有太大的問題，在數(shù)據(jù)量大時(shí)可以使用分片來達(dá)到水平擴(kuò)展以應(yīng)對(duì)數(shù)據(jù)量的增長(zhǎng)。
不過仍有可以改進(jìn)的地方。這要從MongoDB的模型設(shè)計(jì)來講起。簡(jiǎn)單地說，MongoDB是實(shí)用主義，怎么方便怎么來，怎么快怎么來，完全不應(yīng)該受范式的約束。但這也意味著你的模型要從應(yīng)用的需求出發(fā)。僅從上面截圖的信息，可能有2個(gè)不同的需求：

1. 評(píng)論
2. 點(diǎn)贊

考慮到評(píng)論和點(diǎn)贊都有可能上萬甚至上十萬百萬，它們以單獨(dú)的集合來存放會(huì)比較合適。但是為了讀取和存儲(chǔ)效率，我會(huì)考慮把多條評(píng)論壓縮到一起，這種方式通常稱為分桶(bucket)。

非關(guān)系模型存法

{
    _id: ObjectId(...),
    musicId: "...",
    // 根據(jù)需要可能將音樂本身的一些數(shù)據(jù)冗余進(jìn)來
    musicName: "...",
    comments: [
        {content: "...", time: ISODate(...), user: "..."},
        {content: "...", time: ISODate(...), user: "..."},
        {content: "...", time: ISODate(...), user: "..."},
        ...
    ],
    count: 10, // 該桶內(nèi)已有10條comments
}

comments的數(shù)據(jù)量我會(huì)考慮一頁會(huì)展示多少評(píng)論（比如30條），那么在添加評(píng)論時(shí)可以有：

db.comments.updateOne({
    musicId: "...",
    count: {$lt: 30}
}, {
    $push: {
        comments: {content: "...", time: ISODate(...), user: "..."}
    },
    $inc: { count: 1 }
}, {
    upsert: true
});
// 優(yōu)化查詢速度會(huì)使用到索引：
db.comments.createIndex({
    musicId: 1,
    count: 1
});

在查詢時(shí)總是只需要最多取最新的2條記錄就可以查到第一頁：

db.comments.find({
    musicId: "..."
}).sort({_id: -1}).limit(2)
// 這個(gè)查詢需要索引
db.comments.createIndex({
    musicId: 1,
    _id: -1
});

注意_id的高4位是時(shí)間，所以是可以排序的，其順序就是時(shí)間順序。
點(diǎn)贊的問題可以通過類似的方式實(shí)現(xiàn)，就留給你自己思考了。

效率低？ MySQL 畢竟是個(gè)久經(jīng)考驗(yàn)的數(shù)據(jù)庫(kù)，它沒你想得那么脆弱。

再一個(gè)，討論問題要考慮場(chǎng)景：

1. 是不是所有歌曲都有幾十萬的評(píng)論量？
2. 網(wǎng)易云音樂歌曲的 評(píng)論 看起來只有 贊數(shù) 這個(gè)字段會(huì)在記錄生成后被修改，這意味著大多數(shù)時(shí)間它都是只讀的，因此對(duì)于熱門評(píng)論可以做熱緩放在前面抗壓。
3. 并不是一次性拉取幾十萬條評(píng)論到客戶端，如前面所說，熱評(píng)可以放熱緩分壓，客戶端方面即使拉取不那么熱的評(píng)論，也可以一次十條/百條去拉。
4. 其實(shí)這種大量只讀的情況下，熱緩做得好，命中率高的話，數(shù)據(jù)庫(kù)方面本身就不會(huì)承受特別多的壓力。

以上僅是個(gè)人想法，有錯(cuò)誤還請(qǐng)指正 ：)