AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu

自己管理型配置の GridFS

GridFS は、BSON ドキュメントのサイズ制限である 16 MiB を超えるファイルを保存および取得するための仕様です。

注意

GridFS はマルチドキュメントトランザクションをサポートしません。

GridFS は単一documentにファイルを保存する代わりに、チャンク [1] と呼ばれる複数の部分にファイルを分割してから各チャンクを 別々のdocumentとして保存します。デフォルトでは 、 GridFS は255 KeyB のチャンク サイズを使用します。つまり、 GridFS はファイルを最後のチャンクを除いて 255 Kit のチャンクに分割します。最後のチャンクのサイズは必要な範囲に留まります。同様に、ファイルが チャンク サイズ を超えない場合、そのファイルは最終チャンクのみとなり、必要な範囲内の領域と追加のメタデータを使用します。

GridFS は 2 つのコレクションを使用してファイルを保存します。一方のコレクションにはファイルのチャンクが保存され、もう一方のコレクションにはファイルのメタデータが保存されます。

GridFSでファイルをクエリすると、ドライバーは必要に応じてチャンクを再アセンブルします。GridFSを使って保存されたファイルには、範囲クエリを実行できます。ファイルの任意のセクションから情報にアクセスすることもできます。たとえば、ビデオやオーディオを含むファイルの途中に「スキップ」できます。

GridFS は 16 MiB を超えるファイルを保存するだけでなく、ファイルをメモリ全体に読み込むことなくアクセスしたい任意のファイルを保存するのにも役立ちます。GridFS の用途も参照してください。

16 MiB を超えるファイルの保存にはGridFS を使用します。

状況によっては、MongoDB データベースの方がシステムレベルのファイルシステムよりも大きなファイルを保存するには効率的な場合があります。

  • ご使用のファイルシステムでディレクトリ内のファイル数が制限されている場合でも、GridFS を使用すると必要な数のファイルを保存できます。

  • ファイル全体をメモリにロードせずに、大きなファイルの一部にアクセスするには、 GridFS を使用します。

  • 複数のシステムや施設間でファイルとメタデータを同期、配置する場合、 GridFS を使用します。地理的に分散されたレプリカセットを使用すると、 MongoDB はファイルとそのメタデータを複数の施設にわたるmongodインスタンスに分散します。

ファイル全体のコンテンツをアトミック的に更新する必要がある場合は、GridFS を使用しないでください。代替策として、各ファイルの複数のバージョンを保存し、メタデータでファイルの現在のバージョンを指定することができます。新しいバージョンのファイルをアップロードした後、アトミック更新で「最新」ステータスを示すメタデータ フィールドを更新し、必要に応じて後で以前のバージョンを削除できます。

すべてのファイルが16 MiB BSONドキュメント サイズ の制限より小さい場合は、 GridFSを使用する代わりに、各ファイルを単一ドキュメントに保存するとよいでしょう。バイナリ データを保存するには、BinDataデータ型を使用します。 BinData の使用に関する詳細については、 ドライバー のドキュメントを参照してください。

GridFS を使用してファイルを保存および取得するには、次のいずれかの方法を使用します。

  • MongoDB ドライバー。 ドライバーで GridFS を使用する方法について詳しくは、ドライバーのドキュメントを参照してください。

  • The mongofiles command-line tool. See the mongofiles reference for documentation.

GridFS はファイルを次の 2 つのコレクションに保存します。

GridFS は、各コレクションの先頭にバケット名を付けて、コレクションを共通のバケットに配置します。デフォルトでは、GridFS は fs という名前のバケットを持つ次の 2 つのコレクションを使用します。

  • fs.files

  • fs.chunks

別のバケット名を選択したり、単一データベースに複数のバケットを作成したりすることもできます。バケット名を含む完全なコレクション名には、名前空間の長さ制限が適用されます。

chunks [1] コレクション内の各ドキュメントは、GridFS と表記されるファイルの個別チャンクを表します。このコレクションのドキュメントは次の形式をとります。

{
"_id" : <ObjectId>,
"files_id" : <ObjectId>,
"n" : <num>,
"data" : <binary>
}

chunks コレクションのドキュメントには、次のフィールドが含まれています。

chunks._id

チャンクのユニーク ObjectId

chunks.files_id

files コレクションで指定される、「親」ドキュメントの _id

chunks.n

チャンクのシーケンス番号。GridFS はすべてのチャンクに 0 から順に番号を付けます。

chunks.data

BSON Binary 型のチャンクのペイロード。

files コレクション内の各ドキュメントは、GridFS 内のファイルを表します。

{
"_id" : <ObjectId>,
"length" : <num>,
"chunkSize" : <num>,
"uploadDate" : <timestamp>,
"md5" : <hash>,
"filename" : <string>,
"contentType" : <string>,
"aliases" : <string array>,
"metadata" : <any>,
}

files コレクション内のドキュメントには、次のフィールドの一部またはすべてが含まれています。

files._id

このドキュメントのユニークな識別子。_id は元のドキュメント向けに選択したデータ型です。MongoDB ドキュメントのデフォルトの型は BSON ObjectId です。

files.length

バイト単位でのドキュメントのサイズ。

files.chunkSize

バイト単位での各チャンクのサイズ。GridFS は、ドキュメントを chunkSize サイズのチャンクに分割します。ただし、最後のチャンクは例外的に必要なサイズのみになります。デフォルトサイズは 255 キビバイト(KiB)です。

files.uploadDate

GridFS によってドキュメントが最初に保存された日付。この値は Date 型です。

files.md5

非推奨

MD5 アルゴリズムは FIPS140 - によって禁止されています。2 MongoDBドライバーは5 MD5 のサポートを停止し、将来のリリースでは MD 生成を排除します。アプリケーションでファイルダイジェストが必要な場合は、 GridFSの外部で実装し、 に保存する必要があります。files.metadata

filemd5 コマンドによって返される完全なファイルの MD5 ハッシュ。この値は String 型です。

files.filename

任意。人間が判読可能な GridFS ファイルの名前。

files.contentType

非推奨

任意。GridFS ファイルの有効な MIME タイプ。アプリケーション専用です。

Use files.metadata for storing information related to the MIME type of the GridFS file.

files.aliases

非推奨

任意。エイリアス文字列の配列。アプリケーション専用です。

Use files.metadata for storing alias information.

files.metadata

任意.メタデータフィールドはあらゆるデータ型を受け入れ、追加情報を保存して保持できます。filesコレクション内のdocumentに任意のフィールドを追加するには、メタデータフィールドのオブジェクトに追加します。

GridFS uses indexes on each of the chunks and files collections for efficiency. Drivers that conform to the GridFS specification automatically create these indexes. You can also create additional indexes to suit your application.

GridFSfiles_idn フィールドを使用する chunks で、ユニーク複合インデックスを使用します。これにより、以下に例示するとおり、チャンクを効率的に取得できます。

db.fs.chunks.find( { files_id: myFileID } ).sort( { n: 1 } )

Drivers that conform to the GridFS specification automatically ensure that this index exists before read and write operations. See the relevant driver documentation for the specific behavior of your GridFS application.

If this index does not exist, you can issue the following operation to create it using mongosh:

db.fs.chunks.createIndex( { files_id: 1, n: 1 }, { unique: true } );

GridFSfilenameuploadDate を使用する files コレクションでインデックスを使用します。このインデックスにより、以下に例示するとおり、ファイルを効率的に取得できます。

db.fs.files.find( { filename: myFileName } ).sort( { uploadDate: 1 } )

Drivers that conform to the GridFS specification automatically ensure that this index exists before read and write operations. See the relevant driver documentation for the specific behavior of your GridFS application.

If this index does not exist, you can issue the following operation to create it using mongosh:

db.fs.files.createIndex( { filename: 1, uploadDate: 1 } );
[1]12 GridFS に関してチャンクという用語が使用される場合とシャーディングに関してチャンクという用語が使用される場合に関連性はありません。

GridFS には、fileschunks の 2 つのコレクションがあります。

chunks コレクションをシャーディングするには、{ files_id : 1, n : 1 } または { files_id : 1 } のいずれかをシャードキー インデックスとして使用します。files_idObjectId であり、単調に変化します。

アップロードの成功を確認するために filemd5 を実行しない MongoDB ドライバーには、chunks コレクションにハッシュされたシャーディングを使用できます。

MongoDBドライバーがfilemd5 を実行する場合、 ハッシュされたシャーディングは使用できません。詳細については、 SERVER-9888 を参照してください。

files コレクションは小さく、メタデータのみが含まれています。GridFS の必須キーはいずれもシャーディングされた環境での均等な分散には適していません。files をシャーディングされないままにしておくと、すべてのファイル メタデータ ドキュメントを 1 つのシャード上に置くことができます。

files コレクションを どうしても シャーディングしなければならない場合は、_id フィールドを使用し、場合によってはアプリケーションフィールドと組み合わせて使用してください。