1.NoSQL概述

1.1 数据存储的发展

1 、单机MySQL的年代

用户通过应用访问 --> 数据库的访问层 --> 再进入mysql的实例。

90年代，一个基本的网站访问量一般不会太大，单个数据库完全足够。此时更多的是使用静态网页Html，服务器根本没有太大的压力。

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

1 、数据量如果太大、一个机器放不下了。

2 、当mysql数据超过300万条，需要建立索引 （B+ Tree），一个机器内存也放不下。

3 、访问量（读写混合），一个服务器承受不了。

只要你开始出现以上的三种情况之一，那么你就必须要晋级！

2 、Memcached（缓存） + MySQL + 垂直拆分 （读写分离）

​ 网站80%的情况都是在读，每次都要去查询数据库的话就十分的麻烦。所以说我们希望减轻数据的压力，我们可以使用缓存来保证效率。

​ 发展过程： 优化数据结构和索引–> 文件缓存（IO）—> Memcached（当时最热门的技术）

3 、分库分表 + 水平拆分 + MySQL集群

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

本质：数据库（读，写）

早些年MyISAM： 表锁（例如user表有100万条数据，当有用户通过密码查询信息，会将整张表锁起来，其它进程若要进行查询就必须等待，将会影响效率），高并发下就会出现严重的锁问题。

转战Innodb：行锁（比表锁效率高，查询时只锁当前行）。

MySQL推出了表分区，使用分库分表来解决写的压力，这个并没有多少公司使用！后来推出了MySQL的集群，很好满足了所有需求！

4 、如今的年代

​ 2010–2020 十年之间，世界已经发生了翻天覆地的变化；其中例如定位功能，音乐抖音热榜等也是一种数据。此时，MySQL等关系型数据库就不够用了，数据量很多，变化很快。 有的使用MySQL来存储一些比较大的文件，例如文字量较大的博客，大量的图片等，导致数据库表很大，效率就低了。如果有一种数据库来专门处理这种数据，MySQL压力就变得十分小（研究如何处理这些问题）。大数据的IO压力下，表几乎没法更改。

基本的互联网项目：

2.1 为什么要用NoSQL？

例如用户的个人信息，社交网络，地理位置等，用户自己产生的数据、用户日志等等爆发式增长。这时候我们就需要使用NoSQL数据库，NoSQL可以很好的处理以上的情况。

2.2 什么是NoSQL？

关系型数据库：表格 ，行 ，列。

NoSQL = Not Only SQL （不仅仅是SQL）。泛指非关系型数据库的，随着web2.0互联网的诞生，传统的关系型数据库很难应付web2.0时代，尤其是超大规模的高并发的社区， 暴露出来很多难以克服的问题。NoSQL在当今大数据环境下发展的十分迅速，Redis是发展最快的，而且是我们当下必须要掌握的一个技术！

例如很多的数据类型用户的个人信息，社交网络（大量文本），地理位置（拓扑图），流媒体（视频和音频）等，这些数据类型的存储不需要一个固定的格式（即表格数据存储进行列中），不需要多余的操作就可以横向扩展（即允许多台机器来控制的，例如集群）的 ，类似于 Map<String,Object> 使用键值对来控制。

2.3 NoSQL 特点

1、方便扩展（数据之间没有关系，很好扩展）

2、大数据量高性能（Redis 一秒写 8 万次，读取 11 万次，NoSQL的缓存记录级，是一种细粒度的缓存，性
能会比较高）

3 、数据类型是多样型的（不需要事先设计数据库，随取随用；如果是数据量十分大的表，很多人就无法设计了）

4、传统关系型数据库RDBMS 和 非关系型数据库NoSQL

传统关系型数据库RDBMS 
		- 结构化组织，例如：表、行、列
		- SQL
		- 数据和关系都存在单独的表中
		- 数据定义语言、数据操作语言、数据查询语言、事务控制语言、数据控制语言
		- 严格的ACID
		- 基础的事务操作

非关系型数据库NoSQL
		- 不仅仅是数据
		- 没有固定的查询语言
		- 键值对存储、列存储、文档存储、图形数据库(例如社交关系的拓扑图)
		- 最终一致性，允许过程中有误差，结果一致即可
		- CAP定理和BASE理论(例如异地多活，保证整个服务器不会宕机)
		- 高性能、高可用、高可扩

了解：3V+3高

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

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

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

1. 高并发（支持大量用户访问）
2. 高可扩（随时搭建集群，进行水平拆分，拓展机器来解决）
3. 高性能（保证用户体验和性能）

真正在公司中的实践：NoSQL + RDBMS 一起使用才是最强的

2.3 阿里巴巴的数据架构演进

思考问题：页面中大量的数据都是在一个数据库中的吗?


敏捷开发、极限编程、协同开发 、开源等

随着这样的竞争，业务是越来越完善，然后对于开发者的要求也是越来越高

没有什么是加一层解决不了的

例如：商城案例

# 1、商品的基本信息
  名称、价格、商家信息，这些信息在关系型数据库中存储即可。
  例如： MySQL / Oracle
  
# 2、商品的描述、评论
	文字比较多，使用文档型数据库，例如：MongoDB
	
# 3、图片
	分布式文件系统 FastDFS
	- 淘宝自己的 TFS
	- Gooale的 GFS
	- Hadoop HDFS
	- 阿里云  oss
	- 七牛云  oss
	
# 4、商品的关键字 （搜索）
	- 搜索引擎 solr ElasticSearch
	- ISerach：多隆（淘宝）
   
# 5、商品热门的波段信息（秒杀）
	- 内存数据库 Redis Tair、memecache...
	
# 6、商品的交易，外部的支付接口
 	- 三方应用  支付宝支付、银行支付接口、微信支付...

大型互联网应用问题：

	- 数据类型太多了

	- 数据源繁多，经常重构

	- 数据要改造，大面积改造