校验函数,哈希冲突比你想象的多

发布时间:2017-2-20 7:15:07 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"校验函数,哈希冲突比你想象的多 ",主要涉及到校验函数,哈希冲突比你想象的多 方面的内容,对于校验函数,哈希冲突比你想象的多 感兴趣的同学可以参考一下。

校验函数,哈希冲突比你想象的多

在SQL Server 2012,有2个校验函数:check_sum 和 binary_check,在一些Data Table中,如果存在多个字符串字段,并且字符串非常长,在比较字符串是否相同时,使用校验函数,将其转换成 int 类型,能够提高数据比较的速度。但是不要忽略 CSDN 官方文档的Caution:使用校验函数,有时不能探测到数据的更新,除非Application能够容忍偶尔的丢失更新。一旦将校验函数用于实际的项目中,你会发现,不是偶尔,而是经常会发生探测不到数据更新的异常:

BINARY_CHECKSUM(*) will return a different value for most, but not all, changes to the row, and can be used to detect most row modifications.

However, there is a small chance that the checksum will not change. For this reason, we do not recommend using CHECKSUM to detect whether values have changed, unless your application can tolerate occasionally missing a change.

由于存在侥幸心理,在项目中使用了校验函数对字符串字段进行比较,代码大致如下:url,why 和 description 字段都是挺长的字符串字段,特别是description,平均长度是1163字符。

;merge target as t 
using source as s 
    on t.id=s.id
when matched 
    and binary_checksum(t.url,t.why,t.description)
            <>binary_checksum(s.url,s.why,s.description)
....

大多数情况下,函数工作正常,但是,常在河边走,哪能不湿鞋,在一个周末,领导一个短信,我回来加班了,校验函数不能探测出更新的数据,导致数据同步出现问题,对ScoreCard和绩效影响较大,必须及时修改。

如图,Source 和 target 的Description 字段不一致,但是校验函数:binary_check(url,description,why) 返回的值是相同的,痛定思痛,为了避免以后的数据更新被异常丢失,决定在ETL中不再使用校验函数,而是直接使用字符串进行比对。

校验函数对长字符串产生的校验值质量不是很高,那对短的字符串了?经过多次尝试,发现校验函数在短的字符串上更容易出现更新丢失的情况,鉴于校验函数的这些缺点,强烈建议不要在项目中使用校验函数。直接使用字符串进行比较,保证万无一失,相比数据更新出错,数据同步稍稍慢点,更能被容忍。

引用《校验函数:checksum 和 binary_checksum》:

在比较长的字符串时,直接比较会比较慢,使用校验和比较速度会比较高,但是 binary_checksum 和 checksum 产生的校验和的质量比较低,建议不要再项目中使用校验函数。当字符串比较短时,很大可能产生Hash 冲突,例如:下面的脚本返回两行数据,每行的两个column结果相同,相比较而言,使用 checksum 比 binary_checksum效果更好。

--database collation is  SQL_Latin1_General_CP1_CI_AS
select checksum(N'us',N'FL',N'Land O Lakes'),checksum(N'us',N'FL',N'Land O'' Lakes')
select binary_checksum(N'gb',N'c6',N'bude'),binary_checksum(N'no',N'',N'myre')

上一篇:Nginx开启GZIP来压缩网页
下一篇:转:Eclipse Search Tips

相关文章

相关评论