桥山之巅,姬水之畔

NoSQL概述

2019.06.30

引言

  • 随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题,包括超大规模数据的存储。(例如谷歌或Facebook每天为他们的用户收集万亿比特的数据)。这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展。
  • 如今天我们可以通过第三方平台(如:Google,Facebook等)可以很容易的访问和抓取数据。用户的个人信息,社交网络,地理位置,用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘,那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据。

是什么?

  • NoSQL(NoSQL = Not Only SQL ),意即"不仅仅是SQL"。泛指非关系型的数据库。是对不同于传统的关系型数据库的数据库管理系统的统称。

RDBMS vs NoSQL

RDBMS(关系型)NoSQL(非关系型)
高度组织化结构化数据代表着不仅仅是SQL
结构化查询语言(SQL)没有声明性查询语言
数据和关系都存储在单独的表中没有预定义的模式
数据操纵语言,数据定义语言键 - 值对存储,列存储,文档存储,图形数据库
严格的一致性最终一致性,而非ACID属性
基础事务非结构化和不可预知的数据
 CAP定理
 高性能,高可用性和可伸缩性

CAP定理(CAP theorem)

  • CAP定理(CAP theorem), 又被称作布鲁尔定理(Brewer's theorem), 它指出对于一个分布式计算系统来说,不可能同时满足以下三点:
  • 一致性(Consistency) (所有节点在同一时间具有相同的数据)
  • 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
  • 分区容错性(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
  • CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的满足两个
  • 因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类:
  • CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
  • CP - 满足一致性,分区容忍性的系统,通常性能不是特别高。
  • AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。
    CAP theorem
CAP theorem

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 的最终目的。
ACIDBASE
原子性(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年代,一个网站的访问量一般都不大,用单个数据库完全可以轻松应付。
    在那个时候,更多的都是静态网页,动态交互类型的网站不多。
单机MySQL 网站架构
  • 上述架构下数据存储的瓶颈是什么?
  • 1.一个机器能存储数据量的总大小有限
  • 2.数据库的索引与数据在同一个数据库,随着索引增加,效率反而降低
  • 3.读写混合(在同一数据库实例),并发有限

2. Memcached(缓存)+MySQL+垂直拆分

  • 随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题,web程序不再仅仅专注在功能上,同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力,但是当访问量继续增大的时候,多台web机器通过文件缓存不能共享,大量的小文件缓存也带了了比较高的IO压力。在这个时候,Memcached就自然的成为一个非常时尚的技术产品。
Memcached+MySQL+垂直拆分 网站架构
  • Memcached 作为一个独立的分布式的缓存服务器,为多个web服务器提供了一个共享的、高性能缓存服务,在Memcached服务器上,又发展了根据hash算法来进行多台Memcached缓存服务的扩展,然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。

3. MySQL主从读写分离

  • 由于数据库的写入压力增加,Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负,大部分网站开始使用主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
MySQL主从读写分离 网站架构

4. 分表分库+水平拆分+MySQL集群

  • 在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,这时MySQL主库的写压力开始出现瓶颈,而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB(行锁)引擎代替MyISAM。
  • 同时,开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候,分表分库成了一个热门技术,也就在这个时候,MySQL推出了还不太稳定的表分区。虽然MySQL推出了MySQL Cluster集群,但性能也不能很好满足互联网的要求,只是在高可靠性上提供了非常大的保证。
分表分库+水平拆分+MySQL集群 网站架构

5. MySQL的扩展性瓶颈

  • MySQL数据库也经常存储一些大文本字段,导致数据库表非常的大,在做数据库恢复的时候就导致非常的慢,不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小,如果能把这些数据从MySQL省去,MySQL将变得非常的小。关系数据库很强大,但是它并不能很好的应付所有的应用场景。MySQL的扩展性差(需要复杂的技术来实现),大数据下IO压力大,表结构更改困难,正是当前使用MySQL的开发人员面临的问题。

6. 今天是什么样子

致谢:

  1. 尚硅谷-周阳老师的视频教程
  2. NoSQL 简介 | 菜鸟教程