蜜果私塾：异构数据库数据校验方案探讨

文：阿蜜果

日期：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文件，将不一致的用户信息写入错误日志文件中。

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