引言
- 随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了 解 决 大 规 模 数 据 集 合 多 重 数 据 种 类 \color{HotPink}{解决大规模数据集合多重数据种类} 解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题,包括超 大 规 模 数 据 的 存 储 \color{HotPink}{大规模数据的存储} 大规模数据的存储。(例如谷歌或Facebook每天为他们的用户收集万亿比特的数据)。这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展。
- 如今天我们可以通过第三方平台(如:Google,Facebook等)可以很容易的访问和抓取数据。用户的个人信息,社交网络,地理位置,用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘,那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据。
是什么?
- NoSQL(NoSQL = Not Only SQL ),意即"不仅仅是SQL"。泛指 非 关 系 型 的 数 据 库 \color{HotPink}{非关系型的数据库} 非关系型的数据库。是对不同于传统的关系型数据库的数据库管理系统的统称。
RDBMS vs NoSQL
RDBMS(关系型) | NoSQL(非关系型) |
---|---|
高度组织化结构化数据 | 代表着不仅仅是SQL |
结构化查询语言(SQL) | 没有声明性查询语言 |
数据和关系都存储在单独的表中 | 没有预定义的模式 |
数据操纵语言,数据定义语言 | 键 - 值对存储,列存储,文档存储,图形数据库 |
严格的一致性 | 最终一致性,而非ACID属性 |
基础事务 | 非结构化和不可预知的数据 |
CAP定理 | |
高性能,高可用性和可伸缩性 |
CAP定理(CAP theorem)
- CAP定理(CAP theorem), 又被称作布鲁尔定理(Brewer’s theorem), 它指出对于一个分布式计算系统来说,不可能同时满足以下三点:
- 一致性(Consistency) (所有节点在同一时间具有相同的数据)
- 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
- 分区容错性(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
- CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的 满 足 两 个 \color{HotPink}{满足两个} 满足两个。
- 因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类:
- CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
- CP - 满足一致性,分区容忍性的系统,通常性能不是特别高。
- AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。
ACID vs BASE
- 关系型数据库ACID规则
- A(Atomicity) 原子性:在事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚。
- C (Consistency) 一致性:数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。
- I (Isolation) 独立性:并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。
- D (Durability) 持久性:事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失。
- 非关系型数据库BASE思想
- BASE:Basically Available, Soft-state, Eventually Consistent,是NoSQL数据库通常对可用性及一致性的弱要求原则:
- Basically Availble –基本可用
- Soft-state –软状态/柔性事务。 “Soft state” 可以理解为"无连接"的, 而 “Hard state” 是"面向连接"的
- Eventual Consistency – 最终一致性, 也是是 ACID 的最终目的。
- BASE:Basically Available, Soft-state, Eventually Consistent,是NoSQL数据库通常对可用性及一致性的弱要求原则:
ACID | BASE |
---|---|
原子性(Atomicity) | 基本可用(Basically Available) |
一致性(Consistency) | 软状态/柔性事务(Soft state) |
隔离性(Isolation) | 最终一致性 (Eventual consistency) |
持久性 (Durable) |
NoSQL数据库分类
类型 | 部分代表 | 特点 |
---|---|---|
列存储 | Hbase、Cassandra、Hypertable | 顾名思义,是按列存储数据的。最大的特点是方便存储结构化和半结构化数据,方便做数据压缩,对针对某一列或者某几列的查询有非常大的IO优势。 |
文档存储 | MongoDB、CouchDB | 文档存储一般用类似json的格式存储,存储的内容是文档型的。这样也就有有机会对某些字段建立索引,实现关系数据库的某些功能。 |
key-value存储 | Tokyo Cabinet / Tyrant、Berkeley DB、MemcacheDB、Redis | 可以通过key快速查询到其value。一般来说,存储不管value的格式,照单全收。(Redis包含了其他功能) |
图存储 | Neo4J、FlockDB | 图形关系的最佳存储(社交网络图、广告推荐系统)。使用传统关系数据库来解决的话性能低下,而且设计使用不方便。 |
对象存储 | db4o、Versant | 通过类似面向对象语言的语法操作数据库,通过对象的方式存取数据。 |
xml数据库 | Berkeley DB XML、BaseX | 高效的存储XML数据,并支持XML的内部查询语法,比如XQuery,Xpath。 |
附
大致演变历程
- 1. 单机MySQL时代
- 在90年代,一个网站的访问量一般都不大,用单个数据库完全可以轻松应付。
在那个时候,更多的都是静态网页,动态交互类型的网站不多。
- 在90年代,一个网站的访问量一般都不大,用单个数据库完全可以轻松应付。
-
上述架构下数据存储的瓶颈是什么?
- 1.一个机器能存储数据量的总大小有限
- 2.数据库的索引与数据在同一个数据库,随着索引增加,效率反而降低
- 3.读写混合(在同一数据库实例),并发有限
-
2. Memcached(缓存)+MySQL+垂直拆分
- 随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题,web程序不再仅仅专注在功能上,同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。开始比较流行的是通过
文
件
缓
存
\color{HotPink}{文件缓存}
文件缓存来缓解数据库压力,但是当访问量继续增大的时候,多台web机器通过文件缓存不能共享,大量的小文件缓存也带了了比较高的IO压力。在这个时候,
M
e
m
c
a
c
h
e
d
\color{HotPink}{Memcached}
Memcached就自然的成为一个非常时尚的技术产品。
Memcached+MySQL+垂直拆分 网站架构 - M e m c a c h e d \color{HotPink}{Memcached} Memcached 作为一个独立的分布式的 缓 存 服 务 器 \color{HotPink}{缓存服务器} 缓存服务器,为多个web服务器提供了一个共享的、高性能缓存服务,在Memcached服务器上,又发展了根据hash算法来进行多台Memcached缓存服务的扩展,然后又出现了 一 致 性 h a s h \color{HotPink}{一致性hash} 一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。
- 随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题,web程序不再仅仅专注在功能上,同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。开始比较流行的是通过
文
件
缓
存
\color{HotPink}{文件缓存}
文件缓存来缓解数据库压力,但是当访问量继续增大的时候,多台web机器通过文件缓存不能共享,大量的小文件缓存也带了了比较高的IO压力。在这个时候,
M
e
m
c
a
c
h
e
d
\color{HotPink}{Memcached}
Memcached就自然的成为一个非常时尚的技术产品。
-
3. MySQL主从读写分离
- 由于数据库的写入压力增加,Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负,大部分网站开始使用
主
从
复
制
技
术
\color{HotPink}{主从复制技术}
主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
MySQL主从读写分离 网站架构 - 由于数据库的写入压力增加,Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负,大部分网站开始使用
主
从
复
制
技
术
\color{HotPink}{主从复制技术}
主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
-
4. 分表分库+水平拆分+MySQL集群
- 在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,这时MySQL主库的写压力开始出现瓶颈,而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB(行锁)引擎代替MyISAM。
- 同时,开始流行使用
分
表
分
库
\color{HotPink}{分表分库}
分表分库来缓解写压力和数据增长的扩展问题。这个时候,分表分库成了一个热门技术,也就在这个时候,MySQL推出了还不太稳定的表分区。虽然MySQL推出了
M
y
S
Q
L
\color{HotPink}{MySQL}
MySQL
C
l
u
s
t
e
r
集
群
\color{HotPink}{Cluster集群}
Cluster集群,但性能也不能很好满足互联网的要求,只是在高可靠性上提供了非常大的保证。
分表分库+水平拆分+MySQL集群 网站架构 -
5. MySQL的扩展性瓶颈
- MySQL数据库也经常存储一些大文本字段,导致数据库表非常的大,在做数据库恢复的时候就导致非常的慢,不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小,如果能把这些数据从MySQL省去,MySQL将变得非常的小。关系数据库很强大,但是它并不能很好的应付所有的应用场景。MySQL的扩展性差(需要复杂的技术来实现),大数据下IO压力大,表结构更改困难,正是当前使用MySQL的开发人员面临的问题。
-
6. 今天是什么样子
致谢:
- 尚硅谷-周阳老师的视频教程
- NoSQL 简介 | 菜鸟教程