实时查询大型mongodb集合

Question

我们提供的服务允许用户打开房间播放YouTube歌曲，而其他人则实时收听。

在我们的MongoDB中的其他馆藏中，我们有一个存储用户添加到房间播放列表的歌曲，它叫：userSong。 此集合包含为以下组合添加的所有歌曲的记录：user-room-song。

代码在这些主要操作中频繁查询集合：

1. 加载当前播放列表（常规查找具有微不足道的条件）
2. 为一个房间加载随机歌曲（使用Mongo聚合FW）
3. 加载房间热门歌曲（使用Mongo聚合FW）

现在，这个表变得很大（+ 1m记录）并且事情开始变慢，AWS开始更频繁地向我们发送CPU利用率通知，然后跟随mongotop userSong集合使得CPU主要在READ操作中消耗高。

我们对集合索引进行了一些修改，但它有点帮助但它仍然不是解决方案，我们需要找到一些其他方法来排列数据，因为它会呈指数级增长。

我们试图将userSong数据分成低级别分段，而不是通过用户房间歌曲将系统中的每个房间的用户歌曲收集分开，这将缩短从中获取数据的时间DB，现在我们需要决定如何做到这一点：

1. 为每个房间（roomUserSong）制作一个新的集合，该集合将保存特定房间的所有用户歌曲记录。这可能对快速提取很有帮助，但会在数据库中创建一个无限的新收集者（roomusersong-1，roomusersong-2，...，roomusersong-n），我们不知道它在实践中是否有用或有其他一些Mongo在这种解决方案方面存在局限性。
2. 使用以下字段在DB中再创建一个集合： {room: <roomId>, userSongs: [{userSong1, userSong2, ..., userSongN}]，因此每个房间都有自己的文档，里面有一个子文档（一个数组），用于保存这个房间的所有用户歌曲记录。这将解决上一个问题（创建无限集合），但是很难使用Mongoose（我们的ODM）更改原因（据我所知）我们无法为此类数据结构定义高级模式。据我们所知，这可能会使我们达到16MB的子文档大小限制。

听到Mongo在这种情况下经历过的人的建议，我们会很高兴：

1. + 1m是否真的被认为是大的并且应该使这个CPU利用率问题？ （使用AWS m3.medium，一个核心）
2. 什么是更好的解决方案形式？
3. 制作智能缓存的其他任何想法都没有太多改变代码？

感谢帮助者！