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