暂无图片
暂无图片
11
暂无图片
暂无图片
暂无图片

国产数据库时代,一些20年前的数据库设计小技巧又可以拿出来用了

白鳝的洞穴 2025-04-10
660
今年开始数据库国产化替代逐渐进入了深水区,最近和我讨论国产化替代方案的朋友几乎每天都有。昨天晚上在饭桌上谈到某个国产数据库产品的使用体验,一个朋友说,他听到两种十分极端的声音,一种是很好,很方便,一种是太差了,问我哪种可能是真的。我说应该两种说法都是真的,因为他们遇到的应用场景不同,有些场景下这个国产库可以完美替代Oracle,某些场景如果直接把Oracle迁移上去,就支撑不住了。
对于数据库国产化替代这件事,我以前就讨论过平替只适合规模较小,复杂度较低的系统,而对于规模较大,业务复杂度很高的系统,必须进行适配性改造和优化才能在迁移后使用体验下降得不太多。不过对于大量的系统做适配性改造成本也是极高的,我最近听几个大行的朋友说,他们改造非核心系统的压力也是巨大,资金缺口很大。
回想起二三十年前的场景,在使用Oracle数据库的时候,也不敢像现在这样肆无忌惮地设计系统,编写程序。这些年Oracle越来越强大,让开发者光顾着实现功能了,数据库设计是做得越来越水了。
其实目前的国产数据库的能力与当年Oracle差不太多,所以二三十年前的一些数据库设计上的小技巧还是会对国产数据库替代有所启示的。用好这些小技巧,可以解决大多数问题。
首先是数据库内归档表的设计,大部分性能问题是因为数据量大了引发的,那么减少生产表的大小可以有助于解决这方面的问题。大部分大表都是按照时间顺序产生的业务数据的明细表,这些表的数据随着时间推移,新数据访问频次较高,而老数据访问频次较低,甚至有些老数据基本上是死数据,但是偶尔还是有访问需求的,还无法彻底离线存储。
将表的数据分为生产表和在线历史表之后,唯一需要应用适配的是对这些历史数据的在线查询。可以在业务逻辑中设计一个在线时间的判断,自动拼凑两张表中的数据。而如果历史数据查询的重要性不是特别高的场景,甚至可以不提供在线查询的功能,当偶尔需要查询历史数据的时候,通过另外一套体系去查询,比如通过某个数据库访问平台或者专门的历史查询工具去查询。这么做的主要目的并非大家想象的减少应用适配的工作量,另外一个优点是真正降低非必要的历史查询。当年某省移动公司发现历史详单查询消耗的系统资源很高,于是规定互联网营业厅详单查询只能查3个月,三个月以上的必须到营业窗口拿身份证查询。这个措施执行后,超过3个月的详单查询量下降了90%,相关的用户投诉并未增加。
在线历史数据也不能存放时间过长,否则会导致数据库总容量的增长,对于数据库备份恢复造成较大的影响。因此对于超过一定期限的在线历史数据还是要往归档库归档。归档库设计也十分重要,归档库使历史数据可以长时间在线存储,支撑偶发性数据查询和审计等业务。
如果这些数据还是太庞大,那么对在线历史数据进行瘦身依然是必要的,在线历史表可以分为两级,一级为完全的在线历史表,二级为压缩在线历史表。比如当月的一个月数据为生产表,半年内的数据为一级历史表,一年内的数据为二级压缩历史表,半年后的数据在归档库存储。二级压缩历史表并非使用表压缩技术,而是压缩非常用字段,二级压缩历史表中的数据字段数比一级历史表少一些,这样就可以降低表的高水位线,提高表扫描的效率(对这些数据的查询,往往都是要进行表扫描或者表分区扫描的)。归档数据的操作是在一级历史表上进行的,因此在归档库中,依然保留了完整的业务数据。
除了数据归档外,另外一个解决数据库性能问题的小技巧是多级数据汇总。在数据库中,消耗资源的另外一个大户是对生产流水数据的汇总查询操作,比如汇总一天或者一个月的数据。如果某些流水数据一旦生成,某些统计项就是固定的,而且这些统计项经常被查询,那么可以设计一些汇总表,汇总表也可以分为多级,比如日统计、周统计、月统计。有了这些多级统计表后,一些对原始生产表的统计查询就可以直接从汇总表中获得了。
上面两个数据库设计的小技巧,在二三十年前的系统中基本上是必备的,现在依然有不少系统在使用。其主要目的就是降低当前生产业务数据表的高水位线,让与当前核心业务相关的数据量的增长是可控的,从而减少数据库的资源开销,提高数据库的稳定性。可能现在的年轻人都没经历过银行查询交易记录需要分当前交易查询和历史交易查询两个菜单的时代了,并非那个时代的开发人员水平不够,写出的代码不够人性化,而真的是受限于那个时代数据库与服务器的性能做出的无奈之举。这些小技巧,在目前数据库国产化替代的工作中,还是能够发挥不小的作用的。

文章转载自白鳝的洞穴,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论