在各类系统应用服务端开发中，我们经常会遇到文件存储的问题。 常见的磁盘文件系统，DBMS传统文件流存储。今天我们看一下基于NoSQL数据库MongoDb的存储方案。笔者环境 以CentOS 6.5，MongoDb 2.6.3,  Nginx-1.4.7 为例，您需要了解linux常用命令。
先来回顾一下MongoDb的内部文件结构

1. MongoDB在数据存储上按命名空间来划分，一个collection是一个命名空间，一个索引也是一个命名空间
2. 同一个命名空间的数据被分成很多个Extent，Extent之间使用双向链表连接
3. 在每一个Extent中，保存了具体每一行的数据，这些数据也是通过双向链接连接的
4. 每一行数据存储空间不仅包括数据占用空间，还可能包含一部分附加空间，这使得在数据update变大后可以不移动位置
5. 索引以BTree结构实现

然后是GridFs的结构

GridFS在数据库中，默认使用fs.chunks和fs.files来存储文件。

其中fs.files集合存放文件的信息，fs.chunks存放文件数据。

一个fs.files集合中的一条记录内容如下，即一个file的信息如下：

{ 
"_id" : ObjectId("4f4608844f9b855c6c35e298"),       //唯一id，可以是用户自定义的类型
"filename" : "CPU.txt",      //文件名
"length" : 778,      //文件长度
"chunkSize" : 262144,    //chunk的大小
"uploadDate" : ISODate("2012-02-23T09:36:04.593Z"), //上传时间
"md5" : "e2c789b036cfb3b848ae39a24e795ca6",      //文件的md5值
"contentType" : "text/plain"     //文件的MIME类型
"meta" : null    //文件的其它信息，默认是没有”meta”这个key，用户可以自己定义为任意BSON对象
}

对应的fs.chunks中的chunk如下：

{ 
"_id" : ObjectId("4f4608844f9b855c6c35e299"),    //chunk的id
"files_id" : ObjectId("4f4608844f9b855c6c35e298"),  //文件的id，对应fs.files中的对象，相当于fs.files集合的外键
"n" : 0,     //文件的第几个chunk块，如果文件大于chunksize的话，会被分割成多个chunk块
"data" : BinData(0,"QGV...")     //文件的二进制数据，这里省略了具体内容
}

文件存入到GridFS过程中，如果文件大于chunksize，则把文件分割成多个chunk，再把这些chunk保存到fs.chunks中，最后再把文件信息存入到fs.files中。

在读取文件的时候，先据查询的条件，在fs.files中找到一个合适的记录，得到“_id”的值，再据这个值到fs.chunks中查找所有“files_id”为“_id”的chunk，并按“n”排序，最后依次读取chunk中“data”对象的内容，还原成原来的文件。

安装Install与配置

1.安装mongoDb

增加MongoDB Repository，不清楚vim，请参考VIM

vim /etc/yum.repos.d/mongodb.repo

如果是64bit的

[mongodb]

name=MongoDB Repository

baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/

gpgcheck=0

enabled=1

32bit的系统：

[mongodb]

name=MongoDB Repository

baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/i686/

gpgcheck=0

enabled=1

然后安装，会提示Y/N：

yum install mongo-10gen mongo-10gen-server

启动：

service mongod start

查看状态

service mongod status

停止

service mongod stop

更多，关于3.0以上版本，请参考官网。

2.安装nginx及nginx-gridfs

依赖库、工具

# yum -y install pcre-devel openssl-devel zlib-devel

# yum -y install gcc gcc-c++

下载nginx-gridfs源码

# git clone https://github.com/mdirolf/nginx-gridfs.git

# cd nginx-gridfs

# git checkout v0.8

# git submodule init

# git submodule update

下载nginx源码，编译安装。(高版本支持不好)

# wget http://nginx.org/download/nginx-1.4.7.tar.gz

# tar zxvf nginx-1.4.7.tar.gz

# cd nginx-1.4.7

# ./configure --with-openssl=/usr/include/openssl --add-module=../nginx-gridfs/

# make -j8 && make install –j8

注意蓝色字符配置成对应nginx-gridfs的路径

3. 配置nginx-gridfs

vim /usr/local/nginx/conf/nginx.conf

在 server 节点中添加 location 节点

location /img/ {
        gridfs testdb
        field=filename
        type=string;
        mongo 192.168.0.159:27017;
}

location /files/ {
        gridfs testdb
        field=_id
        type=objectid;
        mongo 192.168.0.159:27017;
}

这里我们的mongo服务在ip 192.168.0.159。
如果不指定 field，默认为 MongoDB 的自增ID，且type为int

配置参数介绍：

gridfs：nginx识别插件的关键字
testdb：db名
[root_collection]: 选择collection，如root_collection=blog， mongod就会去找blog.files与blog.chunks两个块，默认是fs
[field]: 查询字段，保证mongdb里有这个字段名，支持_id, filename, 可省略, 默认是_id
[type]: 解释field的数据类型，支持objectid, int, string, 可省略, 默认是int
[user]: 用户名, 可省略
[pass]: 密码, 可省略
mongo: mongodb url

启动nginx服务

# /usr/local/nginx/sbin/nginx

可能出现：
Nginx [emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use)

这时可用使用命令关闭占用80端口的程序

sudo fuser -k 80/tcp

简单测试

用原生的命令行上传一个文件

mongofiles put 937910.jpg --local ~/937910_100.jpg --host 192.168.0.159 --port 27017 --db testdb --type jpg

937910.jpg是我们提前下载好一个图片文件，注意我们没有指定collection，默认是fs

从http://www.robomongo.org/安装robomongo管理工具, 查看刚刚上传的文件

最后我们在浏览器访问，如果看到图片就OK了

http://192.168.0.159/img/937910.jpg

对于.net环境下mongodb CSharpDriver  1.10.0 从Nuget:
Install-Package mongocsharpdriver -Version 1.10.0
我们使用如下片段代码:

                int nFileLen = fileUploadModel.FileBytes.Length;

                MongoGridFSSettings fsSetting = new MongoGridFSSettings() { Root = CollectionName };
                MongoGridFS fs = new MongoGridFS(mongoServer, MongoDatabaseName, fsSetting);

                //调用Write、WriteByte、WriteLine函数时需要手动设置上传时间
                //通过Metadata 添加附加信息
                MongoGridFSCreateOptions option = new MongoGridFSCreateOptions();
                option.Id = ObjectId.GenerateNewId();
                var currentDate = DateTime.Now;
                option.UploadDate = currentDate;
                option.Aliases = alias;
                BsonDocument doc = new BsonDocument();
                //文档附加信息存储
                if(fileUploadModel.DocExtraInfo!=null&&fileUploadModel.DocExtraInfo.Count>0)
                {
                    foreach(var obj in fileUploadModel.DocExtraInfo)
                    {
                        if (!doc.Elements.Any(p => p.Name == obj.Key))
                        {
                            doc.Add(obj.Key, obj.Value);
                        }
                    }
                }
                option.Metadata = doc;

                //创建文件，文件并存储数据
                using (MongoGridFSStream gfs = fs.Create(fileUploadModel.FileName, option))
                {
                    gfs.Write(fileUploadModel.FileBytes, 0, nFileLen);
                    gfs.Close();
                }
                log.ErrorFormat("附件标识：{0} 文件名：{1} 上传成功", alias, fileUploadModel.FileName);
                return option.Id.ToString();

注意，目前gridfs-ngnix不支持_id类型是GUID的，关于ObjectId参考官网，如下图:

mongodb产生objectid还有一个更大的优势，就是mongodb可以通过自身的服务来产生objectid，也可以通过客户端的驱动程序来产生。

什么时候使用Gridfs

来自官方2.6.10版本 手册内容

For documents in a MongoDB collection, you should always use GridFS for storing files larger than 16 MB.  In some situations, storing large files may be more efficient in a MongoDB database than on a system-level filesystem.

• If your filesystem limits the number of files in a directory, you can use GridFS to store as many files as needed.
• When you want to keep your files and metadata automatically synced and deployed across a number of systems and facilities. When using geographically distributed replica sets MongoDB can distribute files and their metadata automatically to a number of mongod instances and  facilities.
• When you want to access information from portions of large files without having to load whole files into memory, you can use GridFS to recall sections of files without reading the entire file into memory.

Do not use GridFS if you need to update the content of the entire file atomically. As an alternative you can store multiple versions of each file and specify the current version of the file in the metadata. You can update the metadata field that indicates “latest” status in an atomic update after uploading the new version of the file, and later remove PRevious versions if needed.

Furthermore, if your files are all smaller the 16 MB BSON Document Size limit, consider storing the file manually within a single document. You may use the BinData data type to store the binary data. See your drivers documentation for details on using BinData.

数据库主从同步

原理图

上图是MongoDB采用Replica Sets模式的同步流程

• 红色箭头表示写操作写到Primary上，然后异步同步到多个Secondary上
• 蓝色箭头表示读操作可以从Primary或Secondary任意一个上读
• 各个Primary与Secondary之间一直保持心跳同步检测，用于判断Replica Sets的状态

数据分片机制

• MongoDB的分片是指定一个分片key来进行，数据按范围分成不同的chunk，每个chunk的大小有限制
• 有多个分片节点保存这些chunk，每个节点保存一部分的chunk
• 每一个分片节点都是一个Replica Sets，这样保证数据的安全性
• 当一个chunk超过其限制的最大体积时，会分裂成两个小的chunk
• 当chunk在分片节点中分布不均衡时，会引发chunk迁移操作

分片时服务器角色

上面讲了分片的标准，下面是具体在分片时的几种节点角色

• 客户端访问路由节点mongos来进行数据读写
• config服务器保存了两个映射关系，一个是key值的区间对应哪一个chunk的映射关系，另一个是chunk存在哪一个分片节点的映射关系
• 路由节点通过config服务器获取数据信息，通过这些信息，找到真正存放数据的分片节点进行对应操作
• 路由节点还会在写操作时判断当前chunk是否超出限定大小，如果超出，就分列成两个chunk
• 对于按分片key进行的查询和update操作来说，路由节点会查到具体的chunk然后再进行相关的工作
• 对于不按分片key进行的查询和update操作来说，mongos会对所有下属节点发送请求然后再对返回结果进行合并

其它关于mongodb 的一些小提示:

• 不要使用32位版本

MongoDB的32位版本也是不建议被使用的，因为你只能处理2GB大小的数据。还记得第一个限制么？这是MongoDB关于该限制的说明。

• 了解官方的限制

让我感到惊讶的是，很少有人会查询关于他们将要使用的工具的限制。幸好，MongoDB的开发人员发布了一篇MongoDB所有限制的博客，你可以提前了解相关信息，避免在使用过程中难堪。

• 主从复制不会确保高可用性

尽管已经不建议被使用了，不过MongoDB还是提供了另外一种复制策略，即主从复制。它解决了12个节点限制问题，不过却产生了新的问题：如果需要改变集群的主节点，那么你必须得手工完成，感到惊讶？看看这个链接吧。

• 通过复制集实现的数据复制效果非常棒，不过也有限制

MongoDB中数据复制的复制集策略非常棒，很容易配置并且使用起来确实不错。但如果集群的节点有12个以上，那么你就会遇到问题。MongoDB中的复制集有12个节点的限制，这里是问题的描述，你可以追踪这个问题看看是否已经被解决了。

结论

        Gridfs最适合大文件存储 ，特别是视频，音频，大型图片超过16MB大小的文件。小型文件也可以存储，不过需要付出2次查询代价(metadata与file content) [Tip#18 50 Tips and Tricks for MongoDB Developers]。不要修改存储文件的内容，而是更新文件元数据如版本，或上传新版本的文件，删除老版本的文件。对于大量文件存储时，需要多个数据节点，复制，数据分片等。别基于nginx访问图片文件，浏览器没有缓存。 从互联网存储图片案例来看，图片大都是jpg, png与缩略图文件，分存式文件系统(DFS)会是更好的解决方案。

资源：

GridFS官方
Building MongoDB applications with Binary Files Using GridFS

如有想了解更多软件,系统 IT,企业信息化 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。