我有一个分片和复制的 MongoDB,有数千万条记录。我知道 Mongo 使用一些填充因子写入数据,以允许快速更新,而且我也知道要复制数据库 Mongo 应该存储需要一些(实际上是很多)空间的操作日志。即使有了这些知识,我也不知道如何在给定典型数据库记录大小的情况下估计 Mongo 所需的实际大小。到目前为止,每周维修之间的差异为 2 - 3 倍。
所以问题是:给定平均记录大小(以字节为单位),如何估计 MongoDB 所需的总存储大小?
我有一个分片和复制的 MongoDB,有数千万条记录。我知道 Mongo 使用一些填充因子写入数据,以允许快速更新,而且我也知道要复制数据库 Mongo 应该存储需要一些(实际上是很多)空间的操作日志。即使有了这些知识,我也不知道如何在给定典型数据库记录大小的情况下估计 Mongo 所需的实际大小。到目前为止,每周维修之间的差异为 2 - 3 倍。
所以问题是:给定平均记录大小(以字节为单位),如何估计 MongoDB 所需的总存储大小?
简短的回答是:你不能,而不是仅仅基于 avg。文档大小(至少不是以任何准确的方式)。
更详细地解释:
磁盘上所需的空间不仅仅是平均文档大小的函数。您创建的任何索引也需要空间。然后,如果您确实触发了这些移动,则需要空间(尽管有填充,这确实发生了) - 该空间被放置在一个列表中以供重复使用,但取决于您随后插入的数据,它可能会或可能不会重新使用该空间。
您还可以添加一个事实,即预分配意味着有时少数文档会在分配新数据文件时将您的磁盘空间利用率增加约 2GB。当然,如果有足够的数据,这本质上是一个舍入误差,但值得牢记。
假设使用模式一致,估计这种类型的数据与大小比率的唯一方法是随着时间的推移针对您的特定用例对其进行趋势分析,并跟踪磁盘空间使用情况与插入的数据(文档数量可能优于数据量)取决于文档大小的可变性)。
同样,如果您跟踪插入率、文档大小和从重新同步/修复中获得的空间。仅供参考 - 您可以从头开始重新同步辅助服务器以获得数据文件的“新”副本,而不是运行修复,这可以减少破坏性,并且根据您的设置使用更少的空间。