关于oracle的缓冲区机制与HDFS中的edit logs的某些关联性的思考

Posted 程序员姜小白

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于oracle的缓冲区机制与HDFS中的edit logs的某些关联性的思考相关的知识,希望对你有一定的参考价值。

可能大家会问,oracle和HDFS属于不同场景的存储系统,它们之间为什么会有联系呢?确实,从技术本身来看,他们确实无关联,但利用“整体学习”的思想,跳出技术本身,可以发现Oracle的缓冲区和HDFS的edit logs都是为了解决频繁IO而出现的,可以解决因频繁读写磁盘而导致性能低的问题。如下图所示:

 

一、Oracle的缓冲区机制

Oracle的缓冲区主要有两种:数据库缓冲区缓存(data buffer cache,后面简称DB chche)和日志缓冲区(redo log)(对oracle实例内存结构感兴趣的同学可自行百度,此处不再过多介绍)。

1.数据库缓冲区缓存(DB Cache)

DB Cache是执行SQL的工作区域,用户会话所有操作数据都是在此缓存中进行,而不是直接操作磁盘。举例来说,当执行select操作时,会先查找DB Cache,如果找到,则直接返回,如果未找到,会再从磁盘加载数据到DB Cache中来,然后再返回。再举个例子,当执行update操作时,其实也只是更新了DB Cache中的数据。如果DB Cache中数据和磁盘中数据不一致,则称此数据为脏数据。

 那么DB Cache的脏数据往磁盘中写入的机制是怎样的呢?Oracle中为此专门有一个数据库写入器的后台进程DBWn,会把DB Cache中的数据写入到磁盘中,当出现以下情况之一时,DBWn会执行写入磁盘操作:

1)没有任何可用DB Cache;

2)脏数据过多; 

3)到达3秒的超时时间; 

4)遇到checkpoint; 

可以看到,DBWn这样写入方式是极懒的,目的就是为了减少IO。

2.日志缓冲区

日志缓冲区是一块小的内存区域,用于存储重做日志文件中的变更向量。当数据库出现故障,导致大量脏数据未来得及写入磁盘时,会根据重做日志文件进行恢复(注意:重做redo和撤销undo是有区别的,不要混淆)。与DBWn一样,重做日志缓冲区也有专门的后台进程LGWR,进行磁盘的写入操作,写入的时机有以下几种情况:

1)commit操作(注意此commit,执行的是重做日志的写入磁盘操作,而不是DB Cache的写入磁盘操作); 

2)日志缓冲区已用超过1/3; 

3)DBWn要写入脏数据(可以想想为什么要这样?原因就在于DBWn可能会将未提交的事务数据写入到磁盘,为了保证这些已写入磁盘的数据可以进行回滚,所以必须也要把对应的重做日志也写入到磁盘中去,其实就是为了事务回滚用的); 

综上,这两类缓冲区都是为了最大限度的减少IO而出现的机制。

二、HDFS的edit logs

 熟悉HDFS namenode启动过程的同学们应该知道,在HDFS namenode启动时,会把fsimage和edit logs加载到namenode的内存中,当namenode需要重启时,会先把内存中的fsimage与edit logs合并写入磁盘后,再重复执行上面的操作(此处edit logs可以认为是namenode的缓冲区,类似于oracle的缓冲区,只是一般不会轻易写磁盘)。因此就会面临如下的问题:

1)当edit logs文件很大时,则namenode的重启时间会过长; 

2)当namenode意外挂掉时,则eidt logs会丢失很多改动;

此时,Secondary namenode就出现了,可以通过定时查询edit logs,然后将edit logs更新到fsimage,再由secondary namenode将更新后的fsimage写入到namenode磁盘,以便下次重启时使用。当然随着Hadoop 2.0以后HA的出现,secondary namenode也被其它HA方案替代了,后面有机会再深入介绍。

综上,oracle的缓冲区与hdfs中的edit logs类似,都是为了防止IO影响性能而出现的,只是写入磁盘的机制不同,但思想可以认为是一致的。

以上是关于关于oracle的缓冲区机制与HDFS中的edit logs的某些关联性的思考的主要内容,如果未能解决你的问题,请参考以下文章

HDFS重要概念

HDFS的Checkpoint机制

十HDFS的namenode工作机制

HDFS元数据管理:fsimage&edits

Hadoop概念补充

HDFS:edit log & fsimage