vlambda博客
学习文章列表

关注新技术，学习新知识！

MongoDB 是基于文档的 NoSql 存储引擎。MongoDB 的数据库管理由数据库、Collection（集合，类似 MySql 的表）、Document（文档，类似 MySQL 的行）组成，每个 Document 都是一个类 JSON 结构 BSON 结构数据。

MongoDB 的核心特性是：No Schema、高可用、分布式（可平行扩展），另外 MongoDB 自带数据压缩功能，使得同样的数据存储所需的资源更少。本节将会依次介绍这些特性的基本知识，以及 MongoDB 是如何实现这些能力的。

1 No Schema

MongoDB 是文档型数据库，其文档组织结构是 BSON(Binary Serialized Document Format) 是类 JSON 的二进制存储格式，数据组织和访问方式完全和 JSON 一样。支持动态的添加字段、支持内嵌对象和数组对象，同时它也对 JSON 做了一些扩充，如支持 Date 和 BinData 数据类型。正是 BSON 这种字段灵活管理能力赋予了 Mongo 的 No Schema 或者 Schema Free 的特性。

No Schema 特性带来的好处包括：

• 强大的表现能力：对象嵌套和数组结构可以让数据库中的对象具备更高的表现能力，能够用更少的数据对象表现复杂的领域模型对象。
  

• 便于开发和快速迭代：灵活的字段管理，使得项目迭代新增字段非常容易
  

• 降低运维成本：数据对象结构变更不需要执行 DDL 语句，降低 Online 环境的数据库操作风险，特别是在海量数据分库分表场景。
  MongoDB 在提供 No Schema 特性基础上，提供了部分可选的 Schema 特性：Validation。其主要功能有包括：
  

• 规定某个 Document 对象必须包含某些字段
  

• 规定 Document 某个字段的数据类型  开头的都是关键字）
  

• 规定 Document 某个字段的取值范围：可以是枚举 regex
  上面的字段包含内嵌文档的，也就是说，你可以指定 Document 内任意一层 JSON 文件的字段属性。validator 的值有两种，一种是简单的 JSON Object，另一种是通过关键字 $jsonSchema 指定。以下是简单示例，想了解更多请参考官方文档：MongoDB JSON Schema 详解。
  

方式一：

db.createCollection("saky_test_validation",{validator: { $and:[ {name:{$type: "string"}}, {status:{$in:["INIT","DEL"]}}] }})

方式二：

db.createCollection("saky_test_validation", { validator: { $jsonSchema: { bsonType: "object", required: [ "name", "status", ], properties: { name: { bsonType: "string", description: "must be a string and is required" }, status: {
 enum: [ "INIT", "DEL"],
 description: "can only be one of the enum values and is required"
 }
} }})

2 MongoDB 的高可用

高可用是 MongoDB 最核心的功能之一，相信很多同学也是因为这一特性才想深入了解它的。那么本节就来说下 MongoDB 通过哪些方式来实现它的高可用，然后给予这些特性我们可以实现什么程度的高可用。

相信一旦提到高可用，浮现在大家脑海里会有如下几个问题：

• 是什么：MongoDB 高可用包括些什么功能？它能保证多大程度的高可用？
  

• 为什么：MongoDB 是怎样做到这些高可用的？
  

• 怎么用：我们需要做些怎样的配置或者使用才能享受到 MongoDB 的高可用特性？
  那么，带着这些问题，我们继续看下去，看完大家应该会对这些问题有所了解了。
  

2.1 MongDB 复制集群

MongoDB 高可用的基础是复制集群，复制集群本质来说就是一份数据存多份，保证一台机器挂掉了数据不会丢失。一个副本集至少有 3 个节点组成：

• 至少一个主节点（Primary）：负责整个集群的写操作入口，主节点挂掉之后会自动选出新的主节点。
  

• 一个或多个从节点（Secondary）：一般是 2 个或以上，从主节点同步数据，在主节点挂掉之后选举新节点。
  

• 零个或 1 个仲裁节点（Arbiter）：这个是为了节约资源或者多机房容灾用，只负责主节点选举时投票不存数据，保证能有节点获得多数赞成票。
  从上面的节点类型可以看出，一个三节点的复制集群可能是 PSS 或者 PSA 结构。PSA 结构优点是节约成本，但是缺点是 Primary 挂掉之后，一些依赖 majority（多数）特性的写功能出问题，因此一般不建议使用。
  复制集群确保数据一致性的核心设计是：
  

• Oplog：oplog 是 MongoDB 的变更记录，类似 MySQL 的 binlog。MongoDB 的写操作都由 Primary 节点负责，Primary 节点会把每一个变更写到内存和 oplog，然后 100ms 一次将 oplog 刷盘。Secondary 节点通过拉取 oplog 信息，回放操作实现数据同步。
  

• Checkpoint：上面提到了 MongoDB 的写只写了内存和 oplog ，并没有做数据持久化，Checkpoint 就是将内存变更刷新到磁盘持久化的过程。MongoDB 会每 60s 一次将内存中的变更刷盘，并记录当前持久化点（checkpoint），以便数据库在重启后能快速恢复数据。
  

• 节点选举：MongoDB 的节点选举规则能够保证在 Primary 挂掉之后选取的新节点一定是集群中数据最全的一个，在 3.3.1 节点选举有说明具体实现
  

从上面 3 点我们可以得出 MongoDB 高可用的如下结论：

1. MongoDB 宕机重启之后可以通过 checkpoint 快速恢复上一个 60s 之前的数据。

2. MongoDB 最后一个 checkpoint 到宕机期间的数据可以通过 oplog 回放恢复。

3. oplog因为是 100ms 刷盘一次，因此至多会丢失 100ms 的数据（这个可以通过 WriteConcern 的参数控制不丢失，只是性能会受影响，适合可靠性要求非常严格的场景）

4. 如果在写数据开启了多数写，那么就算 Primary 宕机了也是至多丢失 100ms 数据（可避免，同上）

2.2 读写策略

从上一小节发现，MongoDB 的高可用机制在不同的场景表现是不一样的。实际上，MongoDB 提供了一整套的机制让用户根据自己业务场景选择不同的策略。这里要说的就是 MongoDB 的读写策略，根据用户选取不同的读写策略，你会得到不同程度的数据可靠性和一致性保障。这些对业务开放者非常重要，因为你只有彻底掌握了这些知识，才能根据自己的业务场景选取合适的策略，同时兼顾读写性能和可靠性。

Write Concern —— 写策略

控制服务端一次写操作在什么情况下才返回客户端成功，由两个参数控制：

• w 参数：控制数据同步到多少个节点才算成功，取值范围0**～节点个数/majority。0 表示服务端收到请求就返回成功，majority**表示同步到大多数（大于等于 N/2）节点才返回成功。其它值表示具体的同步节点个数。默认为 1，表示 Primary 写成功就返回成功。

• j 参数：控制单个节点是否完成 oplog 持久化到磁盘才返回成功，取值范围 true/false。默认 false，因此可能最多丢 100ms 数据。

Read Concern —— 读策略

控制客户端从什么节点读取数据，默认为 primary，具体参数及含义：

• primary：读主节点

• primaryPreferred：优先读主节点，不存在时读从节点

• secondary：读从节点

• secondaryPreferred：优先读从节点，不存在时读主节点

• nearest：就近读，不区分主节点还是从节点，只考虑节点延时。

更多信息可参考MongoDB 官方文档

Read Concern Level —— 读级别

这是一个非常有意思的参数，也是最不容易理解的异常参数。它主要控制的是读到的数据是不是最新的、是不是持久的，最新的和持久的是一对矛盾，最新的数据可能会被回滚，持久的数据可能不是最新的，这需要业务根据自己场景的容忍度做决策，前提是你的先知道有哪些，他们代表什么意义：

• local：直接从查询节点返回，不关心这些数据被同步到了多少个节点。存在被回滚的风险。
  

• available：适用于分片集群，和 local 差不多，也存在被回滚的风险。
  

• majority：返回被大多数节点确认过的数据，不会被回滚，前提是 WriteConcern=majority
  

• linearizable：适用于事务，读操作会等待在它开始前已经在执行的事务提交了才返回
  

• snapshot：适用于事务，快照隔离，直接从快照去。
  

为了便于理解 local 和 majority，这里引用一下 MongoDB 官网上的一张 WriteConcern=majority 时写操作的过程图：

通过这张图可以看出，不同节点在不同阶段看待同一条数据满足的 level 是不同的：

3 MongoDB 的可扩展性 —— 分片集群

水平扩展是 MongoDB 的另一个核心特性，它是 MongoDB 支持海量数据存储的基础。MongoDB 天然的分布式特性使得它几乎可无限的横向扩展，你再也不用为 MySQL 分库分表的各种繁琐问题操碎心了。当然，我们这里不讨论 MongoDB 和其它存储引擎的对比，这个以后专门写下，这里只关注分片集群相关信息。

3.1 分片集群架构

MongoDB 的分片集群由如下三个部分组成：

• Mongos：路由服务，不存具体数据，从 Config 获取集群配置讲请求转发到特定的分片，并且整合分片结果返回给客户端。

• Mongod：一般将具体的单个分片叫 mongod，实质上每个分片都是一个单独的复制集群，具备负责集群的高可用特性。

其实分片集群的架构看起来和很多支持海量存储的设计很像，本质上都是将存储分片，然后在前面挂一个 proxy 做请求路由。但是，MongoDB 的分片集群有个非常重要的特性是其它数据库没有的，这个特性就是数据均衡。数据分片一个绕不开的话题就是数据分布不均匀导致不同分片负载差异巨大，不能最大化利用集群资源。

MongoDB 的数据均衡的实现方式是：

1. 分片集群上数据管理单元叫 chunk，一个 chunk 默认 64M，可选范围 1 ～ 1024M。

2. 集群有多少个 chunk，每个 chunk 的范围，每个 chunk 是存在哪个分片上的，这些数据都是存储在 Config 的。

3. chunk 会在其内部包含的数据超过阈值时分裂成两个。

4. MongoDB 在运行时会自定检测不同分片上的 chunk 数，当发现最多和最少的差异超过阈值就会启动 chunk 迁移，使得每个分片上的 chunk 数差不多。

5. chunk 迁移过程叫 rebalance，会比较耗资源，因此一般要把它的执行时间设置到业务低峰期。

关于 chunk 更加深入的知识会在后面进阶知识里面讲解，这里就不展开了。

3.2 分片算法

MongoDB 支持两种分片算法来满足不同的查询需求：

• 区间分片：可以按 shardkey 做区间查询的分片算法，直接按照 shardkey 的值来分片。

• hash分片：用的最多的分片算法，按 shardkey 的 hash 值来分片。hash 分片可以看作一种特殊的区间分片。

区间分片示例：

hash 分片示例：

从上面两张图可以看出：

• 分片的本质是将 shardkey 按一定的函数变换 f(x) 之后的空间划分为一个个连续的段，每一段就是一个 chunk。

• 区间分片 f(x) = x；hash 分片 f(x) = hash(x)

• 每个 chunk 在空间中起始值是存在 Config 里面的。

• 当请求到 Mongos 的时候，根据 shardkey 的值算出 f(x) 的具体值为 f(shardkey)，找到包含该值的 chunk，然后就能定位到数据的实际位置了。

4 数据压缩

MongoDB 的另外一个比较重要的特性是数据压缩，MongoDB 会自动把客户数据压缩之后再落盘，这样就可以节省存储空间。MongoDB 的数据压缩算法有多种：

• Snappy：默认的压缩算法，压缩比 3 ～ 5 倍

• Zlib：高度压缩算法，压缩比 5 ～ 7 倍

• 前缀压缩：索引用的压缩算法，简单理解就是丢掉重复的前缀

• zstd：MongoDB 4.2 之后新增的压缩算法，拥有更好的压缩率

现在推荐的 MongoDB 版本是 4.0，在这个版本下推荐使用 snappy 算法，虽然 zlib 有更高的压缩比，但是读写会有一定的性能波动，不适合核心业务，但是比较适合流水、日志等场景。

--

知识分享，时代前行！

~~ 时代Java

还有更多好文章……

请查看历史文章和官网，

↓有分享，有收获~