noSQL数据库.ppt

上传人:夺命阿水 文档编号:242074 上传时间:2023-03-16 格式:PPT 页数:26 大小:272.50KB
返回 下载 相关 举报
noSQL数据库.ppt_第1页
第1页 / 共26页
noSQL数据库.ppt_第2页
第2页 / 共26页
noSQL数据库.ppt_第3页
第3页 / 共26页
noSQL数据库.ppt_第4页
第4页 / 共26页
noSQL数据库.ppt_第5页
第5页 / 共26页
点击查看更多>>
资源描述

《noSQL数据库.ppt》由会员分享,可在线阅读,更多相关《noSQL数据库.ppt(26页珍藏版)》请在课桌文档上搜索。

1、NoSQL数据库非关系型数据库,NoSQL数据库,目录,NoSQL数据库简介,为什么使用NoSQL数据库,NoSQLCAP原理,NoSQL数据库应用,NoSQL数据库简介,NoSQL,即是不提供SQL功能的数据库,是一项全新的数据库革命性的运动。NoSQL早期就有人提出,发展至2009年趋势越发高涨。NoSQL是指非关系型数据库,分布式,不提供ACID的数据库设计模式。ACID,是指在数据库管理系统(DBMS)中,事务(transaction)所具有的四个特性:原子性、(atomicity)、一致性(consistency)、独立性(isolation)、持久性(durability)。关系数

2、据库,是建立在关系模型基础上的数据库,借助于集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。标准数据查询语言SQL就是一种基于关系数据库的语言,这种语言执行对关系数据库中的数据的检索和操作。关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成。,为什么使用NoSQL数据库,随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域。传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS(social networking service,即社会性网络服务)类型的web2.0纯动态网站已经显

3、得力不从心,暴露了很多难以克服的问题。,为什么使用NoSQL数据库,web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载分成高,往往要达到每秒上万次的读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。其实对于普通的BBS网站,往往也存在对高并发写请求的需求。,对数据库高并发读写的需求,为什么使用NoSQL数据库,对于大型的SNS网站,每天用户产生海量的用户动态,以国外的Friendfeed为例,一个月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5

4、亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统,例如腾讯,盛大,动辄数以亿计的账号,关系数据库也很难以应付。,对海量数据的高效率存储和访问的需求,为什么使用NoSQL数据库,在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server 和app server 那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服

5、务器节点来实现扩展呢?,对数据库的高可扩展性和高可用性的需求,为什么使用NoSQL数据库,在上面提到的“三高”需求面前,关系数据库遇到了难以克服的障碍,而对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地,例如:1、数据库事务一致性需求 很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高,因此数据库事务管理成了数据库高负载下一个沉重负担。2、数据库的写实时性和读实时性需求 对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但对于很多web应用来说,并不需要这么高的实时性,比如发一条消息之后,过几秒乃至十几秒后,我

6、的订阅者才看到这条动态是完全可以接受的。3、对复杂的SQL查询,特别是多表关联查询的需求任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,此时SQL的功能被极大的弱化了。,为什么使用NoSQL数据库,总结:传统的关系型数据功能支持上通常很宽泛,从简单的键值查询,到复杂的多表联合查询再到事务机制的支持。而与之不同的是,NoSQL系统通常注重性能和扩展性,而非事务机制。,NoSQL数据一致性,传统的SQL数据库的事务通常都是支持ACID的强事务机制。NoSQL中,通常有两个层次的一致性:第一种是强一致性,即集群中的所有机器状态同步保持一致。第二种的

7、最终一致性,既可以允许短暂的数据不一致,但数据最终会保持一致。,CAP原理,分布式系统中,有三种重要的属性,分别是:一致性(Consistency):任何一个读操作总是能读取到之前完成的写操作结果,也就是在分布式环境中,多点的数据是一致的。可用性(Availability):每一个操作总是能够在确定的时间内返回,也就是系统随时都是可用的。分区容忍性(ToleranceofnetworkPartition):在出现网络分区(比如断网)的情况下,分离的系统也能正常运行。,一致性or可用性,下面是一个牺牲一致性换取可用性的小例子。假设N1和N2是分布式环境下的两个节点,它们有保存了共同的数据V,它们

8、的值都是V0,A和B是两个分别对数据进行操作的进程。我们看看这么一个过程:A向N1节点写入了新的V值V1,B读取V的值。,如果一切正常的话,这个过程看起来像是这样的:,(1)A写入V的新值V1。(2)N1向N2发送消息M以更新V值。(3)B读取V的新值V2,但是现实可能是这样子的,由于网络分区,N1发向N2的消息很有可能没送达,那么,B节点将读取到一个过时的V值,不一致性产生了。并且当把节点的规模不断扩大的时候,不一致性问题也会更加严重。所以如果我们希望A B都是高可用的(也就是低延迟),那么一致性通常就不能得到很好的保证,我们必须要容忍一定的不一致性以换取高可用性。,从客户端角度看一致性,强

9、一致性:读取到的数据总是最新的。弱一致性:读取到的数据不一定是最新的。最终一致性:属于弱一致性,不同的是,最终一致性的系统会在后台异步地更新所有的备份,所以最终所有的备份都会是最新的数据。,从服务器端角度看一致性,我们利用一个数学模型来分析一下服务器端对于一致性的实现N:存储备份的节点数目,可以理解为备份的数目。W:更新(写)操作成功之前所必须更新的最少备份数目。假设W=3,表示至少等到3个备份的数据得到更新时,更新操作才算完成。R:读操作所需要连接的最少备份数目。假设R=3,表示读取一个数据时,至少要读取到这个数据的3个备份,然后选其中最新的备份。,调整N、W、R的取值,数据库系统的性质就会

10、发生改变,N越大,同一个数据的备份越多,系统相对也就越不容易丢失数据。W越大,系统的一致性会越高,但更新操作也就越慢。R越大,系统的一致性会越高,但读操作也就越慢。W+RN,系统是强一致性的。为什么?举例来说,假设N=6,W=R=3,当一个更新操作完成的时候,它至少更新了6个备份中的3个备份,那么当我们去读取这个数据的时候,因为R=3,所以我们至少得读3个数据,并从中选择最新的数据,而W+RN就意味着读取的3个数据跟更新的3个数据至少有一个是重叠的,所以读取的3个数据中一定存在最新的数据,因而就能保证系统是强一致性的。W+R=N,系统是弱一致性的。,NoSQL数据库特点,可以处理超大量的数据可

11、以运行在便宜的PC服务器集群上打破了性能的瓶颈 NoSQL的支持者称,通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间,执行速度变得更快。对于那些繁重的重复操作的数据,SQL值得花钱。但是当数据库结构非常简单时,SQL可能没有太大用处。没有过多的操作虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合,而且在数据完整性上也发挥绝对稳定,他们同时也表示,企业的具体需求可能没有那么多。,NoSQL数据库优点,易扩展NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了

12、可扩展的能力。大数据量,高性能NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般MySQL使用 Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的 Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多了。,NoSQL数据库优点,灵活的数据模型 NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字

13、段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。高可用NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。比如Cassandra,HBase模型,通过复制模型也能实现高可用。,MongoDB,MongoDB是一个基于分布式文件存储的数据库。由C+语言编写。主要解决的是海量数据的访问效率问题,为WEB应用提供可扩展的高性能数据存储解决方案。当数据量达到50GB以上的时候,MongoDB的数据库访问速度是MySQL的10倍以上。MongoDB的并发读写效率不是特别出色,根据官方提供的性能测试表明,大约每秒可以处理0.5万1.5万次读写请求。MongoDB还自带了一个出色的分

14、布式文件系统GridFS,可以支持海量的数据存储。MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。他支持的数据结构非常松散,是类似json(基于JavaScript语言的轻量级的数据交换格式)的bjson格式,因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。,MongoDB,所谓“面向集合”(Collenction-Orented),意思是数据被分组存储在数据集中,被称为一个集合(Collen

15、ction)。每个 集合在数据库中都有一个唯一的标识名,并且可以包含无限数目的文档。集合的概念类似关系型数据库(RDBMS)里的表(table),不同的是它不需要定 义任何模式(schema)。模式自由(schema-free),意味着对于存储在mongodb数据库中的文件,我们不需要知道它的任何结构定义。如果需要的话,你完全可以把不同结构的文件存储在同一个数据库里。存储在集合中的文档,被存储为键-值对的形式。键用于唯一标识一个文档,为字符串类型,而值则可以是各中复杂的文件类型。我们称这种存储形式为BSON(Binary Serialized dOcument Format)MongoDB服务

16、端可运行在Linux、Windows或OS X平台,支持32位和64位应用,默认端口为27017。推荐运行在64位平台,因为MongoDB在32位模式运行时支持的最大文件尺寸为2GB,MongoDB特性,它的特点是高性能、易部署、易使用,存储数据非常方便。主要功能特性有:面向集合存储,易存储对象类型的数据。模式自由。支持动态查询。支持完全索引,包含内部对象。支持查询。支持复制和故障恢复。使用高效的二进制数据存储,包括大型对象(如视频等)。自动处理碎片,以支持云计算层次的扩展性。支持RUBY,PYTHON,JAVA,C+,PHP,C#等多种语言。文件存储格式为BSON(一种JSON的扩展)。可通

17、过网络访问。,CouchDB,Apache CouchDB 是一个面向文档的数据库管理系统。它提供以 JSON 作为数据格式的 REST 接口来对其进行操作,并可以通过视图来操纵文档的组织和呈现。CouchDB 是 Apache 基金会的顶级开源项目。CouchDB是用Erlang开发的面向文档的数据库系统,其数据存储方式类似Lucene的Index文件格式。CouchDB最大的意义在于它是一个面向Web应用的新一代存储系统.,CouchDB特性,CouchDB是分布式的数据库,他可以把存储系统分布到n台物理的节点上面,并且很好的协调和同步节点之间的数据读写一致性。这当然也得以于Erlang无

18、与伦比的并发特性才能做到。CouchDB是面向文档的数据库,存储半结构化的数据,比较类似lucene的index结构,特别适合存储文档,因此很适合CMS,电话本,地址本等应用,在这些应用场合,文档数据库要比关系数据库更加方便,性能更好。CouchDB支持REST API,可以让用户使用JavaScript来操作CouchDB数据库,也可以用JavaScript编写查询语句,我们可以想像一下,用AJAX技术结合CouchDB开发出来的CMS系统会是多么的简单和方便。其实CouchDB只是Erlang应用的冰山一角,在最近几年,基于Erlang的应用也得到的蓬勃的发展,特别是在基于web的大规模,分布式应用领域,几乎都是Erlang的优势项目。,谢 谢!,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 在线阅读 > 生活休闲


备案号:宁ICP备20000045号-1

经营许可证:宁B2-20210002

宁公网安备 64010402000986号