私は数千万のレコードを持つ断片化され複製された MongoDB を持っています。Mongo は高速更新を可能にするためにパディング ファクターを使用してデータを書き込むことを知っています。また、データベースをレプリケートするために、Mongo は操作ログを保存する必要があることも知っています。その知識があっても、典型的なデータベース レコードのサイズを考慮して、Mongo が必要とする実際のサイズを見積もる方法がわかりません。今では、毎週の修理の間に 2 ～ 3 倍の不一致があります。
問題は、MongoDB が必要とする合計ストレージ サイズを、バイト単位の平均レコード サイズから見積もる方法です。
短い答えは次のとおりです。平均だけに基づいているわけではありません。文書サイズ (少なくとも正確な方法ではありません)。
より詳細に説明するには:
ディスクに必要な容量は、単純にドキュメントの平均サイズの関数ではありません。作成するインデックスに必要なスペースもあります。次に、これらの移動をトリガーする場合に必要なスペースがあります (パディングにもかかわらず、これは発生します)。そのスペースはリストに配置されて再利用されますが、後で挿入するデータによっては、可能である場合と不可能である場合があります。そのスペースを再利用します。
また、事前割り当てにより、新しいデータ ファイルが割り当てられると、一部のドキュメントによってディスク上のスペースの使用率が最大 2 GB 増加することがあります。もちろん、十分なデータがあれば、これは基本的に丸め誤差になりますが、覚えておく価値があります。
一貫した使用パターンを前提として、このタイプのデータとサイズの比率を推定する唯一の方法は、特定のユース ケースについて経時的に傾向を示し、挿入されたデータに対するディスク容量の使用量を追跡することです (ドキュメントの数はデータ量よりも優れている場合があります)。ドキュメント サイズの変動性に応じて）。
同様に、挿入率、ドキュメント サイズ、および再同期/修復によって得られたスペースを追跡すると、. 参考までに-修復を実行するのではなく、セカンダリを最初から再同期して、データファイルの「新しい」コピーを取得できます。これにより、セットアップに応じて、混乱が少なくなり、使用するスペースが少なくなります。