Mongodb，当数据访问频率低于 RAM 容量时的工作集

Question

我已阅读what-does-it-mean-to-fit-working-set-into-ram-for-mongodb。但我对 mongodb 内存管理非常困惑。 假设我有一台 40G RAM 的机器。我用mongo开发一个游戏，有两个合集。

• 用户，这个集合一直在增长，每月1G数据+0.1G指数，但只有部分用户活跃，假设只有1G数据活跃。是不是意味着这个collection大概会使用1G + 0.1G *month mem，就像应用上线10个月会消耗2G mem一样。

• game_record_${yyyy_MM}，可能包含uid、gameId、win、score、time等列。 此集合存储游戏记录，用户玩游戏时创建的数据，用户与game_record_${yyyy_MM}集合是1：n关系，此集合也在不断增长，每月10G数据+ 1G索引。它是按月分片的（手工分片程序）。假设应用已经上线10个月左右，那么总数据是110G。 有收藏

• user_game_2018_01

• user_game_2017_12
• user_game_2017_11
• user_game_2017_10
• ...
• user_game_2017_01

数据访问模式只是一个简单的分页查询。

db.game_record_${yyyy_MM}.find({uid: 'Kelvin'}).sort({time:-1}).skip(n).limit(10) //n keep update for continuous query

程序不断从当前搜索数据传递。 问题是： 我们假设大多数用户只会检查他们最近 3 个月的数据，因此只有三个数据集合处于活动状态并且都适合内存，它将消耗 33G RAM。在最坏的情况下，当一些用户一直在那里导航到最旧的游戏数据时，所有的集合都会被查询。 mongo 会发生什么，最旧的集合是否会适合内存并换出当前活动的集合，如 user_game_201801

Answer 1

在您的情况下不会出现此问题，因为 Mongo 将索引保留在 RAM 中而不是集合数据中。

因此，在您的情况下，10 个月后您将拥有来自用户集合的 1GB 索引和来自 game_record_{yyyy_MM} 集合的 10GB 索引。

所以你有 11GB 的索引，即小于你的 RAM 大小。