什么是NoSQL

本文最后更新于:2 年前

v2-eff18c2750f437e04d0324b09dac48ea_b

NoSQL是Not Only SQL,即不仅仅是SQL。

NoSQL

关系型数据库的瓶颈与发展

单机MySQL的美好年代

静态页面时代

  • 90年代,网站的访问量小,用单个数据库完全足够;
  • 多是静态网页,动态交互类型的网站少。

数据存储的瓶颈

  1. 数据量的总大小,一个机器放不下时;
  2. 数据的索引(B+ Tree)一个机器的内存放不下时;
  3. 访问量(读写混合)一个实例不能承受;

单机MySQL

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

随着访问量的上升,使用单机MySQL架构网站的数据库出现了性能问题,程序猿们开始使用缓存技术来缓解数据库的压力,优化数据库的结构和索引,主要是通过文件缓存来缓解数据库压力,当访问量继续增大的时候,Memcached(缓存)技术产品就出现了。

缓存

MySQL主从读写分离

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

MySQL主从读写分离

分表分库 + 水平拆分 + Mysql 集群

在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,这时MySQL主库的写压力开始出现瓶颈,而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB引擎

同时,开始流行使用分表分库来缓解写压力和数据增长的扩展问题。当时,MySQL推出了表分区(MySQL Cluster集群),但性能也不能很好满足互联网的需求,只是很好的保证了高可靠性。

分表分库 + 水平拆分 + Mysql 集群

MySQL 的扩展性瓶颈

MySQL数据库 存储的大文本的字段,导致数据库表非常的大,使得在数据库恢复的时候非常的慢。关系数据库很强大,但是MySQL的扩展性差(需要复杂的技术来实现),大数据下IO压力大,表结构更改困难。

如今的数据库

如今的数据库

为什么用NoSQL

NoSQL最常见的解释是“non-relational”, “Not Only SQL”也被很多人接受。NoSQL仅仅是一个概念,泛指非关系型的数据库,区别于关系数据库,它们不保证关系数据的ACID特性。

NoSQL的特点

易扩展

NoSQL 数据库去掉关系数据库的关系型特性

数据之间无关系,这样就非常容易扩展,在架构的层面上也带来了可扩展的能力。

大数据量高性能

NoSQL数据库都具有非常高的读写性能,在大数据量下,同样==具有非常高的读写性能==。

一般MySQL使用Query Cache大粒度),每次表更新Cache失效,在针对Web2.0的交互频繁应用,Cache性能不高

而NoSQL的Cache是记录级(细粒度)的,所以NoSQL在这个层面上来说就要性能高很多了。

官方记录:Redis 一秒可以写8万次,读11万次!

多样灵活的数据模型

无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式,而在关系数据库里,增删
字段一件非常麻烦。

传统的RDBMS 和 NoSQL对比

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

大数据时代的3V(主要是对问题的描述) :

海量 Volume

多样 Variety

实时 Velocity

互联网需求的3高( 主要是对程序的要求) :

高并发

高可用

高性能

==当下的应用是 SQL 和 NoSQL 一起使用==

NoSQL四大分类

KV键值:

新浪:BerkeleyDB+redis

美团:tair+redis

阿里、百度:memcache+redis

文档型数据库(bson格式比较多):

  • CouchDB
  • MongoDB

MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可
扩展的高性能数据存储解决方案。

MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中==功能最丰
富,最像关系数据库的==。

列存储数据库:

  • Cassandra, HBase
  • 分布式文件系统

图关系数据库

  • 不存放放图形的,存放关系(比如:朋友圈社交网络、广告推荐系统)
  • 社交网络,推荐系统等。专注于构建关系图谱
  • Neo4J, InfoGrid

4类NoSQL的对比

NoSQL遵循CAP + BASE原则

关系型数据库遵循ACID规则,事务在英文中是transaction。

传统ACID

  • A (Atomicity) 原子性(事务里的所有操作要么全部做完,要么都不做。事务里只要有一个操作失败,整个事务就失败,事务回滚)
  • C (Consistency) 一致性(事务前后数据的完整性必须保持一致)
  • I (Isolation) 隔离性(并发的事务之间不会互相影响)
  • D (Durability) 持久性(持久性是指一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失)

CAP(三进二)

  • C : Consistency(强一致性)
  • A : Availability(可用性)
  • P : Partition tolerance(分区容错性)

==在分布式存储系统中,最多只能实现上面的两点,没有NoSQL系统能同时保证这三点。==

分区容错性是我们必须需要实现(由于当前的网络硬件肯定会出现延迟丢包等问题)。

一致性和可用性之间取一个平衡。多余大多数web应用,其实并不需要强一致性。

CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,
最多只能同时较好的满足两个。因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP
原则和满足 AP 原则三 大类:

CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。

CP - 满足一致性,分区容忍必的系统,通常性能不是特别高。

AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。

BASE 理论

BASE是对CAP中一致性和可用性权衡的结果,是基于CAP定律逐步演化而来。

核心思想是即使无法做到强一致性,但每个应用根据自身业务特点,采用适当的方式来使系统达到最终一致性

为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

  • 基本可用(Basically Available): 基本可用是指==分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用==。电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。
  • 软状态(Soft State): 软状态是指==允许系统存在中间状态,而该中间状态不会影响系统整体可用性==。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。
  • 最终一致性(Eventual Consistency): 最终一致性是指==系统中的所有数据副本经过一定时间后,最终达到一致的状态==。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

分布式和集群的不同

1、分布式:通过Rpc通信和调用,使不同的多台服务器上面部署不同的服务模块(工程),可以对外
提供服务和组内协作。

2、集群:通过通过分布式调度软件进行统一的调度,使不同的多台服务器上面部署相同的服务模块,可以对外提供
服务和访问。


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!