目录
（1）以一个电商客户、订单、订购、地址模型来对比下关系型数据库和非关系型数据库
1.互联网大背景下，为什么要使用NoSQL?
（1）单机三层架构
在90年代，一个网站的访问量一般不大，用单个数据库完全可以轻松应付
在那个时候，更多的都是静态网页，动态交互类型的网站不多
上述三层架构有如下，数据存储的瓶颈：
- 1.数据量的总大小在一个机器放不下时
- 2.数据的索引在一个机器的内存放不下时
- 3.访问量（读写混合）一个实例不能承受时
（2）Memcathed（缓存）+MySQL+垂直拆分
后来，随之访问量的上升，几乎大部分使用MySQL架构的网站在数据库上出现了性能问题
web程序不再仅仅专注于功能上，同时也在追求性能
于是开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引
开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带来了比较高的IO压力，在这个时候，Memcathed就自然的成为一个非常时尚的技术产品
（3）MySQL主从读写分离
由于数据库的写入压力增大，Memcathed只能缓解数据库的读取压力，读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术（Master-Slave模式）来达到读写分离，以提高读写性能和读库的可扩展性，
（4）分表分库+水平拆分+MySQL集群
在Memcathed的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎替代MyISAM
同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题，这个时候，分表分库成为一个热门技术，
分库：比如把一些用户的注册信息等一些不会经常变动，跟业务不相关的冷数据放在一些库，频繁的，紧密的，跟业务相关的放在另一些库
分表：比如一个表的压力过大，可以把它拆分到几个集群中
虽然MySQL推出了MySQL Cluster集群，但性能也不能很好的满足互联网的要求，只能在高可靠性上提供非常大的保证
（5）MySQL扩展性能瓶颈
MySQL也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库，比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小
关系型数据库很强大，但它并不能很好的应付所有的场景，MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL开发人员面临的问题
（6）为什么使用NoSQL?
今天我们可以通过第三方平台（如：Goole、FaceBook等）可以很容易地访问和抓取数据，用户地个人信息，社交网络，地理位置，用户生成的数据和用户操作的日志已经成倍地增长，我们如果要对用户数据进行挖掘，SQL数据库已经不再适合这些应用，NoSQL数据库的发展却能很好的处理这些大的数据
思考：为什么NoSQL能处理这些大的数据？是基于怎样的原理？
待学习到后面来回答
2.NoSQL是什么？
NoSQL(=Not Only SQL)，泛指非关系型数据库，
随着互联网web2.0的兴起，传统的关系型数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，有很多问题，NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储
这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展
3.NoSQL能干嘛？
（1）易扩展
NoSQL数据库的共同特点：去掉关系型数据库的关系特性
数据之间无关系，就非常容易扩展，也无形在架构的层面上带来了可扩展的能力
（2）大数据量高性能
NoSQL数据库具有非常高的读写性能，尤其在大数据量下，同样变现优秀，这得益于它的无关系性，数据库的结构简单
一般MySQL使用Query Cathe，每次表的更新，Cathe就失败，是一种大粒度的Cathe
在针对web2.0的交互频繁的应用，Cathe性能不高，而NoSQL的jCathe是记录级的，是一种细粒度的jCathe，所以NoSQL在这个层面上，性能就要高很多了，如Redis一秒钟写可以到8万次，读可以到11万次
（3）多样灵活的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式
而在关系数据库中，增删字段是一件非常麻烦的事情，如果是非常大的数据量的表，增加字段简直是一个噩梦
（4）RDBMS vs NoSQL
RDBMS：
- 高度组织化结构化数据
- 结构化查询语言（SQL）
- 数据和关系都存储在单独的表中
- 严格的一致性
- 基础事务
NoSQL：
- 代表着不仅仅是SQL
-
没有声明性查询语言
-
没有预定义的模式
-
键值对存储、列存储、文档存储、图形数据库
-
最终一致性，而非ACID属性
-
非结构化和不可预知的数据
-
CAP定理
-
高性能、高可用和可伸缩
4.当下时代的3V和3高
（1）3V
- 海量Volume
- 多样Variety
- 实时Velocity
（2）3高
- 高并发
- 高可扩（横向的扩展，加一样的机器，构成大集群）
- 高性能
5.当下NoSQL的经典应用
当下的应用是SQL和NoSQL一起使用
淘宝架构的演变过程：
和这里相关的，多数据源多数据类型（有图片，VCR，声音，文字等等数据类型）的存储问题
以女装/女包为例解释上述的多数据源和多数据类型的存储：
- 1.商品的基本信息：名称、价格、出厂日期、生产厂商等
- 存在于关系型数据库mysql/oracle中（淘宝内部的MySQL是自己改造过的）
- 2.商品描述、详情、评价信息（多文字类）
- 多文字类信息描述类，IO读写性能变差
- 存于文档数据库MongoDB中
- 3.商品的图片
- 分布式的文件系统当中，淘宝自己的TFS、Goole的GFS、Hadoop的HDFS
- 4.商品的关键字
- 搜索引擎，ISearch
- 5.商品的波段性热点高频信息
- 内存数据库，Redis、Memcached、Tair
- 6.商品的交易、价格计算、积分累计
- 外部系统，外部第三方接口
- 支付宝
总结：大型互联网应用（大数据、高并发、多样数据类型）的难点和解决方案
难点：
- 数据类型的多样性
- 数据源的多样性和变化重构
- 数据源改造而数据服务平台不需要大面积重构
解决办法：
统一数据平台服务层
如：阿里的UDSL
- 1.映射
- 2.API
- 大大降低了开发人员的开发难度
- 3.热点缓存
6.NoSQL数据模型简介
（1）以一个电商客户、订单、订购、地址模型来对比下关系型数据库和非关系型数据库
1）传统关系数据库如何设计？
如果这套系统已经上线了，再要增加其他模块，字段，更改非常复杂，即可扩展性特别差
2）NoSQL如何设计？
BSON：是一种类json的一种二进制形式的存储格式，简称Binary JSON，它和JSON一样，支持内嵌的文档对象和数组对象
上述示例按照BSON的格式设计如下：
3）两者对比
为什么上述的情况可以用聚合模型来处理？
- 高并发的操作是不太建议有关联查询的，互联网公司用冗余数据来避免关联查询
- 分布式事务是支持不了太多的并发的
当我们使用上述的BSON格式时，根据KV键值对，查出来的是一个串，而不需要按照像关系型数据库那样太多的join
（2）聚合模型
-
1）KV键值对
-
2）Bson
- 3）列簇
- 4）图形
7.NoSQL数据库的四大分类
（1）KV键值对
- Redis
- 新浪：BerkeleyDB+Redis
- 美团：Redis+Tair
- 阿里、百度：Memcathed+Redis
- Memcached
（2）文档型数据库（bson格式比较多）：
-
CouchDB
-
MongoDB
MongoDB是一个基于分布式文件存储的数据库，由C++语言编写，旨在为WEB引用提供可扩展的高性能数据存储解决方案。
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的
（3）列存储数据库：
- Cassandra
- HBase
- 分布式文件系统
（4）图数据库
它不是放图形的，放的是关系比如：朋友圈社交网络、广告推荐系统等，专注于构建关系图谱
- NeoJ4
- InfoGrid
（5）四者对比
9.在分布式数据库中CAP原理和BASE
（1）RDBMS的特点
（2）NoSQL的特点
- C：（Consistence）强一致性
- A：（Availability）可用性
- P：（Partition tolerance）分区容错性
（3）CAP特性3选2
CAP理论就是说在分布式存储系统中，最多只能实现C、A、P两点
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以，分区容忍性是我们必须实现的
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
- CA：传统Oracle数据库
- AP：大多数网站架构的选择（大多数金融、电商系统都采用的是AP）
- 比如双十一，淘宝上有一个女性包包，大家都去看都去买，在包包页面有用户浏览总数、点赞数，
- 第一种需求：强一致性，这个页面的浏览总数、点赞数绝对不能错，页面必须精确的显示
- 第二种需求：高可用性，系统在那一天保证完全可以使用，不崩溃
- 在这样高并发的场景下，用户不是很关心浏览总数，点赞数，但我们那天必须保证系统可用，所以肯定选择AP
- CP：Redis、Mongodb
注意：分布式架构的时候你必须做出取舍
读己之所写，发一条微博过后，自己马上可以看到，但其他人慢慢地在几秒至十几秒后才看到，这样一致性有点弱
（4）BASE
10.分布式和集群
- 分布式：不同的多台服务器上部署不同的服务模块，它们之间通过RPC/RMI之间通信或调用，对外提供服务和组内协作
- 集群：不同的多台服务器上部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问，“人多力量大”