大数据管理系统3 relational c_第1页
大数据管理系统3 relational c_第2页
大数据管理系统3 relational c_第3页
大数据管理系统3 relational c_第4页
大数据管理系统3 relational c_第5页
已阅读5页,还剩36页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

关系型数据管理系统中科院计算所计算机体系结构关系型数据管理系统中科院计算所计算机体系结构国家重点实验室大数据管理系统®2015陈世敏(chensm@)•事务处理•数据仓库•分布式数据库前端后端 大数据管理系统大数据管理系统®2015陈世敏(chensm@)•事务处理•数据仓库•分布式数据库大数据管理系统大数据管理系统®2015陈世敏(chensm@)2事务处理系统•典型例子:银行业务,事务处理系统•典型例子:银行业务,订票,购物等•大量并发用户,少量随机读写操作大数据管理系统®2015陈世敏(chensm@)大数据管理系统®2015陈世敏(chensm@)成功的事务可以用rollback回卷事务或abort•Atomicity口要么完全执行,要么完全没有执行口从一个正确状态转换到另一个正确状态口每个事务与其它并发事务互不影响}}大数据管理系统大数据管理系统®2015陈世敏(chensm@)同一个数据元素被并发访问T1T2X例如:X是银行账户余额•会有什么问题?大数据管理系统大数据管理系统®2015陈世敏(chensm@)3Read(x)Read(x)wwritXRead(x)writ(x)Read(x)Read(x)wwritXRead(x)writ(x)(调度/执行顺序)T2的write被覆盖了Read(x)write(x)大数据管理系统®2015陈世敏(chensm@)(调度/执行顺序)大数据管理系统®2015陈世敏(chensm@)•当两个并发访问都是写,或者一个读一个写时T1T2X例如:X是银行账户余额•场景:同一个账户两笔转帐并发发生会怎样?大数据管理系统大数据管理系统®2015陈世敏(chensm@)更复杂的情况T1T2XY•两个Transactions并发访问多个共享的数据元素•实际上,真实情况更加复杂大数据管理系统大数据管理系统®2015陈世敏(chensm@)4大数据管理系统®2015陈世敏(大数据管理系统®2015陈世敏(chensm@)正确性问题•提出解决方案前,我们必须提问•如何判断一组Transactions正确执行?•存在一个顺序,按照这个顺序依次串行执行这些Transactions,得到的结果与并行执行相同writ(x)Read(x)write(x)Read(x)writ(x)Read(x)write(x)大数据管理系统®2015陈世敏(chensm@)并行并行执行结果某个顺序的某个顺序的串行执行结果•判断一组并行Transactions是否正确执行的标准大数据管理系统大数据管理系统®2015陈世敏(chensm@)ReadRead(x)write(x)Read(y)write(y)Read(x)write(y)Read(xwrite(x)Read(y)write(y)Read(xwrite(y)write(x)Read(y)write(y)writwrit(y)大数据管理系统®2015陈世敏(chensm@)5writ(x)writ(y)Read(x)write(y)大数据管理系统®2015陈世敏writ(x)writ(y)Read(x)write(y)大数据管理系统®2015陈世敏(chensm@)Read(x)writ(x)writ(ywrit(y)〓Overwriteuncommitteddata(更新丢失)大数据管理系统®2015陈世敏(chensm@)(读脏数据)Read(x)wnite(x)Read(x)wnite(y)Read(y)write(y)commitcommit数据冲突引起的问题•Unrepeatablereads(不口如果T2再次读同一个数据,那么将发现不同的值•Overwriteuncommitteddata(更新丢失)(写写)口在T2commit之前,T1重写了T2已经修大数据管理系统大数据管理系统®2015陈世敏(chensm@)(不可重复读)OverwriteuncommitteddataOverwriteuncommitteddata(更新丢失)RdRdYRead(x)writwrit(x)wwritwwrit(y)commitwritwrit(y)commit大数据管理系统大数据管理系统®2015陈世敏(chensm@)6口假设:数据竞争可能经常出现口口假设:数据竞争可能经常出现口采用某种机制确保数据竞争不会出现–如果一个TransactionT1可能和正在运行的其它Transaction有冲突,那么就让这个T1等待,一直等到有冲突的其它所有Transaction都完成为止,才开始执行。•Optimistic口假设:数据竞争很少见口但是Transaction不直接修改数据,口当Transaction结束时,检查这些修改是否有数据竞争–没有竞争,成功结束,真正修改数据–有竞争,丢弃结果,重新计算大数据管理系统®2015陈世敏(chensm@)大数据管理系统®2015陈世敏(chensm@)T1T2XY•这样一来,两个transactions不会同时执行•对每个访问的数据都要加锁后才能访问•算法如下口在Transaction开始时,对每个需要访问的数据加锁–如果不能加锁,就等待,直到加锁成功口在Transactioncommit前,集中•有一个集中的加锁阶段和一个集中的解锁阶段大数据管理系统大数据管理系统®2015陈世敏(chensm@)•有问题吗?T1T2XYRead(x)write(x)Read(y)write(y)Read(x)wnite(y)大数据管理系统®2015陈世敏(chensm@)7大数据管理系统®2015大数据管理系统®2015陈世敏(chensm@)SharedLock(S)ExclusiveLock(X)SharedLock(S)√XExclusiveLock(X)XX大数据管理系统®2015陈世敏(chensm@)SX√√√X√√XXS√X√XXXXXX•锁的粒度是不同的口IS(a):将对a下面更细粒度的数据元素进行读口IX(a):将对a下面更细粒度的数据元素进行写•为了得到X,IX:所有祖先必须为IX大数据管理系统大数据管理系统®2015陈世敏(chensm@)•什么情况下会出现死锁?TT1T3大数据管理系统大数据管理系统®2015陈世敏(chensm@)8•数据库的lock对象很多,•数据库的lock对象很多,不适合死锁避免•死锁检测口周期地对长期等待的Transactions检查是否有circularwait口如果有,那么就选择环上其中一个TransactionabortT2T1T3大数据管理系统®2015陈世敏(chensm@)结果:x=-10;y=-10大数据管理系统®2015陈世敏(chensm@) 初始:x=10;y=10两个账户总和不能透支if(x+y>=20){x=x–20;}if(x+y>=20){y=y–20;}在SnapshotIsolation下,T1与T2可以同时正确执行。注意:虽然在每个事物中,x+y>0,但总结果却不是了•死锁避免口规定lock对象的顺序口按照顺序请求lock口适用于lock对象少的情况口适用于lock对象少的情况T1T3大数据管理系统®2015陈世敏(chensm@)•Snapshot:一个时点的数据库数据状态口在起始时点的snapshot口读:这个snapshot的数据口写:先临时保存起来,在commit时检查有无冲突,有冲突就abort 大数据管理系统大数据管理系统®2015陈世敏(chensm@)9大数据管理系统®2015大数据管理系统®2015陈世敏(chensm@)•Transactioncommit后,结果持久有效,cra•想法一口在transactioncommit时,把所有的修改都写回硬盘口只有当写硬盘完成后,才commit•有什么问题?Atomicity被破坏了!口性能问题:随机写硬盘,等待写完成大数据管理系统®2015陈世敏(chensm@)口记录一个写操作的全部信息•例如:记录的修改操作的日志记录–LSN:Logsequencenumber,是一个不断递增的整数,唯一代表一个记录;每产生一个日志记录,LSN加1–opID:写操作类型–pageID,slotID,columnID:定位到具体一个页的一个记录的一个列–oldvalue,newvalue:旧值和新值•什么是Write-Ahead•怎样保证Durability大数据管理系统大数据管理系统®2015陈世敏(chensm@)•对Transaction中每个写操作产生一个事务日志记录•Transactioncommit会产生一个commit日志记录•Transactionabort会产生一个abort日志记录•日志记录被追加(append)到日志文件末尾大数据管理系统大数据管理系统®2015陈世敏(chensm@)10大数据管理系统®2015大数据管理系统®2015陈世敏(chensm@)口Logging相当于意向,先记录意向,然后再实际操作•写操作口然后执行写操作大数据管理系统®2015陈世敏(chensm@)•简单方法:写日志记录时保证日志记录Durable口必须执行一个写操作,然后用flush保证写操作确实写到硬盘上了,并且等待flush结束口这个过程通常需要~10ms•简单计算口假设每个transaction需要修改10个记录口那么上述写日志就需要~100ms口硬盘同时只能执行一个写操作口所以系统的throughput为10transaction/second–如果每个transaction修改100个记录,会怎么样?•太慢了!•条件:日志是Durable的•当出现掉电时,可以根据日志发现所有写操作口总是先记录意向,然后实际操作口所以只有存在日志记录,相应的操作才有可能发生•对于一个Transaction,寻找它的commit日志记录口如果找到,那么这个transaction已经commit了口如果没找到,那么这个transaction没有完成口根据日志记录,确保所有的写操作都完成了•没有commit口根据日志记录,对每个写操作检查和恢复原值大数据管理系统大数据管理系统®2015陈世敏(chensm@)CPUbufferMainbufferBufferpool•Log:硬盘上日志文件•Logbuffer:在内存中分配一个缓冲区大数据管理系统大数据管理系统®2015陈世敏(chensm@)11CPUbufferMainmemoryBufferpoolcrash大数据管理系统®2015陈世敏(chensm@CPUbufferMainmemoryBufferpoolcrash大数据管理系统®2015陈世敏(chensm@)•日志写在logbuffer中•当commit时write+flush•这样性能好了,但有什口掉电后,硬盘上数据已经修改,但是log没有记录!TransactionTransaction大数据管理系统®2015陈世敏(chensm@)•系统定期把当前活跃的Transaction信息(tID,earliestLSN)记录在log中loglistlist•Crash后重新启动•从后向前读log,寻找最后一个活跃transaction记录,找到crash时所有活跃的transactions口或者是在这个transactionlist之后–新的transaction的日志记录一定在上述读的过程中已经遇到过了•对于一个Transaction,寻找它的commit日志记录口如果找到,那么这个transact–确保所有的写操作都完成了,读数据页,比较LSN,如果未完成就进行写口如果没找到,那么这个transaction没有完成–根据日志记录,对每个写操作检查和恢复原值CPUMainmemorybufferBufferpool•日志写在logbuffer中•当commit时write+flushlogbuffer•Bufferpool在替代写回一个dirtypage时,必须保证pageLSN之前的所有日志已经flush过了•日志记录一定是先于操作出现在硬盘上大数据管理系统大数据管理系统®2015陈世敏(chensm@)•Logfile不能无限地增长•什么情况下一个日志记录不需要了?口对应的transaction完成了口对应的写操作已经在硬盘上了•如果LSN之前的所有日志记录都不需要了,那么就可以删除口Hotpage问题:一个page经常被更新,总是在bufferpool中,很长时间也不写回硬盘,而硬盘上对应的page很长时间没有更新,使得logtruncation难以进行口定期地把长时间缓存在bufferpool中的dirtypage写回口在log中记录检查点信息口从而帮助logtruncation的实现大数据管理系统®2015陈世敏(chensm@)12大数据管理系统®2015陈世敏(大数据管理系统®2015陈世敏(chensm@)•事务处理•数据仓库口行式与列式数据库•分布式数据库数据仓库vs.事务处理•数据仓库口少数数据分析操作口每个操作访问大量的数据口分析操作以读为主口大量的并发transactions口每个transaction访问很少的数据后端数据仓库数据仓库读取大量数据的分析操作前端大数据管理系统大数据管理系统®2015陈世敏(chensm@)商店信息客户信息商品信息送货方式交易员信息付款方式城市信息商店信息客户信息商品信息送货方式交易员信息付款方式城市信息交易记录大数据管理系统大数据管理系统®2015陈世敏(chensm@)13大数据管理系统®2015陈世敏(大数据管理系统®2015陈世敏(chensm@)•一个很大的facttable,多个dimensiontable大数据管理系统®2015陈世敏(chensm@)•例如,二维的数据立方,记录分组的统计数据时间商品1月2月3月笔记本100015001600平板200025003000手机300031003200•例如,三维的数据立方上海北京笔记本手机select…fromfact,dim1,dim2,…,dimkwhere(dim1.aopval1)and(dim2.bopval2)and(dimk.zopvalk)andjoinkeyconstraintshaving…对fact表进行统计分析大数据管理系统®2015陈世敏(chensm@)•多维的数据表示口适合对趋势的分析口可以从宏观到微观,从微观到宏观•常用操作/drilldown大数据管理系统大数据管理系统®2015陈世敏(chensm@)14大数据管理系统®2015陈世敏(大数据管理系统®2015陈世敏(chensm@)•例如,二维的数据立方Rollup时间维度商品时间1月2月3月笔记本100015001600平板200025003000手机300031003200商品total笔记本4100平板7500手机9300•例如,三维的数据立方上海北京笔记本手机广州total上海北京笔记本大数据管理系统®2015陈世敏(chensm@)概念层级•在一个维度上有可能可以定义层级口商品:品种-具体型号-不同厂家的同类产品•前面的例子口Rollup:在某维上求和,降维口Drilldown:把某维的和分解,增维•还可以对概念层级操作口Rollup:在某维上,从细粒度到粗粒度口Drilldown:在某维上,从粗粒度到细粒度total笔记本4100平板7500手机9300商品商品广州total上海total笔记本4100平板7500手机9300商品商品广州total上海北京笔记本时间维度•例如,二维的数据立方时间维度时间1月2月3月笔记本100015001600平板200025003000手机300031003200•例如,三维的数据立方上海北京笔记本手机大数据管理系统大数据管理系统®2015陈世敏(chensm@)•例如,二维的数据立方时间在某维上选一个值商品2月笔记本1500平板2500手机3100商品1月2月3月笔记本100015001600平板200025003000手机300031003200•例如,三维的数据立方上海北京笔记本广州2月上海北京笔记本大数据管理系统大数据管理系统®2015陈世敏(chensm@)15笔记本大数据管理系统®2015陈世敏(chensm@笔记本大数据管理系统®2015陈世敏(chensm@)•例如,二维的数据立方时间在多维上选多个值商品时间1月2月笔记本10001500平板20002500商品1月2月3月笔记本100015001600平板200025003000手机300031003200•例如,三维的数据立方上海北京上海北京笔记本张飞貂蝉孙权关羽赵云男女男男男计算机经管法律计算机计算机Year列式数据存储•每个列产生一个文件,存储所有记录中该列的值BirthdayYear张飞男计算机貂蝉女经管孙权男法律关羽男计算机赵云男计算机存储为7个列文件Birthday大数据管理系统®2015陈世敏(chensm@)行式数据存储tupletuplecolumn1column1•每个记录中把所有的列相邻地存放•优点口多个列的值,可以一次I/O都得到口适合于OLTP,同时需要读写同一个记录的多个列的值•对于数据分析操作有什么问题?只使用少数列大数据管理系统®2015陈世敏(chensm@)张飞貂蝉孙权关羽赵云男女男男男计算机经管法律计算机计算机Year•数据仓库的分析查询口大部分情况只涉及一个表的少数几列口会读一大部分记录•在这种情况下,行式存储需要读很多无用的数据•采用列式存储可以降低读的数据量Birthday大数据管理系统®2015陈世敏(chensm@)16可以有多种简单的方法压缩大数据管理系统可以有多种简单的方法压缩大数据管理系统®2015陈世敏(chensm@)列式存储的压缩•每个文件存储相同数据类型的值•数据更容易被压缩•比行式存储有更高的压缩比Year•思路1口数据存储两份,一份行式,一份列式(FracturedMirrors)•思路2口如果多个列总是一起使用口那么就把它们存在一起大数据管理系统®2015陈世敏(chensm@)张飞貂蝉张飞貂蝉孙权关羽赵云Year•如果用到了一个表的多个列•多列需要拼装在一起,付出拼装代价Join计算机经管法律计算机计算机大数据管理系统®2015陈世敏(chensm@)•事务处理•数据仓库•分布式数据库口分布式查询处理口分布式事务处理大数据管理系统大数据管理系统®2015陈世敏(chensm@)17大数据管理系统®2015陈世敏(chensm@)三种架构大数据管理系统®2015陈世敏(chensm@)三种架构口多机连接相同的数据存储设备口普通意义上的机群系统口由以太网连接多台服务器后端后端后端后端后端大数据管理系统®2015陈世敏(chensm@)前端•一个coordinator运行前端产生并行的queryplan•每台worker服务器上都有后端•Coordinator协调worker服务器执行•系统架构•关键技术大数据管理系统大数据管理系统®2015陈世敏(chensm@)口把数据分布在多台服务器上•通常采用Horizontalpartitioning口把不同的记录分布在不同的服务器上大数据管理系统大数据管理系统®2015陈世敏(chensm@)18大数据管理系统®2015陈世敏(chensm@)前端后端后端后端后端后端口每台服务器负责一个key的区间,所有区间都不重叠大数据管理系统大数据管理系统®2015陈世敏(chensm@)前端后端后端后端后端后端口每台服务器负责一个key的区间,所有区间都不重叠大数据管理系统®2015陈世敏(chensm@)前端后端后端后端后端后端可以并行执行,每台机器单机join•其它情况?前端后端后端后端后端后端写Join可以并行执行吗?大数据管理系统大数据管理系统®2015陈世敏(chensm@)RS•进行分布式partitioning,然后再join•可以优化吗?大数据管理系统大数据管理系统®2015陈世敏(chensm@)19•思路:把没有匹配的记录尽量先过滤掉,从而节省通信开销•方法:•用S.b对R进行过滤这样的操作叫

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论