当前位置:K88软件开发文章中心编程全书编程全书01 → 文章内容

达梦数据库的大对象存取优化

减小字体 增大字体 作者:佚名  来源:翔宇亭IT乐园  发布时间:2019-1-3 2:25:06

这个值适当扩大。显然,从表记录允许存放的大对象体积越大,大对象存取的时间越短,空间利用率也越高。为此,可以考虑将从表中大对象体积的最大值放大到一个极限的位置。下面讨论这个极限值如何确定。

  达梦数据库对记录大小的限制是,系统内部任何物理记录的最大值不能超过块长一半。这种规定是为了确保一条物理记录只在一个物理块中,保证一个B树节点至少有两条物理记录,避免B树退化成链表结构。由此可知,从表中记录的大小不能超过块长一半。由于大对象从表的结构中,前三个字段的大小取值是固定的,因此,在从表记录大小不超过块长一半的前提下,能够精确地计算出从表记录中大对象体积的最大值。计算方法在此从略。显然,通过扩大从表记录中大对象体积的最大值,可以减少大对象分片和分片重组的时间,提高空间利用率。

  2.2 大对象写日志机制的优化

  分析写日志机制可以看出,插入大对象数据到从表中时,为每一条物理记录生成完整的redo日志记录是没有必要的。一种可行的优化思路是:

  1.在redo日志记录中只保存从表物理记录的rowid,colid和fraid字段,而不需要DATA字段既大对象数据。这种做法由于不用保存大对象数据,减少了redo日志的数据量,提高了写日志的速度,进而减少大对象数据插入所消耗的时间。

  2.记录插入过程中,保存了从表物理记录的数据块的块号,在大对象插入结束之后,事务提交之前,首先将插入操作生成的redo日志刷盘,然后将这些块刷盘。

  显然,这种redo日志优化方法将提高大对象插入的效率。下面从对事务的redo和undo操作两个方面来说明这种优化方法可以保证数据的正确性。

  1.对于在故障前已提交的事务,故障恢复时需要恢复而不是撤销事务对数据库的更新操作。在系统重启后,由于上次系统运行时往从表中插入的物理记录已经在事务提交之前被刷盘,所以此时(既系统重启后)从表中的记录都是完整和正确的,此时再使用redo日志记录来覆盖物理记录,只不过是将物理记录的前三个字段重新写入数据块而已,不会造成数据的丢失,虽然redo日志记录并没有记录大对象数据。

  2.对于在故障前未提交的事务,故障恢复时需要撤销事务对数据库的改动。此时,首先打开redo日志文件,从事务的开始点出发,正向扫描redo日志文件,使用redo日志记录中的rowid,colid和fraid替换表中的相应物理记录的这三个字段,直到故障发生的地方停止替换。然后再使用undo日志文件从故障发生的地方开始,反向利用回滚记录将具有与回滚记录相同rowid和colid的物理记录恢复到事务开始前的状态。这样,事务对从表的插入操作被成功撤销。

  由此可见,采用这种方法完全可以在系统发生故障后保证数据的正确性。这种优化方案是完全可行的。优化方案的具体做法如下:

  (1)修改redo日志生成机制。优化前的系统对从表的insert操作,为物理页上的所有改动生成日志记录并写入日志文件。优化后,RREC记录上只记录不包含分片数据的其他修改;

  (2)将大对象插入到从表时记录被修改的从表数据页号;

  (3)往从表插入一个大对象结束以后,将redo日志刷盘;

  (4)将redo日志刷盘后,将插入过程中修改的从表数据页全部刷盘。

  2.3 写日志机制优化的补充说明

  完成redo日志优化的优化工作后,在性能测试中我们发现,对redo日志生成机制进行优化并不能百分百地减少大对象插入的时间。当插入的大对象数据量较小时,优化后插入所消耗的时间反而要大于优化前。出现这种现象的原因是,优化后,每插入一个大对象数据都需要将从表中的相应数据页刷盘,刷盘将引起大量I/O操作,这将为日志生成增加额外的时间,数据量小的情况下,增加的时间将超过由于优化减少的时间。

  针对这个问题,我们设计了以下解决方案:

  (1)由应用系统开发人员来决定是否需要对大对象存储进行日志生成优化。如果需要存储的大对象数据量不是很大(建议值为小于100K),可以指定不进行日志优化,如果需要存储的大对象数据量比较大,可以指定进行日志优化。

  (2)系统中增加一个存储过程,用户可以调用此存储过程来指定是否对日志生成进行优化。

  (3)如果要插入的大对象数据类型是TEXT,系统默认不对日志进行优化,如果插入的大对象数据类型是BLOB,系统默认对日志进行优化。

  3.优化前后的测试结果

  最后给出优化前后的测试对比结果。由于本次优化工作的目标是缩小DM5.6相对于Oracle9i在大对象存取效率上的差异,因此首先给出优化前的DM5.6与Oracle9i的大对象存取速度对比结果,然后给出DM5.6优化前后的大对象存取速度对比结果。通过比较Oracle9i和优化后的DM5.6在在大对象存取速度上相对于优化前DM5.6的提升率,可以间接比较Oracle9i和优化后的DM5.6在大对象存取上的时间效率的差异。

  3.1 优化前DM与Oracle的大对象存取性能对比

  (1)相关配置说明

  硬件配置:

  CPU(个数) Pentium cpu 2.66GHz

  内存 1G

  操作系统 WINXP

  数据库版本:

  ORACLE ORACLE 9i

  DM 优化前的DM5.6

  内部参数:

  ORACLE 默认配置

  DM 默认配置

  测试数据:

  大对象数据采用大小为5M 的MPG格式文件。测试时,分别往数据库中插入1-64条,共5-320MB大对象数据。测试结果取三次的平均值。

  (2)ODBC方式插入大对象

  测试程序采用ODBC方式连接数据库,每插入一条数据便提交一次事务。首先给出优化前的DM5.6与Oracle9i的大对象插入速度对比结果。

  图1 优化前的DM5.6和Oracle9i的大对象插入速度对比

  (3)ODBC方式读取大对象

  接下来给出优化前的DM5.6与Oracle9i的大对象读取速度对比结果。

  图2 优化前的DM5.6和Oracle9i的大对象读取速度对比

  3.2 优化前后DM大对象存取性能对比

  (1)相关配置说明

  硬件配置:

  CPU(个数) 酷睿双核1.6GHz

  内存 1G

  操作系统 WINXP

  数据库版本:

  DM 优化前的DM5.6

  DM 优化后的DM5.6

  内部参数:

  ORACLE 默认配置

  DM 默认配置

  测试数据:

  在内存中生成1MB的大对象数据,测试时往数据库中插入1-500条大对象记录。测试结果取三次的平均值。

  (2)ODBC方式插入大对象

  测试程序采用ODBC方式连接数据库,每插入一条数据便提交一次事务。首先给出优化前后的DM5.6大对象插入速度对比结果。

  图3 优化前后的DM5.6大对象插入速

上一页  [1] [2] [3]  下一页


达梦数据库的大对象存取优化