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

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

關(guān)系模型存法

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

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

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

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

考慮到評論和點(diǎn)贊都有可能上萬甚至上十萬百萬，它們以單獨(dú)的集合來存放會比較合適。但是為了讀取和存儲效率，我會考慮把多條評論壓縮到一起，這種方式通常稱為分桶(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ù)量我會考慮一頁會展示多少評論（比如30條），那么在添加評論時可以有：

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

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

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

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

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

再一個，討論問題要考慮場景：

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

以上僅是個人想法，有錯誤還請指正 ：)