把稳
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.filesfs.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.uploadDateGridFS首次存储这个文档的日期。此值为有日期类型。
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-china/MongoDB-CN-Manual/blob/master/cun-chu/gridfs.md
关于作者:张琦
Java 开拓工程师,陕西西安。