《MongoDB数据库技术总结.doc》由会员分享，可在线阅读，更多相关《MongoDB数据库技术总结.doc（17页珍藏版）》请在三一办公上搜索。
1、MongoDB数据库技术总结目录第1章MONGODB简介3第2章MONGODB特性3第3章MONGODB工作方式6第4章要点介绍7索引8capped collection8复制与分片8性能9GridFS9用合适的数据库做适合的事情9第5章MONGODB分布式复制9第6章MONGODB分布式部署及分片11第7章MONGODB性能对比14第8章MONGODB占用空间过大原因16第1章 MongoDB简介MongoDB是一款开源，高性能，可扩展，无模式，面向文档(与JSON类似的数据模式)的数据库，它为时下最流行的编程语言提供了驱动，如PHP，Python，Perl，Ruby，JavaScript，
2、C+等，支持全文索引，自动分片，跨LAN或WAN扩展，采用Key/Value方式存储数据。MongoDB服务端可运行在Linux、Windows或OS X平台，支持32位和64位应用。世界上最大的单词收录网站Wordnik就从MySQL转向了MongoDB。第2章 MongoDB特性 Mongo是一个高性能，开源，无模式的文档型数据库，它在许多场景下可用于替代传统的关系型数据库或键/值存储方式。Mongo使用C+开发，提供了以下功能：面向集合的存储：适合存储对象及JSON形式的数据。动态查询：Mongo支持丰富的查询表达式。查询指令使用JSON形式的标记，可轻易查询文档中内嵌的对象及数组。完整
3、的索引支持：包括文档内嵌对象及数组。Mongo的查询优化器会分析查询表达式，并生成一个高效的查询计划。查询监视：Mongo包含一个监视工具用于分析数据库操作的性能。复制及自动故障转移：Mongo数据库支持服务器之间的数据复制，支持主-从模式及服务器之间的相互复制。复制的主要目标是提供冗余及自动故障转移。高效的传统存储方式：支持二进制数据及大型对象（如照片或图片）。自动分片以支持云级别的伸缩性（处于早期alpha阶段）：自动分片功能支持水平的数据库集群，可动态添加额外的机器。MongoDB的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，
4、集两者的优势于一身。根据官方网站的描述，Mongo适合用于以下场景：网站数据：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo搭建的持久化缓存层可以避免下层的数据源过载。大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce引擎的内置支持。用于对象及JSON数据的存储：Mongo
5、的BSON数据格式非常适合文档化格式的存储及查询。自然，MongoDB的使用也会有一些限制，例如它不适合：高度事务性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。需要SQL的问题MongoDB支持OS X、Linux及Windows等操作系统，并提供了Python，PHP，Ruby，Java及C+语言的驱动程序，社区中也提供了对Erlang及.NET等平台的驱动程序。所谓“面向集合”（Collenction-Oriented），意思
6、是数据被分组存储在数据集中，被称为一个集合（Collenction)。每个集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库（RDBMS）里的表（table），不同的是它不需要定义任何模式（schema)。 模式自由（schema-free)，意味着对于存储在mongodb数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。 存储在集合中的文档，被存储为键-值对的形式。键用于唯一标识一个文档，为字符串类型，而值则可以是各中复杂的文件类型。我们称这种存储形式为BSON（Binary Serializ
7、ed dOcument Format）。 MongoDB服务端可运行在Linux、Windows或OS X平台，支持32位和64位应用，默认端口为27017。推荐运行在64位平台，因为MongoDB在32位模式运行时支持的最大文件尺寸为2GB。第3章 MongoDB工作方式第4章 要点介绍跟mysqld一样，一个mongod服务可以有建立多个数据库，每个数据库可以有多张表，这里的表名叫collection，每个collection可以存放多个文档（document），每个文档都以BSON（binary json）的形式存放于硬盘中。跟关系型数据库不一样的地方是，它是的以单文档为单位存储的，你可
8、以任意给一个或一批文档新增或删除字段，而不会对其它文档造成影响，这就是所谓的schema-free，这也是文档型数据库最主要的优点。跟一般的key-value数据库不一样的是，它的value中存储了结构信息，所以你又可以像关系型数据库那样对某些域进行读写、统计等操作。可以说是兼备了key-value数据库的方便高效与关系型数据库的强大功能。索引跟关系型数据库类似，mongodb可以对某个字段建立索引，可以建立组合索引、唯一索引，也可以删除索引。当然建立索引就意味着增加空间开销，我的建议是，如果你能把一个文档作为一个对象的来考虑，在线上应用中，你通常只要对对象ID建立一个索引即可，根据ID取出对
9、象某些数据放在memcache即可。如果是后台的分析需要，响应要求不高，查询非索引的字段即便直接扫表也费不了太多时间。如果还受不了，就再建一个索引得了。默认情况下每个表都会有一个唯一索引：_id，如果插入数据时没有指定_id，服务会自动生成一个_id，为了充分利用已有索引，减少空间开销，最好是自己指定一个unique的key为_id，通常用对象的ID比较合适，比如商品的ID。capped collectioncapped collection是一种特殊的表，它的建表命令为：db.createCollection(mycoll, capped:true, size:100000)允许在建表之初就
10、指定一定的空间大小，接下来的插入操作会不断地按顺序APPEND数据在这个预分配好空间的文件中，如果已经超出空间大小，则回到文件头覆盖原来的数据继续插入。这种结构保证了插入和查询的高效性，它不允许删除单个记录，更新的也有限制：不能超过原有记录的大小。这种表效率很高，它适用于一些暂时保存数据的场合，比如网站中登录用户的session信息，又比如一些程序的监控日志，都是属于过了一定的时间就可以被覆盖的数据。复制与分片mongodb的复制架构跟mysql也很类似，除了包括master-slave构型和master-master构型之外，还有一个Replica pairs构型，这种构型在平常可以像mas
11、ter-slave那样工作，一但master出现问题，应用会自动了连接slave。要做复制也很简单，我自己使用过master-slave构型，只要在某一个服务启动时加上master参数，而另一个服务加上slave与source参数，即可实现同步。分片是个很头疼的问题，数据量大了肯定要分片，mysql下的分片正是成为无数DBA的噩梦。在mongodb下，文档数据库类似key-value数据库那样的易分布特性就显现出来了，无论构造分片服务，新增节点还是删除节点都非常容易实现。但mongodb在这方面做还不足够成熟，现在分片的工作还只做到alpha2版本（mongodb v1.1），估计还有很多问题
12、要解决，所以只能期待，就不多说了。性能在我的使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。mysql实际无法胜任大数据量下任意字段的查询，而mongodb的查询性能实在让我惊讶。写入性能同样很令人满意，同样写入百万级别的数据，mongodb比我以前试用过的couchdb要快得多，基本10分钟以下可以解决。补上一句，观察过程中mongodb都远算不上是CPU杀手。GridFSgridfs是mongodb一个很有趣的类似文件系统的东西，它可以用一大块文件空间来存放大量的小文件，这个对于存储web2.0网站中常见的大量小文
13、件（如大量的用户头像）特别有效。使用起来也很方便，基本上跟一般的文件系统类似。用合适的数据库做适合的事情mongodb的文档里提到的user case包括实时分析、logging、全文搜索，国内也有人使用mongodb来存储分析网站日志，但我认为mongodb用来处理有一定规模的网站日志其实并不合适，最主要的就是它占空间过于虚高，原来1G的日志数据它可以存成几个G，如此下去，一个硬盘也存不了几天的日志。另一方面，数据量大了肯定要考虑sharding，而mongodb的sharding到现在为止仍不太成熟。由于日志的不可更新性的，往往只需APPEND即可，又因为对日志的操作往往只集中于一两列，所
14、以最合适作为日志分析的还是列存储型的数据库，特别是像infobright那样的为数据仓库而设计的列存储数据库。由于mongodb不支持事务操作，所以事务要求严格的系统（如果银行系统）肯定不能用它。第5章 MongoDB分布式复制一、主从配置（Master Slave） 主从数据库需要两个数据库节点即可，一主一从（并不一定非得两台独立的服务器，可使用-dbpath参数指定数据库目录）。一个从节点可以有多个主节点，这种情况下，local.sources中会有多条配置信息。一台服务器可以同时即为主也为从。如果一台从节点与主节点不同步，比如从节点的数据更新远远跟不上主节点或者从节点中断之后重启但主节点
15、中相关的数据更新日志却不可用了。这种情况下，复制操作将会终止，需要管理者的介入，看是否默认需要重启复制操作。管理者可以使用resync:1 命令重启复制操作，可选命令行参数 -autoresync可使从节点在不同步情况发生10秒钟之后，自动重启复制操作。如果指定了-autoresync参数，从节点在10分钟以内自动重新同步数据的操作只会执行一次。-oplogSize命令行参数（与-master一同使用）配置用于存储给从节点可用的更新信息占用的磁盘空间（M为单位），如果不指定这个参数，默认大小为当前可用磁盘空间的5%（64位机器最小值为1G，32位机器为50M）。 二、互为主从（Replica
16、Pairs） 数据库自动协调某个时间点上的主从关系。开始的时候，数据库会判断哪个是从哪个是主，一旦主服务器负载过高，另一台就会自动成为主服务器。remoteserver组中的其他服务器host，可加:port指定端口。arbiterserver 仲裁（arbiter ）的host，也可指定端口。仲裁是一台mongodb服务器，用于协助判断某个时间点上的数据库主从关系。如果同组服务器在同一个交换机或相同的ec2可用区域内，就没必要使用仲裁了。如果同组服务器之间不能通信，可是使用运行在第三方机器上的仲裁，使用“抢七”方式有效地敲定主服务器，也可不使用仲裁，这样所有的服务器都假定是主服务器状态，可通
17、过命令人工检测当前哪台数据库是主数据库：$ ./mongo db.$cmd.findOne(ismaster:1); ismaster : 0.0 , remote : 192.168.58.1:30001 , ok : 1.0 一致性：故障转移机制只能够保障组中的数据库上的数据的最终一致性。如果机器L是主服务器，然后挂了，那么发生在它身上的最后几秒钟的操作信息就到达不了机器R，那么机器R在机器L恢复之前是不能执行这些操作的。安全性：同主从的操作相同。数据库服务器替换。当一台服务器失败了，系统能自动在线恢复。但当一台机器彻底挂了，就需要替换机器，而替换机器一开始是没有数据的，怎么办？以下会解释
18、如何替换一组服务器中的一台机器。假设nodes(n1,n2)中的n2挂了，需要变成nodes(n1,n3)。1、假设n2彻底挂了下线了，不能在线恢复。2、需要告诉n1，你的搭档已经不是n2了而是n3。可使用replacepeer 命令，检测该操作的返回值以确保操作成功。n1 ./mongo n1/admin db.$cmd.findOne(replacepeer:1);info : adjust local.sources hostname; db restart now required ok : 1.0 3、使用以下命令重启n1。n1 ./mongod -pairwith n3 -arbi
19、ter 4、启动n3。n3 ./mongod -pairwith n1 -arbiter 注意的是，n3在与n1数据完全同步之前不能接收作为主节点的任何操作。如果从节点设置了ok标志（db.getMongo().setSlaveOk() ），就可以查询从节点了。第6章 MongoDB分布式部署及分片 一、MongoDB集群包括一定数量的mongod（分片存储数据）、mongos（路由处理）、config server、clients。以下会一一介绍。1、shards：一个shard为一组mongod，通常一组为两台，主从或互为主从，这一组mongod中的数据时相同的，具体可见mongodb分布
20、式之数据复制。数据分割按有序分割方式，每个分片上的数据为某一范围的数据块，故可支持指定分片的范围查询，这同google的BigTable 类似。数据块有指定的最大容量，一旦某个数据块的容量增长到最大容量时，这个数据块会切分成为两块；当分片的数据过多时，数据块将被迁移到系统的其他分片中。另外，新的分片加入时，数据块也会迁移。2、mongos：可以有多个，相当于一个控制中心，负责路由和协调操作，使得集群像一个整体的系统。mongos可以运行在任何一台服务器上，有些选择放在shards服务器上，也有放在client 服务器上的。mongos启动时需要从config servers上获取基本信息，然后
21、接受client端的请求，路由到shards服务器上，然后整理返回的结果发回给client服务器。3、config server：存储集群的信息，包括分片和块数据信息。主要存储块数据信息，每个config server上都有一份所有块数据信息的拷贝，以保证每台config server上的数据的一致性。4、shard key：为了分割数据集，需要制定分片key的格式，类似于用于索引的key格式，通常由一个或多个字段组成以分发数据，比如： name : 1 _id : 1 lastname : 1, firstname : 1 tag : 1, timestamp : -1 mongoDB的分片
22、为有序存储，shard key相邻的数据通常会存在同一台服务器（数据块）上。config server的db中存储的信息如下：二、服务器部署可以有多种方式。首先，每台config server、mongos、mongod都可以是单独的服务器，但这样会导致某些服务器的浪费，比如config server。下图为物理机共享的集群部署，不需要额外加机器。 当然也有其他的方案，比如把mongos部署在所有的mongod（server1-6）上，又或者在每个运用服务器（server7）上部署mongos。这样部署有个好处在于，appserver和mongos之间的通信建立在localhost inter
23、face上，减少了通信成本。当然，此乃官方说法，但本人有想法，尽管减少了appserver和mongos之间的通信成本，但mongos与mongod之间的通信成本却增加了，而且把mongos部署在appserver上并不是很利于sa管理，mongoDB应该是一个相对独立的系统，与应用的耦合度应该尽量降到最低，万一应用想要换数据库，也能多少减少些工作量。当然，视个人习惯了。第7章 MongoDB性能对比2010年8月5日，Mongodb 1.6正式发布了，这个版本增加和改进了很多功能，我了解的几个比较大的改进在：1) Mongodb存储文件申请磁盘空间的方式做了改进。在mongodb 1.4的时
24、候是按128M,256M,512M,1024M,2048M这样的方式申请磁盘空间的；而在mongodb 1.6中，已经是动态小量的申请磁盘空间了。2) 增加了$or等查询操作符，这在mongodb 1.4的时候是没有的。3) 改进和提高了并发性能。4) Replication的同步方面做了改进。5) etc.详细的changelog可以看：http:/jira.mongodb.org/browse/SERVER?report=com.atlassian.jira.plugin.system.project:changelog-panel在我发表这篇文章时，发现Mongodb 1.6.1也已经发
25、布了，主要是修复了一些bug。居然说性能得到了提高，那么我们就对Mongodb 1.6和Mongodb 1.4分别做了一个性能测试，想对比下看看Mongodb 1.6性能到底比Mongodb 1.4提高了多少。测试机器为一台普通台式机，安装在64位centos linux 5.4系统。cpu为Intel E7500，内存为2G,单个普通500G硬盘。测试程序为自己用java写的，可在此下载：测试程序每次测试都会insert 100万条记录（如10并发测试，每并发insert 10万条记录；20并发测试，每并发5万条记录.），每记录大小为1KB，然后再逐条update所有记录，最后逐条selec
26、t出来。测试程序是在本机跑的，所以本次测试忽略网络延时。好，下面我们看测试结果：下面图中横轴10.100是指并发测试的并发线程。在insert测试内，Mongodb1.4和Mongodb1.6平分秋色，基本上没有区别。虽然在mongodb 1.6中对申请磁盘空间方式做了改进，但对性能的提升没有体现出来。随着并发的增加，性能快速下降的问题也没有得到改进。在update方面，性能提升显著，合计有75%的性能提高。而且表现平稳，随着并发的增加，性能稳定。非常不错。select方面表现也不错，合计有83%性能提高。在并发线程小时尤其明显。第8章 MongoDB占用空间过大原因1、空间的预分配：为避免形
27、成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那样的指数递增，直到2G为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。2、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是最大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个in
28、dex，每个字段名用一个字节表示，这样就不用担心字段名取多长了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是拿空间来换取时间吧。3、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。4、可以定期运行db.repairDatabase()来整理记录，但这个过程会比较缓慢。因为官方文档中对各方面的内容已经有很详细的叙述，所以我并没有再过多的引用原文与代码，只是结合自己的使用归纳一些心得，有兴趣的朋友不妨直接去翻文档中自己感兴趣的问题，超群的博客上有一个很好的入门介绍。最后总结一句，文档型数据库有点像波粒二象性，总能在适当的时候表现出它作为关系型数据库或key-value数据库的优势来。
