MongoDB的分布式文件存储系统

概述

对于MongoDB的存储基本单元BSON文档对象，字段值可以是二进制类型，基于此特点，我们可以直接在MongoDB中存储文件，但是有一个限制，由于MongoDB中单个BSON对象不能大于16MB，故而如果需要存储更大的文件，就需要GridFS了。

小文件存储系统与GridFS文件存储

我们先看下MongoDB存储小文件系统的例子：

先采用MongoDB的mongofiles执行文件上传：

通过mongos命令查看文件存储情况：

可以看到文件上传成功了

由于本章节主要涉及到的是部分理论以及运维实践，暂不涉及具体代码的开发实现（具体代码将以java为例在后面章节中介绍）。

上传一个大于16MB的文件试一试：

通过mongos命令查看文件存储情况：

也成功了，

查看chunks:

可以看到大文件被分成了好多个chunk，那么为什么上传16MB以上的文件也会成功呢，因为我们采用的就是GridFS系统存储的文件，因为我们采用的是mongfiles方式上传的文件。

下面分别是查询、下载、删除操作：

实际上，我们还可以自定义集合的前缀，默认是fs，或者设置chunk的大小，默认是256KB。

总结

那么在实际场景的分布式文件存储系统中如何确定改用哪种存储方案呢，可以采用如下方式： 1. 对于用户上传的任何文件，在客户端进行大小判断； 2. 当文件大小小于16MB时，则直接存储到MOngoDB普通集合中 3. 当文件大小大于16MB时，上传到GridFS中，利用集合fs.files以及fs.chunks来保存文件 4. 当用户下载文件时，再根据不同文件的大小属性不同到不同的集合中查找

另外，对于fs.chunks文件我们可以分片存储，片键可以选择索引字段{“files_id”}，该字段尽量保证了此文件在所有被分割的chunk都在同一个片上，fs.files不需要分片，此集合只保存文件的元数据信息，数据量不大，同时还可以设置默认块大小（256KB）

需要注意的是：GridFS并不适合小文件存储，因为从GridFS中读取文件涉及到两次查询操作，先查询fs.files集合，再查询fs.chunks集合，chunks合并后获取整个文件。

需要注意的另一点是：文件分块大小为256KB，而分片的块大小默认64MB，不要搞混了。