1. 技术文章
  2. MongoDB入门

MongoDB入门

由 给你一囗甜甜゛ 提交于 2019-12-30 04:22:33

1.什么是NoSQL

Nosql的全称是Not Only Sql
这个概念早起就有人提出，而我们常用的都是关系型数据库。就像我们常用mysql,sqlserver一样，这些数据库一般用来存储重要信息，应对普通的业务是没有问题的。但是，随着互联网的高速发展，传统的关系型数据库在应付超大规模，超大流量以及高并发的时候力不从心。而就在这个时候，Nosql得到的告诉的发展。

2.为什么要使用NoSQL

单机 MySQL 的美好时代

在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。
在那个时候，更多的都是静态网页，动态交互类型的网站不多

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yHjk2K6A-1577542875039)(D:\youruike\MongoDB\assets\1575617897290.png)]

上述架构下，我们来看看数据存储的瓶颈是什么？

DAL : Data Access Layer（数据访问层 – Hibernate，MyBatis）

  • 数据量的总大小一个机器放不下时
  • 数据的索引（B+ Tree）一个机器的内存放不下时
  • 访问量(读写混合)一个实例不能承受

如果满足了上述1 or 3个时，只能对数据库的整体架构进行重构。

Memcached(缓存)+MySQL+垂直拆分

后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-25eniiP3-1577542875040)(D:\youruike\MongoDB\assets\1575618255216.png)]

Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端

Mysql主从读写分离

由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zE5djKfO-1577542875041)(D:\youruike\MongoDB\assets\1575618540005.png)]

分库分表+水平拆分+mysql集群

在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM在写数据的时候会使用表锁，在高并发写数据的情况下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM

ps：这就是为什么 MySQL 在 5.6 版本之后使用 InnoDB 做为默认存储引擎的原因 – MyISAM 写会锁表，InnoDB 有行锁，发生冲突的几率低，并发性能高。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dKFq1sYZ-1577542875041)(D:\youruike\MongoDB\assets\1575618900337.png)]

同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证

MySQL的扩展性瓶颈

MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题

今天是什么样子

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XQzRfQjS-1577542875043)(D:\youruike\MongoDB\assets\1.png)]

最前面的是企业级防火墙，后面通过负载均衡主机（软负载：Nginx，硬负载：F5）在 web 服务器集群之间进行调度，再由具体的 web 服务器（Tomcat）去访问缓存，访问数据库。

今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据

3.NoSQL代表

MongDB、 Redis、Memcache、ES

4.关系型数据库与NoSQL的区别

RDBMS(关系型数据库)

  • 高度组织化结构化数据
  • 结构化查询语言（SQL）
  • 数据和关系都存储在单独的表中。
  • 数据操纵语言，数据定义语言
  • 严格的一致性
  • 基础事务
  • ACID

关系型数据库遵循ACID规则

事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：

A (Atomicity) 原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。

C (Consistency) 一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。

I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的

D (Durability) 持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

NoSQL(非关系型数据库)

  • 代表着不仅仅是SQL
  • 没有声明性查询语言
  • 没有预定义的模式
  • 键 - 值对存储，列存储，文档存储，图形数据库
  • 最终一致性，而非ACID属性
  • 非结构化和不可预知的数据
  • CAP定理
  • 高性能，高可用性和可伸缩性

分布式数据库中的CAP原理(了解)

CAP定理：
    Consistency(一致性), 数据一致更新，所有数据变动都是同步的
    Availability(可用性), 好的响应性能
    Partition tolerance(分区容错性) 可靠性
    P: 系统中任意信息的丢失或失败不会影响系统的继续运作。

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。

而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。

所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点

说明：C：强一致性 A：高可用性 P：分布式容忍性

举例：

CA：传统Oracle数据库

AP：大多数网站架构的选择

CP：Redis、Mongodb

注意：分布式架构的时候必须做出取舍。

一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。

因此牺牲C换取P，这是目前分布式数据库产品的方向。

5.数据库流行度排名

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mUHpodp0-1577542875045)(D:\youruike\MongoDB\assets\16f5d6dec655ad8e.jpeg)]

6.国内哪些公司在使用MongoDB

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nCuR0VCH-1577542875049)(D:\youruike\MongoDB\assets\1575619800742.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZMPbxY8l-1577542875052)(D:\youruike\MongoDB\assets\1575621290795.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lkor16gd-1577542875053)(D:\youruike\MongoDB\assets\1575621316329.png)]

7.什么是MongoDB

MongoDB 是一个跨平台的，面向文档的数据库，是当前 NoSQL数据库产品中最热门的一种。它介于关系数据库和非关系数据库之间，是非关系数据库当中功能最丰富，最像关系数据库的产品。它支持的数据结构非常松散，是类似 JSON 的 BSON 格式，因此可以存储比较复杂的数据类型。

MongoDB 的官方网站地址是：http://www.mongodb.org/

8.MongoDB特点

MongoDB 最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象 的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。它是一个面向集合的,模式自由的文档型数据库。

具体特点总结如下：

  • 面向集合存储，易于存储对象类型的数据
  • 模式自由
  • 支持动态查询
  • 支持完全索引，包含内部对象
  • 支持复制和故障恢复
  • 使用高效的二进制数据存储，包括大型对象（如视频等）
  • 自动处理碎片，以支持云计算层次的扩展性
  • 支持 Python，PHP，Ruby，Java，C，C#，Javascript，Perl 及 C++语言的驱动程 序，社区中也提供了对 Erlang 及.NET 等平台的驱动程序
  • 文件存储格式为 BSON（一种 JSON 的扩展）

9.MongoDB体系结构

MongoDB 的逻辑结构是一种层次结构。主要由： 文档(document)、集合(collection)、数据库(database)这三部分组成的。逻辑结构是面 向用户的，用户使用 MongoDB 开发应用程序使用的就是逻辑结构。

  1. MongoDB 的文档（document），相当于关系数据库中的一行记录。
  2. 多个文档组成一个集合（collection），相当于关系数据库的表。
  3. 多个集合（collection），逻辑上组织在一起，就是数据库（database）。
  4. 一个 MongoDB 实例支持多个数据库（database）。 文档(document)、集合(collection)、数据库(database)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NZvaOA1b-1577542875053)(D:\youruike\MongoDB\assets\2018060711202099.png)]

数据库中的对应关系，及存储形式的说明

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-I1dMWQvX-1577542875054)(D:\youruike\MongoDB\assets\1190037-20180106141036237-258431155.png)]

10.数据类型

  • 基本数据类型
  • null：用于表示空值或者不存在的字段，{“x”:null}
  • 布尔型：布尔类型有两个值true和false，{“x”:true}
  • 数值：shell默认使用64为浮点型数值。{“x”：3.14}或{“x”：3}。对于整型值，可以使用
  • NumberInt（4字节符号整数）或NumberLong（8字节符号整数）， {“x”:NumberInt(“3”)}{“x”:NumberLong(“3”)}
  • 字符串：UTF-8字符串都可以表示为字符串类型的数据，{“x”：“呵呵”}
  • 日期：日期被存储为自新纪元依赖经过的毫秒数，不存储时区，{“x”:new Date()}
  • 正则表达式：查询时，使用正则表达式作为限定条件，语法与JavaScript的正则表达式相同，{“x”😕[abc]/}
  • 数组：数据列表或数据集可以表示为数组，{“x”： [“a“，“b”,”c”]}
  • 内嵌文档：文档可以嵌套其他文档，被嵌套的文档作为值来处理，{“x”:{“y”:3 }}
  • 对象Id：对象id是一个12字节的字符串，是文档的唯一标识，{“x”: objectId() }
  • 二进制数据：二进制数据是一个任意字节的字符串。它不能直接在shell中使用。如果要将非utf-字符保存到数据库中，二进制数据是唯一的方式。
  • 代码：查询和文档中可以包括任何JavaScript代码，{“x”:function(){/…/}}

11.Mongodb的优点与不足

（1）Mongodb的不足之处

在集群分片中的数据分布不均匀
单机可靠性比较差
大数据量持续插入，写入性能有较大波动
磁盘空间占用比较大

（2）Mongodb的过人之处

无模式
查询与索引方式灵活，是最像SQL的Nosql
支持复制集、主备、互为主备、自动分片等特性

12.MongoDB 的应用场景和不适用场景

1.适用场景

对于MongoDB实际应用来讲，是否使用MongoDB需要根据项目的特定特点进行甄别，这就需要我们对MongoDB适用和不适用的场景有一定的了解。

根据MongoDB 官网的说明，MongoDB 的适用场景如下:

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

2.不适合场景

高度事务性系统:例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
传统的商业智能应用:针对特定问题的BI 数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
需要复杂SQL查询的问题。

相信通过上面的说明，你已经大致了解了MongoDB 的使用规则，需要说明一点的是，MongoDB 不仅仅
是数据库，更多的使用是将MongoDB 作为一个数据库中间件在实际应用中合理划分使用细节，这一点对
于MongoDB 应用来讲至关重要！

标签
mongodb
nosql
mysql
缓存服务器
数据库事务
外链
mysql集群
数据库一致性
防盗链
sql优化
关系型数据库
分布式一致性
数据库
mysql数据库
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!