MongoDB介绍与部署使用

MongoDB的功能特性

MongoDB是一个高性能、开源、无模式的文档型数据库，设计用于提供高性能、水平可扩性、高可用性和高级可查询性，为Web应用提供可扩展的高性能数据存储解决方案。MongoDB的名称取自单词”humogous”中间的几个字符，是很大、巨大的意思。该数据库由10gen公司开发并提供技术支持，它属于NoSQL数据库家族中的一员，在许多场景下可以用来替代传统关系型数据库或key/value存储方式。
MongoDB使用C++开发实现，不支持SQL，但拥有功能强大的查询语法，其语法有点类似面向对象的查询语言，几乎可以实现类似关系数据库表查询的绝大部分功能。
MongoDB可以运行于Windows、Linux、OS X和Solaris等多种操作系统平台上，安装部署也比较简单。
MongoDB的设计目标是高性能、可扩展、易部署、易使用，存储数据非常方便。其主要功能特性如下：

面向集合存储，容易存储对象类型的数据。在MongoDB中数据被分组存储在集合中，集合类似RDBMS中的表，一个集合可以存储无限多的文档。
模式自由，采用无模式结构存储。在MongoDB里的集合中，存储的是无模式的文档，采用无模式存储数据是集合(Collection)区别于RDBMS中的表(Table)的一个重要特征。
支持完全索引，可以在任意属性上建立索引，包含内部对象。MongoDB的索引和RDBMS的索引基本一样，可以在指定属性、内部对象上创建索引以提高查询的速度。除此之外，MongoDB还可以提供创建基于地理空间的索引的能力。
支持查询。MongoDB支持丰富的查询操作，MongoDB几乎支持SQL中的大部分查询。
强大的聚合工具。MongoDB除了提供丰富的查询功能外，还提供强大的聚合工具，如count、group等，支持使用MapReduce完成复杂的聚合任务。
支持复制和数据恢复。MongoDB支持主从复制机制，可以实现数据备份、故障恢复、读扩展等功能。而基于副本集的复制机制提供了自动故障恢复的功能，确保了集群数据不会丢失。
使用高效的二进制数据存储，包括大型对象(如视频)。使用二进制格式存储，可以保存任何类型的数据对象。
自动处理分片，以支持云计算层次的扩展。MongoDB支持集群自动切分数据，对数据进行分片可以使集群存储更多的数据，实现更大的负载，也能保证存储的负载均衡。并且自动分片功能支持水平的数据库集群，可动态添加额外的机器。
支持Perl、PHP、Java、C#、JavaScript、Ruby、C和C++语言的驱动程序，Mon提供了当前所有主流开发语言的数据库驱动包，开发人员使用任何一种主流开发语言都可以轻松编程，实现访问MongoDB数据库。
文件存储格式为BSON(JSON的一种拓展)。BSON是二进制格式JSON的简称，BSON支持文档和数组的嵌套。MongoDB很像关系数据库MySQL，文档(Document)对应MySQL的行(row)，集合(Collection)对应MySQL中的表(Table)。
可以通过网络远程访问MongoDB数据库。
MongoDB从4.0引入支持事务功能，支持多文档ACID特性，可根据具体需要选择版本。

MongoDB适用的场景

网站数据：MongoDB 非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性；
缓存：由于性能很高，MongoDB 也适合作为信息基础设施的缓存层。在系统重启之后，由 MongoDB 搭建的持久化缓存层可以避免下层的数据源过载；
大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储；
高伸缩性的场景：MongoDB 非常适合由数十或数百台服务器组成的数据库。MongoDB的路线图中已经包含对 MapReduce 引擎的内置支持；
用于对象及 JSON 数据的存储：MongoDB 的 BSON 数据格式非常适合文档化格式的存储及查询。

MongoDB不适用的场景

要求高度复杂事务性的系统：所以对于需要大量原子性复杂事物的应用程序来说，还是需要关系型数据库的。MongoDB从4.0引入支持事务功能，支持多文档ACID特性，可根据具体需要选择版本。
传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
复杂的表级联查询：MongoDB不支持join。

MongoDB概念解析

下面对MongoDB的概念做一个解析，mongodb中基本的概念是文档、集合、数据库。

数据库

数据库是一个集合的物理容器。每个数据库获取其自己设定在文件系统上的文件。一个单一的MongoDB服务器通常有多个数据库。

集合

集合是一组MongoDB的文件。它与一个RDBMS表是等效的。一个集合存在于数据库中。集合不强制执行模式。集合中的文档可以有不同的字段。通常情况下，在一个集合中的所有文件都是类似或相关目的。

文档

文档是一组键值对。文档具有动态模式。动态模式是指，在同一个集合的文件不必具有相同一组集合的文档字段或结构，并且相同的字段可以保持不同类型的数据。
下表是SQL与MongDB对应的术语说明：

SQL术语/概念	MongoDB术语/概念	解释/说明
database(数据库)	database(数据库)
table(数据库表)	collection(集合)
row(行)	document(文档)
column(列)	field(字段)
index(索引)	index(索引)
table joins(表联合)		MongoDB不支持表连接，但MongoDB支持嵌入文档
primary key(主键)	primary key(主键)	MongoDB自动将_id字段设置为主键

数据类型

下表为MongoDB中常用的几种数据类型。

数据类型	描述
String	字符串。存储数据常用的数据类型。在 MongoDB 中，UTF-8 编码的字符串才是合法的。
Integer	整型数值。用于存储数值。根据你所采用的服务器，可分为 32 位或 64 位。
Boolean	布尔值。用于存储布尔值（真/假）。
Double	双精度浮点值。用于存储浮点值。
Min/Max keys	将一个值与 BSON（二进制的 JSON）元素的最低值和最高值相对比。
Arrays	用于将数组或列表或多个值存储为一个键。
Timestamp	时间戳。记录文档修改或添加的具体时间。
Object	用于内嵌文档。
Null	用于创建空值。
Symbol	符号。该数据类型基本上等同于字符串类型，但不同的是，它一般用于采用特殊符号类型的语言。
Date	日期时间。用 UNIX 时间格式来存储当前日期或时间。你可以指定自己的日期时间：创建 Date 对象，传入年月日信息。
Object ID	对象 ID。用于创建文档的 ID。
Binary Data	二进制数据。用于存储二进制数据。
Code	代码类型。用于在文档中存储 JavaScript 代码。
Regular expressionl	正则表达式类型。用于存储正则表达式。

MongoDB部署方式

MongoDB常用的集群搭建方式有三种：Master-Slaver/Replica Set/Sharding 。

Master-Slaver

主从复制一般用于备份或者做读写分离。由两种组件构成：
主(Master)：可读可写，当数据有修改的时候，会将oplog同步到所有连接的salve上去。
从(Slave)：只读不可写，自动从Master同步数据。

但从3.2版本开始，官方不再推荐这种模式，。因为如果主节点宕机后不能自动恢复，需要手动切换。除非Replica节点数超过50，才会使用Master-Slaver架构。

Replica Set

副本集是MongoDB提供的一种优于主从复制模式的解决方案，也是官方推荐替换主从复制的解决方案。该模式的好处在于，节点之间不分特定的主从关系，任何一个节点都可以是主节点primary，而其他节点都是secondary。

Replica Set的一堆mongod的实例集合，它们有着同样的数据内容。包含三类组件：
主节点（Primary）：接收所有的写请求，然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点，当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。默认读请求也是发到Primary节点处理的，需要转发到Secondary需要客户端修改一下连接配置。
副本节点（Secondary）：与主节点保持同样的数据集。当主节点挂掉的时候，参与选举主节点。
仲裁者（Arbiter）：不保存数据，只进行选主投票。Arbiter比价廉价，几乎不会占用什么系统资源，所以可随意部署在网络通的地方，但重要的一点是，在生产环境下不要和其他数据节点部署在同一台机器上。
注意：一个自动转移故障的Replica Set节点数必须为奇数。
如下图：Replica Set可以由三个相同的mongod组成，也可以由两个mongod和一个Arbiter组成，目的就是选主投票的时候要有一个大多数才能进行选主决策。

如下图：一但主节点挂掉，从节点就会选举一个新的primary，从而保证了数据的高可用性。

Sharding

随着mongodb数据量的增多，可能会达到单个节点的存储能力限制，以及application较大的访问量也会导致单个节点无法承担，所以此时需要构建集群环境，并通过sharding方案将整个数据集拆分成多个更小的chunk，并分布在集群中多个mongod节点上，最终达到存储和负载能力扩容、压力分流的作用。

分片集群有三个组件：

Shards:分片，即数据结点，存储数据和执行计算。为了保证高可用和数据一致性，生产环境中shards应该做成replica set，以防止数据片的单点故障引发的数据丢失。集群中有一个primary shard，执行非分片的任务。
mongos(query routers):查询路由，负责client的连接，并把任务分给shards，然后收集结果。一个集群中可以有多个query routers，以分担客户端请求(负载均衡)。
config server:配置服务器。保存了集群的元数据(比如数据放在哪个shards上)，query router通过config server中的配置信息决定把任务分配到哪个shards上。从3.4版本开始，Config servers必须部署为副本集(replica set)。

数据的分区

数据的分区根据“shard key”，对于每个需要sharding的collection，都需要指定“shard key”（分片键）；分片键必须是索引字段或者为组合索引的左前缀；mongodb根据分片键将数据分成多个chunks，并将它们均匀分布在多个shards节点上。目前，mongodb支持两种分区算法：区间分区（Range）和哈希（Hash）分区。

Range分区：首先shard key必须是数字类型，整个区间的上下边界分别为“正无穷大”、“负无穷大”，每个chunk覆盖一段子区间，即整体而言，任何shard key均会被某个特定的chunk所覆盖。区间均为作闭右开。每个区间均不会有重叠覆盖，且互相临近。当然chunk并不是预先创建的，而是随着chunk数据的增大而不断split。（参见下文）
Hash分区：计算shard key的hash值（64位数字），并以此作为Range来分区，基本方式同1）；Hash值具有很强的散列能力，通常不同的shard key具有不同的hash值（冲突是有限的），这种分区方式可以将document更加随机的分散在不同的chunks上。

Range分区更好的支持range查询，根据指定的shard key进行range查询，router可以很简单的判断出那些chunks覆盖此range，并将请求转发给特定的几个shards。不过当shard key是单调递增时，range分区会导致数据分布不均，因为在一定时间内，所有write请求（读取最新数据的read请求）将会映射到一个shard上，即少数shards在某段时间内承载了系统的大部分请求。
Hash分区正好相反，即使是单调递增的shard key，它们的Hash值也有较大不同，因此这些数据将会比较随机的分散在多个chunks上，但是这引入了range查询的问题，临近的shard key可能分布在不同的chunks上甚至是shards上，这意味着range查询需要访问所有的shards，特别是在有sort、limit等操作时。
数据的增删操作以及集群中增减shards节点，都可能导致数据的分布不均，不过mongos提供了balancer机制，它可以对chunks进行split（分裂）和迁移，最终动态平衡数据分布。

Splitting

一个后台进程用于避免chunk增长的过大，当chunk尺寸超过指定的chunk size时（默认为64M，可以命令修改），mongodb将会把此chunk分成等同的2个；inserts和updates操作均可以触发split，分离时mongodb不会迁移任何数据，也不会对shard产生影响（split之后shard将会修改config server中的metadata，IO通讯方式同“chunk迁移”，参见下文）。

Balancing

一个后台线程用于管理chunks迁移，balancer可以运行在任何一个（多个）mongos上；当集群中collection数据分布不均时，balancer将把一部分chunks从chunks量最大的shard上迁移到持有量最小的shards上，直到平衡为止；在chunk迁移时，源shard将会把此chunk数据全部发送给目标shard，在此期间，源shard仍负责接收客户端的请求（read、write）；最终，在config servers上变更chunks的位置信息。如果迁移过程中，发生异常，balancer将会终止此chunk的迁移，chunk也将继续保留在原来的shard上；当迁移成功后，mongodb将会删除原来shard上的chunk文件。

集群环境可以动态调整，比如数据量增大到一定程度，可以向集群中增加shard节点；如果数据量紧缩，也可以移除shard；这些过程均会触发chunks的动态平衡。

MongoDB部署使用

根据以上对MongoDB的介绍，我们可以看出，MongoDB非常适合存储价值低，大批量，高读写的数据。同时MongoDB的高可用性又保证了数据的可靠性，MongoDB自身对副本集和分片的支持也可以很方便我们进行水平扩展，实现更大的负载的同时，也能保证存储的负载均衡。以下以3.4.16版本做部署示例。

架构方案

采用分片架构模式，各节点设计为：3个mongos + 3个config servers + 4个shard。分片可以在数据量或者访问量过大时水平扩展架构，副本集可以保证每个分片都有一个副本，当某一个主节点出现异常时，该节点的副本集就会被重新选为主节点，保证系统的正常运行，主节点恢复运行后重新加入副本集，作为从节点继续运行。同时config也使用副本集。

1.mongos
mongos实例是轻量级服务，只会有一定的CPU消耗用于一些运算，并不需要数据目录，官方说明mongos可部署于其他应用服务器，本方案中mongos和config server部署同一台服务器上；
为保证mongos高可用，mongos会部署3个，单个mongos故障不会影响集群正常使用，待故障的mongos修复重新拉起即可。
2.config server
config server用于保存集群的所有元数据，包括分片规则、分片副本集信息、集合信息等。配置服务三个服务节点部署于其中三台分片服务器上，复用分片服务器的原因：
1).config server配置为副本集模式，单节点或者单个分片服务器的故障都不会影响到集群的读写；
2).配置服务不参与数据的处理，仅消耗少量的内存和存储，不会对分片服务器的性能造成严重影响；
3.sharding
四个分片副本集交叉部署于四台MongoDB服务器上，单个节点或者单个服务器故障均不会引发集群宕机，故障的分片副本集都可已保证有两个存活的几点并重新选举主节点.

部署规划

资源清单

通常考虑使用mongodb的场景数据量相对较大，考虑物理资源，规划7台服务器，其中3台虚假，4台实体机，其中3台虚机上部署mongos、config节点，实体机上部署mongodb副本级节点，这里一般建议副本节点机器磁盘挂载SSD，RAID磁盘阵列根据实际需要和数据价值选择。

服务器	机器类型	软件配置
Mongos/config服务器1	虚拟机	Mongodb3.4.16
Mongos/config服务器2	虚拟机	Mongodb3.4.16
Mongos/config服务器3	虚拟机	Mongodb3.4.16
MongoDB服务器1	实体机	Mongodb3.4.16
MongoDB服务器2	实体机	Mongodb3.4.16
MongoDB服务器3	实体机	Mongodb3.4.16
MongoDB服务器4	实体机	Mongodb3.4.16

目录结构和端口

所有服务器创建用户：mongo，数据库的所有部署目录都基于此用户。MongDB安装包解压于：/home/mongo/mongodata/mongodb中，日志和数据、配置等目录规划如下，端口可使用默认的，也可根据自身需要和管理规范选择，以下为示例：

服务器	实例	目录	端口
Mongos/config服务器1	Mongos	/home/mongo/mongodata/mongos/log	27001
Mongos/config服务器1	Config	/home/mongo/mongodata/config/data; /home/mongo/mongodata/config/data	27002
Mongos/config服务器2	Mongos	/home/mongo/mongodata/mongos/log	27001
Mongos/config服务器2	Config	/home/mongo/mongodata/config/data; /home/mongo/mongodata/config/data	27002
Mongos/config服务器3	Mongos	/home/mongo/mongodata/mongos/log	27001
Mongos/config服务器3	Config	/home/mongo/mongodata/config/data; /home/mongo/mongodata/config/data	27002
MongoDB服务器1	Shard1-master	/home/mongo/mongodata/shard1/data;/home/mongo/mongodata/shard1/log	27003
MongoDB服务器1	Shard4-slave	/home/mongo/mongodata/shard2/data;/home/mongo/mongodata/shard2/log	27004
MongoDB服务器1	Shard3-arbiter	/home/mongo/mongodata/shard3/data;/home/mongo/mongodata/shard3/log	27005
MongoDB服务器2	Shard2-master	/home/mongo/mongodata/shard1/data;/home/mongo/mongodata/shard1/log	27003
MongoDB服务器2	Shard1-slave	/home/mongo/mongodata/shard2/data;/home/mongo/mongodata/shard2/log	27004
MongoDB服务器2	Shard4-arbiter	/home/mongo/mongodata/shard3/data;/home/mongo/mongodata/shard3/log	27005
MongoDB服务器3	Shard3-master	/home/mongo/mongodata/shard1/data;/home/mongo/mongodata/shard1/log	27003
MongoDB服务器3	Shard2-slave	/home/mongo/mongodata/shard2/data;/home/mongo/mongodata/shard2/log	27004
MongoDB服务器3	Shard1·-arbiter	/home/mongo/mongodata/shard3/data;/home/mongo/mongodata/shard3/log	27005
MongoDB服务器4	Shard4-master	/home/mongo/mongodata/shard1/data;/home/mongo/mongodata/shard1/log	27003
MongoDB服务器4	Shard3-slave	/home/mongo/mongodata/shard2/data;/home/mongo/mongodata/shard2/log	27004
MongoDB服务器4	Shard2-arbiter	/home/mongo/mongodata/shard3/data;/home/mongo/mongodata/shard3/log	27005

说明：Replica Set名称
config：cfgReplSet
shard1：shard1ReplSet
shard2：shard2ReplSet
shard3：shard3ReplSet
shard4：shard4ReplSet

片键索引选择

前面提到对于副本集架构，数据的分区根据“shard key”，分片中的数据是以chunk管理的，mongo根据分片键将数据分成多个chunks，并将它们均匀分布在多个shards节点上。片键的选择需要根据具体的使用场景来确认，如大量的写，同时查询相对较少，可考虑hash片键，写压力比较均匀分散到各个副本节点上,通过并行性来提高IO吞吐量,但在范围查询时需要mongos从不同数据节点拿数据块做聚合汇和，带来一些查询效率较低。所以片键的选择是一个权衡的过程。
MongDB的索引分为以下几种类型：单键索引、复合索引、多键索引、地理空间索引、全文本索引和哈希索引。合适索引对查询效率不言而喻，根据具体业务场景创建索引。

应用层连接

writeConcern，其实就是在写操作的新能和可靠性之间做权衡。MongoDB Write Concern，简称MongoDB写入安全机制，是一种客户端设置，用于控制写入安全的级别。Write Concern 描述了MongoDB写入到mongod单实例，副本集，以及分片集群时何时应答给客户端。默认情况下，mongoDB文档增删改都会一直等待数据库响应(确认写入是否成功)，然后才会继续执行。具体参见：https://blog.csdn.net/leshami/article/details/52913705

更多异步操作见官方：http://mongodb.github.io/mongo-java-driver/3.5/driver-async/getting-started/quick-start/。
应用层查询读取可采用读写分离策略。需注意从节点在数据同步时会加读锁，直到本次同步结束，会影响查询效率，可根据实际场景选择读写分离策略。