MongoDB数据库技术总结

《MongoDB数据库技术总结》由会员分享，可在线阅读，更多相关《MongoDB数据库技术总结（17页珍藏版）》请在装配图网上搜索。

1、MongoDB 数据库技术总结目录第1章MONGODB简介3第 2 章MONGODB 特性 3第 3 章MONGODB 工作方式 6第 4章要点介绍 7索引 8capped collection 8复制与分片 8性能 9GridFS 9用合适的数据库做适合的事情 9第 5 章 MONGODB 分布式复制 9第 6 章 MONGODB 分布式部署及分片 11第 7 章 MONGODB 性能对比 14第 8 章 MONGODB 占用空间过大原因 16第1章 MongoDB 简介MongoDB 是一款开源，高性能，可扩展，无模式，面向文档（与 JSON 类似的数据 模式）的数据库，它为时下最流行的编

2、程语言提供了驱动，如 PHP，Python，Perl，Ruby， JavaScript, C+等，支持全文索引，自动分片，跨LAN或WAN扩展，采用Key/Value 方式存储数据。MongoDB服务端可运行在Linux、Windows或OS X平台，支持32位和 64位应用。世界上最大的单词收录网站Wordnik就从MySQL转向了 MongoDB。-3前正在使用MongoDB的网站或企业已超过100家视觉伞国shutterfly-*SPhoneMedia MathsoliLnfl讹丈帆sahibindenuCom、 _ M1:JoomlaAdsZ06FS第2章 MongoDB 特性Mong

3、o是一个高性能，开源，无模式的文档型数据库，它在许多场景下可用于 替代传统的关系型数据库或键/值存储方式。Mongo使用C+开发，提供了以下功能：面向集合的存储：适合存储对象及JSON形式的数据。动态查询：Mongo支持丰富的查询表达式。查询指令使用JSON形式的标记，可 轻易查询文档中内嵌的对象及数组。完整的索引支持：包括文档内嵌对象及数组。Mongo的查询优化器会分析查询表 达式，并生成一个高效的查询计划。查询监视：Mongo包含一个监视工具用于分析数据库操作的性能。复制及自动故障转移：Mongo数据库支持服务器之间的数据复制，支持主-从模 式及服务器之间的相互复制。复制的主要目标是提供冗

4、余及自动故障转移。高效的传统存储方式：支持二进制数据及大型对象（如照片或图片）。自动分片以支持云级别的伸缩性（处于早期 alpha 阶段）：自动分片功能支持水 平的数据库集群，可动态添加额外的机器。MongoDB的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统 的RDBMS系统（丰富的功能）架起一座桥梁，集两者的优势于一身。根据官方网站的 描述，Mongo适合用于以下场景：网站数据：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储 所需的复制及高度伸缩性。缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之 后，由Mongo搭建的持久化缓存

5、层可以避免下层的数据源过载。大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较 昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo 的路线图中已经包含对MapReduce引擎的内置支持。用于对象及JSON数据的存储:Mongo的BSON数据格式非常适合文档化格式的存 储及查询。自然，MongoDB的使用也会有一些限制，例如它不适合：高度事务性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适 用于需要大量原子性复杂事务的应用程序。传统的商业智能应用:针对特定问题的BI数据库会对产生

6、高度优化的查询方式。 对于此类应用，数据仓库可能是更合适的选择。需要SQL的问题MongoDB 支持 OS X、Linux 及 Windows 等操作系统，并提供了 Python, PHP, Ruby, Java及C+语言的驱动程序，社区中也提供了对Erlang及.NET等平台的驱动程序。所谓“面向集合”(Collenction-Oriented )，意思是数据被分组存储在数 据集中，被称为一个集合(Collenction)。每个集合在数据库中都有一个唯一的 标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库( RDBMS) 里的表(table )，不同的是它不需要定义任何模式(s

7、chema)。模式自由(schema-free)，意味着对于存储在mongodb数据库中的文件，我 们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件 存储在同一个数据库里。存储在集合中的文档，被存储为键-值对的形式。键用于唯一标识一个文档， 为字符串类型，而值则可以是各中复杂的文件类型。我们称这种存储形式为BSON (Binary Serialized dOcument Format)。MongoDB服务端可运行在Linux、Windows或OS X平台，支持32位和64位 应用，默认端口为 27017。推荐运行在 64 位平台，因为 MongoDB 在 32 位模式运

8、行时支持的最大文件尺寸为 2GB。第3章MongoDB工作方式-MongoDB是一个介丁-关系数据库和养关系数据库之间的产品 1楚卄关系数据丼出中功能最半富并n最像决系型数据库。*传统的关系数据库一般市数据库(database).表(table).记 录(record)三个层次概念组成，MongoDB同样也衆由数据 库(database).集合(collection .文档& (document) 个咗次组咚 MongoDB里的集合对附于关系型数据库电的 表，但婭集合中没有列“行和关系的概念，这体现了模式口 由胳特点口-在MongoDB中数据以单-文档为单位存储.这样就能在单个 数据对象中表示

9、复杂的关系口文档可以由独立的某本类型属 性、内嵌文档或文档数组组成和 MongoDB存储时数据楼武是key-value对的集合,键是符 11 ,值可以是数扼类型集合里的任意类型,包插数组和文档刈 象这种数据格式称作BSON ,即Binary Sena!izedDocument Notation诫T呈一种类似JSON的二进制序列化 文档a MongoDB是一个免女装的数据库将它解圧后生 成一个bin目v1.6),其中包含10个可执行文件 ，除此之外不再需要任何苴它的二进制依赖文件。通常情况下启动数据库只需耍关注其中旳:两个可执 行文竹r mongod.exe利mongo.exe ,前者是 Mon

10、goDB数駅库进杜本身是核心数据库脈务器， 麻者竟命令行Shell客户端苴使用方法通常类似 T MySQL命令行Shell客卢端，用丁确保胪有内容 部已止常安装H能正常运行并口可以对数据进行 CRUD操作、执行管理任务尊等-MongoDB使用了内存映射文件进行数据管理，把所冇空 闲内存当缓存使用且不能撮崑内存大小。这既是优点也 是隸点?稅点f可以最大限度提升性能；缺点一容昜受 哄它程序干扰口数据空间采用预分配目的是为了避免形成过多的硬盘碎 片。它为每个数抑库分配一系列文件，每个数据文件都 会被预分呪一个大小，第一个文件名字为-.0 -,大 小为64MB ,第二个文件“ J 为128MB ,依此

11、类推 ,在32位模式运行时支持的最大文件为2GB 随看数 据量的增加，町以在其数据冃录里看到这些不断递增的 文件。 MongoDB没冇自动递增或序列特性，当BSON对 象插天到数据库屮时,如果没冇提供龍id ” ?- 段，数据库会自动生成亠个Objectld 作 为“id ”的值插入到集合中作为该文档的主键 (这京无避免苴它数据库意外地选择相同的惟一标 贝符的情况)，id -的值山4字节的时间戳,3 字节的机器粤,2字节的进程id以及3字节的自埴 计数组成。半然字段-id ?T的值可以手动生成 (任意类型都可)，只蛹旨够保证惟一性。-每个插入的BSON对象人小不能超过4MB,如果 超过4M时需

12、使用GridFS来储存数拥勺-删除记录后不会释放分配的空间，换句话说文原 记录空间不删除。第4章 要点介绍跟 mysqld 一样，一个 mongod 服务可以有建立多个数据库，每个数据库可以有多 张表，这里的表名叫collection，每个collection可以存放多个文档(document), 每个文档都以BSON (binary json)的形式存放于硬盘中。跟关系型数据库不一样的 地方是，它是的以单文档为单位存储的，你可以任意给一个或一批文档新增或删除字 段，而不会对其它文档造成影响，这就是所谓的schema-free，这也是文档型数据库 最主要的优点。跟一般的 key-value 数

13、据库不一样的是，它的 value 中存储了结构信 息，所以你又可以像关系型数据库那样对某些域进行读写、统计等操作。可以说是兼 备了 key-value 数据库的方便高效与关系型数据库的强大功能。索引 跟关系型数据库类似，mongodb可以对某个字段建立索引，可以建立组合索引、唯一 索引，也可以删除索引。当然建立索引就意味着增加空间开销，我的建议是，如果你 能把一个文档作为一个对象的来考虑，在线上应用中，你通常只要对对象 ID 建立一个 索引即可，根据ID取出对象某些数据放在memcache即可。如果是后台的分析需要， 响应要求不高，查询非索引的字段即便直接扫表也费不了太多时间。如果还受不了，

14、就再建一个索引得了。默认情况下每个表都会有一个唯一索引：_id,如果插入数据时没有指定_id，服务会 自动生成一个_id，为了充分利用已有索引，减少空间开销，最好是自己指定一个 unique的key为_id,通常用对象的ID比较合适，比如商品的ID。capped collectioncapped collection是一种特殊的表，它的建表命令为：db.createCollection(mycoll, capped:true, size:100000)允许在建表之初就指定一定的空间大小，接下来的插入操作会不断地按顺序 APPEND 数据在这个预分配好空间的文件中，如果已经超出空间大小，则回到文

15、件头覆盖原来 的数据继续插入。这种结构保证了插入和查询的高效性，它不允许删除单个记录，更 新的也有限制：不能超过原有记录的大小。这种表效率很高，它适用于一些暂时保存 数据的场合，比如网站中登录用户的session信息，又比如一些程序的监控日志，都 是属于过了一定的时间就可以被覆盖的数据。复制与分片mongodb的复制架构跟mysql也很类似，除了包括master-slave构型和master-master 构型之外，还有一个Replica pairs构型，这种构型在平常可以像master-slave那样 工作，一但mas ter出现问题，应用会自动了连接slave。要做复制也很简单，我自己 使

16、用过mas ter-slave构型，只要在某一个服务启动时加上-mas ter参数，而另一个 服务加上-slave与-source参数，即可实现同步。分片是个很头疼的问题，数据量大了肯定要分片，mysql下的分片正是成为无数DBA 的噩梦。在 mongodb 下，文档数据库类似 key-value 数据库那样的易分布特性就显现 出来了，无论构造分片服务，新增节点还是删除节点都非常容易实现。但 mongodb 在 这方面做还不足够成熟，现在分片的工作还只做到alpha2版本(mongodb v1.1)，估 计还有很多问题要解决，所以只能期待，就不多说了。性能 在我的使用场合下，千万级别的文档对象

17、，近 10G 的数据，对有索引的 ID 的查询不会 比 mysql 慢，而对非索引字段的查询，则是全面胜出。 mysql 实际无法胜任大数据量 下任意字段的查询，而 mongodb 的查询性能实在让我惊讶。写入性能同样很令人满意， 同样写入百万级别的数据mongodb比我以前试用过的couchdb要快得多，基本10分 钟以下可以解决。补上一句，观察过程中 mongodb 都远算不上是 CPU 杀手。GridFSgridfs 是 mongodb 一个很有趣的类似文件系统的东西，它可以用一大块文件空间来存 放大量的小文件,这个对于存储web2.0网站中常见的大量小文件（如大量的用户头像） 特别有效

18、。使用起来也很方便，基本上跟一般的文件系统类似。用合适的数据库做适合的事情mongodb的文档里提到的user case包括实时分析、logging、全文搜索，国内也有人 使用 mongodb 来存储分析网站日志，但我认为 mongodb 用来处理有一定规模的网站日 志其实并不合适，最主要的就是它占空间过于虚高，原来 1G 的日志数据它可以存成几 个G,如此下去，一个硬盘也存不了几天的日志。另一方面，数据量大了肯定要考虑 sharding,而mongodb的sharding到现在为止仍不太成熟。由于日志的不可更新性的， 往往只需APPEND即可，又因为对日志的操作往往只集中于一两列，所以最合适

19、作为日 志分析的还是列存储型的数据库，特别是像 infobright 那样的为数据仓库而设计的列 存储数据库。由于mongodb不支持事务操作，所以事务要求严格的系统（如果银行系统）肯定不能 用它。第5章 MongoDB 分布式复制一、主从配置 （Master Slave）主从数据库需要两个数据库节点即可，一主一从（并不一定非得两台独立的服务 器，可使用-dbpath 参数指定数据库目录）。一个从节点可以有多个主节点，这种情 况下， local.sources 中会有多条配置信息。一台服务器可以同时即为主也为从。如 果一台从节点与主节点不同步，比如从节点的数据更新远远跟不上主节点或者从节点 中

20、断之后重启但主节点中相关的数据更新日志却不可用了。这种情况下，复制操作将 会终止，需要管理者的介入，看是否默认需要重启复制操作。管理者可以使用resync:l 命令重启复制操作，可选命令行参数 -autoresync 可使从节点在不同步情况发生 10 秒钟之后，自动重启复制操作。如果指定了-autoresync 参数，从节点在 10 分钟以 内自动重新同步数据的操作只会执行一次。-oplogSize 命令行参数(与-master 一同使用)配置用于存储给从节点可用的更新 信息占用的磁盘空间(M为单位)，如果不指定这个参数，默认大小为当前可用磁盘 空间的 5%(64 位机器最小值为 1G， 32

21、 位机器为 50M)。二、互为主从(Replica Pairs)数据库自动协调某个时间点上的主从关系。开始的时候，数据库会判断哪个是从 哪个是主，一旦主服务器负载过高，另一台就会自动成为主服务器。remoteserver组中的其他服务器host,可加：port指定端口。arbiterserver仲裁(arbiter )的host,也可指定端口。仲裁是一台mongodb服务 器，用于协助判断某个时间点上的数据库主从关系。如果同组服务器在同一个交换机 或相同的 ec2 可用区域内，就没必要使用仲裁了。如果同组服务器之间不能通信，可 是使用运行在第三方机器上的仲裁，使用“抢七”方式有效地敲定主服务器

22、，也可不 使用仲裁，这样所有的服务器都假定是主服务器状态，可通过命令人工检测当前哪台 数据库是主数据库：$ ./mongo db.$cmd.findOne(ismaster:1); ismaster : 0.0 , remote : 192.168.58.1:30001 , ok : 1.0 一致性：故障转移机制只能够保障组中的数据库上的数据的最终一致性。如果机器 L 是主服务器，然后挂了，那么发生在它身上的最后几秒钟的操作信息就到达不了机器 R,那么机器R在机器L恢复之前是不能执行这些操作的。 安全性：同主从的操作相同。数据库服务器替换。当一台服务器失败了，系统能自动在线恢复。但当一台机器彻

23、底 挂了，就需要替换机器，而替换机器一开始是没有数据的，怎么办？以下会解释如何 替换一组服务器中的一台机器。假设 nodes(nl,n2)中的 n2 挂了，需要变成 nodes(nl,n3)。1、假设n2彻底挂了下线了，不能在线恢复。2、需要告诉nl,你的搭档已经不是n2 了而是n3。可使用replacepeer命令，检测 该操作的返回值以确保操作成功。nl ./mongo nl/admin db.$cmd.findOne(replacepeer:l);info : adjust local.sources hostname; db restart now requiredok : l.03、

24、使用以下命令重启 nl。nl ./mongod -pairwith n3 -arbiter 4、启动 n3。n3 ./mongod -pairwith nl -arbiter 注意的是，n3在与nl数据完全同步之前不能接收作为主节点的任何操作。如果从节点设置了 ok标志(db.getMongo().setSlaveOk()，就可以查询从节点了。第6章 MongoDB 分布式部署及分片一、MongoDB集群包括一定数量的mongod (分片存储数据)、mongos (路由处理)、 config server clients。以下会一一介绍。sh日比shardLshard2shardsmonodn

25、ongadcanfig senz&rsmongosclientmcngodmongDdmongDdmongodmongosmongodnnongodrrongodmongodnnongod1、shards： 个shard为一组mongod，通常一组为两台，主从或互为主从，这一组 mongod中的数据时相同的，具体可见mongodb分布式之数据复制。数据分割按有 序分割方式，每个分片上的数据为某一范围的数据块，故可支持指定分片的范围查询， 这同 google 的 BigTable 类似。数据块有指定的最大容量，一旦某个数据块的容量增 长到最大容量时，这个数据块会切分成为两块；当分片的数据过多时，

26、数据块将被迁 移到系统的其他分片中。另外，新的分片加入时，数据块也会迁移。2、mongos:可以有多个，相当于一个控制中心，负责路由和协调操作，使得集群像一 个整体的系统。 mongos 可以运行在任何一台服务器上，有些选择放在 shards 服务器 上，也有放在client服务器上的。mongos启动时需要从config servers上获取基本 信息，然后接受client端的请求，路由到shards服务器上，然后整理返回的结果发 回给client服务器。3、config server:存储集群的信息，包括分片和块数据信息。主要存储块数据信息， 每个 config server 上都有一份所

27、有块数据信息的拷贝，以保证每台 config server 上的数据的一致性。4、shard key：为了分割数据集，需要制定分片key的格式，类似于用于索引的key 格式，通常由一个或多个字段组成以分发数据，比如： name : 1 _id : 1 lastname : 1, firstname : 1 tag : 1, timestamp : -1 mongoDB的分片为有序存储,shard key相邻的数据通常会存在同一台服务器（数 据块）上。config server的db中存储的信息如下：collection min keymaxkeylocationusersname:Miller

28、1 name :Nessman shard jusersname:Nessman - name :Ogden shards二、服务器部署可以有多种方式。首先，每台config server、mongos、mongod都可 以是单独的服务器，但这样会导致某些服务器的浪费，比如config server。下图为 物理机共享的集群部署，不需要额外加机器。当然也有其他的方案，比如把mongos部署在所有的mongod (serverl-6)上， 又或者在每个运用服务器(server7 )上部署mongos。这样部署有个好处在于， appserver 和 mongos 之间的通信建立在 localhos

29、t interface 上，减少了通信成本。 当然，此乃官方说法，但本人有想法，尽管减少了 appserver 和 mongos 之间的通信成 本，但mongos与mongod之间的通信成本却增加了，而且把mongos部署在appserver 上并不是很利于sa管理，mongoDB应该是一个相对独立的系统，与应用的耦合度应该 尽量降到最低，万一应用想要换数据库，也能多少减少些工作量。当然，视个人习惯 了。第7章MongoDB性能对比 2010年8月5日，Mongodb 1.6正式发布了，这个版本增加和改进了很多功能，我了 解的几个比较大的改进在：1) Mongodb 存储文件申请磁盘空间的方式

30、做了改进。在 mongodb 1.4 的时候是按 128M,256M,512M,1024M,2048M这样的方式申请磁盘空间的；而在mongodb 1.6中， 已经是动态小量的申请磁盘空间了。2) 增加了$or等查询操作符，这在mongodb 1.4的时候是没有的。3) 改进和提高了并发性能。4) Replication 的同步方面做了改进。5) etc.详细的 changelog 可以看：htt p:/jira.mongodb.org/browse/SERVER?repor t二 com.a tl assian.jira.plugin.sys tem.project: changelog-p

31、anel在我发表这篇文章时，发现Mongodb 1.6.1也已经发 布了，主要是修复了一些bug。居然说性能得到了提高，那么我们就对Mongodb 1.6和Mongodb 1.4分别做了一个性 能测试，想对比下看看Mongodb 1.6性能到底比Mongodb 1.4提高了多少。测试机器为一台普通台式机，安装在64位centos linux 5.4系统ocpu为Intel E7500， 内存为 2G, 单个普通 500G 硬盘。测试程序为自己用java写的，可在此下载：htt p:/ test-0.4.rar测试程序每次测试都会insert 100万条记录(如10并发测试，每并发insert

32、10万 条记录；20并发测试，每并发5万条记录.)，每记录大小为1KB，然后再逐条update 所有记录，最后逐条 select 出来。测试程序是在本机跑的，所以本次测试忽略网络延时。好，下面我们看测试结果： 下面图中横轴10.100是指并发测试的并发线程。在 insert 测试内， Mongodb1.4 和 Mongodb1.6 平分秋色，基本上没有区别。虽然在mongodb 1.6 中对申请磁盘空间方式做了改进，但对性能的提升没有体现出来。 随着并发的增加，性能快速下降的问题也没有得到改进。Mongodb:L6与14 update性能对比4Q000|cxxxJ25000?20000-150

33、00100005000/z11114102030405075100Mongodb 1.4.422727217392173B22222222222222121276Mongodb 1.6.0400003B46138461384613B4613846038461在 update 方面，性能提升显著，合计有 75% 的性能提高。而且表现平稳，随着并发的 增加，性能稳定。非常不错。30000Mongodb 16与select性能对比200000102030405075100 Monge db 1.4.414705147058771291566226B495714IVIon godb 1.6.02S57

34、11537316666135131537312047813015DDO100005000select 方面表现也不错，合计有 83%性能提高。在并发线程小时尤其明显。http：hi haidu com/farmerluo/hlog/item/ec60h2116e6deh72ch80c479 htmlhtt p:/第8章 MongoDB 占用空间过大原因1、空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生 成一大块的硬盘空间，而且申请的量从 64M、 128M、 256M 那样的指数递增，直到 2G 为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这

35、些整块生 成容量不断递增的文件。2、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把 每个字段的key-value都以BSON的形式存储，如果value域相对于key域并不大，比 如存放数值型的数据，则数据的overhead是最大的。一种减少空间占用的方法是把字 段名尽量取短一些，这样占用空间就小了，但这就要求在易读性与空间占用上作为权 衡了。我曾建议作者把字段名作个index，每个字段名用一个字节表示，这样就不用 担心字段名取多长了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结 果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现 在的实现算是拿空间来换取时间吧。3、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原 记录空间不删除，只标记“已删除”即可，以后还可以重复利用。4、可以定期运行db.repairDatabase()来整理记录，但这个过程会比较缓慢。因为官方文档中对各方面的内容已经有很详细的叙述，所以我并没有再过多的引用原 文与代码，只是结合自己的使用归纳一些心得，有兴趣的朋友不妨直接去翻文档中自 己感兴趣的问题，超群的博客上有一个很好的入门介绍。最后总结一句，文档型数据库有点像波粒二象性，总能在适当的时候表现出它作为关 系型数据库或 key-value 数据库的优势来。