MongoDBのスペース使用量を理解する

MongoDBを初めて使用する方にとって、MongoDBのスペース使用量は非常に混乱しているように思われるかもしれません。この記事では、MongoDBがスペースを割り当てる方法と、ObjectRocketダッシュボードのスペース使用量情報を解釈して、インスタンスを圧縮する必要がある場合や、インスタンスで使用可能なスペースを増やすためにシャードを追加する必要がある場合を判断する方法について説明します。

まず、単一の5GBシャードで構成される新しいMediumインスタンスから始めましょう。このインスタンスに「ocean」という名前のデータベースのテストデータを入力します。テストデータを追加し、いくつかのインデックスを作成した後の、このインスタンスのスペース使用量は次のようになります（この記事の目的のために、テストデータセットに比べてサイズがかなり大きいことがわかっている追加のインデックスを意図的に追加しました）。

315MiBのデータと254MiBのインデックスは、5GiBのシャードのうち2.1GiBを使用していることをどのように意味しますか？説明するために、MongoDBが一連のエクステントとしてデータをディスクに保存する方法から始めましょう。 ObjectRocketインスタンスはsmallfilesオプションで実行されるため、最初のエクステントは16MBとして割り当てられます。これらのエクステントは、512MBに達するまでサイズが2倍になり、その後、すべてのエクステントが512MBのファイルとして割り当てられます。したがって、この例の「ocean」データベースのファイル構造は次のとおりです。

$ ls -lh ocean/

total 1.5G

-rw------- 1 mongodb mongodb  16M Aug 20 22:30 ocean.0
-rw------- 1 mongodb mongodb  32M Aug 20 20:44 ocean.1
-rw------- 1 mongodb mongodb  64M Aug 20 22:23 ocean.2
-rw------- 1 mongodb mongodb 128M Aug 20 22:30 ocean.3
-rw------- 1 mongodb mongodb 256M Aug 20 22:30 ocean.4
-rw------- 1 mongodb mongodb 512M Aug 20 22:30 ocean.5
-rw------- 1 mongodb mongodb 512M Aug 20 22:30 ocean.6
-rw------- 1 mongodb mongodb  16M Aug 20 22:30 ocean.ns
drwxr-xr-x 2 mongodb mongodb 4.0K Aug 20 22:30 _tmp

これらのエクステントには、データベースのデータとインデックスの両方が格納されます。 MongoDBでは、データがエクステントに書き込まれるとすぐに、次の論理エクステントが割り当てられます。したがって、上記の構造では、ocean.6には現時点ではデータがない可能性がありますが、ocean.5がいっぱいになったときに事前に割り当てられています。データがocean.6に書き込まれるとすぐに、新しい512MBのエクステントocean.7が再び事前に割り当てられます。 MongoDBデータベースからデータが削除されると、圧縮するまでスペースが解放されません。そのため、時間の経過とともに、データが削除されると（または、追加のキーが追加されたためにドキュメントが元の保存場所を超えた場合）、これらのデータファイルが断片化する可能性があります。圧縮中にこれらのデータファイルがデフラグされます。これは、圧縮中にデータがレプリカセットの別のメンバーから複製され、データファイルが最初から再作成されるためです。

追加の16MBファイルは名前空間を格納します。これはocean.nsファイルです。これと同じパターンが、MongoDBインスタンスの各データベースで発生します。 「ocean」データベースに加えて、シャードには「admin」と「local」の2つの追加のシステムデータベースがあります。 「admin」データベースには、すべてのデータベースユーザーのユーザー情報が格納されます（2.6.xより前では、このデータベースは管理者ユーザーにのみ使用されていました）。 adminデータベースは小さいですが、16MBのエクステント、事前に割り当てられた32MBのエクステント、およびこのデータベース用の16MBの名前空間ファイルがあります。

2番目のシステムデータベースは「ローカル」データベースです。 ObjectRocketで提供する各シャードは、3メンバーのレプリカセットです。これらのレプリカの同期を維持するために、MongoDBは各更新のoplogと呼ばれるログを維持します。これは各レプリカで同期が保たれ、セカンダリレプリカで行う必要のある変更を追跡するために使用されます。このoplogは、「ローカル」データベース内に上限付きコレクションとして存在します。 ObjectRocketでは、oplogのサイズを通常シャードサイズの10％に構成します。5GBのシャードの場合、oplogは500MBとして構成されます。したがって、「ローカル」データベースは、16MBのエクステント、512MBのエクステント、および16MBの名前空間ファイルで構成されます。

最後に、この例のシャードには、もう1つのハウスキーピング領域であるジャーナルが含まれています。ジャーナルは、それぞれサイズが約128MBの1〜3個のファイルのセットです。書き込みが発生するたびに、MongoDBは最初に更新をジャーナルに順次書き込みます。次に、バックグラウンドスレッドが定期的に、これらの更新を実際のデータファイル（前述のエクステント）にフラッシュします。通常は60秒に1回です。この二重書き込みの理由は、ジャーナルへの順次書き込みが、実際のデータファイルへの書き込みに必要なシークよりもはるかに高速であることが多いためです。 MongoDBは、変更をジャーナルにすぐに書き込むことで、クラッシュが発生した場合に、変更がデータファイルに書き込まれるまですべての書き込みを待機することなく、データを確実に回復できます。現在のプライマリレプリカの場合、2つのジャーナルファイルがアクティブになっていることがわかります。

$ ls -lh journal/

total 273M

-rw------- 1 mongodb mongodb 149M Aug 20 22:26 j._1
-rw------- 1 mongodb mongodb 124M Aug 20 22:30 j._2

MongoDBは、更新の頻度とディスクへのバックグラウンドフラッシュの頻度に応じて、これらのファイルを自動的にローテーションします。

MongoDBがディスクスペースをどのように使用するかについて説明したので、これは、前に示したObjectRocketダッシュボードのスペース使用バーに表示されるものとどのように対応しますか？

• NS値、48MB —前述の3つのデータベース、ocean、admin、およびlocalの3つの16MB名前空間ファイルの合計。
• データ値、315MiB — db.stats()でdataSizeについて報告された値の合計 すべてのデータベース（システムデータベースを含む）。
• インデックス値、253.9MiB、— db.stats()でindexSizeについて報告された値の合計 すべてのデータベース（システムデータベースを含む）。
• ストレージ値、687.2MiB —すべてのデータベースのデータとインデックスの合計に加えて、削除によって再利用されていないスペース。
• 合計ファイル値、2.0 GiB —プライマリレプリカで合計で使用しているディスクの量。 Storage値とNS値でカバーされるスペース以外に、これには事前に割り当てられたエクステントも含まれますが、ジャーナルで使用されるスペースは含まれません。

これらのメトリックが与えられると、このインスタンスが圧縮を必要とするほど断片化されているかどうかを判断するために、いくつかの簡単な計算を行うことができます。断片化によって失われる可能性のあるスペースを計算するには、次を使用します。

100％–（データ+インデックス）/ストレージ

この例のインスタンスの場合、これは17％（100％–（315MiBデータ+ 253.9MiBインデックス）/687.2MiBストレージ=17％）になります。断片化が20％に近づいたら、インスタンスを圧縮することをお勧めします。

実行できるもう1つの計算は、全体的なスペース使用量に基づいて、このインスタンスにシャードを追加する必要があるかどうかです。全体的なスペース使用量を計算するには、次のようにします。

（合計ファイル/（プランサイズ*シャードの数））* 100％

この例の例では、これは40％（（2 GiB / 5 GiB * 1シャード）* 100％=40％）になります。通常、全体的なスペース使用量が80％に近づいたら、シャードを追加することをお勧めします。スペース使用量が80％に達していることに気付いた場合は、サポートに連絡してください。インスタンスにシャードを追加するお手伝いをします。