MongoDB数据库技术总结.doc

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