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来存储所需数量的文件。
当你要拜访大文件局部的信息而不用将整个文件加载到内存中时,能够应用GridFS来调用文件的某些局部,而无需将整个文件读入内存。
当你心愿放弃文件和元数据在多个零碎和设施之间主动同步和部署时,能够应用GridFS。应用地理分布的复制集时,MongoDB能够主动将文件及其元数据散发到多个mongod实例和设施。
如果您须要对整个文件的内容进行原子更新,请不要应用GridFS。或者,您能够存储每个文件的多个版本,并在元数据中指定文件的以后版本。上传文件的新版本后,您能够原子更新元数据中批示为“最新”状态的字段,而后在须要时删除以前的版本。
此外,如果文件均小于16 MB BSON文档大小限度,请思考将每个文件存储在单个文档中,而不是应用GridFS。您能够应用BinData数据类型存储二进制数据。无关应用BinData的详细信息,请参见驱动程序文档。
应用GridFS
要应用GridFS存储和检索文件,请应用以下任一办法:
MongoDB驱动程序。请参阅驱动程序文档,以获取无关将GridFS与驱动程序一起应用的信息。
mongofiles命令行工具。无关文档,请参见mongofiles参考。
GridFS Collections
GridFS将文件存储在两个汇合中:
块存储二进制块。无关详细信息,请参见chunks汇合。
文件存储文件的元数据。无关详细信息,请参见文件汇合。
GridFS通过应用存储桶名称为每个汇合增加前缀,将汇合搁置在一个公共存储桶中。默认状况下,GridFS应用两个汇合以及一个名为fs的存储桶:
fs.files
fs.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二进制类型的荷载。
文件汇合
文件汇合中的每个文档代表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 KB。
files.uploadDate
GridFS首次存储这个文档的日期。此值为有日期类型。
files.md5
过期
FIPS 140-2禁止应用MD5算法。MongoDB驱动程序已弃用MD5反对,并将在将来版本中删除MD5的生成。须要文件摘要的应用程序应在GridFS内部实现它,并将其存储在files.metadata中。
filemd5命令返回的残缺文件的MD5哈希。此值为字符串类型。
files.filename
可选的。GridFS文件的可读名称。
files.contentType
过期
可选的。GridFS文件的无效MIME类型。仅应用程序用。
应用files.metadata来存储与GridFS文件的MIME类型无关的信息。
files.aliases
过期
可选的。别名字符串数组。仅用于应用程序
应用files.metadata来存储与GridFS文件的MIME类型无关的信息。
files.metadata
可选的。元数据字段能够是任何数据类型,并且能够保留您要存储的任何其余信息。如果心愿将其余任意字段增加到文件汇合中的文档,请将其增加到元数据字段中的对象。
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-ch…
对于作者:张琦
Java 开发工程师,陕西西安。