NoSQL数据库

NoSQL数据库

1、NoSQL简介

前期表示“反SQL”运动,用新型的非关系型数据库取代关周密据库;现在代表“Not
only SQL”关系和非关系型数据库各有利害,相互都无法互相代替。

平凡,NoSQL数据库具有以下多少个特色:

(1)灵活的可扩充性

(2)灵活的数据模型

(3)与云计算近紧密融合

2、NoSQL兴起的来头

1.关全面据库已经不可能满意Web2.0的须求。紧要表现在以下多少个方面:

(1)无法满意海量数据的保管必要

(2)不可以满意数码高并发的要求

(3)无法知足高可伸张性和高可用性的要求

MySQL集群是否能够完全解决问题?

  • 复杂:安插、管理、配置很复杂
  • 数据库复制:MySQL主备份之间利用复制形式,只好是异步复制,当主库压力较大时或许发生较大延迟,主备切换可能会对视最终一部分更新工作,那时往往须求人工插手,备份和恢复生机不便宜
  • 扩容问题:借使系统压力过大需要充实新的机械,那几个进度涉及多少重复划分,整个进程相比较复杂,且易于出错
  • 动态数据库迁移问题:要是某个数据库组压力过大,要求将其中一部分数码迁移出去,迁移进度须要总控节点全体协调,以及数据库节点的合作。这几个进程很难做到自动化

2.“One size fits all”形式很难适用于完全差别的事务场景

  • 关系模型作为联合的数据模型即被用来数据解析,也被用于在线工作。但那三头一个强调高吞吐,一个强调低时延,已经衍生和变化出不相同的架构。用同一套模型来抽象鲜明是不对劲的
  • Hadoop就是对准数据解析
  • MongoDB、Redis等是针对性在线工作,两者都遗弃了事关模型

3.关全面据库的机要特性包蕴周全的作业机制和高速的查询机制。然而,关全面据库引以为傲的三个特征,到了Web2.0时代却成了鸡肋,首要展现在偏下几个地点:

(1)Web2.0网站系统日常不要求从严的数据库事务

(2)Web2.0并不须求严苛的读写实时性

(3)Web2.0普普通通不分包大量犬牙相错的SQL查询(去结构化,防止多表查询,存储空间换取更好的询问性能)

3、NoSQL与关周到据库的相比较

NoSQL和关周密据库的简便相比较

比较标准 RDBMS NoSQL 备注
数据库原理 完全支持 部分支持 RDBMS有关代数理论作为基础
NoSQL没有统一的理论基础
数据规模 超大 RDBMS很难实现横向扩展,纵向扩展的空间也比较有限,性能会随着数据规模的增大而降低
NoSQL可以很容易通过添加更多设备来支持更大规模的数据
数据库模式 固定 灵活 RDBMS需要定义数据库模式,严格遵守数据定义和相关约束条件
NoSQL不存在数据库模式,可以自由灵活定义并存储各种不同类型的数据
查询效率 可以实现高效简单查询,但是不具备高度结构化查询等特性,复杂查询的性能不尽人意 RDBMS借助于索引机制可以实现快速查询(包括记录查询和范围查询)
很多NoSQL数据库没有面向复杂查询的索引,虽然NoSQL可以使用MapReduce来加速查询,但是,在复杂查询方面的性能仍然不如RDBMS
一致性 强一致性 弱一致性 RDBMS严格遵守事务ACID模型,可以保证事务强一致性
很多NoSQL数据库放松了对事务ACID四性的要求,而是遵守BASE模型,只能保证最终一致性
数据完整性 容易实现 很难实现 任何一个RDBMS都可以很容易实现数据完整性,比如通过主键或者非空约束来实现实体完整性,通过主键、外键来实现参照完整性,通过约束或者触发器来实现用户自定义完整性
但是,在NoSQL数据库却无法实现
扩展性 一般 RDBMS很难实现横向扩展,纵向扩展的空间也比较有限
通过添加廉价设备实现扩展
可用性 很好 RDBMS在任何时候都可以保证数据一致性为优先目标,其次才是优化系统性能,随着数据规模的增大,RDBMS为了保证严格的一致性,只能提供相对较弱的可用性
大多数NoSQL都能提供较高的可用性
标准化 RDBMS已经标准化(SQL)
NoSQL还没有行业标准,不同的NoSQL数据库都有自己的查询语言,很难规范应用程序接口
StoneBraker认为:NoSQL缺乏统一查询语言,将会拖慢NoSQL发展
技术支持 RDBMS经过几十年的发展,已经非常成熟,Oracle等大型厂商都可以提供很好的技术支持
NoSQL在技术方面仍然处于起步阶段,还不成熟,缺乏有力的技术支持
可维护性 复杂 复杂 RDBMS需要专门的数据库管理员(DBA)维护
NoSQL数据库虽然没有DBMS复杂,也难以维护

总结:

(1)关周密据库

优势:以完美的涉嫌代数理论作为基础,有严厉的正式,扶助事务ACID四性,借助索引机制得以兑现飞快的查询,技术成熟,有专业公司的技术协助。

逆风局:可伸张性较差,不能较好匡助海量数据存储,数据模型过于刻板、不能较好帮助Web2.0用到,事务机制影响了系统的完整性能等。

(2)NoSQL数据库

优势:能够支撑超大规模数据存储,灵活的数据模型可以很好地协理Web2.0行使,具有强有力的横向扩展能力等。

逆风局:缺少数学理论基础,复杂查询性能不高,大都无法促成事务强一致性,很难达成数据完整性,技术尚不成熟,缺少专业协会的技术支持,维护较困难等。

关周详据库和NoSQL数据库各有利弊,互相不可能替代

  • 关周详据库应用场景:电信、银行等领域的主要性作业系统,要求确保强事务一致性
  • NoSQL数据库应用场景:互联网公司、传统公司的非关键业务(比如数据解析)

动用混合架构:

案例:亚马逊公司就应用差别档次的数据库来援助它的电子商务应用

对于“购物篮”那种临时数据,选拔键值存储会愈来愈神速;
当前的产品和订单新闻则吻合存放在关周详据库中;
多量的历史订单音讯则吻合保存在近似MongoDB的文档数据库中

4、NoSQL的四大项目

NoSQL数据库就算数额很多,不过,归纳起来,典型的NoSQL数据库一般包蕴键值数据库、列族数据库、文档数据库和图片数据库。

  • 文档数据库:马克(Mark)Logic、Couchbase、mongoDB
  • 图表数据库:Neo4j、InfiniteGraph
  • 键值数据库:redis、亚马逊(Amazon) DynamoDB、riak
  • 列族数据库:HYPERTABLE、accumulo、HBASE、亚马逊(Amazon) SimpleDB

1.键值数据库

相关产品 Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached
数据模型 键/值对
键是一个字符串对象
值可以是任意类型的数据,比如整型、字符型、数组、列表、集合等
典型应用 涉及频繁读写、拥有简单数据模型的应用
内容缓存,比如会话、配置文件、参数、购物车等
存储配置和用户数据信息的移动应用
优点 扩展性好,灵活性好,大量写操作时性能高
缺点 无法存储结构化信息,条件查询效率较低
不适用情形 不是通过键而是通过值来查:键值数据库根本没有通过值查询的途径
需要存储数据之间的关系:在键值数据库中,不能通过两个
使用者 百度云数据库(Redis)、GitHub(Riak)、BestBuy(Riak)、Twitter(Redis和Memcached)、StackOverFlow(Redis)、Instagram(Redis)、Youtube(Memcached)、Wikipedia(Memcached)

键值数据库成为可以的缓冲层解决方案。
Redis有时候会被人们称作“强化版的Memcached”支持持久化、数据复苏、越多数据类型。

2.列族数据库

相关产品 BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
数据模型 列族
典型应用 分布式数据存储与管理
数据在地理上分布于多个数据中心的应用程序
可以容忍副本中存在短期不一致情况的应用程序
拥有动态字段的应用程序
拥有潜在大量数据的应用程序,大到几百TB的数据
优点 查找速度快,可扩展性强,容易进行分布式扩展,复杂性低
缺点 功能较少,大都不支持强事务一致性
不适用情形 需要ACID事务支持的情形,Cassandra等产品就不适用
使用者 Ebay(Cassandra)、Instagram(Cassandra)、NASA(Cassandra)、Twitter(Cassandra and HBase)、Facebook(HBase)、Yahoo!(HBase)

3.文档数据库

“文档”其实是一个数量记录,这么些记录可知对含有的数据类型和情节开展“自我描述”。XML文档、HTML文档和JSON文档就属于这一类。SequoiaDB就是应用JSON文档格式的文档数据库,它的积存的数码是如此的:

{
    "ID" : 1,
    "NAME" : "SequoiaDB",
    "Tel" : {
        "Office" : "123123" , "Mobile" : "132132132"
        }
    "Addr" : "China,GZ"
}
  • 多少是窘迫的,每一条记下包蕴了富有的关于“SequoiaDB”的音讯而从不其余外部的引用,那条记下就是“自包蕴”的
  • 那使得记录很简单完全运动到别的服务器,因为那条记下的兼具新闻都含有在其间了,不需求考虑还有音讯在其他表没有同步迁移走
  • 并且,因为在运动进度中,唯有被移动的那一条记下(文档)须要操作,而不像关系型中每个有涉嫌的表都须求锁住来确保一致性,那样一来ACID的担保就会变得更快速,读写的进程也会有很大的升迁
相关产品 MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit
数据模型 键/值
值(value)是版本化的文档
典型应用 存储、索引并管理面向文档的数据或者类似的半结构化数据
比如,用于后台具有大量读写操作的网站、使用JSON数据结构的应用、使用嵌套结构等非规范化数据的应用程序
优点 性能好(高并发),灵活性高,复杂性低,数据结构灵活
提供嵌套式文档功能,将经常查询的数据存储在同一个文档中
既可以根据键来构建索引,也可以根据内容构建索引
缺点 缺乏统一的查询语法
不适用情形 在不同的文档上添加事务。文档数据库并不支持文档间的事务,如果对这方面有需求则不应该选用这个解决方案
使用者 百度云数据库(MongoDB)、SAP(MongoDB)、Codecademy(MongoDB)、Foursquare(MongoDB)、NBC News(RavenDB)

4.图形数据库

相关产品 Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB
数据模型 图结构
典型应用 专门用于处理具有高度相互关联关系的数据,比较适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题
优点 灵活性高,支持复杂的图形算法,可用于构件复杂的关系图谱
缺点 复杂性高,只能支持一定的数据规模
使用者 Adobe(Neo4J)、Cisco(Neo4J)、T-Mobile(Neo4J)

差别类型数据库相比分析

  • MySQL发生年代较早,而且趁机LAMP大潮得以成熟。固然其没有怎么大的改进,不过新兴的互联网应用的最多的数据库
  • MongoDB是个新生事物,提供更灵活的数据模型、异步提交、地理地点索引等五花十色的功力
  • HBase是个“仗势欺人”的大象兵。依仗着Hadoop的生态环境,可以有很好的扩大性。不过就像象兵一样,使用者须求养一头大象(Hadoop),才能促使他
  • Redis<是键值存储的意味,效用最简易。提供随机数据存储。就像一根棍子一样,没有剩余的社团。可是也正是由此,它的伸缩性尤其好。似乎悟空手里的金箍棒,大可捅破天,小能缩成针。

5、NoSQL的三大基本

CAP、最后一致性、BASE

CAP指的是:

  • C(Consistency):一致性,是指其余一个读操作总是可以读到以前形成的写操作的结果,也就是在分布式环境中,多点的数额是如出一辙的,或者说,所有节点在同一时间具有同等的多寡;
  • A(Availability):可用性,是指神速获取数据,可以在规定的光阴内再次来到操作结果,保险每个请求不管成功照旧失败都有响应;
  • P(Tolerance of Network
    Partition):分区容忍性,是指当出现网络分区的情事时(即系统中的一有些节点不可以和别的节点开展交通),分离的连串也可以正常运作,也就是说,系统中随机音讯的散失或破产不会潜移默化系统

CAP理论告诉我们,一个分布式系统不可以还要满意一致性、可用性和分区容忍性那七个须求,最多只可以同时满意其中三个,正所谓“鱼和熊掌不可兼得”。

当处理CAP的题材时,能够有多少个明明的选取:

1.CA:也就是强调一致性(C)和可用性(A),放任分区容忍性(P),最简便的做法是把具备与业务相关的始末都置于同一台机器上。很明朗,那种做法会严重影响系统的可扩大性。传统的关系型数据库(MySQL、SQL
Server和PostgreSQL),都采用了那种设计标准,因而,伸张性都比较差。

2.CP:也就是强调一致性(C)和分区容忍性(P),扬弃可用性(A),当出现网络分区的场地时,受影响的劳务需求等待数据一致,由此在守候时期就无法对外提供劳务(Neo4J、Bigtable、MongoDB、Hbase、Hypertable、Redis)

3.AP:也就是强调可用性(A)和分区容忍性(P),扬弃一致性(C),允许系统重临不相同等的多少(Dynamo、Cassandar、Voldemort、CouchDB、Riak)
BASE(Basically Availble,Soft-state,伊芙ntual consistency)

一个数据库事务有着ACID四性:

ACID BASE 说明
原子性(Atomicity) 基本可用(Basically Available) 指事务必须是原子工作单元,对于其数据修改,要么全都执行,要么全都不执行
一致性(Consistency) 软状态/柔性事务(Soft state) 指事务在完成时,必须使所有的数据都保持一致状态
隔离性(Isolation) 最终一致性(Eventual consistency) 指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离
持久性(Durable)   指事务完成之后,它对于系统的影响是永久性的,该修改即使出现致命的系统故障也将一直保持

BASE的主导含义是基本可用(Basically
Availble)软状态(Soft-state)和结尾一致性(伊夫(Eve)ntual consistency):

着力可用:

骨干可用,是指一个分布式系统的一有的发生问题变得不可用时,其他部分依旧可以健康使用,也就是允许分区失败的气象现身

软状态:

“软状态(soft-state)”是与“硬状态(hard-state)”相对应的一种说法。数据库保存的数目是“硬状态”时,可以保险数据一致性,即保障数据一向是未可厚非的。“软状态”是指情况可以有一段时间不联合,具有自然滞后性

终极一致性:

一致性的项目包蕴强一致性和弱一致性,二者的首要性不相同在于高并发的多少访问操作下,后续操作是否可以拿走最新的数据。对于强一致性而言,当执行完一回立异操作后,后续的其余读操作就足以确保读到更新后的新星数据;反之,若是不可以保障后续访问读到的都是翻新后的新式数据,那么就是弱一致性。而结尾一致性只可是是弱一致性的一种特例,允许继承的造访操作可以临时读不到履新后的数额,可是通过一段时间之后,必须最终读到更新后的多少。

最广泛的完毕最后一致性的连串是DNS(域名连串)。一个域名更新操作按照安顿形式被分发出去,并结合有逾期机制的缓存;最终具备的客户端可以观看最新的值。

终极一致性依据更新数据后各进度访问到数码的时日和办法的不比,又有啥不可区分为:

 因果一致性:若是经过A布告进程B它已更新了一个数码项,那么进度B的继续访问将赢得A写入的新式值。而与经过A无因果关系的进度C的拜访,依然遵从一般的最终一致性规则

 “读己之所写”一致性:可以算得因果一致性的一个特例。当进度A自己履行一个翻新操作之后,它和谐总是可以访问到履新过的值,绝不会看到旧值

 单调读一致性:若是经过早已看到过多少对象的某个值,那么其余后续访问都不会回到在相当值在此之前的值

 会话一致性:它把走访数据系统的历程放到会话(session)的光景文中,只要会话还留存,系统就有限支持“读己之所写”一致性。若是是因为某些退步处境令会话终止,就要创建新的对话,而且系统有限支撑不会三番五遍到新的对话

 单调写一致性:系统保险来自同一个经过的写操作顺序执行。系统必须确保那种程序的一致性,否则就卓殊难以编程了

哪些贯彻各系列型的一致性?

对于分布式数据系统:

  • N : 数据复制的份数
  • W : 更新数据是亟需保证写完毕的节点数
  • R : 读取多少的时候必要读取的节点数

若果 W+R > N
,写的节点和读的节点重叠,则是强一致性,例如对于典型的一主一备同步复制的关系型数据库,N=2,W=2,R=1,则无论读的是主库照旧备库的多少,都是一样的。一般设定是
R+W = N+1 ,那是保障强一致性的蝇头设定

即使 W+R <=
N,则是弱一致性。例如对于一主一备异步复制的关系型数据库,N=2,
W=1,R=1,则只要读的是备库,就足以无法读取主库已经更新过的数据,所以是弱一致性。

对于分布式系统,为了确保高可用性,一般设置N >=
3。分歧的N,W,R组合,是在可用性和一致性之间取一个平衡,以适应分歧的使用场景。

如果N=W,R=1,任何一个写节点失效,都会招致写失利,由此可用性会下滑,可是由于数据分布的N个节点是一道写入的,由此得以确保强一致性。

实例:HBASE是依靠其底层的HDFS来落到实处其数量冗余备份的。HDFS拔取的就是强一致性有限支持。在数据尚未完全同步到N个节点前,写操作是不会重回成功的。也就是说它的W=N,而读操作只须求读到一个值即可,也就是说它R=1。

像Voldemort,卡桑德拉和Riak那些类Dynamo的系统,常常都同意用户按须要设置N,R,W多个值,纵然是安装成W+R
<=
N也是足以的。也就是说他同意用户在强一致性和最后一致性之间自由选择。而在用户选取了最终一致性,或者是W
<
N的强一致性时,则总会出现一段“各样节点数据不联合导致系统处理不平等的光阴”。为了提供最终一致性的支撑,那些种类会提供部分工具来使数据更新被最后同步到具备的有关节点。

6、从NoSQL到NewSQL数据库

本着差距的采用使用不相同的数据库,使用OldSQL协理事务处理,使用NoSQL扶助互联网选取,NewSQL同时兼有关系型数据库和NoSQL数据库的长处。

 

网站地图xml地图