Redis基础学习之NoSQL概述和MySQL发展史

1.1 为什么要学习NoSQL？

我们现在处于大数据时代，一般的数据库都无法进行处理了！所以就需要引入NoSQL，让NoSQL配合MySQL，来满足一些开发时的需求！

那么在学习NoSQL之前，我们首先需要了解一下数据库架构的发展史，要知道，数据库的架构设计并不是一开始就考虑周全的，而是经历了又一次的架构升级，这样才能符合时代的要求！

1.1.1 单机MySQL时代

在中国的互联网刚兴起的90年代里，一个基本的网站访问量一般不会太大，单个数据库就完全足够使用！我们更多的使用的都是一个静态网页 (当时很流行的一些导航网站，把一些网址链接贴在首页)，这时的服务器是没有很大的压力的！

思考：在这种情况下，整个网站的瓶颈是什么呢？

• 如果用户数据增多，数据库的数据量越来越大，仅凭一台机器存放肯定是不够的！
• 网站规模变大，数据库的索引也随之增多 (底层是B+Tree实现)，这时候一台机器的内存就吃不消了！
• 随着用户量的增加，网站的访问量也随之增多 (包括读写混合)，这样只靠一台服务器是无法承受巨大的访问量！

如果你的网站出现以上三种情况之一，那么我们的数据库就需要进行升级！

1.1.2 Memcached (缓存) + MySQL + 垂直拆分 (读写分离)

1.垂直拆分

1-1 什么是垂直拆分(分库/分表)？

垂直拆分数据库是根据业务进行划分 (例如将某电商系统的商品数据库，拆分成商品、用户、订单等数据库)，通过降低单库 (表) 的大小来提高性能，但这种方式并没有解决高数据量带来的性能损耗；

同样的，分表就是将一个大表根据业务功能拆分成一个个子表 (例如，将用户表根据业务需求拆分成基本信息表和详细信息表等)

1-2 垂直拆分的优缺点

优点：

1. 拆分后业务清晰，达到专库专用效果
2. 可以实现热数据和冷数据的分离，将不经常的数据和变动较大的数据分散在不同的数据库/表中
3. 便于后期维护

2.主从复制

2-1 什么是主从复制？

主从复制是指数据可以从一个主节点复制到一个或者多个从节点，即把主库中事务性操作导致的变更同步到集群中的从库上 (MySQL默认采用异步复制方式，这样从节点不用一直访问主库来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主库中的所有数据库或者特定的数据库，或者特定的表)

注：以上的“MySQL数据库主服务器”都简称为 “主库” 或者 “主节点”，“MySQL数据库从服务器”都简称为 “从库” 或 “从节点”

假如一共有三个MySQL数据库服务器，我们可以让其中一个MySQL2 (主库) 负责去写入数据，而其他两个MySQL1和MySQL3 (从库) 负责读操作，当MySQL2写入数据后，它们只需将MySQL2中的写入数据同步过来

2-2 为什么需要主从复制?

1. 在业务复杂的系统中，如果存在锁表问题 (例如执行某个SQL写入操作时，需要将整个数据表进行锁定才能执行，这就导致暂时无法对该数据表进行读取操作)，会影响运行中的业务；因此我们可以使用主从复制（让主库负责写，从库负责读)，这样即使主库出现锁表，读取从库也可以保证业务的正常运作
2. 做数据的热备份 (热备份是在数据库正常运转的情况下，两余度同时工作 ( 默认采用archivelog mode 方式备份数据库)，当某一余度出现故障时，系统可切除故障余度，启动单余度方式，降级工作)
3. 架构的扩展 (随着业务量越来越大，I/O访问频率过高，单机MySQL已无法满足我们的需求，此时做多库的存储，降低磁盘I/O访问的频率，来提高单个服务器的I/O性能)

3.读写分离的定义和使用原因

3-1 什么是读写分离？

读写分离就是让主库处理事务性增、删、改操作 (Insert、Update、Delete)，而从库处理Select查询操作

假如一共有三个MySQL数据库服务器，我们可以让其中一个MySQL2 (主库) 负责写入数据，而其他两个MySQL1和MySQL3 (从库) 负责读操作

3-2 为什么要读写分离呢？

因为数据库的"写"操作 (例如写10000条数据到Oracle可以要3分钟)，操作时比较耗时的，而数据库的“读”操作 (例如从Oracle读取10000条数据可能只要5秒钟)，因此需要读写分离，解决的数据库的写入影响了查询的效率

4. 使用缓存的发展过程

其实大多数的网站80%的情况下都是在执行读操作，如果每次都要去查询数据库的话就十分麻烦！所以我们希望能够减轻数据库的压力，因此可以使用缓存来保证效率！

发展历程：优化数据库结构和索引 --> 使用文件缓存(IO流) --> Memcahed (当时最热门的技术！)

• 阶段一：优化数据库结构和索引：在遇到了数据量大导致访问速度慢问题后，开发人员从根本上进行解决，优化数据库的结构和索引！
• 阶段二：使用文件缓存 (基于IO流操作)：当经历了阶段一的优化数据库后，还是无法满足我们的需求时，开发人员想到使用文件方式来缓存一些数据信息，从而减轻数据库的压力，但这样的做法还是杯水车薪，并且不够安全！
• 阶段三：Memcached：最后，开发人员开始使用缓存来减轻数据库压力，将经常访问且不经常变化的数据存入缓存中，下次查询时只需查询缓存即可，Mencached就是其中的代表之一！

1.1.3 分库分表 + 水平拆分 + MySQL集群

本质：数据库 ( 读 + 写 )

技术和业务在发展的同时，对人的要求也越来越高！

1. 水平拆分的定义和优缺点

1-1 什么是水平拆分？

水平拆分是根据一定规则 (根据时间或者id序列值等) 进行数据的拆分，每个数据库结构一致 (这点与垂直分库分表相反)，数据得以拆分，从而提升性能

例如根据年份来拆分不同的数据库，或者根据用户的id值，通过特定规则拆分成若干个表

1-2 为什么要进行水平拆分？

由于单一节点无法满足需求，需要扩展为多个节点，多个节点具有一致的功能，组成一个服务池，一个节点服务一部分请求量，所有的节点共同处理大规模高并发的请求量

1-3 水平拆分的优缺点？

优点：

1. 单库 (表) 的数据量得以减少，从而提高性能
2. 提高了系统的稳定性和负载能力
3. 拆分出的表结构相同，程序改动较少

缺点：

1. 拆分规则较难抽象
2. 数据分片在扩容时需要迁移
3. 维护量增大
4. 存在跨库无法进行join连接等问题，同时涉及分布式事务，数据一致性等问题

2. MySQL数据库引擎 MyISAM 和 InnoDB

• 在早些年使用的MyISAM引擎中，会存在表锁 (假设有100万条数据，我要去查询某个用户的账号和密码，那么我在查询到这条数据的时候，会将表中的其他数据进行锁定)，这样就十分影响效率！
• 而后来转战到InnoDB引擎后，将表锁修改为了行锁 (只会锁定当前行数据)，行锁相对表锁，执行效率得到了明显提高！

上面都是在数据库引擎 (即物理层面) 减轻数据库的读写压力!

进入了微服务阶段，开始使用分库分表来减轻读写的压力

3.分库分表定义和原因

3-1 什么是分库分表？

顾名思义，分库分表就是按照一定的规则，对原有的数据库和表进行拆分，将原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表上的数据分块存储到多个表上。

例如为了满足性能需要，我们将某个电商系统之前所设计的商品数据库，拆分为商品详情，用户信息，订单详情，支付记录等多个数据库和数据表，这就实现了简单的分库分表！

3-2 为什么要进行分库分表？

随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更大的磁盘、IO流操作、系统开销等，甚至是性能上的瓶颈，而一台服务器的资源终究是有限的，因此需要对数据库和表进行拆分，从而更好的提供数据服务！

1.1.4 当今大数据时代

2010~2020十年之间，中国的互联网已经发生了翻天覆地的变化，从PC互联网时代到移动端互联网时代，再到如今的大数据时代，人们对导航定位，实时热搜，个性推荐等的功能需求越来越大，现在的数据量不仅很大，并且变化速度很快，只依靠MySQL等传统的关系型数据库显然已经不够了

然后就出现了像MongoDB这样介于关系型数据库和非关系型数据库之间的产品，还有Redis这种如今使用非常广泛的非关系型数据库

4-1 MongoDB的定义和特点

什么是MongDB？

MongoDB是一个基于分布式文件存储的数据库。由C++语言编写，旨在为Web应用提供可扩展的高性能数据存储解决方案

MongDB特点是什么？

• MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的；
• 它支持的数据结构非常松散，是类似JSON的BSON格式，因此可以存储比较复杂的数据类型；
• MongoDB最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引

上面提到在MongoDB中使用的类似于JSON的BSON格式，BSON类似于JSON，难道BSON是JSON失散多年的亲兄弟吗 (哈哈，开个玩笑)

有调皮的小伙伴又要问了，其实JSON我都不知道是个啥？
哈哈，看来有点高看你们啦，不卖关子了，那我们首先了解一下什么是JSON？

4-2 JSON的定义和特点

什么是JSON？

JSON (JavaScript Object Notation，JS对象标记) 是一种轻量级的数据交换格式

JSON的特点是什么？

• 采用完全独立于编程语言的文本格式来存储和显示数据
• 简洁和清晰的层次结构使得JSON成为理想的数据交换语言
• 易于人阅读和编写，同时也易于及其解析和生成，并有效地提升网络传输效率

说完了JSON，我们来聊聊BSON

4-3 BSON的定义和特点

什么是BSON？

其实BSON之名源于JSON，含义为Binary JSON (二进制JSON，这么说其实JSON是BSON它爹？)

BSON是一种计算机数据交换格式，主要被用于MongDB数据库中的数据存储和网络传输格式。它是一种二进制表示形式，能用来表示简单数据结构、关联数组，以及MongoDB中的各种数据类型

4-4 解决数据库存储大文件问题

如果用MySQL来存储一些比较大的文件 (例如博客和图片 (图片需要转换为二进制或者base64形式) 等)，这样就会占用数据库表很大的内存，而且查询效率也很低！

如果在大数据的IO处理压力下，数据库几乎没法变得更大！但如果有一种专门的数据库来存储这些比较大的文件，这样就会让MySQL的压力变小！

4-5 企业级互联网项目架构

了解完了数据库架构的发展史，想必你不仅对MySQL数据库有了一个更加全面的认识，而且对为什么要使用NoSQL也有了自己的答案！

总结：

在当今的大数据时代，每个用户的资料信息，网络社交，导航定位，包括用户使用时所产生的数据，还有用户的日志信息等的开始爆发式增长，这时就需要使用NoSQL数据库，NoSQL数据库可以很好的处理这些数据！

1.2 什么是NoSQL？

1.2.1 NoSQL定义

听到NoSQL数据库，你的第一反应是不是No SQL，没有SQL语句的数据库，这样理解那就大错特错了！

其实，NoSQL (全称Not Only SQL，即不仅仅是SQL) 泛指非关系型数据库；随着 互联网 Web 2.0 网站的兴起 ，传统的关系数据库在处理 Web 2.0 网站，特别是超大规模和高并发的 SNS (社交网络服务) 类型的 Web 2.0 纯动态网站 (动态是相对于html静态网页而言) 已经显得力不从心，出现了很多难以克服的问题，而非关系型数据库则由于其本身的特点得到了非常迅速的发展。

知识拓展：

什么是互联网 Web 2.0 时代？

Web2.0是相对于Web1.0的新的时代。指的是一个利用Web的平台，由用户主导而生成的内容互联网产品模式，为了区别传统由网站雇员主导生成的内容而定义为第二代互联网，web2.0是一个新的时代。

互联网 Web 2.0 时代的特点是什么？

Web 2.0 模式下的互联网应用具有以下显著特点：去中心化、开放和共享

1. 用户分享。在Web2.0模式下，可以不受时间和地域的限制分享各种观点。用户可以得到自己需要的信息也可以发布自己的观点。
2. 信息聚合。信息在网络上不断积累，不会丢失。
3. 以兴趣为聚合点的社群。在Web2.0模式下，聚集的是对某个或者某些问题感兴趣的群体，可以说，在无形中已经产生了细分市场。
4. 开放的平台，活跃的用户。平台对于用户来说是开放的，而且用户因为兴趣而保持比较高的忠诚度，他们会积极的参与其中。

什么是SNS？

SNS (全称是Social Networking Services，即“社交网站”或“社交网”)，专指社交网络服务，包括了社交软件和社交网站，代表应用有QQ，微信，钉钉和人人网等

了解完这些，你是否觉得当今最为流行的视频网站B站，博客论坛CSDN都与Web2.0模式下的互联网应用特点相一致，因为我们正处于这个开放包容的Web 2.0 互联网时代中，每个人都是创作者，都可以参与到网站内容的制作中来！

总结：

在当今大数据环境中，NoSQL的发展十分迅速，其中Redis是发展最快、当下最为流行和应用最广泛的非关系型数据库，因此Redis是我们当下所必需掌握的一门技术！

1.2.2 NoSQL特点

NoSQL主要有以下特点：

1. 以键值对形式存储数据

   例如我们在Java集合中所学习的Map<String,Object>，使用键值对来存储信息，而我们的Redis中的也是使用Key-Value形式存储内容 (其实就是往Map里put值)

2. 易扩展

   去掉了关系数据库的关系型特性，数据之间无关系，这样就非常容易进行扩展 (例如用户的资料信息，网络社交，导航定位，这些数据类型的存储不需要一个固定的格式，不需要多余的操作就可以横向扩展！)

3. 大数据量，高性能

   据官方统计，Redis读取速度是11万次每秒，写入速度是8万次每秒，NoSQL的缓存记录等级，是一种细粒度的缓存，因此性能会比较高！

4. 数据类型多样

   不需要我们去事先设计数据库，随取随用，如果是关系型数据库需要设计高性能的、存储大量数据的数据库表，很多人就无能为力了！

1.2.3 NoSQL与关系型数据库区别

传统的关系型数据库：

• 存储方式：传统的关系型数据库采用表格的存储方式 (数据以行和列的形式进行存储)，读取和查询都十分方便
• 存储结构：关系型数据库按照结构化的方法存储数据 (每个数据表都必须提前定义好结构和字段，再根据表的结构存入数据)，所以数据表的可靠性和稳定性都比较高
• 存储规范：为了避免重复、规范化数据以及充分利用好存储空间，关系型数据库把数据按照最小的关系表的形式进行存储，使得数据管理变得很清晰，一目了然
• 扩展方式：关系型数据库只具备纵向扩展能力 (即如果要提高处理能力，只能选择速度更快性能更强的计算机)；由于关系型数据库将数据存储在数据表中，数据操作的瓶颈出现在多张数据表的操作中，而且数据表越多这个问题越严重
• 查询方式：关系型数据库采用结构化查询语言 (即SQL) 来对数据库进行查询，支持数据库的CRUD (增加，查询，更新，删除) 操作，具有非常强大的功能，SQL还可以采用类似索引的方法来加快查询操作
• 规范化：在数据库的设计开发过程中，开发人员通常会面对同时需要对一个或者多个数据实体（包括数组、列表和嵌套数据）进行操作；在关系型数据库中，一个数据实体一般首先要分割成多个部分，然后再对分割的部分进行规范化，规范化以后再分别存入到多张关系型数据表中，这是一个复杂的过程。
• 事务性：关系型数据库强调ACID规则 (即原子性 (Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性 (Durability) )，可以满足对事务性要求较高或者需要进行复杂数据查询的数据操作，而且可以充分满足数据库操作的高性能和操作稳定性的要求。
• 读写性能：面对大量数据的处理时效率很低，特别是遇到高并发读写时性能会很差 ( 由于关系型数据库十分强调数据的一致性，虽然在存储数据和处理数据的可靠性高，但需要付出牺牲读写性能的巨大的代价！)
• 授权方式：大多数关系型数据库在使用时，都需要花费高昂的费用 (例如常见的关系型数据库 Oracle和SQLServer) ，但Mysql除外，其免费的同时，它的性能也受到了诸多的限制。

NoSQL：

• 存储方式：非关系型数据库主要采用键值对 (Key-Value) 形式存储，还包括列存储，文档存储和图形数据库 (存储网络社交关系)
• 扩展方式：易扩展 (去掉了关系数据库的关系型特性，数据之间无关系，这样就非常容易进行扩展)
• 查询方式：没有固定的查询语言 (不像关系型数据库有专门的SQL语句)
• 事务性：遵循最终一致性原则
• 读写性能：高性能 (特别对于大数据量，NoSQL表现出很高的读写性能！)
• 相关定理：CAP定理 (C：强一致性；A：高可用性；P：分区容错性) 和BASE (异地多活)

1.2.4 了解3V+3高

大数据时代的3V：主要是描述问题的

1. 海量 Volume
2. 多样 Variety
3. 实时 Velocity

大数据时代的3高：主要是对程序的要求

1. 高并发
2. 高可扩 (随时水平拆分，当我们的服务器不够用时，可以很快的进行扩展)
3. 高性能 (保证网站的高性能和用户的体验)

总结：

在真正的企业开发中，一定是 关系型数据库 + NoSQL一起配合使用！

参考视频链接：
https://www.bilibili.com/video/BV1S54y1R7SB (B站UP主遇见狂神说的Redis基础学习)

参考博客链接：
https://zhuanlan.zhihu.com/p/96212530 (mysql主从复制原理)
https://blog.csdn.net/u013421629/article/details/78793966 (mysql读写分离)
https://www.jianshu.com/p/3fed6db29a01 (分库分表浅谈)