数据库管理-第330期 数据库国产化可以顺便做的事情（20250528）

数据库管理-第330期 数据库国产化可以顺便做的事情（20250528）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

感觉又是好几天没写文章了，这两天在看OBCP的培训材料，东西有点多啊。
上周MySQL 30周年庆典活动上，和周彦伟老师聊了一些他正在做的数据编织相关的东西，其实数据编织这个东西我目前还是云里雾里的，后面深入了解之后再做分享。今天想聊的其实也是一个比较老的话题了，只不过是把这件事放在数据库国产化改造的过程中。

1 数据交互的现状

先拿两个资源管理类的应用做个简单说明，这两个系统是需要做数据交互的，但是有一个非常尴尬的数据问题，即两个系统的基础数据内容不一致，比如A系统中“成都”的代码是“001”，B系统中则是“A01”。这就造成了一些问题：数据关联操作时，需要先将两个系统的基础数据信息进行匹配，然后才能关联数据，这就造成了两个系统的关联查询要么频繁扫对方的基础数据，要么缓存同步对方的基础数据，大规模数据批量同步处理的时候亦是如此。当前的现状就是每天晚上两个系统间的数据同步有大量计算资源是消耗在匹配基础数据上。
不止这两个系统，在我这里和很多场景下，多个应用系统之间的基础数据之间不一致是常态现象，而企业级应用往往又需要多个系统的数据关联，这种背景下就带来了数据一致性很难确保，要么实时查询要么实时同步，链路混乱，查询操作复杂。其实说到这里大多数人应该猜出来，今天我要提的内容其实还是数据治理。

2 时代背景

以前因为种种原因（多数是麻烦+要花钱），数据治理往往是一拖再拖，不了了之。但是现在正好有个契机——数据库国产化，针对使用大多数国产数据库来说，原来运行在国外主流数据库上的应用是需要进行大改的，这里不仅仅限于针对不同数据库的代码变更，更多的还是需要对针对数据库的能力去调整、拆分、整合业务逻辑，这中间也包含数据的组织形式。既然在数据库国产化的过程中是需要做迁移、同步、数据变更，那么在这期间索性把统一基础数据之类的数据治理的操作一并做了，可以带来以下一些好处：

• 减少数据交互过程中针对数据转换匹配的需求，简化数据交互操作复杂度
• 减少数据转换带来数据异常的概率，提升全局数据一致性与准确性
• 较少多系统间数据冗余的需求，降低数据存储成本
• 减少数据同步需求，降低数据同步维护工作
• …

通过以上这些好处还可以在一定程度上解决国产数据库能力不足带来的问题。

3 锦上添花

除了可以在数据库国产化的过程中完成数据治理方面的工作，还可以做一些其他的事情：

• 规范数据库使用
• 优化业务逻辑
• 提升应用代码质量
• 收敛不合理需求

上面可以做的事情每一项展开讲都能有很多内容，这里就仅仅是抛砖引玉一下。

总结

数据库国产化过程，不仅仅是将数据迁移到国产数据库，而是还可以在这一过程中完成整个业务应用的升级的。
老规矩，知道写了些啥。