mongodb对大文件存储能,为什么MongoDB适合大数据的存储
一、如何把mongodb中的数据读到内存中
这种用法对于以下应用场合来讲,超实用:
置于慢速RDBMS系统之前的写*作密集型高速缓存
需要轻量级数据库而且库中数据可以很容易清除掉的单元测试(unit testing)
如果这一切可以实现就真是太优雅了:我们就能够巧妙地在不涉及磁盘*作的情况下利用MongoDB的查询/检索功能。可能你也知道,在99%的情况下,磁盘IO(特别是随机IO)是系统的瓶颈,而且,如果你要写入数据的话,磁盘*作是无法避免的。
MongoDB有一个非常酷的设计决策,就是她可以使用内存影射文件(memory-mapped file)来处理对磁盘文件中数据的读写请求。这也就是说,MongoDB并不对RAM和磁盘这两者进行区别对待,只是将文件看作一个巨大的数组,然后按照字节为单位访问其中的数据,剩下的都交由*作系统(OS)去处理!就是这个设计决策,才使得MongoDB可以无需任何修改就能够运行于RAM之中。
这一切都是通过使用一种叫做tmpfs的特殊类型文件系统实现的。在Linux中它看上去同常规的文件系统(FS)一样,只是它完全位于RAM中(除非其大小超过了RAM的大小,此时它还可以进行swap,这个非常有用!)。我的服务器中有32GB的RAM,下面让我们创建一个16GB的 tmpfs:
#mkdir/ramdata#mount-ttmpfs-osize=16000Mtmpfs/ramdata/#dfFilesystem1K-blocksUsedAvailableUse%Mountedon/dev/xvde15905712497392487179286%/none153449360153449360%/dev/shmtmpfs163840000163840000%/ramdata
接下来要用适当的设置启动MongoDB。为了减小浪费的RAM数量,应该把**allfiles和noprealloc设置为true。既然现在是基于RAM的,这么做完全不会降低性能。此时再使用journal就毫无意义了,所以应该把nojournal设置为true。
dbpath=/ramdatanojournal=true**allFiles=truenoprealloc=true
MongoDB启动之后,你会发现她运行得非常好,文件系统中的文件也正如期待的那样出现了:
#mongoMongoDBshellversion:2.3.2connectingto:test>db.test.insert({a:1})>db.test.find(){"_id":ObjectId("51802115eafa5d80b5d2c145"),"a":1}#ls-l/ramdata/total65684-rw-------.1rootroot16777216Apr3015:52local.0-rw-------.1rootroot16777216Apr3015:52local.ns-rwxr-xr-x.1rootroot5Apr3015:52mongod.lock-rw-------.1rootroot16777216Apr3015:52test.0-rw-------.1rootroot16777216Apr3015:52test.nsdrwxr-xr-x.2rootroot40Apr3015:52_tmp
现在让我们添加一些数据,证实一下其运行完全正常。我们先创建一个1KB的document,然后将它添加到MongoDB中4百万次:
>str="">aaa="aaaaaaaaaa"aaaaaaaaaa>for(vari=0;i<100;++i){str+=aaa;}>for(vari=0;i<4000000;++i){db.foo.insert({a:Math.random(),s:str});}>db.foo.stats(){"ns":"test.foo","count":4000000,"size":4544000160,"avgObjSize":1136.00004,"storageSize":5030768544,"numExtents":26,"nindexes":1,"lastExtentSize":536600560,"paddingFactor":1,"systemFlags":1,"userFlags":0,"totalIndexSize":129794000,"indexSizes":{"_id_":129794000},"ok":1}
可以看出,其中的document平均大小为1136字节,数据总共占用了5GB的空间。_id之上的索引大小为130MB。现在我们需要验证一件非常重要的事情:RAM中的数据有没有重复,是不是在MongoDB和文件系统中各保存了一份?还记得MongoDB并不会在她自己的进程内缓存任何数据,她的数据只会缓存到文件系统的缓存之中。那我们来清除一下文件系统的缓存,然后看看RAM中还有有什么数据:
#echo3>/proc/sys/vm/drop_caches#freetotalusedfreesharedbufferscachedMem:30689876629278024397096010445817368-/+buffers/cache:47436830215508Swap:000
可以看到,在已使用的6.3GB的RAM中,有5.8GB用于了文件系统的缓存(缓冲区,buffer)。为什么即使在清除所有缓存之后,系统中仍然还有5.8GB的文件系统缓存??其原因是,Linux非常聪明,她不会在tmpfs和缓存中保存重复的数据。太棒了!这就意味着,你在RAM只有一份数据。下面我们访问一下所有的document,并验证一下,RAM的使用情况不会发生变化:
既然服务器在重启时RAM中的数据都会丢失,所以你可能会想使用**。采用标准的副本集(replica set)就能够获得自动故障转移(failover),还能够提高数据读取能力(read capacity)。如果有服务器重启了,它就可以从同一个副本集中另外一个服务器中读取数据从而重建自己的数据(重新同步,resync)。即使在大量数据和索引的情况下,这个过程也会足够快,因为索引*作都是在RAM中进行的:)
有一点很重要,就是写*作会写入一个特殊的叫做oplog的collection,它位于local数据库之中。缺省情况下,它的大小是总数据量的5%。在我这种情况下,oplog会占有16GB的5%,也就是800MB的空间。在拿不准的情况下,比较安全的做法是,可以使用oplogSize这个选项为oplog选择一个固定的大小。如果备选服务器宕机时间超过了oplog的容量,它就必须要进行重新同步了。要把它的大小设置为1GB,可以这样:
既然拥有了MongoDB所有的查询功能,那么用它来实现一个大型的服务要怎么弄?你可以随心所欲地使用分片来实现一个大型可扩展的内存数据库。配置服务器(保存着数据块分配情况)还还是用过采用基于磁盘的方案,因为这些服务器的活动数量不大,老从头重建集群可不好玩。
RAM属稀缺资源,而且在这种情况下你一定想让整个数据集都能放到RAM中。尽管tmpfs具有借助于磁盘交换(swapping)的能力,但其性能下降将非常显著。为了充分利用RAM,你应该考虑:
使用usePowerOf2Sizes选项对存储bucket进行规范化
定期运行compact命令或者对节点进行重新同步(resync)
schema的设计要相当规范化(以避免出现大量比较大的document)
二、【Python基础】mongodb存储文件的优缺点
MongoDB是一个开源的、基于分布式的、面向文档存储的非关系型数据库。是非关系型数据库当中功能丰富、像关系数据库的。MongoDB高性能、易部署、易使用,存储数据非常方便。
1、高性能:弱一致性,访问速度较快
2、文档结构的存储方式,能够更便捷的获取数、存储数据方便,高效存储二进制大对象
3、支持**集、主备、互为主备、自动分片等特性
4、全索引支持,查询语言功能非常强大
1、不支持事务,实际开发时得搞清楚哪些功能需要使用数据库提供的事务支持
2、MongoDB占用空间大(需要强大硬盘支持)
3、相对于MySQL那样成熟的维护工具,MongoDB维护工具不够完善、成熟
三、为什么MongoDB适合大数据的存储
1、Mongo是一个高性能,开源,无模式的文档型数据库,它在许多场景下可用于替代传统的关系型数据库或键/值存储方式。Mongo使用C++开发,提供了以下功能:
2、◆面向**的存储:适合存储对象及JSON形式的数据。
3、◆动态查询:Mongo支持丰富的查询表达式。查询指令使用JSON形式的标记,可轻易查询文档中内嵌的对象及数组。
4、◆完整的索引支持:包括文档内嵌对象及数组。Mongo的查询优化器会分析查询表达式,并生成一个高效的查询计划。
5、◆查询监视:Mongo包含一个监视工具用于分析数据库*作的性能。
6、◆**及自动故障转移:Mongo数据库支持服务器之间的数据**,支持主-从模式及服务器之间的相互**。**的主要目标是提供冗余及自动故障转移。
7、◆高效的传统存储方式:支持二进制数据及大型对象(如照片或图片)。
8、◆自动分片以支持云级别的伸缩性(处于早期alpha阶段):自动分片功能支持水平的数据库集群,可动态添加额外的机器。
9、MongoDB的主要目标是在键/值存储方式(提供了高性能和高度伸缩性)以及传统的RDBMS系统(丰富的功能)架起一座桥梁,集两者的优势于一身。根据官方网站的描述,Mongo适合用于以下场景:
10、◆网站数据:Mongo非常适合实时的插入,更新与查询,并具备网站实时数据存储所需的**及高度伸缩性。
11、◆缓存:由于性能很高,Mongo也适合作为信息基础设施的缓存层。在系统重启之后,由Mongo搭建的持久化缓存层可以避免下层的数据源过载。
12、◆大尺寸,低价值的数据:使用传统的关系型数据库存储一些数据时可能会比较昂贵,在此之前,很多时候程序员往往会选择传统的文件进行存储。
13、◆高伸缩性的场景:Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce引擎的内置支持。
14、◆用于对象及JSON数据的存储:Mongo的BSON数据格式非常适合文档化格式的存储及查询。
15、自然,MongoDB的使用也会有一些限制,例如它不适合:
16、◆高度事务性的系统:例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
17、◆传统的商业智能应用:针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用,数据仓库可能是更合适的选择。
18、MongoDB支持OS X、Linux及Windows等*作系统,并提供了Python,PHP,Ruby,Java及C++语言的驱动程序,社区中也提供了对Erlang及.NET等平台的驱动程序。