蜜果私塾：異構數據庫數據校驗方案探討

文：阿蜜果

日期：2011-8-5

版權所有，轉載請注明出處

最近在琢磨異構數據庫數據校驗的事情，想來想去覺得都不是易事，我想出了一個方案，但最終因為工作量、時間等原因，項目決定不再進行數據校驗，在這里分享一下,拋磚引玉，希望得到同仁們的一些更好的方案。

1、為什么要進行數據校驗？

首先要回答這個問題：“為什么要進行異構數據庫的數據校驗呢？”本博的前兩篇文章探討了進行異構數據庫同步的方案，但是不論使用何種方式進行同步，都可能因為各種原因導致兩邊數據庫的不同步，例如一方的SQL語句執行成功，而另一方轉換成新的SQL語句后執行失敗，而沒有得到實時處理，或者同步程序存在bug等原因。

進行數據校驗的原因是為了保證兩邊數據庫的數據一致性和完整性。

數據不一致可能導致的結果：

（1）使得用戶進行了某個設置，但未見生效；

（2）用戶已經刪除了某設置，但仍然繼續生效；

（3）某個用戶在一方平臺已經注銷或到期，而在另一平臺仍然可以使用等等。

貼幾段關于數據一致性和數據完整性的代碼：

數據一致性通常指關聯數據之間的邏輯關系是否正確和完整。而數據存儲的一致性模型則可以認為是存儲系統和數據使用者之間的一種約定。如果使用者遵循這種約定，則可以得到系統所承諾的訪問結果。

數據庫完整性（Database Integrity）是指數據庫中數據的正確性和相容性。數據庫完整性由各種各樣的完整性約束來保證，因此可以說數據庫完整性設計就是數據庫完整性約束的設計。數據完整性包括：實體完整性、域完整性、參照完整性和用戶定義完整性。可以使用主鍵、check約束和外鍵等來實現。

為了保證數據庫的一致性和完整性，設計人員往往會設計過多的表間關聯，盡可能的降低數據的冗余。表間關聯是一種強制性措施，建立后，對父表和子表的插入、更新、刪除操作均要占用系統的開銷。

如果數據冗余低，數據的完整性容易得到保證，但增加了表間連接查詢的操作，為了提高系統的響應時間，合理的數據冗余也是必要的。使用規則和約束來防止系統操作人員誤輸入造成數據的錯誤是設計人員的另一種常用手段，但是，不必要的規則和約束也會占用系統的不必要開銷，需要注意的是，約束對數據的有效性驗證要比規則快。所有這些，設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。

2、哪些是需要關心的表和字段？

異構數據庫的雙方需要確定哪些是需要進行數據校驗的表？需要關心的字段是哪些？哪一些字段不會影響到業務可以不去關心？畢竟進行數據校驗是一個耗時耗力的活。

3、采用何種數據校驗方案

我感覺思維受限，暫時只想到這個個方案：

（1）關鍵表的總量比較。

（2）用戶信息的抽樣校驗：因為主要關心跟用戶有關的信息，因此對用戶信息進行抽樣檢驗。隨機抽取部分用戶（例如：10000個用戶）對其各項信息進行比對，兩邊的數據按照一樣的XML Schema生成，可使用各種方式進行比對（例如Shell進行文件比對）。

數據校驗包括的程序大致如下：

（1）隨機抽樣程序

隨機抽取若干（例如10000）號碼的程序

（2）數據校驗定時程序

同步用戶下的“數據校驗定時程序”定時讀取（例如每天的晚上12點）需要進行數據校驗的用戶信息，對每一行的用戶啟動一個“數據校驗處理程序”的自動機進行處理。

（3）數據校驗處理程序

每個“數據校驗處理程序”自動機只處理一個用戶信息，它通過查詢若干表得到該用戶的詳細信息，并根據定義好的XML格式寫入XML文件中。兩邊同步用戶采用一樣的XML Schema，按照一樣的排序生成XML文檔，XML Schema有待在校驗數據確定后進行定義。

（4）數據校驗比對程序

該程序對比對（例如通過Linux命令進行比對）兩個同步用戶下生成的XML文件，將不一致的用戶信息寫入錯誤日志文件中。

歡迎大家提出好的想法！開拓下我的思路。