DTS开发记录(5)-- 挑战增量导出

    增量导出恐怕是DTS系统中最艰难的部分了,我们曾考虑过很多方案,最后都因为需要表大纲做一定的假设而不具备通用性而放弃。有很多效率较高的方案,由于为了追求通用性而无法实现,因为现实的情况比我们理想的要复杂许多。
    下面将列举我们曾考虑的几种主要方案,这些方案乍一看似乎都很有希望,可通过层层分析,最后都因为复杂的现实情况而胎死腹中。

1.触发器
    这是一个非常简单直接的解决方案,我们只需要将DTS引擎驻留在比如windows服务中,该引擎通过数据库的触发器事件获取源表数据更新的所有情况,即增量,然后相应的更新目的表。然而,由谁来创建触发器了?
    我们DTS系统的任务是将数据从一个表迁移到另外一个表,它所拥有的权限是:
(1)读取源表
(2)读写目的表
    我们没有创建触发器的权限,更别说接收触发器的事件了。
    触发器方案马上被否决!

2.查询数据库的增量记录
    触发器方案被否决后,我们退而求其次,我们希望所有的数据库都提供了某种机制,能让我们查询指定表的增量记录。比如,我们给出一个时间段和指定表的名称,调用数据库的某个函数或存储过程或扩展SQL命令,数据库返回一个结果数据集,这个数据集中包含了指定的时间段内,指定表中有哪些数据是新添加的、哪些数据被删除了、哪些数据是更新过的。如果能进行这样的数据库增量查询,那么增量导出也会比较简单。
    为此,我们寻找了相关的资料,主要针对Oracle和SqlServer,到现在为止,还没有发现其中的一个数据库内置了类似的机制。其实,我们可以想想,数据库当然可以实现这样的机制,但是代价可能非常高昂。比如,数据库要记录“删除增量”,如果对应的指定表没有设置主键,数据库该用什么来唯一标志被删除的记录了,可能的办法是使用临时表把被删除的记录完整的记录下来,如果要完整的记录下被删除的记录,那么临时表的大纲就需要与指定表的大纲完全相同。因此,数据库需要为每个表都建一个大纲完全相同的表来存储这些增量记录。随时间流逝,无疑,这些临时表中的数据会越来越多,那么,谁来负责删除这些临时表中的增量记录数据了?该删除哪些增量记录了?
    我们知道,大多数据库都实现了增量备份的功能,如果增量备份不是采用主条记录比对的话,可能就是使用了临时表,这样,增量备份的时刻就是数据库清空临时表的最佳时机。但是对于随机的、可重复性的增量导出来说,还存在清空临时表的时机吗?也许你刚刚清空了临时表的部分记录,而我再一次类似的增量导出可能需要用到你刚清除的那些增量记录。
    看来,我们希望所有的数据库(不仅仅是Oracle和SqlServer)提供一种机制、自动为我们记录所有时间内每个表的增量是不太可能的。该方案被否决。

3.双排序逐条记录比对
    我们再一次退而求其次,采用最笨的逐条记录比对的方法。最笨的方案中也可以用一些效率较高的技巧,我们首先考虑到的是双排序逐条记录比对。
    所谓双排序,只的是对存在于源表中的记录和目的表中的记录都采用主键排序的方式,这样通过主键值相同来识别匹配的记录,然后再比对其余的字段来判断数据是否更新;如果源表中的某条记录在目的表中没有找到匹配,表明这条记录是新增加的。
   如何判断那条记录是删除的?通常的做法是采用反向遍历,即从目标表中选取一条记录,然后遍历源表,如果没有发现这条记录,则表明发现了一个删除增量。
    采用双排序的方法,可以很快的识别删除增量。我们分别为已排序的源记录和已排序的目标记录设置一个指针,这个指针只能单步前进,然后将两个指针指向的记录拿出来进行主键值比较,如果发现相同,则说明发现了匹配,处理该条记录,然后两个指针各前进一步;如果源主键值较小,则说明该条记录是新增加的;如果源主键值较大,则说明目的指针指向的当前记录已经在源表中被删除,这是一个删除增量。
    这种方案似乎是可行的,虽然要逐条比对,但是效率也不会太低。
    可是,如果所操作的表采用的是联合主键了(即,联合主键中的任何一个键的数据都可能是重复的,但是将它们联合起来,在表中却又是唯一的)?我们仍然可以进行实现排序,记录匹配也同样可以进行,只不多前面我们通过主键值相等来进行匹配,这里需要通过多个列的值全相等来进行匹配。
    我们再考虑复杂一点的情况,如果主键进行了分裂,或者参与了合并的情况了?经过排序后,主键的值是有序的,可是主键分裂的值(或者合并后的目标值)却不一定是有序的。这样就没有办法进行双排序操作了。因为当操作源数据中的任意一条记录时,都可能需要遍历目的表中的所有记录。

4.单排序逐条记录比对
    我们现在采用的方法是单排序逐条记录比对,即只对源表记录排序,然后逐条记录处理。这样效率要低得多,但是任务反而变得单纯些。效率最低的地方体现在识别“删除增量”,因为要用到反向遍历操作。我们希望找到更好的方法来替代它。

     在实际的实现中,你可能还会遇到一些困难,比如,我们的源表/目的表中的记录非常多,所以不可能一次将它们读入到内存中,我们需要分页。标准的sql不支持分页,针对不同的数据库有不同的实现方式,特别是当复杂的排序(如联合主键排序)掺杂在其中时,分页操作更为困难。再就是,对BLOB、CLOB、LOB数据的比对,是否要一个一个byte的进行比较来决定其是否为“更新增量”了?
    另外,我们需要对增量导出做更细粒度的控制,比如可以让其选择在增量导出时能分别控制开启或关闭“Add增量”、“Update增量”、“Delete增量”的导出。如果我们确信不需要“Delete增量”导出,那么就可以节省大量的导出执行时间。

转到:DTS开发记录(序)

时间: 2024-10-24 20:01:45

DTS开发记录(5)-- 挑战增量导出的相关文章

DTS开发记录(8)-- 主键的影响

    对于数据源向同一数据目标导出(我们称之为"数据汇集")和增量导出来说,对主键的处理也是一个大的挑战.    我先定义一下在本DTS系统中主键(PrimaryKey)的含义:PrimaryKey 表示主键或联合主键,PrimaryKey并不是针对某个数据库表的,而是针对某个特定的DataMapping而言的,它用于在数据迁移过程中来唯一确定数据源或数据目标中每条记录.    所以,本DTS系统中的PrimaryKey很多时候就是数据库表的主键,有些时候则可能不是,只要它能满足&q

DTS开发记录(序)

    (原文发表于2006-06-27 ,修正于2006-07-03)    目前手头上正在负责一个DTS(这里的DTS是Data Transfer System的缩写)系统的开发,我打算写一系列的文章来记录这个开发的全过程,这个记录可以说是实时的--每当遇到一个重要问题或解决一个重要问题,我将记录之.侯捷老师说,"发表是最好的记忆",这一系列的文章除了权作笔记外,也希望能对后来者有所参考.        在开发任何系统之前,我们都需要弄清楚,这个系统是用来干什么的?主要职责是什么?

DTS开发记录(6)-- 数据映射

    在DTS开发记录(4)-- 映射列一文中,我们详细的讨论了参与映射的源列和目标列,在拥有了映射列的基本概念的基础上,我们可以讨论数据映射DataMapping了.    数据映射主要由一组映射项(MappingItem)组成,它包含了源数据大纲到目标数据大纲的详细的完整的映射关系.    首先要注意一点,数据映射与数据大纲绑定,但是并不与任何特定的数据库表绑定.这样,DataMapping可以运用在不同的数据库表上,只要对应的数据库表结构兼容DataMapping要求的数据大纲即可.  

DTS开发记录(10)-- 可视化的流程编辑

   在将数据从数据源导出到数据目标的过程中,我们通常需要对数据进行一些检查.验证.加工.转换等操作,而这个加工转换的流程可能是非常复杂的,DTS通过可视化的拖拽的方式对数据加工转换流程进行自定义编辑.   下面的一个例子,是将某个市的学生记录表中的数据导出到省的学生记录表中,市数据库使用的是SqlServer,省数据库采用的是Oracle.    左边的工具栏中是不同类型的Filter,它们用于对数据进行某些处理,这些Filter分为五类:(1)数据载体:用于存储数据的容器,如数据库.文件.消

DTS开发记录(9)-- 数据迁移任务 DataTask

    在DTS开发记录(1)--系统总体结构 一文中,我们已经看到,一次数据传递任务基于一个连接对和一个数据映射进行.但是之前,我们并没有提到"数据迁移任务"这个元素.随着设计的演化,我们发现一个数据任务已经不再仅仅是一个连接对加上一个数据映射了.现在,我们完全有必要把"数据迁移任务"这个概念抽象的表示出来,称之为DataTask.     有了DataTask,我们的数据引擎就可以修改为基于一个指定的DataTask执行.DataTask不仅封装了在其上执行数据

DTS开发记录(7)-- 灵活的引擎 IAgileEngine

    数据引擎是数据传递系统(DTS)的核心,正如游戏引擎是PC游戏的核心一样.    IAgileEngine从目前手上的DTS系统中不断的重构完善出来,虽然IAgileEngine已经不局限于在本DTS系统中使用,但是,我还是打算在这个系列文章中来介绍它.     正如,任何事物都有最简单的雏形,IAgileEngine也是一样.DTS系统最初的引擎也是一个非常简单的引擎,随着功能不断的加入.完善,我们不断地对其重构,使其满足新的需求.终于,它慢慢地成长,这种成长的结果也是我最初没有意料到

DTS开发记录(1)--系统总体结构

    (原文发表于2006-06-28 ,修正于2006-07-03)     在DTS开发记录(序)一文中,我们已经明白了当前这个Data Transfer System的主要目标和存在的难点与挑战.在接下来的一系列的文章中,我将记录我们开发中是如何解决这些难点.如何应付这些挑战的,有的技巧或方案可能还并不成熟,所以如果你有任何想法,请留言告诉我.     本文就先从系统结构讲起.     通过我们的分析归纳,确定了该DTS系统中存在三个核心的概念,这三个核心概念建立在如下基本概念之上:(1

DTS开发记录(2)-- 数据管道及插件

    通过前面两篇文章(已于2006-07-03修正)的介绍,我们已经大致明白了系统的目标的总体结构,从这篇文章开始,我们将逐渐深入到系统内部.     本文讲述数据管道,数据管道是用于在数据源/数据目标与DataTable之间进行数据传递的组件,它是与数据库类型和文件类型相关的,数据从数据源经过数据管道后,就变成与数据源类型无关的数据了,这样映射编辑和数据引擎便能对它们进行一致的处理.    数据管道接口定义的类图如下:     数据管道接口IDataPipe从另外两个接口继承:数据导入器(

DTS开发记录(4)-- 映射列

    在DTS开发记录(1)--系统总体结构 一文中,我们介绍到映射列:"参与了数据映射的源列或目标列.注意,并不是所有的列都会参与映射,这是常见的情况." 1.映射列分为:源映射列和目标映射列.     public interface IMappingColumn    {        string ColumnName { get;set;}    }     public interface IDestMappingColumn : IMappingColumn    {