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

關系模型存法

不多介紹，可以按照范式設計成跟關系數(shù)據(jù)庫一樣的表結構來存儲，大概是：

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

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

1. 評論
2. 點贊

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

非關系模型存法

{
    _id: ObjectId(...),
    musicId: "...",
    // 根據(jù)需要可能將音樂本身的一些數(shù)據(jù)冗余進來
    musicName: "...",
    comments: [
        {content: "...", time: ISODate(...), user: "..."},
        {content: "...", time: ISODate(...), user: "..."},
        {content: "...", time: ISODate(...), user: "..."},
        ...
    ],
    count: 10, // 該桶內已有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位是時間，所以是可以排序的，其順序就是時間順序。
點贊的問題可以通過類似的方式實現(xiàn)，就留給你自己思考了。

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

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

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

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