为什么要使用NoSQL？
发展过程
1、单机MySQL的年代！
APP：应用，一个网站。
DAL：数据库访问层，简单来说实现对数据库的CRUD
MySQL：数据库
早期的访问量不大的时候，单个数据库足够！那个时候的服务器根本没有太大的压力！
思考一下，在如今的互联网时代，原来的单个数据库，会遇到哪些瓶颈？
-
如果数据量太大，一个机器放不下（数据库保存数据是持久化的操作，是需要保存在硬盘上的）
-
数据的索引问题，如果一张表有百万条数据，肯定需要建立索引，但是索引太多，一个内存也放不
下- 如果不建立索引，整个的CRUD都会很慢
- 目前MySQL使用（B + Tree）
- 访问可以会有读写混合，一个服务器承受不了
记住，如果创业的都是从最原始的开始，需要确定真的有那么大的访问量的时候，采取扩充
2、Memcached（分布式的高速缓存系统） + MySQL + 垂直拆分（读写分离）
网站80%的情况都是在读，每一次都直接查询数据库的话十分麻烦，数据库也承载不了，所以说我们希望减轻数据库的压力，可以使用缓存来保证效率！
该时代的发展过程：先优化数据库结构和索引（对数据库的底层进行的优化）--> 文件缓存（IO，将数据保存在文件中肯定比数据库的性能要好） --> Memcached（当时最热门的技术！）
针对单机MySQL，为了解决在高并发下读的压力，在中间加入cache缓存，可以很好的解决这个问题。
数据库可以进行垂直查分 ，比如：1个写，2个存，写的内容通过主从复制，同步更新到另外两个数据库。
3、分库分表+ 水平拆分 + MySQL集群
数据库的本质（读、写）
解决了读的问题，现在解决写的问题，这些都是减轻压力的操作。
物理治疗
- MySQL的存储引擎
- 早年使用：MyISAM
- 早些年MySQL的引擎使用的是这个，它针对写的操作时，利用了表锁。
- 就是每次写都需要进行等待，所以十分影响效率！在高并发的情况下出现严重的锁问题。
- 比如：修改一下张三的密码，那么就是锁住整张表，其他的进程只能等待
- 后来转战：Innodb
-
- 它是一个行锁，顾名思义锁表的行记录，那么效率相比之前肯定有所提高
精神治疗
数据库再怎么优化都只有一个，如果一张表有1亿条数据，就会很麻烦！
所以慢慢的就开始使用分库分表来解决写的压力！MySQL那个年代推出了表分区！这个并没有被许多公司使用！
而MySQL的集群，就很满足那个年代的所有需求！
用户访问集群，先查看缓存中有没有，再去3个集群中访问，每个集群分别存着数据的一部分，最后将结果合并。
4、如今的时代
关系型数据库所存在的问题：
2010~2020年，十年之间，世界已经发生了天翻地覆的变化；现在大点的公司都可以发布自己的卫星了。
如果要实现一些定位、最新音乐、热榜等功能，这些都是大数据量的！并且数据类型不能以列和行存储。
MySQL等关系型数据库就不够用了！数据量很多，变化又很快！
MySQL会使用它来存储一些比较大的文件，比如：博客的文章，图片！那么对应的数据表就会很大，效率就低了！但是如果有一种数据库专门处理这种数据，那么MySQL压力就变得十分小！
如何处理这些问题？
大数据的IO压力下，如果表有1亿条数据，那么表结构几乎无法更改，现在让你加一个列，相当于加了1
亿条数据。
所以：数据库的结构，都是在一开始，花费大量时间商讨，解决的。
目前 一个基本的互联网的项目！
用户访问都会经过企业防火墙或者路由网关，做转发、验证。
之后利用负载均衡和服务熔断，分别保证资源的分配平均和服务宕机使用备用的情况。
微服务架构，每一个服务分别部署在不同的服务器上，并且对应有着自己独立的数据库。
虽然很好的解决了问题，但是技术成本也很大，最近bilibili的财报分析，亏损了13个亿，为什么b站这
么多用户还是亏损的？就是因为这个东西的技术成本很大。
使用的原因
用户的个人信息，社交网络，地理位置。用户自己产生的数据，用户日志等待爆发式增长！
这时候我们就需要使用NoSQL数据库，它可以很好的处理以上的情况！
什么是NoSQL
NoSQL
NoSQL = Not Only SQL（不仅仅是数据库）
关系型数据库结构：表、行、列
NoSQL泛指非关系型数据库，随着web2.0互联网的诞生！传统数据库很难对付web2.0时代！尤其是超大规模的高并发的社区！暴露出来很多难以克服的问题，NoSQL在当今大数据环境下发展的十分迅速，Redis是发展最快的，而且是我们当下必须掌握的一个技术！
很多的数据类型：用户的个人信息、社交网络、地理位置。这些数据类型的存储不需要一个固定的格式！不需要多余的操作就可以横向扩展！
非关系型数据库一般利用 Map<String, Object> 键值对控制！而这个Object就可以使任何类型的。
NoSQL特点
1、方便扩展（数据之间没有关系，很好扩展！）
2、大数据量高性能人（Redis一秒写8万次，读取11万，NoSQL的缓存记录，是一种细粒度的缓存，性
能会比较高！）
3、数据类型是多样型的！（不需要事先设计数据库！随取随用！如果是数据量十分大的表，很多就无
法设计了！）
4、传统 RDMS（关系数据库）和 NoSQL区别
传统的 RDMS
- 结构化组织（有固定的结构）
- SQL（按固定的结构去查询）
- 数据和关系都存在单独的表中，表里只有行和列
- 复杂的操作，数据定义语言（CRUD操作和与数据库的有关的语言，比如：modify）
- 严格的一致性
- 事务
-....
NoSQL
- 不仅仅是数据
- 没有固定的查询语言
- 键值对存储，列存储，文档存储，图形数据库（用于社交关系存储）
- 只保证最终一致性即可
- CAP定理和BASE (异地多活)，如果搞懂这两个定理那么可以说就是一个初级架构师！
- 高性能、高可用、高可扩
- ....
了解：3V + 3高
大数据时代的3V：主要是描述问题的（以微信和淘宝举例）
- 数据海量Volume：淘宝可能在一瞬间数据量就上亿。
- 多样Variety：微信可以发图片，有社交关系（好友），定位，都是不同类型的数据。
- 实时Velocity：数据要达到实时的，现在的4G时代，直播可能有延迟。
大数据时代的3高：主要是对程序的要求
- 高并发
- 高可扩：如果服务器不够用了，可以横向扩展再加一台没有任何影响
- 高性能
真正的公司中的实践：NoSQL + RDBMS 一起使用才是最强的。
技术没有高低之分，就看你如何去使用！（提升内功，思维的提高！）
阿里巴巴演进分析
可以看到淘宝随便一个商品的页面，包含了图片、视频、信息、评论等，肯定不会放在关系型数据库。
# 1、商品的基本信息 名称、价格、商家信息等等 关系型数据库就可以解决了！比如说MySQL/Oracle （淘宝早年就去IOE了！ - 了解王坚，推荐文章：阿里云的这群疯子） 但是淘宝使用的MySQL不是大家使用的MySQL，底层根据自己的业务改变了 # 2、商品的描述、评论（文字比较多） 使用文档型数据库，MongDB是一种，所以学完Redis还需要去学习它 # 3、图片 分布式文件系统 FastDFS - 淘宝自己的 TFS - Googel GFS - Hadoop HDFS - 阿里云的 oss # 4、商品的关键字（搜索） - 搜索引擎 solr elasticsearch - 淘宝自己的： ISerach 这里可以去了解 多隆这个人（多去了解一下这些技术大佬！） # 5、商品热门的波段信息 - 内存数据库 - Redis Tair、Memcache。。。 # 6、商品的交易，外部的支付接口 - 第三方应用
阿里也解决了这个问题，每个数据展示和功能都有对应的调用，但是也可以看到app是直接调用的底层。
但是你要知道，一个简单的网页背后的技术一定不是大家所想的那么简单！
大型互联网应用问题：
-
数据类型太多了！
-
数据源繁多，经常重构！
-
数据要改造，大面积改造？就好比你增加了列，是不是在代码中要改很多
解决问题：
如果你未来相当一个架构师： 要知道没有什么是加一层解决不了的！
所以阿里在中间加了一层UDSL，肯定去到阿里学习也只需要学习中间的API如何调用即可，然后图中的Mapping DSL可以自动去映射到对应的数据源。
缓存问题
这里以上都是NoSQL入门概述，不仅能够提高大家的知识，还可以帮助大家了解大厂的工作内容！
NoSQL的四大分类
KV键值对
-
新浪：Redis（必须掌握）
-
美团：Redis + Tair
-
阿里、百度： Redis + Memcache
文档型数据库（和bson格式 、json格式一样）
-
MongDB（必须掌握）
-
MongDB是一个基于分布式文件存储的数据库，C++编写，主要用来处理大量的文档！
-
MongoDB是一个介于关系型数据库和非关系型数据库中间的产品！MongDB是非关系型数据库中功能最丰富的，最像关系型数据库的！
-
-
ConthDB
列存储数据库
-
HBase
-
分布式文件系统
图关系数据库
-
-
Neo4j，InfoGrid
