MongoDB详细介绍

1 基本概念、基本特征

MongoDB是一种强大、灵活、可扩展的数据存储方式。它扩展了关系型数据库的众多有用功能，如辅助索引、范围查询（range query）和排序。MongoDB的功能非常丰富，比如内置的对MapReduce式聚合的支持，以及对地理空间索引的支持。
MongoDB的数据模型对开发者来说非常友好，配置选项对于管理员来说也很轻松，并且有驱动程序和数据库shell提供的自然语言式的API。MongoDB会为你扫除障碍，让你关注编程本身而不是为存储数据烦恼。
MongoDB只支持对单行记录的原子性修改，并不支持对多行数据的原子操作。

1.1 丰富的数据类型

MongoDB是面向文档的数据库，不是关系型数据库。放弃关系模型的主要原因就是为了更加方便的扩展性，当然还有其他好处。
基本的思路就是将原来“行”（row）的概念换成更加灵活的“文档”（document）模型。面向文档的方式可以将文档或者数组内嵌进来，所以用一条记录就可以表示非常复杂的层次关系。
MongoDB没有模式：文档的键不会事先定义也不会固定不变。由于没有模式需要更改，通常不需要迁移大量数据。不必将所以数据都放到一个模子里面，应用层可以处理新增或者丢失的键。

1.2 容易扩展

MongoDB从最初设计的时候就考虑到了扩展的问题。它所采用的面向文档的数据模型使其可以自动在多台服务器之间分割数据。它还可以平衡集群的数据和负载，自动重排文档。要是需要更大的容量，只需在集群中添加新机器，然后让数据库处理剩下的事。

1.3 丰富的功能

（1）索引
MongoDB支持通用辅助索引，能进行多种快速查询，也提供唯一的、复合的和地理空间索引能力。
（2）存储JavaScript
开发人员不必使用存储过程了，可以直接在服务端存取JavaScript的函数和值。
（3）聚合
MongoDB支持MapReduce和其他聚合工具
（4）固定集合
集合的大小是有上限的，这对某些类型和数据（比如日志）特别有用。
（5）文件存储
MongoDB支持用一种容易使用的协议存储大型文件和文件的元数据。

有些关系型数据库的常见功能MongoDB并不具备，比如联接（join）和复杂的多行事务。这个架构上的考虑是为了提高哦扩展性，因为这两个功能实在很难在一个分布式系统上实现。

1.4 不牺牲速度

MongoDB使用MongoDB传输协议作为与服务器交互的主要方式（与之对应的协议需要更多的开销，如HTTP/REST）。它对文档进行动态填充，预分配数据文件，用空间换取性能的稳定。默认的存储引擎中使用了内存映射文件，将内存管理工作交给操作系统去处理。动态查询优化器会“记住”执行查询最高效的方式。

1.5 简便的管理

MongoDB尽量让服务器自治来简化数据库的管理。除了启动数据库服务器外，疾呼没有什么必要的管理操作。如果主服务器挂掉了，MongoDB会自动切换到备份服务器上，并且将备份服务器提升为活跃服务器。在分布式环境下，集群只需要知道有新增的节点，就会自动集成和配置新节点。

2 应用场景

MongoDB的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，集两者的优势于一身。mongo适用于以下场景：
（1）网站数据：mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
（2）缓存：由于性能很高，mongo也适合作为信息基础设施的缓存层。在系统重启之后，由mongo搭建的持久化缓存可以避免下层的数据源过载。
（3）大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。
（4）高伸缩性的场景：mongo非常适合由数十或者数百台服务器组成的数据库。
（5）用于对象及JSON数据的存储：mongo的BSON数据格式非常适合文档格式化的存储及查询。

不适合的场景：
（1）高度事物性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
（2）传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
（3）需要SQL的问题。

3 存储模型

MongoDB的文档是个抽象概念。其具体的呈现形式取决于使用的驱动和编程语言。因为MongoDB中的通信大量依赖于文档，所以需要一种所有驱动、工具和进程都能共享的文档表达方式，这中表达叫做Binary JSON（BSON）。
BSON是轻量的二进制格式，能将MongoDB的所有文档表示为字节字符串。数据库能理解BSON，存在磁盘上的文档也是这种格式。
当驱动要插入文档，或者将文档作为查询条件，驱动会将文档转换成BSON，然后再发往服务器。同样，返回到客户端的文档也是BSON格式的字符串。驱动需要将这些数据解码，变成本机的文档表示，最后返回给客户端。

用BSON格式的三个主要目标。
（1）效率
BSON设计用来更有效地表示数据，占用更少的空间。最差的情况下，BSON比JSON效率略低；最好的情况下（比如存放二进制数据或大数），BSON要更高效得多。
（2）可便利性
有些时候BSON牺牲了空间效率，换取更容易遍历的格式。例如，在字符串前面加入其长度，而不是在结尾处使用一个终结符。这对MongoDB内省文档很有用。
（3）性能
最后BSON的编码和解码速度都很快。它用C风格的表现方式来表示类型，在大多数编程语言中都非常快。

4 并发控制

MongoDB不支持事务，也就没有数据库级别的悲观锁了。那么我们的并发控制只能依赖乐观锁。

（1）悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
（2）乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性，乐观锁不能解决脏读和多读的问题。

5 内存管理

MongoDB默认的存储引擎是内存映射引擎。当服务器启动后，将所有数据文件映射到内存。然后由操作系统来负责将缓冲数据写入磁盘并将数据调入调出内存页面。这样的引擎有若干重要的特性。
（1）MongoDB管理内存的代码非常精炼，原因就是大部分工作推给了操作系统。
（2）MongoDB服务器进程的虚拟大小通常会非常大，超过整个数据集的大小。
（3）MongoDB不能控制数据写入到磁盘的顺序，也就是不能用预写日志提供单机的持久性。
（4）32位的MongoDB服务器有个限制，每个mongod最多只能处理2GB数据。这是因为所有数据必须能用32位地址访问到。

6 容灾备份

6.1 备份

（1）mongodump和mongorestore
mongodump是一种能在运行时备份的方法，它对运行的MongoDB做查询，然后将所有查到的文档写入磁盘。Mongodump使用普通的查询机制，所以产生的备份不一定是服务器数据的实时快照，同时还会对其他客户端的性能产生不利的影响。除了mongodump，MongoDB还提供了从备份中恢复数据的工具mongorestore。
（2）fsync和锁
虽然用mongodump和mongorestore 能不停机备份，但是却失去了获取实时数据视图的能力。MongoDB的fsync命令能在MongoDB运行时复制数据目录还不会损毁数据。fsync命令会强制服务器将所有缓冲区写入磁盘。还可以选择上锁阻止对数据库的进一步写入，直到释放锁为止。
（3）从属备份
虽然上面说的几种方式在备份数据方面已经很灵活了，但是都不及在从服务器上备份，因为不太在乎从属服务器的性能或是能不能读写，于是就能随意选择上面的3种备份方式：关停、转储和恢复工具或fsync命令。

6.2 修复

MongoDB内置的修复功能会试着修复损坏的数据文件。修复所有数据库最简单的方式就是加上—repair:mongod –repair来启动服务器。修复数据库的实际过程实际上非常简单：将所有文档导出然后马上导入，忽略那些无效的文档。完成以后，会重新建立索引。

7 MongoDB传输协议

驱动在TCP/IP协议的基础上简单封装了MongoDB传输协议，用来与MongoDB交互。基本上就是一个简单封装的BSON数据。例如，插入消息会有20字节的头部数据（包括告知服务器执行插入操作的代码，以及消息长度）、要插入的集合名、要插入的BSON文档列表。

8 MongoDB文件内部结构

MongoDB在数据存储上按命名空间来划分，一个Collection是一个命名空间，一个索引也是一个命名空间。
同一个命名空间的数据被分成很多个Extent，Extent之间使用双向链表连接。
在每一个Extent中，保存了具体每一行的数据，这些数据也是通过双向链接来连接的。
每一行数据存储空间不仅包括数据占用空间，还可能包含一部分附加空间，这使得在数据Update变大后可以不移动位置。
索引以BTree结构实现。

9 MongoDB数据同步

MongoDB采用Replica Sets模式的同步流程
本流程可简要描述如下：
（1）红色箭头表示写操作可以写到Primary上。然后异步同步到多个Secondary上。
（2）蓝色箭头表示读操作可以从Primary或Secondary任意一个中读取。
（3）各个Primary与Secondary之间一直保持心跳同步检测，用于判断Replica Sets的状态。

10 分片机制

MongoDB的分片是指定一个分片key来进行，数据按范围分成不同的chunk，每个chunk的大小有限制。
有多个分片节点保存这些chunk，每个节点保存一部分的chunk。
每一个分片节点都是一个Replica Sets，这样保证数据的安全性。
当一个chunk超过其限制的最大体积时，会分裂成两个小的chunk。
当chunk在分片节点中分布不均衡时，会引发chunk迁移操作。

前面讲了分片的机制，下面是具体在分片时几种节点的角色
客户端访问路由节点mongos来进行数据读写。
config服务器保存了两个映射关系，一个是key值的区间对应哪一个chunk的映射关系，另一个是chunk存在哪一个分片节点的映射关系。
路由节点通过config服务器获取数据信息，通过这些信息，找到真正存放数据的分片节点进行对应操作。
路由节点还会在写操作时判断当前chunk是否超出限定大小。如果超出，就分列成两个chunk。
对于按分片key进行的查询和update操作来说，路由节点会查到具体的chunk然后再进行相关的工作。
对于不按分片key进行的查询和update操作来说，mongos会对所有下属节点发送请求然后再对返回结果进行合并。