MongoDB~基础知识记录

为何要学Mongodb

工作以来，使用最多、了解最多的是MySQL。但技术的发展一定是依据痛点来的，就比如我遇到的痛点，一个业务、一个平台能力、存储的一个对象，随着产品和运营的需求，不断的进行变更，每一次的变更，我都得去写DDL语言，去改表，每一次的改表，都让我胆战心惊：

• 会不会影响到其他逻辑？
• SQL执行过程中会不会有其他的线上影响？
• 改后的表如何兼容老逻辑？
• 有哪些下游接了这个BD的binlog，对他们会不会有什么影响？
• 考虑完上面，这些最后还得去改表、改代码、测试、灰度。。。。

所以学习Mongodb就是为了其的：高可扩展、高性能和高可用

虽然目前已经发展到7版本，但使用最多的是还是4开头的版本，再者是5开头的版本，在我眼里，主要原因还是4开头的版本支持了分布式的事务，能力已经足够，无需再去冒险升级扩展。
所以我学习的也是4.x版本。

简要

Mongodb是一个分布式的NoSQL存储系统，也就是非关系型的数据库，是文档数据库，可以直接理解为“是一个直接存储文档的数据库”，因为其的高性能、高扩展、高可用使用的场景大多还是web业务的系统。

基础概念

类似于MySQL中的数据库、表、行、列，在Mongodb里对一些对比，有助于快速理解
MongoDB 的存储结构区别于传统的关系型数据库，主要由如下三个单元组成：

• 字段（Field）：一个数据对象，对应的字段，可以理解为MySQL中的一列（Col）
• 文档（Document） ：MongoDB 中最基本的单元，由 BSON 键值对（key-value）组成，类似于关系型数据库中的行（Row）。
• 集合（Collection） ：一个集合可以包含多个文档，类似于关系型数据库中的表（Table）。
• 数据库（Database） ：一个数据库中可以包含多个集合，可以在 MongoDB 中创建多个数据库，类似于关系型数据库中的数据库（Database）。

文档的键是字符串。除了少数例外情况，键可以使用任意 UTF-8 字符。

• 键不能含有 \0(空字符）。这个字符用来表示键的结尾。
• . 和 $ 有特别的意义，只有在特定环境下才能使用。
• 以下划线_开头的键是保留的(不是严格要求的)。

集合不需要事先创建，当第一个文档插入或者第一个索引创建时，如果该集合不存在，则会创建一个新的集合。

Mongodb基本特点及其原理

模式自由、高扩展性

在Mongodb里，一个对象被存储为一个文档，本质是一个bson的数据。多个文档组成一个集合，类似MySQL里的表，但该集合没有schema限制，不需要定义，随存随扩展。

Bson 数据，是 JSON 文档的二进制表示。

Bson与JSON

Json本质就是一个字符串，如何对其里面的某一个字段进行查找和修改会非常痛苦，很耗时，所以bson就将字段进行拆分，为每一个字段存储一个其长度，以助于知道长度后，进行快速定位其位置，然后具体的数据会被解析成二进制存储。

所以降低了Json的可读性，但提高了查找和修改的效率，存储占用上也差不太多。

查询能力突出

基本的CRUD都支持，比较特殊的是嵌套文档查询和地理空间查询。

嵌套文档查询

例如有以下数据

db.inventory.insertMany( [{ item: "journal", qty: 25, size: { h: 14, w: 21, uom: "cm" }, status: "A" },{ item: "notebook", qty: 50, size: { h: 8.5, w: 11, uom: "in" }, status: "A" },{ item: "paper", qty: 100, size: { h: 8.5, w: 11, uom: "in" }, status: "D" },{ item: "planner", qty: 75, size: { h: 22.85, w: 30, uom: "cm" }, status: "D" },{ item: "postcard", qty: 45, size: { h: 10, w: 15.25, uom: "cm" }, status: "A" }
]);

如果要对size字段对应的文档内容，做等值查询。
下面的案例返回inventory集合中size字段的值等于文档{ h: 14, w: 21, uom: “cm” } 的所有文档。

db.inventory.find( { size: { h: 14, w: 21, uom: "cm" } } )

对嵌套文档整体做等值匹配的时候，要求的是对指定文档的精确匹配，包含字段顺序。

下面的案例无法查询到任何文档。

db.inventory.find( { size: { w: 21, h: 14, uom: "cm" } } )

地理空间查询

地理空间数据

在MongoDB中，您可以将地理空间数据存储为GeoJSON对象遗留坐标对。

要指定GeoJSON数据，请使用嵌入的文档:

• 一个名为type的字段，用于指定GeoJSON对象类型
• 一个名为坐标的字段，用于指定对象的坐标。

如果指定纬度和经度坐标，请先列出经度，然后再列出纬度：

• 有效的经度值在**-180到180**之间（包括两者）。
• 有效的纬度值在**-90到90**之间（包括两者之间）。

    location: {type: "Point",coordinates: [-73.856077, 40.848447]}

还有专属的地理空间索引，这里就不过多看了，简单知道即可。
而对于查询，比如要查询：指定GeoJSON点至少1000米，最多5000米的文档，并按从最近到最远的顺序排序：

db.places.find(  {   location:  { $near:   {  $geometry: { type: "Point",  coordinates: [ -73.9667, 40.78 ] },   $minDistance: 1000,      $maxDistance: 5000    }   } }
)

事务支持、锁机制、MVCC

NoSQL 数据库通常不支持事务，为了可扩展和高性能进行了权衡。MongoDB 就支持事务。与关系型数据库一样，MongoDB 事务同样具有 ACID 特性。MongoDB 单文档原生支持原子性，也具备事务的特性。MongoDB 4.0 加入了对多文档事务的支持，但只支持复制集部署模式下的事务，也就是说事务的作用域限制为一个副本集内。MongoDB 4.2 引入了分布式事务，增加了对分片集群上多文档事务的支持，并合并了对副本集上多文档事务的现有支持。

MongoDB 事务同样具有 ACID 特性，说明如下：

• 原子性（ Automicity ）： 一个事务要么完全执行成功，要么不做任何改变。
• 一致性（ Consistency ）： 当多个事务并行执行时，元素的属性在每个事务中保持一致。
• 隔离性（ Isolation ）： 当多个事务同时执行时，互不影响。WiredTiger 本身支持多种不同类型的隔离级别，如读-未提交（ read-uncommitted ）（会有脏读）、读-已提交（ read-committed ）（会有不可重复读和幻读问题）和快照（ snapshot ）隔离。MongoDB 默认选择的是快照隔离。
• 持久性（ Durability ）： 一旦提交事务，数据的更改就不会丢失。

WiredTiger 存储引擎支持 read-uncommitted 、read-committed 和 snapshot3 种事务隔离级别，MongoDB 启动时默认选择 snapshot 隔离。

事务开始时，系统会为将要编辑的行创建一个快照，从已提交的事务中获取行版本数据，如果行版本数据标识的事务尚未提交，则从更早的事务中获取已提交的行版本数据作为其事务开始时的值。

通过事务可以看到其他还未提交的事务修改的行版本数据，但不会看到事务 id 大于 snap_max 的事务修改的数据。

MVCC 并发控制机制

要实现事务之间的并发操作，可以使用锁机制或 MVCC 控制等。对于 WiredTiger 来说，使用 MVCC 控制来实现并发操作，相较于其他锁机制的并发，MVCC 实现的是一种乐观并发机制。

MVCC 并发控制机制：

（1） A 事务首先从表中读取要修改的行数据，读取的库存值为100，行记录的版本号为0。

（2） B 事务也从中读取要修改的相同行数据，读取的库存值为100，行记录的版本号为0。

（3） A 事务修改库存值后提交，同时行记录版本号加1，变为1，大于 A 事物一开始读取行记录版本号1，A 事务可以提交。

（4） 但 B 事务提交时发现此时行记录版本号已经变为1，产生冲突，B 事务提交失败。

（5） B 事务尝试重新提交，此时再次读取的版本号为1，加1后版本号变为2，不会产生冲突，正常提交 B 事务。