NoSQL概述

引言

• 随着互联网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

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 的最终目的。

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年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。
    在那个时候，更多的都是静态网页，动态交互类型的网站不多。
    

单机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 简介 | 菜鸟教程