是在抱歉,本应该周五是其他数据库,周一到周四都是 postgresql , mysql ,但目前的状态下,(都不知道今天是星期几)暂时不在准守这样的设置,以后待稳定后,在恢复原来的“人设”。
正文
———————————————————————————————
数据库中大部分都不建议存储较大的文件到数据库中,而在MONGODB 数据库中有一种方式可以存储较大的文件,这种文件的格式叫做GridFS.
这里就产生一个问题,这个GRIDFS 功能到底什么时候才有用
首先Gridfs的文件存储方式和数据提取方式都与普通的MONGO的信息存储的方式不同,根据文档的提示 gridfs 存储的数据应该是超过16MB的BSON文件。
GridFS并没有将文件存储在单个文档中,而是将文件分成多个部分(即块[1]),并将每个块存储为单独的文档。默认情况下,GridFS使用255 kB的默认块大小;也就是说,GridFS将文件分成255 kB的块(最后一块除外)。最后一块的大小取决于需要。类似地,不大于块大小的文件只有最后一个块,只使用所需的空间和一些额外的元数据。
本身MONGODB 的Gridfs是通过两个文件来进行存储数据的, 而Gridfs 和文档存储最大的区别在于,对于内存的消耗,如果是文档方式存储,则数据需要他通过内存来进行输出,而如果采用gridfs的方式来存储数据,则文件是通过驱动程序来进行文件的组装,而不再通过内存的方式来进行数据的提取。
说到这里可能已经有声音提出异议, 我存储文件使用文件系统好不好,为什么要用数据库来存储,性能怎么样,你的优势优势又在哪里,这估计是比较难于回答的问题之一。
在文件系统中,存储数据的个数是有限制的,这和文件的系统的设计是有关的,(Windows linux )都有类似的问题,而MONGODB 的方式来存储文件,这样的情况就不是一个需要特别考虑的问题。
这是其一, 而后面的问题是,如果我希望我的文件是同步传输的,这样的问题,估计要操作系统的文件系统来进行处理,就会出现问题。例如我在A 地点写了一个文件,我希望我能在B 地点来读取这个文件,或者我希望我的文件有备份,有COPY 有保护。
说到这里,估计提出异议的同学的声音慢慢会变得安静下来, 的确上面的问题让文件系统来做,方案,消耗对比,都不那么容易。
而交给MONGODB 则会变得容易了许多,如果你能保证网络的稳定性,的确可以进行在北京写入的文件,在上海同步提取,并且可能广州想同时获取也不是问题。这不就是一个异地的文件分发系统,如果能二次开发一下,我想这样的产品也会有相关的需求。
而另外祭出的一个点就是,数据安全方面的需求,对于文件系统如果对文件进行细致的权限划分将是很难的一件事情,而对于数据库则是本身具有的功能,从数据的安全性来看,如果多数据的安全性有较高的要求,完全可以通过MONGODB 的方式来更换传统的文件存储的模式。
废话这么多,可以看看到底怎么操作gridfs ,下面是将一个目录的文件,塞进mongodb中
文档中提出,如果需要自动更新整个文件的内容,请不要使用GridFS。作为替代方法,您可以存储每个文件的多个版本,并在元数据中指定文件的当前版本。您可以在上传文件的新版本后,在原子更新中更新指示“最新”状态的元数据字段,然后根据需要删除以前的版本。
在操作完上面的PYTHON 脚本后,查看下面的image database ,collection 会有两个
fs.chunks
fs.files
fs.files 是负责存储文件的非实体信息,可以认为他是一个目录, 而fs.chunks 则是存储实体的file的chunks 信息。
所以两个collection 任何一个受损都不是一件好事情。
为了提高效率,GridFS在每个块和文件集合上使用索引。为了方便,符合GridFS规范的驱动程序会自动创建这些索引。您还可以根据需要创建任何附加索引,以满足应用程序的需要。
GridFS使用filename和uploadDate字段对文件集合使用索引
现实中如果不使用python,在外部进行mongodb 的文件操作则可以使用 mongofiles 对MONGNODB 的存储文件进行简单的查询和数据的处理
对于小型的文件,并且有上面提到的需求的情况下,使用MONGODB 是可以来完满的达到相关的需求的,所以数据库可以替代存储,在某些场合是有优势的。
当然可能还有些同学提出,如果文件是在文件系统中可以打开后直接修改,而使用了gridfs 系统则不可以,而必须下载文件,然后在将修改后的文件上传,原文件删除,这样的做法是不是有点太麻烦了,这里就牵扯另一个问题了,重要点。
1 MONGODB GRIDFS使用它的目的是在文件的分发和权限的控制,以及文件的高可用和复用,多版本文件分发等等功能,这些功能都是文件系统不能给与你的
2 文件系统固然比GRIDFS 要方便,但如果你需要上面的功能,必须妥协。
经常听到有些质疑声,站在A 点 说B 点好,而B 点达不到你的要求,鱼和熊掌兼得,技术上当然是兼得最好,但要搞清楚主次,那些是你必须的,那些是可以舍弃的,幻想和理想,也仅仅就差一个字。
群里有一些共享文件,感谢数友最近提供的 POSTGRESQL 初级的练习考题