1、是什么
NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,
泛指非关系型的数据库
。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题,包括超大规模数据的存储。
(例如谷歌或Facebook每天为他们的用户收集万亿比特的数据)。
这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展。
2、能干嘛
2.1 易扩展
NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性
。
数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。
2.2 大数据量高性能
NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。
这得益于它的无关系性,数据库的结构简单。
一般MySQL使用Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的Cache是记录级的,是一种细粒度的Cache
,所以NoSQL在这个层面上来说就要性能高很多了。
2.3 多样灵活的数据模型
NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式
。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。
2.4 传统RDBMS VS NOSQL
RDBMS
- 高度组织化结构化数据
- 结构化查询语言(SQL)
- 数据和关系都存储在单独的表中。
- 数据操纵语言,数据定义语言
- 严格的一致性
- 基础事务
NoSQL
- 代表着不仅仅是SQL
- 没有声明性查询语言
- 没有预定义的模式
-键 – 值对存储,列存储,文档存储,图形数据库 - 最终一致性,而非ACID属性
- 非结构化和不可预知的数据
- CAP定理
- 高性能,高可用性和可伸缩性
3、3V+3高
大数据时代的3V
- 海量Volume
- 多样Variety
- 实时Velocity
互联网需求的3高
- 高并发
- 高可扩
- 高性能
4、NoSQL数据模型简介
4.1 以一个电商客户、订单、订购 、地址模型来对比下关系型 数据库和非关系型数据库
传统的关系型数据库你如何设计?
ER图(1:1/1:N/N:N,主外键等常见)
image.png
Nosql你如何设计
- 什么是
BSON
BSON
是一种类json的一种二进制形式的存储格式,简称Binary JSON,
它和JSON一样,支持内嵌的文档对象和数组对象。
用BSon画出构建的数据模型
{
"customer":{
"id":1136,
"name":"Z3",
"billingAddress":[{"city":"beijing"}],
"orders":[
{
"id":17,
"customerId":1136,
"orderItems":[{"productId":27,"price":77.5,"productName":"thinking in java"}],
"shippingAddress":[{"city":"beijing"}]
"orderPayment":[{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],
}
]
}
两者对比,问题和难点
- 为什么上述的情况可以用聚合模型来处理
高并发的操作是不太建议有关联查询的, 互联网公司用冗余数据来避免关联查询;
分布式事务是支持不了太多的并发的。
5、NoSQL数据库的四大分类
5.1 KV键值:典型介绍
- 新浪:BerkeleyDB+redis
- 美团:redis+tair
- 阿里、百度:memcache+redis
5.2 文档型数据库(bson格式比较多):典型介绍
- CouchDB
- MongoDB
MongoDB 是一个基于分布式文件存储的数据库
。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。
MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。
5.3 列存储数据库
- Cassandra, HBase
- 分布式文件系统
5.4 图关系数据库
- 它不是放图形的,放的是关系比如:朋友圈社交网络、广告推荐系统
- 社交网络,推荐系统等。专注于构建关系图谱
- Neo4J, InfoGrid
5.5 四者对比
image.png
6、在分布式数据库中CAP原理 CAP+BASE
6.1 传统的ACID分别是什么
关系型数据库遵循ACID规则
事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性:
1、A (Atomicity) 原子性
原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚。比如银行转账,从A账户转100元至B账户,分为两个步骤:1)从A账户取100元;2)存入100元至B账户。这两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了100元。
2、C (Consistency) 一致性
一致性也比较容易理解,也就是说数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。
3、I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户,在这个交易还未完成的情况下,如果此时B查询自己的账户,是看不到新增加的100元的
4、D (Durability) 持久性
持久性是指一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失。
6.2 CAP
- C:Consistency(强一致性)
- A:Availability(可用性)
- P:Partition tolerance(分区容错性)
6.3 CAP的3进2
CAP理论就是说在分布式存储系统中,最多只能实现上面的两点
。
而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性
是我们必须需要实现的。
所以我们只能在一致性
和可用性
之间进行权衡,没有NoSQL系统能同时保证这三点
。
- CA 传统Oracle数据库
- AP 大多数网站架构的选择
- CP Redis、Mongodb
注意:
分布式架构的时候必须做出取舍。大多数web应用,其实并不需要强一致性。因此牺牲C换取P,这是目前分布式数据库产品的方向
一致性与可用性的决择
对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地。
- 数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低, 有些场合对写一致性要求并不高。允许实现最终一致性
。 - 数据库的写实时性和读实时性需求
对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说发一条消息之 后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。 - 对复杂的SQL查询,特别是多表关联查询的需求
任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的报表查询,特别是SNS类型的网站,从需求以及产品设计角 度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。
6.4 经典CAP图
CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,
最多只能同时较好的满足两个。
因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类:
- CA – 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
- CP – 满足一致性,分区容忍必的系统,通常性能不是特别高。
AP – 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。
image.png
6.5 BASE
BASE
就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
BASE其实是下面三个术语的缩写:
- 基本可用(Basically Available)
- 软状态(Soft state)
- 最终一致(Eventually consistent)
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢,缘由就在于大型系统往往由于地域分布和极高性能的要求,不可能采用分布式事务来完成这些指标,要想获得这些指标,我们必须采用另外一种方式来完成,这里BASE就是解决这个问题的办法。
6.6 分布式+集群简介
简单来讲:
分布式:不同的多台服务器上面部署不同的服务模块(工程),他们之间通过Rpc/Rmi之间通信和调用,对外提供服务和组内协作。
集群:不同的多台服务器上面部署相同的服务模块,通过分布式调度软件进行统一的调度,对外提供服务和访问。