GridFS

在本页面

GridFS是用于存储和检索超过 16 MB 的BSON -document size limit的文件的规范。

GridFS 不会将文件存储在单个文档中，而是将文件分为多个部分或大块[1]，并将每个大块存储为单独的文档。默认情况下，GridFS 使用的默认块大小为 255 kB；默认值为 255 kB。也就是说，除了最后一个块，GridFS 会将文件划分为 255 kB 的块。最后一块只有必要的大小。同样，不大于块大小的文件只有最后一块，只使用所需的空间以及一些其他元数据。

GridFS 使用两个集合来存储文件。一个集合存储文件块，另一个集合存储文件元数据。 GridFS Collections部分详细介绍了每个集合。

当您查询 GridFS 文件时，驱动程序将根据需要重新组装块。您可以对通过 GridFS 存储的文件执行范围查询。您还可以从文件的任意部分访问信息，例如“跳到”视频或音频文件的中间。

GridFS 不仅可用于存储超过 16 MB 的文件，而且还可用于存储您要访问的任何文件而不必将整个文件加载到内存中。另请参见何时使用 GridFS。

何时使用 GridFS

在 MongoDB 中，使用GridFS来存储大于 16 MB 的文件。

在某些情况下，在 MongoDB 数据库中存储大型文件可能比在系统级文件系统上存储效率更高。

如果文件系统限制了目录中文件的数量，则可以使用 GridFS 来存储所需数量的文件。
当您要访问大文件部分的信息而不必将整个文件加载到内存中时，可以使用 GridFS 来调用文件的某些部分，而无需将整个文件读入内存。
当您希望保持文件和元数据在多个系统和设施之间自动同步和部署时，可以使用 GridFS。使用地理上分散的副本集时，MongoDB 可以自动将文件及其元数据分发到许多mongod实例和设施。

如果您需要自动更新整个文件的内容，请不要使用 GridFS。或者，您可以存储每个文件的多个版本，并在元数据中指定文件的当前版本。上载文件的新版本后，您可以更新原子更新中指示“最新”状态的元数据字段，然后在需要时删除以前的版本。

此外，如果文件均小于 16 MB BSON Document Size的限制，请考虑将每个文件存储在单个文档中，而不要使用 GridFS。您可以使用 BinData 数据类型存储二进制数据。有关使用 BinData 的详细信息，请参见drivers文档。

Use GridFS

要使用GridFS存储和检索文件，请使用以下任一方法：

MongoDB 驱动程序。有关在驱动程序上使用 GridFS 的信息，请参见drivers文档。
mongofiles命令行工具。有关文档，请参见mongofiles参考。

GridFS Collections

GridFS将文件存储在两个集合中：

chunks存储二进制块。有关详细信息，请参见块集合。
files存储文件的元数据。有关详细信息，请参见文件集合。

GridFS 通过使用存储桶名称为每个集合添加前缀，将集合放置在一个公共存储桶中。默认情况下，GridFS 使用两个集合，它们的存储桶名为fs：

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
- 每个块的大小，以 bytes 为单位。 GridFS 将文档分成大小为chunkSize的块，最后一个除外，后者仅根据需要而变大。默认大小为 255 KB。
files. uploadDate
- GridFS 首次存储文档的日期。此值具有Date类型。
files. md5
- Deprecated

FIPS 140-2 禁止使用 MD5 算法。 MongoDB 驱动程序已弃用 MD5 支持，并将在以后的版本中删除 MD5 生成。需要文件摘要的应用程序应在 GridFS 外部实现它并存储在files.metadata中。

filemd5命令返回的完整文件的 MD5 哈希。该值具有String类型。

files. filename
- 可选的。 GridFS 文件的可读名称。
files. contentType
- Deprecated

可选的。 GridFS 文件的有效 MIME 类型。仅用于应用程序。

使用files.metadata来存储与 GridFS 文件的 MIME 类型有关的信息。

files. aliases
- Deprecated

可选的。别名字符串数组。仅用于应用程序。

使用files.metadata来存储与 GridFS 文件的 MIME 类型有关的信息。

files. metadata
- 可选的。元数据字段可以是任何数据类型，并且可以包含您要存储的任何其他信息。如果要向files集合中的文档添加其他任意字段，请将其添加到元数据字段中的对象。

GridFS Indexes

GridFS 使用每个chunks和files集合上的索引来提高效率。为方便起见，符合GridFS specification的Drivers自动创建这些索引。您还可以根据需要创建任何其他索引，以满足您的应用程序需求。

块索引

GridFS使用files_id和n字段在chunks集合上使用unique，compound索引。可以有效地检索块，如以下示例所示：

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

符合GridFS specification的Drivers将在读和写操作之前自动确保此索引存在。有关 GridFS 应用程序的特定行为，请参阅相关的驱动程序文档。

如果该索引不存在，则可以发出以下操作以使用mongo shell 创建它：

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

文件索引

GridFS使用filename和uploadDate字段在files集合上使用index。该索引允许有效地检索文件，如本示例所示：

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

符合GridFS specification的Drivers将在读和写操作之前自动确保此索引存在。有关 GridFS 应用程序的特定行为，请参阅相关的驱动程序文档。

如果该索引不存在，则可以发出以下操作以使用mongo shell 创建它：

db.fs.files.createIndex( { filename: 1, uploadDate: 1 } );

[1]	(1，2)在 GridFS 上下文中使用术语* chunks 与在分片上下文中使用术语 chunks *不相关。

Sharding GridFS

gridfs-files和chunks有两个集合可供考虑。

如果需要分片 GridFS 数据存储，请使用chunks收集设置{ files_id : 1, n : 1 }或{ files_id : 1 }作为分片键索引。

files_id是objectid并更改monotonically。

分片chunks集合时不能使用Hashed Sharding。

files集合很小，仅包含元数据。 GridFS 所需的所有键都不适合在分片环境中进行平均分配。如果您必须分片files集合，请使用_id字段，可能与应用程序字段结合使用。

保留files的未分片格式将使所有文件元数据文档都保留在primary shard上。

Docs

Docs4dev

Title here