当前位置:   article > 正文

MongoDB~基础知识记录

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" }
]);
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

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

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

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

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

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

地理空间查询

地理空间数据

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

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

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

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

  • 有效的经度值在**-180180**之间(包括两者)。
  • 有效的纬度值在**-9090**之间(包括两者之间)。
    location: {
    type: "Point",
    coordinates: [-73.856077, 40.848447]

}
  • 1
  • 2
  • 3
  • 4
  • 5

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

db.places.find(  
        {   
            location:  
                { $near:   
                    {  
                        $geometry: { type: "Point",  coordinates: [ -73.9667, 40.78 ] },   
                        $minDistance: 1000,      
                        $maxDistance: 5000    
                    }   
                } 
        }
)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

事务支持、锁机制、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 事务。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/我家小花儿/article/detail/675520
推荐阅读
相关标签
  

闽ICP备14008679号