自己管理型配置の GridFS
GridFS は BSON ドキュメントのサイズ制限である 16 MB を超えるファイルを保存および取得するための仕様です。
注意
GridFS はマルチドキュメントトランザクションをサポートしません。
GridFS は単一ドキュメントにファイルを保存する代わりに、ファイルをチャンク [1] と呼ばれる複数の部分に分割してから各チャンクを別々のドキュメントとして保存します。GridFS はデフォルトでは 255 kB という既定チャンクサイズを使用します。そのため、ファイルは最後のチャンクを除いて 255 kB のチャンクに分割されます。最後のチャンクのサイズは必要な大きさに留まります。同様に、チャンクサイズよりも大きくないファイルは、最終チャンクのみを持ち、必要なだけのスペースと追加のメタデータのみが使用されます。
GridFS は 2 つのコレクションを使用してファイルを保存します。一方のコレクションにはファイルのチャンクが保存され、もう一方のコレクションにはファイルのメタデータが保存されます。「GridFS コレクション」セクションで、各コレクションについて詳述しています。
GridFS に対してファイルのクエリを実行すると、ドライバーは必要に応じてチャンクを再構成します。GridFS を使って保存されたファイルには、範囲クエリを実行できます。ファイルの任意のセクションから情報にアクセスすることもできます。たとえば、ビデオやオーディオを含むファイルの途中で「スキップ」できます。
GridFS は16 MB を超えるファイルを保存するだけでなく、ファイル全体をメモリにロードする必要なしにアクセスしたいファイルを保存する場合にも役立ちます。 「 GridFS を使用する場合 」も参照してください。
GridFS の用途
MongoDB では、16 MB を超えるファイルの保存に GridFS を使用します。
状況によっては、MongoDB データベースの方がシステムレベルのファイルシステムよりも大きなファイルを保存するには効率的な場合があります。
ご使用のファイルシステムでディレクトリ内のファイル数が制限されている場合でも、GridFS を使用すると必要な数のファイルを保存できます。
大きなファイルの一部から情報にアクセスしたい場合、ファイル全体をメモリに読み込むことなく、GridFS を使用してファイルのセクションを呼び出すことができます。
ファイルとメタデータを複数のシステムと施設間で自動的に同期および、配置する場合、GridFS を使用できます。地理的に分散されたレプリカセットを使用する場合、MongoDB はファイルとそのメタデータを複数の
mongodインスタンスと施設に自動的に分散できます。
ファイル全体のコンテンツをアトミック的に更新する必要がある場合は、GridFS を使用しないでください。代替策として、各ファイルの複数のバージョンを保存し、メタデータでファイルの現在のバージョンを指定することができます。新しいバージョンのファイルをアップロードした後、アトミック更新で「最新」ステータスを示すメタデータ フィールドを更新し、必要に応じて後で以前のバージョンを削除できます。
さらに、すべてのファイルが BSON ドキュメント サイズの制限である 16 MB より小さい場合は、GridFS を使用する代わりに、各ファイルを単一ドキュメントに保存するとよいでしょう。バイナリ データを保存するには、BinData データ型を使用できます。BinData の使用に関する詳細については、ドライバーのドキュメントを参照してください。
GridFS の使用
GridFS を使用してファイルを保存および取得するには、次のいずれかの方法を使用します。
MongoDB ドライバー。 ドライバーで GridFS を使用する方法について詳しくは、ドライバーのドキュメントを参照してください。
mongofilesコマンドライン ツール。ドキュメントについては、mongofilesに関する参考資料を参照してください。
GridFS コレクション
GridFS はファイルを次の 2 つのコレクションに保存します。
chunksはバイナリ チャンクを保存します。詳細については、「chunksコレクション」を参照してください。filesはファイルのメタデータを保存します。詳細については、「filesコレクション」を参照してください。
GridFS は、各コレクションの先頭にバケット名を付けて、コレクションを共通のバケットに配置します。デフォルトでは、GridFS は fs という名前のバケットを持つ次の 2 つのコレクションを使用します。
fs.filesfs.chunks
別のバケット名を選択したり、単一データベースに複数のバケットを作成したりすることもできます。バケット名を含む完全なコレクション名には、名前空間の長さ制限が適用されます。
コレクション<a class=\" \" href=\" \" title=\" \"><svg xmlns=\" \" width=\" \" height=\" \" fill=\" \" viewbox=\" \"chunks class=\" \" role=\" \" aria-label=\" \"><path fill=\" \" d=\" \"> <path fill=\" \" d=\" \">
chunks [1] コレクション内の各ドキュメントは、GridFS と表記されるファイルの個別チャンクを表します。このコレクションのドキュメントは次の形式をとります。
{ "_id" : <ObjectId>, "files_id" : <ObjectId>, "n" : <num>, "data" : <binary> }
chunks コレクションのドキュメントには、次のフィールドが含まれています。
chunks._idチャンクのユニーク ObjectId。
chunks.dataBSON
Binary型のチャンクのペイロード。
コレクション<a class=\" \" href=\" \" title=\" \"><svg xmlns=\" \" width=\" \" height=\" \" fill=\" \" viewbox=\" \"files class=\" \" role=\" \" aria-label=\" \"><path fill=\" \" d=\" \"> <path fill=\" \" d=\" \">
files コレクション内の各ドキュメントは、GridFS 内のファイルを表します。
{ "_id" : <ObjectId>, "length" : <num>, "chunkSize" : <num>, "uploadDate" : <timestamp>, "md5" : <hash>, "filename" : <string>, "contentType" : <string>, "aliases" : <string array>, "metadata" : <any>, }
files コレクション内のドキュメントには、次のフィールドの一部またはすべてが含まれています。
files.chunkSizeバイト単位での各チャンクのサイズ。GridFS は、ドキュメントを
chunkSizeサイズのチャンクに分割します。ただし、最後のチャンクは例外的に必要なサイズのみになります。デフォルトのサイズは 255 キロバイト（kB）です。
files.md5非推奨
MD5 アルゴリズムは FIPS 140-2 によって禁止されています。MongoDB ドライバーは MD5 のサポートを廃止し、将来のリリースで MD5 の生成を削除する予定です。アプリケーションでファイル ダイジェストが必要な場合は、GridFS の外部で実装し、
files.metadataに保存する必要があります。filemd5 コマンドによって返される完全なファイルの MD5 ハッシュ。この値は
String型です。
files.contentType非推奨
任意。GridFS ファイルの有効な MIME タイプ。アプリケーション専用です。
GridFS ファイルの MIME タイプに関連する情報を保存するには、
files.metadataを使用します。
files.aliases非推奨
任意。エイリアス文字列の配列。アプリケーション専用です。
GridFS ファイルの MIME タイプに関連する情報を保存するには、
files.metadataを使用します。
GridFS Indexes
GridFS は効率性を高めるために、 コレクションとchunks filesコレクションのそれぞれでインデックスを使用します。GridFS 仕様 に準拠する ドライバー 便宜上これらのインデックスを自動的に作成します。また、アプリケーションのニーズに合わせて、必要に応じて追加のインデックスを作成することもできます。
chunksインデックス<a class=\" \" href=\" \" title=\" \"><svg xmlns=\" \" width=\" \" height=\" \" fill=\" \" viewbox=\" \" class=\" \" role=\" \" aria-label=\" \"><path fill=\" \" d=\" \"> <path fill=\" \" d=\" \">
GridFS は files_id と n フィールドを使用する chunks で、ユニーク複合インデックスを使用します。これにより、以下に例示するとおり、チャンクを効率的に取得できます。
db.fs.chunks.find( { files_id: myFileID } ).sort( { n: 1 } )
GridFS 仕様 に準拠した ドライバー は、読み取りおよび書込み操作の前にこのインデックスが存在することを自動的に確認します。GridFS アプリケーションの具体的な動作については、関連するドライバーのドキュメントを参照してください。
このインデックスが存在しない場合は、mongosh を使用して次のインデックス作成操作を発行できます。
db.fs.chunks.createIndex( { files_id: 1, n: 1 }, { unique: true } );
filesインデックス<a class=\" \" href=\" \" title=\" \"><svg xmlns=\" \" width=\" \" height=\" \" fill=\" \" viewbox=\" \" class=\" \" role=\" \" aria-label=\" \"><path fill=\" \" d=\" \"> <path fill=\" \" d=\" \">
GridFS はfilename と uploadDate を使用する files コレクションでインデックスを使用します。このインデックスにより、以下に例示するとおり、ファイルを効率的に取得できます。
db.fs.files.find( { filename: myFileName } ).sort( { uploadDate: 1 } )
GridFS 仕様 に準拠した ドライバー は、読み取りおよび書込み操作の前にこのインデックスが存在することを自動的に確認します。GridFS アプリケーションの具体的な動作については、関連するドライバーのドキュメントを参照してください。
このインデックスが存在しない場合は、mongosh を使用して次のインデックス作成操作を発行できます。
db.fs.files.createIndex( { filename: 1, uploadDate: 1 } );
| [1] | （1、2） GridFS に関してチャンクという用語が使用される場合とシャーディングに関してチャンクという用語が使用される場合に関連性はありません。 |
シャーディング用 GridFS
GridFS で考慮が必要なコレクションは、files と chunks の 2 つです。
chunks コレクション
chunks コレクションをシャーディングするには、{ files_id : 1, n : 1
} または { files_id : 1 } のいずれかをシャードキー インデックスとして使用します。files_id は ObjectId であり、単調に変化します。
アップロードの成功を確認するために filemd5 を実行しない MongoDB ドライバーには、chunks コレクションにハッシュされたシャーディングを使用できます。
MongoDB ドライバーが filemd5 を実行する場合、ハッシュされたシャーディングは使用できません。詳細については、SERVER-9888 を参照してください。
files コレクション
files コレクションは小さく、メタデータのみが含まれています。GridFS の必須キーはいずれもシャーディングされた環境での均等な分散には適していません。files をシャーディングされないままにしておくと、すべてのファイル メタデータ ドキュメントを 1 つのシャード上に置くことができます。
files コレクションを どうしても シャーディングしなければならない場合は、_id フィールドを使用し、場合によってはアプリケーションフィールドと組み合わせて使用してください。