GridFS是用于存储和检索超过16 MB大小限制的BSON文档文件的规范。
注意
GridFS 不支持多文档事务
相较于将一个文件存储在单条文档中，GridFS将文件分为多个部分或块[1]，并将每个块存储为单独的文档。默认情况下，GridFS使用的块默认大小为255kB；也就是说，除最后一个块，GridFS会将文件划分为255 kB的块。最后一个块只有必要的大小。同样，最后的那个块也不会大于默认的块大小，仅使用所需的空间以及一些其他元数据。
GridFS使用两个集合来存储文件。一个集合存储文件块，另一个集合存储文件元数据。 GridFS集合一节详细介绍了每个集合。
当你从GridFS查询文件时，驱动程序将根据需要重新组装该文件所有的块。你可以对GridFS存储的文件进行范围查询。你还可以从文件的任意部分访问其信息，例如“跳到”视频或音频文件的中间。
GridFS不仅可用于存储超过16 MB的文件，而且还可用于存储您要访问的任何文件而不必将整个文件加载到内存中。另请参阅何时使用GridFS。
什么时候使用GridFS
在MongoDB中，使用GridFS存储大于16 MB的文件。
在某些情况下，在MongoDB数据库中存储大型文件可能比在系统级文件系统上存储效率更高。
如果您需要对整个文件的内容进行原子更新，请不要使用GridFS。或者，您可以存储每个文件的多个版本，并在元数据中指定文件的当前版本。上传文件的新版本后，您可以原子更新元数据中指示为“最新”状态的字段，然后在需要时删除以前的版本。
此外，如果文件均小于16 MB BSON文档大小限制，请考虑将每个文件存储在单个文档中，而不是使用GridFS。您可以使用BinData数据类型存储二进制数据。有关使用BinData的详细信息，请参见驱动程序文档。
使用GridFS
要使用GridFS存储和检索文件，请使用以下任一方法：
GridFS Collections
GridFS将文件存储在两个集合中:
GridFS通过使用存储桶名称为每个集合添加前缀，将集合放置在一个公共存储桶中。默认情况下，GridFS使用两个集合以及一个名为fs的存储桶：
您可以选择其他存储桶名称，也可以在一个数据库中创建多个存储桶。完整集合名称（包括存储桶名称）受命名空间长度限制。
块集合
块[1]集合中的每个文档都代表了GridFS中表示的文件的不同的块。此集合中的文档具有以下格式：
{
"_id" : <ObjectId>,
"files_id" : <ObjectId>,
"n" : <num>,
"data" : <binary>
}
chunks集合中的文档包含以下字段：
文件集合
文件集合中的每个文档代表GridFS中的一个文件。
{
"_id" : <ObjectId>,
"length" : <num>,
"chunkSize" : <num>,
"uploadDate" : <timestamp>,
"md5" : <hash>,
"filename" : <string>,
"contentType" : <string>,
"aliases" : <string array>,
"metadata" : <any>,
}
files集合中的文档包含以下一些或全部字段：
该文档的唯一标识符。 _id是您为原始文档选择的数据类型。MongoDB文档的默认类型是BSON ObjectId。
文档的大小（以字节为单位）。
每个块的大小（以字节为单位）。GridFS将文档分为大小为chunkSize的块，最后一个除外，后者仅根据需要而变大。默认大小为255 KB。
GridFS首次存储这个文档的日期。此值为有日期类型。
过期
FIPS 140-2禁止使用MD5算法。MongoDB驱动程序已弃用MD5支持，并将在未来版本中删除MD5的生成。需要文件摘要的应用程序应在GridFS外部实现它，并将其存储在files.metadata中。
filemd5命令返回的完整文件的MD5哈希。此值为字符串类型。
可选的。GridFS文件的可读名称。
过期
可选的。GridFS文件的有效MIME类型。仅应用程序用。
使用files.metadata来存储与GridFS文件的MIME类型有关的信息。
过期
可选的。别名字符串数组。仅用于应用程序
使用files.metadata来存储与GridFS文件的MIME类型有关的信息。
可选的。元数据字段可以是任何数据类型，并且可以保存您要存储的任何其他信息。如果希望将其他任意字段添加到文件集合中的文档，请将其添加到元数据字段中的对象。
GridFS索引
GridFS使用每个块和文件集合上的索引来提高效率。为了方便起见，符合GridFS规范的驱动程序会自动创建这些索引。您还可以根据需要创建任何其他索引，以满足您的应用程序需求。
chunks索引
GridFS使用files_id和n字段在chunks集合上使用唯一的复合索引。可以有效地检索块，如以下示例所示：
db.fs.chunks.find( { files_id: myFileID } ).sort( { n: 1 } )
符合GridFS规范的驱动程序将在读取和写入操作之前自动确保此索引存在。有关GridFS应用程序的特定行为，请参阅相关的驱动程序文档。
如果该索引不存在，则可以执行以下操作以使用mongo shell创建它：
db.fs.chunks.createIndex( { files_id: 1, n: 1 }, { unique: true } );
files索引
GridFS在files集合上的filename和uploadDate字段上使用索引。该索引允许高效地检索文件，如本示例所示：
db.fs.files.find( { filename: myFileName } ).sort( { uploadDate: 1 } )
符合GridFS规范的驱动程序将在读取和写入操作之前自动确保此索引存在。有关GridFS应用程序的特定行为，请参阅相关的驱动程序文档。
如果该索引不存在，则可以执行以下操作以使用mongo shell创建它：
db.fs.files.createIndex( { filename: 1, uploadDate: 1 } );
|
[1] |
(1, 2) 在GridFS上下文中使用术语块与在分片上下文中使用术语块无关。 |
分片GridFS
GridFS考虑两个集合-files和chunks。
chunks集合
要分片chunks集合，请使用{ files_id : 1, n : 1 } 或{ files_id : 1 } 作为分片键索引。files_id是一个ObjectId，并且单调更改。
对于不运行filemd5来验证成功上传的MongoDB驱动程序（例如，支持MongoDB 4.0或更高版本的MongoDB驱动程序），可以将哈希分片用于chunks集合。
如果MongoDB驱动程序运行filemd5，则不能使用Hashed Sharding。有关详细信息，请参阅SERVER-9888。
files集合
files集合很小，仅包含元数据。GridFS所需的所有密钥都不适合在分片环境中进行平均分配。保留未分片的files允许所有文件元数据文档保留在主分片上。
如果必须分片files集合，请使用_id字段，可能与应用程序字段结合使用。
原文链接：
https://github.com/mongodb-china/MongoDB-CN-Manual/blob/master/cun-chu/gridfs.md
关于作者：张琦
JAVA 开发工程师，陕西西安。
