基于異構系統數據時間同步模型的研究與應用

摘要：針對異構數據庫系統數據時間同步所提出的新問題，詳細介紹了異構數據庫系統數據時間同步的特點、要求。根據異構數據庫系統數據時間同步的特點，提出了一種基于新時鐘、時間戳與觸發器的異構數據庫系統數據時間同步模型。

關鍵詞：異構性；數據庫系統；時間同步；時間戳；觸發器

中圖分類號：TK262文獻標識碼：A文章編號：1672-3198（2007）10-0261-02

1異構數據庫系統數據時間同步模型與算法的研究

異構數據庫系統數據時間同步的精確度主要受到以下因素的影響：異構數據庫系統數據時間同步采取的策略；服務器端與客戶端時鐘系統的精確度；服務器端與客戶端運行的操作系統；服務器端與客戶端所運行的DBMS；服務器端與客戶端的網絡狀況等。

現行的異構系統使用的數據同步策略主要有基于快照差分算法的數據同步策略與基于日志分析的數據同步策略。

基于快照差分算法的策略不但需要消耗同等數量級的存儲空間和I/O開銷，而且需要大量的時間進行數據的排序、分析和比對，特別是對于大數據量的快照差分，數據同步的效率會急劇下降；基于日志的數據同步策略雖然效率會提高，但是對數據日志的分析一般難以實現。可見，必須找出另外方法，本文在觸發器的基礎上，將電子商務中的時間戳技術運用到其中，提出了一種基于時間戳和觸發器的數據同步策略。

在本策略中有兩個難點需要解決，一個是數據源的類型多樣，如何方便地自動地無需人工干預建立觸發器。第二個難點是如何在分布式環境下最大化地減少數據傳輸的冗余量，實現數據的快速同步，且減少對數據源的影壓力。

針對第一個問題，因為異構數據源的類型不確定，可以采用函數的方法，實現觸發器的自動建立。針對數據庫管理系統多樣性，數據庫觸發器的建立方法不同，可事先針對不同的數據庫系統分別建立不同的函數。當第一次集成的時候，自動加載相應的函數到數據庫管理系統當中去，并執行函數給每個要集成的表建立觸發器。

針對第二個問題，在目前常用的數據同步策略中，傳輸對象都是以一條一條記錄為最小單位的，也就是說，當數據源表中某一個字段發生變化時，會把該條記錄的內容全部發送給目的端，這種處理方式導致數據的傳輸冗余量太大，嚴重的增加了網絡的負載，影響了數據同步的效率。在這里，考慮將監視發送對象縮小到字段，在傳輸的過程當中只把變化字段的內容發送給目標端，平衡網絡的負載。同時為了減少對數據源的壓力，設計了一個源操作表，它記錄了對數據的所有操作，包括增加、修改和刪除記錄等信息。

源操作表位于源數據端，隨時同源表的數據保持一致，在第一次抽取的時候會建立，每個要抽取的表都各自對應一個源操作表，其表名為要抽取的表名加后綴“_SNP”源操作表的結構如表1所示。

（1）當修改數據的記錄時，觸發器被觸發，將操作的時間、類型和修改的值以及記錄的標示寫入源操作表當中；比如，當修改源表的某條記錄的一個字段時，查找源操作表是否有關于該字段的修改記錄(字段Data_primary和Name_column的值必須完全匹配)，如果有則直接在該記錄上修改(Type_oper字段值為U)，并將修改的值填入Data_column字段即可，如果沒有則在源操作表插入一條記錄即可。

當源表中插入一條記錄時，只需要在源操作表中將非空字段的信息寫入即可(Type_oper字段值為I)，那些空值的字段不需要填寫其信息，也就是說，雖然源表有N個字段，但在插入一記錄時只由M個字段插入了新值，源操作表中只增加了M個記錄而不是N個記錄。

當在源表中刪除一條記錄時，查找源操作表是否有關于該記錄的信息(只要字段Data_primary匹配)，如果信息表明該記錄是新插入的(即該記錄信息中有一個Type_oper為I的記錄)把找到的所有記錄刪除即可，如果該記錄不是新插入的(即不能找到該記錄信息中有一個Type_oper為I的記錄)則將信息寫入源操作表(字段Typeoper值為D)。

（2）同步模塊將根據源操作表的內容和修改時間字段的值，更新臨時數據表中的內容(臨時數據表相當于臨時中間數據緩沖區)，實現了臨時表和源數據的同步，并返回從系統新時鐘讀取的更新的時間New_Updatetime(其值也就是字段Update_time的值)；

（3）將源操作表當中字段Update_time的值小于New_Updatetime的所有記錄刪除。

解決了上述關鍵性問題之后，下面我們提出基于異構系統數據時間同步的模塊結構圖。如圖2所示：

其中數據源為用戶所需要的數據來源，也是異構系統同步的數據源，比如：SQLServer、Oracle、DB2、access等；目標數據庫是數據的目的地；中間數據區作為數據的中介，是數據集成的主要環節，用戶所要進行的數據轉換都是在此進行，其中主要有一個臨時數據存儲區1和臨時數據存儲區2，它們分別負責存儲轉換之前和之后的數據，因此是數據的臨時緩存區。

其中用戶控制模塊負責和用戶進行通信，接受用戶命令，并將用戶的配置和命令傳遞到其它模塊；任務管理模塊是數據集成的核心，負責任務的調度和其他模塊的管理；預集成模塊主要負責集成前的準備，包括建立各種觸發器，建立源操作表或MDS源操作表等；同步模塊依據不同的數據同步策略負責數據的同步；轉換模塊根據用戶的配置和任務管理模塊進行數據的轉換；時間同步模塊主要是用來從時間服務器或者新時鐘獲取高精度的時鐘信息。

系統開始運行后，首先各個數據源與目標數據庫均執行時間同步算法，構建統一的時間平臺。然后由數據訪問模塊將數據從異構數據源中抽取出來，再經過預集成、數據同步、數據轉換等完成數據的同步與轉換，最后由加載模塊將同步數據加載到目標數據庫中。

2實驗結果

實驗平臺中，我們選擇了SQLServer和Oracle進行數據同步。在同步過程中，我們發現數據更新的數據量對同步時間有很大的影響。因此，實驗過程如下:對一張數據表更新30000條記錄，該表具有20個字段，每個字段的大小相同均為20個字符，每次實驗變化的是修改字段的數量。修改字段數量所占的比例即為修改的數據量所占總數據量的比例。

如圖3所示，橫坐標表示修改的字段所占的比例，縱坐標表示同步所用的時間。記錄級同步策略采用傳統的快照差分算法的同步策略，字段級的同步策略采用的時本文主要介紹的基于新時鐘與時間輟和觸發器的同步模型。

經過對實驗數據的分析，我們發現，在數據庫中僅有極少記錄需要同步時，本算法和傳統算法均有著較好的時間同步精度。隨著字段修改比例的增加，傳統記錄級的數據時間同步策略所需的時間抖動不明顯，整個曲線呈平緩上升的趨勢。而本文中提出的基于時間輟和觸發器的同步策略所需的時間呈上升趨勢，整個曲線的上升趨勢即斜率要大于傳統記錄級得曲線。當修改比例在70%以下，基于時間輟和觸發器的同步策略較記錄級的同步策略是較優的，其原因在于將監視對象縮小為字段，減少了冗余量和網絡傳輸量。但當修改比例超過70%，基于時間戳和觸發器的同步策略較記錄級的同步策略反而更差。主要原因是當更新的數據比例過多，雖然本算法將監視對象縮小為字段處理，但是這種縮小字段帶來的時間和效率上的提升的不到體現，反而會因為在處理的過程中增加了一些處理中間環節導致整體算法效率上的降低；從而導致了按字段處理不如按記錄處理的情況發生。

因此可以考慮將傳統的數據時間同步算法與本算法結合起來，設置一個監視模塊，當發現修改比例超過70%就調用傳統算法進行數據的時間同步。

參考文獻

［1］汪靜，賀鵬.一種分布式數據庫系統時間同步技術研究［J］.微計算機信息，2007，(18).

［2］周書民，湯彬.RDGSM分布式數據庫系統的時間同步策略［J］.計算機應用，2004.

［3］David.L.Mills.NetworkTimeProtocolSpecification.ImplementationandAnalysis［M］.DARPANetwGroupReportRFC1305，Univ.Delaware.1992.

［4］彭杰.PROFINET及其同步實時通信分析［J］.微計算機信息，2006，(25).