第5章 NoSQL数据库
NoSQL概述
NoSQL是对非关系数据库的统称,它所采用的是类似键值、列族、文档等非关系模型。NoSQL数据库没有固定的表结构,通常也不存在连接操作,也没有严格遵守ACID约束。因此与关系数据库相比,NoSQL具有灵活的水平可扩展性,可以支持海量数据存储。
NoSQL数据库具有以下3个特点:
- 灵活的可扩展性
传统的关系数据库由于自身设计的局限性,通常很难实现“横向扩展”。当数据库负载大规模增加时,往往需要升级硬件来实现“纵向扩展”。由于硬件制造工艺的限制,性能提升的速度已经赶不上数据库系统负载的增加速度,且高性能配置价格不菲,因此,纵向扩展越来越不现实。相反“横向扩展”仅需非常普通且廉价的标准化刀片服务器,具有较高的性价比,提供了理论上近乎无限的扩展空间。NoSQL天生具有“横向扩展”能力。
- 灵活的数据模型
关系数据库模型是关系数据库的基石,它以完备的关系代数理论为基础,具有规范的定义,遵守各种严格的约束条件,无法满足各种新兴的业务需求。NoSQL采用键值、列族等非关系数据模型,允许在一个数据元素里存储不同类型的数据。
- 与云计算紧密融合
NoSQL数据库可凭借自身良好的横向扩展能力,充分利用云计算基础设施,很好地将数据库融入云计算环境中,构建基于NoSQL的云数据库服务。
NoSQL兴起的原因
- 关系数据库无法满足Web2.0的需求
- 无法满足海量数据的管理需求
- 无法满足数据高并发的需求
- 无法满足高扩展性和高可用性需求
- 关系数据库的主键特性在Web2.0时代成为“鸡肋”
- Web2.0网站系统通常不要求严格的数据库事务
- Web2.0并不要求严格的读写实时性
- Web2.0通常不包含大量复杂的SQL查询
NoSQL与关系数据库的比较
对比指标 |
NoSQL |
关系数据库 |
备注 |
数据库原理 |
部分支持 |
完全支持 |
关系数据库有关系代数理论作为基础 NoSQL没有统一的理论基础 |
数据规模 |
超大 |
大 |
关系数据库很难实现横向扩展,纵向扩展的空间也很有限,性能会随着数据规模的增大而降低 NoSQL可以很容易的通过添加更多设备来支持更大规模的数据 |
数据库模式 |
灵活 |
固定 |
关系数据库需要定义数据库模式,严格遵守数据定义和相关约束条件 NoSQL不存在数据库模式,可以自由、灵活地定义并存储各种不同类型的数据 |
查询效率 |
可以实现高效的简单查询,但是不具备高度结构化查询等特性,复杂查询的性能不尽如人意 |
快 |
关系数据库借助于索引机制可以实现快速查询(包括记录查询和范围查询) 很多NoSQL数据库没有面向复杂查询的索引,虽然NoSQL可以使用MapReduce来加速查询,但是复杂查询方面的性能仍然不如关系数据库 |
一致性 |
弱一致性 |
强一致性 |
关系数据库严格遵守事务ACID模型,可以保证事务强一致性。 很多NoSQL数据库放松了对事务ACID四性的要求,而是遵守BASE模型,只保证最终一致性 |
数据完整性 |
很难实现 |
容易实现 |
任何一个关系数据库都可以很容易实现数据完整性,如通过主键或者非空约束来实现实体完整性,通过主键、外键来实现参照完整性,通过约束或者触发器来实现用户自定义完整性,但是在NoSQL数据库无法实现 |
扩展性 |
好 |
一般 |
关系数据库很难实现横向扩展,纵向扩展的空间也很有限 NoSQL在设计之初就充分考虑了横向扩展的需求,可以很容易通过添加廉价设备来实现扩展 |
可用性 |
很好 |
好 |
关系数据库在任何时候都以保证数据一致性为优先目标,其次才是优化系统性能。随着数据规模的增大,关系数据库为了保证严格的一致性,只能提供相对较弱的可用性。 大多数NoSQL都能提供较高的可用性 |
标准化 |
否 |
是 |
关系数据库已经标准化(SQL) NoSQL还没有行业标准,不同的NoSQL数据库有不同的查询语言,很难规范应用程序接口 |
技术支持 |
低 |
高 |
关系数据库经过几十年的发展,已经的非常成熟,Oracle等大型厂商都可以提供很好的技术支持 NoSQL在技术支持方面仍然处于起步阶段,还不成熟,缺乏有力的技术支持 |
可维护性 |
复杂 |
复杂 |
关系数据库需要专门的数据库管理员(DataBase Administrator,DBA)维护 NoSQL数据库虽然没有关系数据库复杂,但难以维护 |
NoSQL的四大类型
NoSQL数据库数量众多,但是归结起来,典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图数据库。
项目 |
键值数据库 |
列族数据库 |
文档数据库 |
图数据库 |
相关产品 |
Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached |
BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PUNTS |
CouchDB、MongoDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Persevere、Jackrabbit |
Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB |
数据模型 |
键值对 |
列族 |
版本化的文档 |
图结构 |
典型应用 |
内容缓存,如会话、配置文件、参数、购物车等 |
分布式数据存储与管理 |
存储、索引并管理面向文档的数据或者类似半结构化数据 |
应用于大量复杂、互连接、低结构化的图结构场合,如社交网络、推荐系统等 |
优点 |
扩展性好、灵活性好、大量写操作时性能高 |
查找速度快、可扩展性强、容易进行分布式扩展、复杂性底 |
性能好、灵活性高、复杂性底、数据结构灵活 |
灵活性高、支持复杂的图算法、可用于构建复杂的关系图谱 |
缺点 |
无法存储结构化信息、条件查询效率较低 |
功能较少,大都不支持强事务一致性 |
缺乏统一的查询语法 |
复杂性高、只能支持一定的数据规模 |
使用者 |
百度云数据库(Redis)、GitHub(Riak)、BestBuy(Riak)、StackOverFlow(Redis)、Instagram(Redis) |
Ebay(Cassandra)、Instagram(Cassandra) |
百度云数据库(MongoDB)、SAP(MongoDB)、Codecademy(MongoDB)、Foursquare(MongoDB) |
Adobe(Neo4J)、Cisco(Neo4J) |
键值数据库
键值数据库(Key-Value Database)会使用一个哈希表,包含Key和Value:
- Key
Key用来定位Value,即存储和检索具体的Value。
- Value
一个指针指向的特定值
Value对数据库而言是透明不可见的,不能对Value进行索引和查询,只能通过Key进行查询。
Value可以用来存储任意类型的数据。
键值数据库分类:
- 内存键值数据库
内存键值数据库把数据保存在内存中,如Memcached和Redis;
- 持久化(Persistent)键值数据库
持久化键值数据库把数据保存在磁盘,如BerkeleyDB、Voldmort和Riak。
键值数据库的缺点:
- 条件查询就是键值数据库的弱项
- 应该尽量避免多表关联查询,可采用双向冗余存储关系来代替表关联,把操作分解成单表操作。
- 发生故障时不支持回滚操作,无法支持事务
列族数据库
- 采用列族数据模型
- 数据库由多个行构成
- 每行数据包含多个列族,不同的行可以具有不同数量的列族
- 同一列族的数据会被存放在一起
- 行通过行键来定位
文档数据库
- 文档是数据库的最小单位
- 通过键来定位文档
- 即可以根据链来构建索引,也可以基于文档内容来构建索引。
图数据库
- 图数据库以图论为基础
- 使用图作为数据模型来存储数据
- 专门用户处理具有高度相互关联的数据,可高效地处理实体之间的关系。
- 适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等
NoSQL的三大基石
NoSQL的三大基石包括CAP、BASE和最终一致性。
CAP
C(Consistency):一致性。它是指任何一个读操作总是能够读到之前完成的写操作的结果,也就是在分布式环境中,多点的数据是一致的。
A(Availability):可用性。它是指快速获取数据,且在确定的时间内返回操作结果。
P(Tolerance of Network Partition):分区容忍性。它是指当出现网络分区的情况时(即系统中的一部分节点无法和其他节点进行通信),分离的系统也能够正常运行。
CAP理论告诉我们,一个分布式系统不可能同时满足一致性、可用性和分区容忍性这3个特性,最多只能同时满足其中2个。
CA:也就是强调一致性C和可用性A,放弃分区容忍性P。最简单的做法是把所有与事务相关的内容都放到同一台机器上。这也意味着放弃系统的扩展性,系统不再是分布式的,有违设计的初衷。传统的关系数据库MySQL、SQL Server和PostgreSQL都采用了这种设计原则,因此扩展性都比较差。
CP:也就是强调一致性C和分区容忍性P,放弃可用性A。当出现网络分区的情况时,受影响的服务需要等待数据一致,因此在等待期间就无法对外提供服务。在数据一致性要求比较高的场合(如:ZooKeeper、HBase) 是比较常见的做法,一旦发生网络故障或者消息丢失,就会牺牲用户体验,等恢复之后用户才逐渐能访问。Neo4J、BigTable和HBase等NoSQL数据库都采用了CP设计原则。
AP:也就是强调可用性A和分区容忍性P,放弃一致性C。允许系统返回不一致的数据。这对于许多WEB2.0网站而言是可行的。当然,在采用AP设计时,也可以不完全放弃一致性,转而采用最终一致性。DynamoDB、Riak、CouchDB、Cassandra等NoSQL数据库就采用了AP设计原则。
BASE
(1)ACID
- A(Atomicity):原子性。
它是指事务必须是原子工作单元,对于其数据修改,要么全部执行,要么全都不执行。
- C(Consistency):一致性。
它是指事务在完成时,必须使所有的数据都保持一致状态。
- I(Isolation):隔离性。
它是指由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。
- D(Durability):持久性。
它是指事务完成之后,它对于系统的影响是永久性的,该修改即使出现致使的系统故障也将一直保持。
(2)BASE
- BA(Basically Availble):基本可用。
它是指一个分布式系统的一部分发生问题变得不可用时,其他部分仍然可以正常使用,也就是允许分区失败的情形出现。
- S(Soft-state):软状态。
它是与硬状态(Hard-state)相对应的一种提法。数据库保存的数据是“硬状态”时,可以保证数据一致性,即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步,具有一定的滞后性。
- E(Eventual consistency):最终一致性。
一致性的类型包括强一致性和弱一致性,二者的主要区别在于在高并发的数据访问操作下,后续操作是否能够获取最新的数据。对于强一致性而言,当执行完一次更新操作后,后续的其他读操作就可以保证读到更新后的最新数据;反之,如果不能保证后续访问读到的都是更新后的最新数据,那么就是弱一致性。最终一致性是弱一致性的特例,允许后续的访问操作可以暂时读不到更新后的数据,但是经过一段时间之后,用户必须读到更新后的数据。
最终一致性
从服务端来看,一致性是指更新如何复制分布到整个系统,以保证数据最终一致。从客户端来看,一致性主要指的是在高并发的数据访问操作下,后续操作是否能够获取最新的数据。
如果一个操作OP往分布式存储系统中写入一个值,遵循最终一致性的系统可以保证,如果后续访问发生之前没有其他写操作去更新这个值,那么,最终所有后续的访问都可以读取操作OP写入的最新值。从OP操作完成到后续访问可以最终读取OP写入的最新值,这之间的时间间隔称为“不一致性窗口”。
最终一致性根据更新数据后各进程访问到数据的时间和方式的不同,又可以进行如下区分:
- 因果一致性
如果进程A通知进程B它已更新了一个数据项,那么进程B的后续访问将获得进程A写入的最新值。而与进程A无因果关系的进程C的访问,仍然遵守一般的一致性规则。
- “读已之所写”一致性:可以视为因果一致性的特例。当进程A自己执行一个更新操作之后,它自己总是可以访问到更新过的值,绝不会看到旧值。
- 会话一致性:它把访问存储系统的进程放到会话的上下文中,只要会话还存在,系统就保证“读已之所写”一致性。如果由于某些失败情形令会话终止,就要建立新的会话,而且系统保证不会延续到新的会话。
- 单调读一致性
如果进程已经看到过数据对象的某个值,那么任何后续访问都不会返回在那个值之前的值。
- 单调写一致性
系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程序的一致性,否则编程难以进行。
从NoSQL到NewSQL数据库
NewSQL是对各种新的可扩展、高性能数据库的简称,这类数据库不仅具有NoSQL对海量数据的存储能力,还保持了传统数据库支持ACID和SQL等特性。不同的NewSQL数据库内部结构差异很大,但是它们有两个显著的共同特点:都支持关系数据模型;都使用SQL作为其主要的接口。
以前,业界和学术界追求的方向是一种架构支持多类应用(One Size Fits All),包括事务型应用(OLTP系统)、分析型应用(OLAP、数据仓库)和互联网应用(Web2.0)。
大数据时代,数据库架构开始向着多元化方向发展,并形成了传统关系数据库(OldSQL)、NoSQL数据库和NewSQL数据库3个阵营。
第5章 NoSQL数据库相关推荐
- 第七章-NoSQL数据库
第七章-NoSQL数据库 文章目录 第七章-NoSQL数据库 NoSQL简介 NoSQL VS. 关系数据库 NoSQL的四大类型 键值数据库 列族数据库 文档数据库 图形数据库 不同类型数据库比较 ...
- 大数据技术原理与应用(第五章 NoSQL数据库)
目录 5.1 NoSQL数据库 Not only SQL特点 传统的关系型数据库特点 MySQL集群方式的缺陷 5.2 NoSQL与关系型数据库的比较 数据库原理 数据规模 数据库模式 查询效率 事务 ...
- Linux实战教学笔记44:NoSQL数据库开篇之应用指南
第1章 NoSQL数据库 1.1 NoSQL概述 自关系型数据库诞生40年以来,从理论产生发展到现实产品,例如:大家最常见的MySQL和Oracle,逐渐在数据库领域里上升到了霸主地位,形成每年高达数 ...
- 【大数据存储技术】第8章 其他NoSQL数据库
文章目录 第8章 其他NoSQL数据库 8.1 图数据库简介 8.2 Neo4j 8.2.1 Neo4j 简介 8.2.2 Neo4j 的安装与实践 8.3 Redis和内存数据库 8.3.1 内存数 ...
- NoSQL数据库探讨 - 为什么要用非关系数据库?
源地址:http://robbin.javaeye.com/blog/524977 随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速.而传 ...
- 第01章_数据库概述
第01章_数据库概述 1. 为什么要使用数据库 持久化(persistence):把数据保存到可掉电式存储设备中以供之后使用.大多数情况下,特别是企业级应用,数据持久化意味着将内存中的数据保存到硬盘上 ...
- NoSQL数据库探讨之一 - 为什么要用非关系数据库?
随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速.而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2. ...
- nosql数据库学习总结
大数据时代的数据库选择:SQL还是NoSQL? 执行大数据项目的企业面对的关键决策之一是使用哪个数据库,SQL还是NoSQL?SQL有着骄人的业绩,庞 大的安装基础;而NoSQL正在获得可观的收益,且 ...
- NoSQL 数据库不应该放弃 Consistency
谈到 NoSQL,一定会提及一致性(Consistency),按照 CAP 定理,有些 NoSQL 数据库放弃了一致性,但是 NoSQL 放弃是必然的选择吗? 从 1970's,关系型数据库(RDB, ...
- NoSQL数据库探讨- 为什么要用非关系数据库?
随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速.而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2. ...
最新文章
- Java集合框架(1)
- 编程小白的第一本python入门书-《编程小白的第一本Python入门书》读书笔记
- 在ASP.NET中把数据POST到其他页面
- 怎么建立微信生态用户增长模型?
- git报错fatal: HTTP request failed
- JS基础_JS基础语法
- python3.6教程案例分析_python 3.6 --实战Scrapy
- 线性最小二乘法(附MATLAB代码)
- 【Spring MVC】学习笔记汇总
- java打印插件_java c/s项目中有没有好用的打印插件?
- ubuntu删除OpenCV
- 我的大数据之路(一)-数据仓库也需要大数据
- 如何使用南方CASS绘制地形图
- .Net 中使用 iTextSharp 组件生成 PDF
- BP神经网络——激活函数
- 淘宝数据可视化大屏案例(Hadoop实验)
- 在Windows 7 Media Player中轻松播放Flac,Ogg和其他文件格式
- 计算机中华五岳说课稿,中国五岳 地理课前三分钟演讲.ppt
- 5G时代IDC数据中心经历变革,分布式云存储服务器将独占鳌头
- MCAL知识点(十九):SENT驱动详细配置