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/。
应用层查询读取可采用读写分离策略。需注意从节点在数据同步时会加读锁，直到本次同步结束，会影响查询效率，可根据实际场景选择读写分离策略。
本文地址：https://blog.csdn.net/weixin_38388584/article/details/107347173