精华内容
下载资源
问答
  • HDFS数据存储模式

    千次阅读 2019-04-08 16:23:40
    HDFS(Hadoop Distributed File System)是Hadoop分布式计算中的数据存储系统,是基于流数据模式访问和处理超大文件的需求而开发的。下面我们首先介绍HDFS中的一些基础概念,然后介绍HDFS中读写操作的过程,最后分析...

    Hadoop中HDFS的存储机制

    HDFS(Hadoop Distributed File System)是Hadoop分布式计算中的数据存储系统,是基于流数据模式访问和处理超大文件的需求而开发的。下面我们首先介绍HDFS中的一些基础概念,然后介绍HDFS中读写操作的过程,最后分析了HDFS的优缺点。

    1. HDFS中的基础概念

    Block:HDFS中的存储单元是每个数据块block,HDFS默认的最基本的存储单位是64M的数据块。和普通的文件系统相同的是,HDFS中的文件也是被分成64M一块的数据块存储的。不同的是,在HDFS中,如果一个文件大小小于一个数据块的大小,它是不需要占用整个数据块的存储空间的。

    NameNode:元数据节点。该节点用来管理文件系统中的命名空间,是master。其将所有的为了见和文件夹的元数据保存在一个文件系统树中,这些信息在硬盘上保存为了:命名空间镜像(namespace image)以及修改日志(edit log),后面还会讲到。此外,NameNode还保存了一个文件包括哪些数据块,分布在哪些数据节点上。然而,这些信息不存放在硬盘上,而是在系统启动的时候从数据节点收集而成的。

    DataNode:数据节点。是HDFS真正存储数据的地方。客户端(client)和元数据节点(NameNode)可以向数据节点请求写入或者读出数据块。此外,DataNode需要周期性的向元数据节点回报其存储的数据块信息。

    Secondary NameNode:从元数据节点。从元数据节点并不是NameNode出现问题时候的备用节点,它的主要功能是周期性的将NameNode中的namespace image和edit log合并,以防log文件过大。此外,合并过后的namespace image文件也会在Secondary NameNode上保存一份,以防NameNode失败的时候,可以恢复。

    edit log:修改日志。当文件系统客户端client进行------写------操作的时候,我们就要把这条记录放在修改日志中。在记录了修改日志后,NameNode则修改内存中的数据结构。每次写操作成功之前,edit log都会同步到文件系统中。

    fsimage:命名空间镜像。它是内存中的元数据在硬盘上的checkpoint。当NameNode失败的时候,最新的checkpoint的元数据信息就会从fsimage加载到内存中,然后注意重新执行修改日志中的操作。而Secondary NameNode就是用来帮助元数据节点将内存中的元数据信息checkpoint到硬盘上的。

    2. HDFS中文件读写操作流程

    在HDFS中,文件的读写过程就是client和NameNode以及DataNode一起交互的过程。我们已经知道NameNode管理着文件系统的元数据,DataNode存储的是实际的数据,那么client就会联系NameNode以获取文件的元数据,而真正的文件读取操作是直接和DataNode进行交互的。

    写文件的过程:

    客户端调用create()来创建文件DistributedFileSystem用RPC调用元数据节点,在文件系统的命名空间中创建一个新的文件。元数据节点首先确定文件原来不存在,并且客户端有创建文件的权限,然后创建新文件。DistributedFileSystem返回DFSOutputStream,客户端用于写数据。客户端开始写入数据,DFSOutputStream将数据分成块,写入data queue。Data queue由Data Streamer读取,并通知元数据节点分配数据节点,用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。DFSOutputStream为发出去的数据块保存了ack queue,等待pipeline中的数据节点告知数据已经写入成功。如果数据节点在写入的过程中失败:

    关闭pipeline,将ack queue中的数据块放入data queue的开始。
    当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示,则错误节点重启后能够察觉其数据块是过时的,会被删除。
    失败的数据节点从pipeline中移除,另外的数据块则写入pipeline中的另外两个数据节点。
    元数据节点则被通知此数据块是复制块数不足,将来会再创建第三份备份。
    当客户端结束写入数据,则调用stream的close函数。此操作将所有的数据块写入pipeline中的数据节点,并等待ack queue返回成功。最后通知元数据节点写入完毕。

    读取文件的过程:

    客户端(client)用FileSystem的open()函数打开文件DistributedFileSystem用RPC调用元数据节点,得到文件的数据块信息。对于每一个数据块,元数据节点返回保存数据块的数据节点的地址。DistributedFileSystem返回FSDataInputStream给客户端,用来读取数据。客户端调用stream的read()函数开始读取数据。DFSInputStream连接保存此文件第一个数据块的最近的数据节点。Data从数据节点读到客户端(client)当此数据块读取完毕时,DFSInputStream关闭和此数据节点的连接,然后连接此文件下一个数据块的最近的数据节点。当客户端读取完毕数据的时候,调用FSDataInputStream的close函数。 在读取数据的过程中,如果客户端在与数据节点通信出现错误,则尝试连接包含此数据块的下一个数据节点。失败的数据节点将被记录,以后不再连接。

    3. HDFS的优缺点分析

    优点:

    1)能够处理超大的文件;

    2)流式访问数据。HDFS能够很好的处理“一次写入,多次读写”的任务。也就是说,一个数据集一旦生成了,就会被复制到不同的存储节点中,然后响应各种各样的数据分析任务请求。在多数情况下,分析任务都会涉及到数据集中的大部分数据。所以,HDFS请求读取整个数据集要比读取一条记录更加高效。

    3)可以运行在比较廉价的商用机器集群上。

    缺点和改进策略:

    1)不适合低延迟数据访问:HDFS是为了处理大型数据集分析任务的,主要是为达到大数据分析,所以延迟时间可能会较高。改进策略:对于那些有低延时要求的应用程序,HBase是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升,它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力,以减少延时。还有就是对HDFS系统内部的修改,这就得权衡大吞吐量与低延时了。

    2)无法高效存储大量小文件:因为Namenode把文件系统的元数据放置在内存中,所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说,每一个文件、文件夹和Block需要占据150字节左右的空间,所以,如果你有100万个文件,每一个占据一个Block,你就至少需要300MB内存。当前来说,数百万的文件还是可行的,当扩展到数十亿时,对于当前的硬件水平来说就没法实现了。还有一个问题就是,因为Map task的数量是由splits来决定的,所以用MR处理大量的小文件时,就会产生过多的Maptask,线程管理开销将会增加作业时间。举个例子,处理10000M的文件,若每个split为1M,那就会有10000个Maptasks,会有很大的线程开销;若每个split为100M,则只有100个Maptasks,每个Maptask将会有更多的事情做,而线程的管理开销也将减小很多。改进策略:要想让HDFS能处理好小文件,有不少方法。利用SequenceFile、MapFile、Har等方式归档小文件,这个方法的原理就是把小文件归档起来管理,HBase就是基于此的。对于这种方法,如果想找回原来的小文件内容,那就必须得知道与归档文件的映射关系。横向扩展,一个Hadoop集群能管理的小文件有限,那就把几个Hadoop集群拖在一个虚拟服务器后面,形成一个大的Hadoop集群。google也是这么干过的。多Master设计,这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计,还支持Master的Failover,而且Block大小改为1M,有意要调优处理小文件啊。
    附带个Alibaba DFS的设计,也是多Master设计,它把Metadata的映射存储和管理分开了,由多个Metadata存储节点和一个查询Master节点组成。

    3)不支持多用户写入以及任意修改文件:在HDFS的一个文件中只有一个写入者,而且写操作只能在文件末尾完成,即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作,以及在文件任意位置进行修改。

    展开全文
  • Rolap的数据存储模式

    2013-07-09 07:34:08
    常见三种数据存储模式:星型模式、雪花模式、宽表模式 其中雪花模式很少用,个人认为,这种模式基本是以oltp的规范来做olap的设计,实际使用过程中存在诸多问题,实用性不强。 宽表模式是目前我用的比较多的,即...

    常见三种数据存储模式:星型模式、雪花模式、宽表模式

    其中雪花模式很少用,个人认为,这种模式基本是以oltp的规范来做olap的设计,实际使用过程中存在诸多问题,实用性不强。

    宽表模式是目前我用的比较多的,即所有的维度都是退化维。整个cube转化成为一张宽表,维度表可有可无。这种方式在以前是无法实现的,因为表太大太宽(行数可能达到亿级,列数可以达到几百列),即便以oracle这样强大的数据库管理系统都很难支撑这种表的查询。但是在大数据技术逐渐普及的今天,列式数据库和索引技术的发展,给这种大表的olap查询提供可能,我们目前使用的基于solr的改进方案,查询大表的响应时间非常短,毫秒级的。

    星型模式是传统关系型数据库中占主流的物理存储模式。事实表与维表连接整个模式看起来像星状物而得名。

    维度表:包含表示维度的列。通常不符合第三范式的要求,可以通过支架表来扩展为雪花模型,并符合第3范式。

    事实表:事实+维度表代理键,事实表中的外键通常区分事实表中唯一的行。事实表中的行存储特定级别的细节的事实。细节的级别成为事实表的粒度。

    典型的星型模式:

     

    rolap的查询使用mdx语法进行组织,下图是一个MDX查询的过程(来自msdn)

     

    一个简单的mdx查询过程分解为sql:

     

    展开全文
  • Redis中数据存储模式有2种:cache-only,persistence; cache-only即只做为“缓存”服务,不持久数据,数据在服务终止后将消失,此模式下也将不存在“数据恢复”的手段,是一种安全性低/效率高/容易扩展的方式; ...

    Redis中数据存储模式有2种:cache-only,persistence;

    • cache-only即只做为“缓存”服务,不持久数据,数据在服务终止后将消失,此模式下也将不存在“数据恢复”的手段,是一种安全性低/效率高/容易扩展的方式;
    • persistence即为内存中的数据持久备份到磁盘文件,在服务重启后可以恢复,此模式下数据相对安全。

    对于persistence持久化存储,Redis提供了两种持久化方法:

    • Redis DataBase(简称RDB)
    • Append-only file (简称AOF)

    除了这两种方法,Redis在早起的版本还存在虚拟内存的方法,现在已经被废弃。

    一、RDB概述

    RDB是在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。
    优点:使用单独子进程来进行持久化,主进程不会进行任何IO操作,保证了redis的高性能
    缺点:RDB是间隔一段时间进行持久化,如果持久化之间redis发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

    这里说的这个执行数据写入到临时文件的时间点是可以通过配置来自己确定的,通过配置redis在n秒内如果超过m个key被修改这执行一次RDB操作。这个操作就类似于在这个时间点来保存一次Redis的所有数据,一次快照数据。所有这个持久化方法也通常叫做snapshots。

    RDB默认开启,redis.conf中的具体配置参数如下;

    #dbfilename:持久化数据存储在本地的文件
    dbfilename dump.rdb
    #dir:持久化数据存储在本地的路径,如果是在/redis/redis-3.0.6/src下启动的redis-cli,则数据会存储在当前src目录下
    dir ./
    ##snapshot触发的时机,save <seconds> <changes>  
    ##如下为900秒后,至少有一个变更操作,才会snapshot  
    ##对于此值的设置,需要谨慎,评估系统的变更操作密集程度  
    ##可以通过“save “””来关闭snapshot功能  
    #save时间,以下分别表示更改了1个key时间隔900s进行持久化存储;更改了10个key300s进行存储;更改10000个key60s进行存储。
    save 900 1
    save 300 10
    save 60 10000
    ##当snapshot时出现错误无法继续时,是否阻塞客户端“变更操作”,“错误”可能因为磁盘已满/磁盘故障/OS级别异常等  
    stop-writes-on-bgsave-error yes  
    ##是否启用rdb文件压缩,默认为“yes”,压缩往往意味着“额外的cpu消耗”,同时也意味这较小的文件尺寸以及较短的网络传输时间  
    rdbcompression yes  

    snapshot触发的时机,是有“间隔时间”和“变更次数”共同决定,同时符合2个条件才会触发snapshot,否则“变更次数”会被继续累加到下一个“间隔时间”上。snapshot过程中并不阻塞客户端请求。snapshot首先将数据写入临时文件,当成功结束后,将临时文件重名为dump.rdb。

    使用RDB恢复数据:
    自动的持久化数据存储到dump.rdb后。实际只要重启redis服务即可完成(启动redis的server时会从dump.rdb中先同步数据)

    客户端使用命令进行持久化save存储:

    ./redis-cli -h ip -p port save
    ./redis-cli -h ip -p port bgsave

    一个是在前台进行存储,一个是在后台进行存储。我的client就在server这台服务器上,所以不需要连其他机器,直接./redis-cli bgsave。由于redis是用一个主线程来处理所有 client的请求,这种方式会阻塞所有client请求。所以不推荐使用。另一点需要注意的是,每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。

    二、AOF概述

    Append-only file,将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部,在append操作返回后(已经写入到文件或者即将写入),才进行实际的数据变更,“日志文件”保存了历史所有的操作过程;当server需要数据恢复时,可以直接replay此日志文件,即可还原所有的操作过程。AOF相对可靠,它和mysql中bin.log、apache.log、zookeeper中txn-log简直异曲同工。AOF文件内容是字符串,非常容易阅读和解析。
    优点:可以保持更高的数据完整性,如果设置追加file的时间是1s,如果redis发生故障,最多会丢失1s的数据;且如果日志写入不完整支持redis-check-aof来进行日志修复;AOF文件没被rewrite之前(文件过大时会对命令进行合并重写),可以删除其中的某些命令(比如误操作的flushall)。
    缺点:AOF文件比RDB文件大,且恢复速度慢。

    我们可以简单的认为AOF就是日志文件,此文件只会记录“变更操作”(例如:set/del等),如果server中持续的大量变更操作,将会导致AOF文件非常的庞大,意味着server失效后,数据恢复的过程将会很长;事实上,一条数据经过多次变更,将会产生多条AOF记录,其实只要保存当前的状态,历史的操作记录是可以抛弃的;因为AOF持久化模式还伴生了“AOF rewrite”。
    AOF的特性决定了它相对比较安全,如果你期望数据更少的丢失,那么可以采用AOF模式。如果AOF文件正在被写入时突然server失效,有可能导致文件的最后一次记录是不完整,你可以通过手工或者程序的方式去检测并修正不完整的记录,以便通过aof文件恢复能够正常;同时需要提醒,如果你的redis持久化手段中有aof,那么在server故障失效后再次启动前,需要检测aof文件的完整性。

    AOF默认关闭,开启方法,修改配置文件reds.conf:appendonly yes

    ##此选项为aof功能的开关,默认为“no”,可以通过“yes”来开启aof功能  
    ##只有在“yes”下,aof重写/文件同步等特性才会生效  
    appendonly yes  
    
    ##指定aof文件名称  
    appendfilename appendonly.aof  
    
    ##指定aof操作中文件同步策略,有三个合法值:always everysec no,默认为everysec  
    appendfsync everysec  
    ##在aof-rewrite期间,appendfsync是否暂缓文件同步,"no"表示“不暂缓”,“yes”表示“暂缓”,默认为“no”  
    no-appendfsync-on-rewrite no  
    
    ##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite,默认“64mb”,建议“512mb”  
    auto-aof-rewrite-min-size 64mb  
    
    ##相对于“上一次”rewrite,本次rewrite触发时aof文件应该增长的百分比。  
    ##每一次rewrite之后,redis都会记录下此时“新aof”文件的大小(例如A),那么当aof文件增长到A*(1 + p)之后  
    ##触发下一次rewrite,每一次aof记录的添加,都会检测当前aof文件的尺寸。  
    auto-aof-rewrite-percentage 100  

    AOF是文件操作,对于变更操作比较密集的server,那么必将造成磁盘IO的负荷加重;此外linux对文件操作采取了“延迟写入”手段,即并非每次write操作都会触发实际磁盘操作,而是进入了buffer中,当buffer数据达到阀值时触发实际写入(也有其他时机),这是linux对文件系统的优化,但是这却有可能带来隐患,如果buffer没有刷新到磁盘,此时物理机器失效(比如断电),那么有可能导致最后一条或者多条aof记录的丢失。通过上述配置文件,可以得知redis提供了3中aof记录同步选项:

    • always:每一条aof记录都立即同步到文件,这是最安全的方式,也以为更多的磁盘操作和阻塞延迟,是IO开支较大。
    • everysec:每秒同步一次,性能和安全都比较中庸的方式,也是redis推荐的方式。如果遇到物理服务器故障,有可能导致最近一秒内aof记录丢失(可能为部分丢失)。
    • no:redis并不直接调用文件同步,而是交给操作系统来处理,操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步;这是一种普通的文件操作方式。性能较好,在物理服务器故障时,数据丢失量会因OS配置有关。

    其实,我们可以选择的太少,everysec是最佳的选择。如果你非常在意每个数据都极其可靠,建议你选择一款“关系性数据库”吧。
    AOF文件会不断增大,它的大小直接影响“故障恢复”的时间,而且AOF文件中历史操作是可以丢弃的。AOF rewrite操作就是“压缩”AOF文件的过程,当然redis并没有采用“基于原aof文件”来重写的方式,而是采取了类似snapshot的方式:基于copy-on-write,全量遍历内存中数据,然后逐个序列到aof文件中。因此AOF rewrite能够正确反应当前内存数据的状态,这正是我们所需要的;*rewrite过程中,对于新的变更操作将仍然被写入到原AOF文件中,同时这些新的变更操作也会被redis收集起来(buffer,copy-on-write方式下,最极端的可能是所有的key都在此期间被修改,将会耗费2倍内存),当内存数据被全部写入到新的aof文件之后,收集的新的变更操作也将会一并追加到新的aof文件中,此后将会重命名新的aof文件为appendonly.aof,此后所有的操作都将被写入新的aof文件。如果在rewrite过程中,出现故障,将不会影响原AOF文件的正常工作,只有当rewrite完成之后才会切换文件,因为rewrite过程是比较可靠的。*

    触发rewrite的时机可以通过配置文件来声明,同时redis中可以通过bgrewriteaof指令人工干预。

    redis-cli -h ip -p port bgrewriteaof

    因为rewrite操作/aof记录同步/snapshot都消耗磁盘IO,redis采取了“schedule”策略:无论是“人工干预”还是系统触发,snapshot和rewrite需要逐个被执行。

    AOF rewrite过程并不阻塞客户端请求。系统会开启一个子进程来完成。

    三.总结:

    AOF和RDB各有优缺点,这是有它们各自的特点所决定:

    • 1) AOF更加安全,可以将数据更加及时的同步到文件中,但是AOF需要较多的磁盘IO开支,AOF文件尺寸较大,文件内容恢复数度相对较慢。
      *2) snapshot,安全性较差,它是“正常时期”数据备份以及master-slave数据同步的最佳手段,文件尺寸较小,恢复数度较快。

    可以通过配置文件来指定它们中的一种,或者同时使用它们(不建议同时使用),或者全部禁用,在架构良好的环境中,master通常使用AOF,slave使用snapshot,主要原因是master需要首先确保数据完整性,它作为数据备份的第一选择;slave提供只读服务(目前slave只能提供读取服务),它的主要目的就是快速响应客户端read请求;但是如果你的redis运行在网络稳定性差/物理环境糟糕情况下,建议你master和slave均采取AOF,这个在master和slave角色切换时,可以减少“人工数据备份”/“人工引导数据恢复”的时间成本;如果你的环境一切非常良好,且服务需要接收密集性的write操作,那么建议master采取snapshot,而slave采用AOF。

    下面关于Redis的文章您也可能喜欢,不妨参考下:

    Ubuntu 14.04下Redis安装及简单测试 http://www.linuxidc.com/Linux/2014-05/101544.htm

    Redis主从复制基本配置 http://www.linuxidc.com/Linux/2015-03/115610.htm

    Redis集群明细文档 http://www.linuxidc.com/Linux/2013-09/90118.htm

    Redis系列-安装部署维护篇 http://www.linuxidc.com/Linux/2012-12/75627.htm

    CentOS 6.3安装Redis http://www.linuxidc.com/Linux/2012-12/75314.htm

    Redis安装部署学习笔记 http://www.linuxidc.com/Linux/2014-07/104306.htm

    Redis配置文件redis.conf 详解 http://www.linuxidc.com/Linux/2013-11/92524.htm

    Redis 的详细介绍请点这里
    Redis 的下载地址请点这里

    本文永久更新链接地址http://www.linuxidc.com/Linux/2016-10/136352.htm

    展开全文
  • Oracle与DB2数据存储模式的相关知识是本文我们主要要介绍的内容,接下来就让我们一起来了解一下这部分内容吧。“Oracle的普通表即堆表,存储数据时没有顺序可言,而Oracle的索引组织表是根据主键顺序来存储表中的...
    Oracle与DB2数据存储模式的相关知识是本文我们主要要介绍的内容,接下来就让我们一起来了解一下这部分内容吧。“Oracle的普通表即堆表,存储数据时没有顺序可言,而Oracle的索引组织表是根据主键顺序来存储表中的数据的。”
      记得第一次得知Oracle的这个特性时,几欲昏倒,不啻是对数据库世界观的颠覆。意识到原来这两种主流的RDBMS竟然能有如此大的区别。对于Oracle而言,大多数表的数据存储是没有顺序的;而对于DB2,大多数表的数据存储是按照聚簇索引(Cluster Indxe)来排序的,也就是说,DB2中大多数的表按照Oracle的分类规则都属于索引组织表。

      对于DB2,唯一的例外情况就是这个表没有索引——只要哪怕有一个索引,即便这个索引没有被显式地指定为Cluster Index,DB2仍然会尽量按照这个索引的键顺序来存储表中的数据。

    “对于普通表而言,Oracle保证数据插入到表中之后,数据的物理地址ROWID不会再发生改变。当然对表进行MOVE,或者ENABLE ROW MOVEMENT之后对分区表的分区键值进行修改等明确导致表数据位置发生变化的操作除外。也就是说,普通的增、删、改不会导致现有记录的物理地址发生变化。
      即使记录的长度发生了变化,导致当前数据块中无法容纳这条记录,Oracle也会在原位置上留下一个ROWID信息,通过这个ROWID信息可以找到这条记录的新的位置。这也就是行迁移、行链接的实现方式。虽然增加了额外的IO,但是确保了ROWID不发生变化。“
      这就是所谓的Position Update,即普通的Update不会改变记录的物理位置。当然也有例外,那就是:

    1,记录所属表分区改变,那么记录肯定要移动到目标分区对应的物理文件中,位置改变在所难免;
      2,记录本身是变长记录,这里的变长是指“物理变长”,不仅指含有变长字段(Variable Length)的记录,而且也指表属性为COMPRESS YES的记录(因为DB2 z的DATA COMPRESS是ROW COMPRESS),当变长记录Update时,物理长度可能会变化,通常缩短都没问题,仍然可以做到Position Update,但是如果增长的话,有可能原来的物理位置没有足够的空间存放增长后的记录,所以记录只能重新去寻找一个合适的空间安身,而在原来的物理位置存放一个指向新位置的指针(当然,指针本身肯定很短,原位置足够存放得下),这就称为Overflow.
      也就是原来ROWID指向的物理位置是一个指针,指针指向新位置(或者也可能指向另一个指针,但最终会指向记录实际的物理位置,从而形成一个较长的指针链(Pointer Chain),当然这种情况对性能的伤害会更大)。
      “可以看到,前面提到的MOVE,以及一些导致ROWID发生变化的分区操作,在使得ROWID变化的同时,也会导致索引处于不可用状态。”

    问题来了。ROWID变化怎么会导致索引处于不可用状态呢?在DB2中,记录的物理位置变化,或者ROWID的改变,对应的Index Entry会跟着改变。换句话说,如果一个update涉及索引字段(index key columns)的改变,那么这个update至少包含两部分内容,即对表的更新和对索引的更新。
      “那么现在存在一个问题,对于索引组织表而言,为了保证数据存储是根据主键顺序进行的,就必须根据数据的增、删、改随时调整表中数据的位置,这使得ROWID不发生改变这个前提无法实现。而对于索引组织表,第二个索引需要一个方法来找到表中数据的具体位置,因此也就有了逻辑ROWID.”

    技术的差异体现在这里了。对索引组织表,Oracle严格保证数据存储按索引顺序排列,也就是说在记录修改时,在前端就调整记录的位置。而DB2则不然,DB2是尽量去保证数据按照索引顺序排列(聚簇),但并不严格和强求,记录如果不能存放到最佳位置(按索引排序的理想位置),可以存放到附近的次佳位置或偏离最佳位置更远。随着记录修改越多,聚簇的效率(Cluster Ratio)也就越差,所以需要重组(REORG utility),也就是DB2在后端通过重组来调整记录的位置。因此,REORG在DB2中远比Oracle中来的重要。
      然而,在DB2的世界,第二个索引,或者叫次索引(Secondary Index),非聚簇索引(Non-Clustered Index),仍然是通过记录的ROWID来找到记录的物理位置,没有逻辑ROWID的概念。只是,一个聚簇效率完好(Cluster Ratio=100)的索引,从索引的Leaf page上的entry通过ROWID指向数据data page的关系好比是梳理过的,顺序排列的(如下图上方的索引IX所示)。而非聚簇索引的entry到表data page的关系是乱序的(如下图下方的索引IX2所示)。即便重组,也只会使表的记录按照聚簇索引的顺序重新排列,上方索引的Cluster Ratio=100,而不会使下方非聚簇索引的Cluster Ratio有质的改变。


     
      “对于索引组织表,虽然存储位置可能会经常发生变化,但是主键是必须存在的。如果不能通过物理位置来寻找,那么通过主键来查找也可以找到这条记录。不过Oracle的实现并不是这么简单。 逻辑ROWID除了包含表的主键信息外,还包括了这条记录在索引创建时的物理地址信息。关于逻辑ROWID相信结构描述,可以参考:http://yangtingkun.itpub.net/post/468/11363.而这个地址信息,就是用来实现物理猜的。
      如果物理猜能够在目标数据块中找到这条记录,那么这个效率和物理ROWID的效率是一样的,只需要一次IO就找到了目标。如果通过物理猜找不到对应的记录,那么Oracle只能通过逻辑ROWID中包含的主键信息,通过主键扫描来定位这条记录,根据索引的层高,这个操作可能会多消耗几次IO操作。“
      对于DB2,通常情况下,记录的存储位置并不容易发生变化,update也是Position Update为主,尽管这是对cluster规则的一种破坏,但是DB2依靠后端的REORG来进行修复,而换取的好处是记录在前端进行修改的性能。无论是聚簇索引还是非聚簇索引,DB2都通过ROWID来直接定位到记录的物理位置,因此始终是物理ROWID,而无逻辑ROWID的概念。依据引文的观点,Oracle的次索引的逻辑ROWID包含索引创建时记录的物理位置。
      但是,当记录发生多次update后,这个逻辑ROWID能命中的概率会显著下降,不得不借助主键(Primary Key)信息再绕回到聚簇索引上去定位数据记录的位置。这里有两个问题值得注意:
      1,Oracle为了维护cluster规则,记录进行修改时前端的性能会相对较差;
      2,即便这样,cluster规则仍然会被破坏,逻辑ROWID的命中率较低,而必须多做几次I/O,也就是从非聚簇索引再绕回聚簇索引。因此,Oracle对聚簇索引的依赖度更高。
      结论:
      DB2总是通过ROWID来定位记录的物理位置,无论是聚簇索引还是非聚簇索引都一样;Oracle通过聚簇索引的ROWID来定位记录的物理位置,非聚簇索引的ROWID也包含主键信息以利用聚簇索引,但是采用了“物理猜”作为一个捷径,即寄希望于记录的物理位置在非聚簇索引创建后不改变。
      可见,DB2的表数据的存储大多数都是按索引排序的,而Oracle表数据的存储大多数是无序的(这是多么巨大的差异啊)。对这种索引组织表的应用,会有一些限制(比如更适合只读表,等等),而update性能会较差。
      关于Oracle与DB2数据存储模式的区别的相关知识就介绍到这里了,希望本次的介绍能够对您有所收获!

    转自:http://www.2cto.com/database/201109/105115.html


    展开全文
  • Hive的数据存储模式

    2014-08-02 15:24:19
    Hive的数据分为表数据和元数据,表数据是Hive中表格(table)... 在《Hive到底是什么》博文中我们提到Hive是基于Hadoop分布式文件系统的,它的数据存储在Hadoop分布式文件系统中。Hive本身是没有专门的数据存储格式
  • 计算机数据存储模式

    2014-04-11 20:42:00
    *计算机存储数据是二进制形式,二进制每8位为一个字节,如你的例子: 十进制  二进制 41715 1010 0010 1111
  • NAS:以数据为中心的数据存储模式(澳柯玛天地数码科技有限公司 2001年05月30日 17:20)计算机给世界的发展带来了巨大的动力。科技的进步,使人们急需从各种地方获得有效的资源。网络时代的发展,加上五彩斑斓的...
  • 由于对关系型数据库有所了解,初次接触hbase时,怎么也不理解hbase的存储模式,反复找资料现在大概了解,以关系型数据库中常用的“学生表”来记录下堆hbase数据存储模式的理解。可能有理解不到位或错误之处,还请...
  • 在InnoDB存储引擎中,所有数据都存放在表空间(tablespace)中,表空间由段(segment)、区(extent)、页(page)、行(Row)组成,它们的关系如下图: 表空间(tablespace) 在MySQL中,所有InnoDB存储引擎表中的数据都...
  • Hive的架构及元数据三种存储模式

    千次阅读 2018-12-19 22:07:09
    Hive的特点Hive的架构元数据存储模式 什么是Hive?   Hive最初是由FaceBook公司开发的一个基于Hadoop框架并且开源的一个数据仓库工具,后贡献给了Apache基金会由Apache来进行维护和更新。Hive可以将结构化的文件...
  • 改变数据存储模式

    2013-08-12 17:04:28
    改变数据存储模式,如将一个整数的大端存储模式改为小端存储模式或将一个整数的小端存储模式改为大端存储模式 做法就是,用一个临时变量反序存储参数中的内容,然后将这个变量再赋值给原参数,可以用引用,这样就...
  • 键值数据存储模式 文档数据存储模式 列族数据存储模式数据存储模式 其他数据存储模式 尤其键值存储模式是Redis 数据库的基础;文档存储模式是MongoDB数据库的基础。 数据库的主要功能是存储和处理数据,由此NOSQL...
  • Uber无模式数据存储

    千次阅读 2016-03-17 16:16:11
    Uber无模式数据存储设计无模式。Uber工程师使用MySQL定制数据库,允许我们从2014向后扩展。这是无模式三部分系列的第一部分。 在项目Mezzanine中,我们描述了如和从单一Postgres实例迁移Uber核心到无模式、容错以及...
  • Hive的数据分为表数据和...一、Hive的数据存储在让你真正明白什么是hive 博文中我们提到Hive是基于Hadoop分布式文件系统的,它的数据存储在Hadoop分布式文件系统中。Hive本身是没有专门的数据存储格式,也没有为数据建
  • 数据存储大小端模式

    千次阅读 2009-06-04 10:32:00
    所谓的大端模式,是指数据的低位(就是权值较小的后面那几位)保存在内存的高地址中,而数据的高位,保存在内存的低地址中,这样的存储模式有点儿类似于把数据当作字符串顺序处理:地址由小向大增加,而数据从高位往...
  • 因为不同架构的处理器,所以造成了数据在各种处理器中数据存储方式的不同;一般情况下分为两种,一种是大段模式,另外一种是小段模式。通常情况下:x86、ARM,DSP架构处理器都是小端模式,而Motorola为大端模式。 ...
  • 存储模式

    2020-07-12 09:32:19
    存储模式也可以称为面向列的存储模式,在面向列的存储模式中,属于不同列或列族的数据存储在不同的文件中,这些文件可以分布在不同的位置上,甚至不同的节点上。 相比之下,在面向行的存储模式中,数据以行的方式...
  • 前言 对于整型来说:数据存放在内存中其实存放的是补码(深度剖析数据在内存中的存储:...这就和我们今天讨论的主题——大端存储模式和小端存储模式有着密切的关系。 什么是大小端 ...
  • https://www.cnblogs.com/little-white/p/3236548.html
  • SaaS多租户模式数据存储方案

    千次阅读 热门讨论 2015-08-07 14:46:16
    云计算多租户几乎用于所有软件即服务 (Software as a Service, SaaS) 应用程序,因为计算资源是可伸缩的,而且...根据存储在企业网络之外的软件供应商的基础架构上的数据不同,安全需求也在不断增长。应用程序需要多租
  • 本文主要说MTP模式下恢复, USB数据存储&amp;大容量存储模式直接跳到第2步。1、 手机有root权限,用re文件管理器打开data/property/persist.sys.usb.config文件将mtp,adb改为mass_storage 保存后重启手机。...
  • C语言判断数据存储时大端模式还是小端模式 所谓的大端模式,是指数据的低位保存在内存的高地址中,而数据的高位,保存在内存的低地址中; 所谓的小端模式,是指数据的低位保存在内存的低地址中,而数据的...
  •  其为大端模式存储。 2、小端模式  小端模式,是指数据的低字节保存在内存的低地址中,而数据的高字节,保存在内存的高地址中。  例子:  汉字 “液”字的国标码为:D2BA(2个字节),D2...
  • 让你彻底明白hive数据存储各种模式

    千次阅读 2017-04-25 23:31:17
    本帖最后由 pig2 于 2014-5-19 12:59 编辑 问题导读 1.hive数据分为那两种类型? 2.什么表数据? 3.什么是元数据?...4.Hive表里面导入数据的本质什么?...Hive的数据分为表数据和元...而元数据是用来存储表的名字,表
  • 第八章数据存储维护模式 数据存储维护模式类似于主机的维护模式。当数据存储置入维护模式,所有数据存储上注册的虚拟机被迁移到数据存储群集上其它的数据存储。通过调用vCenter数据存储API,存储DRS学习到哪些注册的...
  • 存储数据的大小端模式 1. 比如存储 int a = 0x1234567    Big endian : 大端模式 :内存的低位存数据的高位,内存的高地址存数据的低位。  Little endian:小端模式:内存的低地址存数据的低位,内存的高地址存...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 30,260
精华内容 12,104
关键字:

数据存储模式