共计 1814 个字符，预计需要花费 5 分钟才能阅读完成。
自动写代码机器人，免费开通
MongoDB 数据库容量规划是指什么，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面丸趣 TV 小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
MongoDB 数据库容量规划是什么
我们讨论的存储，说到底都是基于操作系统之上的一个应用软件，而操作系统能利用的，无非是系统的存储：磁盘、内存、CPU cache 等等。所以容量规划的意义就是：按要存储的数据特点，针对一段时间的数据量，对机器各个存储的容量、性能及系统配置进行合理预估。
通常这个问题在实际容量规划中可以化简为对内存，硬盘容量和性能的预估。
下面我们就以 MongoDB 为例说一下容量预估的一些计算方法。我们通常的一个粗糙的要求是要将所有热数据放到内存中。这里的热数据可能包括经常访问的数据，索引和系统开销。下面我们就这三个方面进行说明：
常访问的数据
根据不同的应用场景，你可以对数据访问情况进行预估。比如用 MongoDB 保存帖子内容，每个帖子大小为 1k，目前有 1 亿个帖子，每天新增 100w 个帖子，那么 3 个月后帖子量大概为 2 亿，需要 200G 的硬盘空间。
每天新增的 100w 帖子是常访问的，而可能我们每天活跃访问的贴子为 200w，也就是说另外 100w 是之前的老帖子。如果我们规划给热数据的内存大小为 1G，那只能装下 100w 数据，装不了 200w 数据。由于帖子访问的随机性，最坏的情况是我们每次访问的数据都不在内存中 (比如先访问了不在内存中的 100w，加载到内存中，再访问刚刚被换到磁盘上的数据，又需要再加载一次)，需要进行和 PV 相同次数的磁盘 IO，灾难! 最好的情况我们也需要 100w 次 磁盘 IO(比如先对在内存中的 100w 数据进行频繁访问，再对不在内存中的 100w 数据进行频繁访问)，在访问频率均匀的情况下，每秒需要进行大概 12 次 的磁盘 IO。
那我们把规划给热数据的内存大小调为 2G，看看会如何，这时候一天 200w 热数据正好能装下。那么最好的情况下，需要进行 100w 次磁盘 IO(比如 200w 数据中的 100w 老数据全都在昨天的热数据中，则只需要对 100w 数据进行重新加载)，在访问频率均匀的情况下，每秒需 要进行大概 12 次的磁盘 IO。最坏的情况下，需要进行 200w 次磁盘 IO(比如今天访问的 200w 条数据和昨天的热数据没有重合)，在访问频率均匀的情况 下，每秒需要进行大概 25 次的磁盘 IO。
MongoDB 数据库容量规划是什么
同理，我们再增大内存，会需要访问的数据在内存中的机率增大，从而减小磁盘 IO 的频率。
上面说的是一个简单例子，具体你可以根据自己的数据访问特性进行评估和计算，而且不仅要算平均 IO，更重要的是巅峰 IO。
同时不要忘了，MongoDB 还会定时调用 fsync 将内存中的脏页 flush 到磁盘 (默认一分钟一次)，你可以根据你自己脏数据的量或者比例来评估每次的 IO，然后你再考虑是否需要将 fsync 的频率调低一点。
如果你还开启了 journaling log，那这个 IO 量也需要加进去。
当然，接下来的就是你的磁盘是否能够承受最终的 IO 量，然后你可以考虑你是否需要使用更快的硬盘，是否需要 RAID，是否需要换用 SSD 等等了。
索引量
索引和常访问数据不同，索引要求全部放在内存中，所以索引的容量计算就相对容易很多。通过 MongoDB 的 db.stats() 命令就能看到你当前占用 的索引大小。比如上面的例子，现在 1 亿条数据如果索引大小为 5G 的话，那么 2 亿条的时候大概需要 10G。所以内存必须要装下这 10G 索引。
系统开销
MongoDB daemon 的开销基本可以理解为一个常数，所以这里的系统开销就主要是连接开销。这取决于你的应用特点。比如你最大的并发操作为 100。也就是同时 100 个连接与 MongoDB 相连。每个连接一个线程开销为系统的 stack size 设置，默认是 10M，那就是 1G(当然你可以适当调整这个值)。需要对数据进行实时排序的话，需要再算上排序时的内存开销。
总结
当然，上面讲的是一个简单的预估方法，我们不期望能够通过计算得出真实的容量估算结果，毕竟互联网产品的变化总是那么不可控。但是在部署前按业务情况进行相关的容量预估是非常重要的。好的预估可以在金钱、性能和运维成本上得到一个相对平衡的结果。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注丸趣 TV 行业资讯频道，感谢您对丸趣 TV 的支持。
向 AI 问一下细节
