令人奔溃的数据和业务逻辑

前段时间不经意间看到一个数据库的日志,我将这个日志进行简化和脱敏。

可能有人会说这个没有索引,是全表扫描。其实这个和索引没关系。

不知道大家有没有觉得奇怪?为什么时间不一样,但是每次的行数都是一样的?关键是扫描行数和返回行数一模一样。(真实的数据是好几万行的扫描和好几万行的返回)

我不相信每天产生的数据一条不差。这个和是不是有索引没有关系。

这个时候我第一感觉就是,看看表里面的数据是什么样的吧?

查看我脱敏的样例数据。

怎么样是不是很吃惊?

再看看表结构,这下明白了吧?这个数据类型就根本不对。

我见过用字符串表示时间的,这个是我极力反对的。这个无论在什么数据库上一般都不是好的选择。

当然用UNIX时间戳也不是不可以,最起码比字符串好。可惜这个ETL并不知道源数据是什么。还是按照date类型处理。结果就是这样了。

另外一个好奇点是,每次这样拿过去的数据有意义吗?因为完全不是实际的数据,根本对不上。或许这个业务重要程度低,无所谓数据对错了。

所以ETL处理数据要考虑很多事情,而避免这些问题最好的方式就是使用OGG等技术方案做日志级别同步,或者采用HTAP的解决方案。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值