数据库管理-第321期数据库国产的工作量（20250507）-CSDN博客

本文链接：https://blog.csdn.net/yhw1809/article/details/147759179

数据库管理321期 2025-05-07

数据库管理-第321期数据库国产的工作量（20250507）

数据库管理-第321期数据库国产的工作量（20250507）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner

10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）

公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

最近在和客户估算下一年度数据库国产化过程中，我这边需要完成多少工作量，其实在这个过程中，DBA需要配合做的事情可以很多，也可以很少。本期也只是从我一个数据库从业者角度来简单分析一下，换数据库大概需要在哪些地方付出努力。

1 数据

首先第一点就得先确认，我原来的数据是不是可以全量且无损的迁移并存放到新的国产数据库中，这中间最需要考虑的就是数据库之间数据类型的兼容性了，但这可不是简简单单两边数据类型名称相同就可以解决问题的，在期间可能遇到以下一些问题：

数据精度：不同数据库相同数据库类型的精度可能是不一样的，比如数字类型最大支持多少位，小数点后支持多少位；或者时间戳类型能精确到哪一位等等。在一些特殊场景下是需要足够的数据精度来实现一些功能的，如果不能实现可能就需要考虑多字段拼接甚至调整业务需求放弃一定的精度要求。
数据长度：以varchar为例，Oracle现在支持32k的长度（有没有性能问题暂且不说），而且他很多数据库还在以前的4K为上限长度，如果有场景需要大概率需要在国产库使用长字段类型，如果表中本身还有其他长字段类型，那么这张表的性能有可能会变得不怎么好。
特殊内容：在一些场景下，一些特殊符号、生僻字等数据内容也是无法直接存储的，实在不行就把对应内容通过富文本方式存放在对象存储，数据库存放URL调取

以上的几点注定在数据本身这一层面需要进行非常多的调研比对与测试，然后在一定程度上可能需要在数据层面进行一些取舍。

2 语句

语句兼容性不止是相同的普通SQL语句能不能跑，还需要能在不改动的基础上在相同的数据量、并发量下跑出差不多的性能，需要做到这点其实是很难的，一般来说需要数据库厂商针对语句运行中出现的问题进行针对性优化，有些时候在权衡利弊之下也不得不对语句进行少量改写以适配数据库特性获得更好的性能。
另一方面如果大量使用了原有数据库的一些特性，比如Oracle的存储过程、包、函数或者MySQL、SQLServer、DB2等数据库独有的操作方式，那么实现这些数据库的某些操作要么同样需要数据来适配，要么需要将一些业务逻辑从数据库中上移至应用实现。
上面说到的两个方面同数据层面类似，都是需要充分的调研与测试，也是需要对所有业务逻辑进行评估，考虑在国产数据库中用哪部分来实现业务需求。

3 硬件估算

在以前使用Oracle数据库的时候，我估算硬件要求的时候还是相对简单的，可以根据描述和经验结合推算出合理的硬件需求，中间在加上适当的监控与优化，一般来说不会出现太大的问题。但是在国产数据库的硬件评估上，我却犯了难：

望着手上大把SATA SSD磁盘的服务器，在望着数据库推荐使用NVMe SSD的我，陷入了深深的沉思
数据量估算，嗯~副本先来3倍，文本数据还要扩增2倍，要6倍磁盘空间？！那我得要多少块硬盘啊！
只有XC硬件，唉~还得大概换算下性能差异，这好难算啊
数据库性能比不过传统数据库，要更多的CPU，但是多核心协调/NUMA适配的不好，CPU还不能太多？这是怎么个悖论，难道只能…

一旦硬件估算出现了偏差，重新评估、申请硬件、装系统、部署数据库、测试、优化等等操作都得重新来，这时候你会发现如果前后硬件类型不同，一些差异会显现出来，工作量会增加不少啊。

4 迁移测试

我一直认为没有全量数据的长时间全压力测试的测试结果都是耍流氓，仅仅解决前面的数据存储问题和语句能跑或者如何实现功能的基础问题是远远不够的，在不同数据量和并发量压力下，数据库的表现是不一致的，长时间高负荷运行的稳定性也是数据库必须要考察的指标之一。在这一过程中肯定还会遇到各种各样的问题，这就需要实时监控介入找到问题，并进行针对性的调整与优化，当然这一过程中很可能会回到上一节的内容从头开始。

5 双向同步

对于国产数据库的稳定性，大多数人还是心存疑虑的，在很多核心、重要业务系统上就会有这样一个要求，国产库需要与原有数据库实现双向同步，实现完全的异构主备，就是希望在国产库出现问题时原有数据库能够快速甚至是无缝接管业务。其实实现数据双向同步不难，但是在大规模数据操作的同时实现高效同步其实不是那么简单。
另一方面如何实现数据库异常时能够快速切换才是最难得，要么实现业务双写双读，业务代码和数据库两个层面实现数据校验，这样可以减轻数据库间同步压力，但这就有一个难题，代码要适配两种数据库，说白了就用就低原则改造代码；另一种方式则还是靠数据库本身实现同步，准备两套适配不同数据库的应用程序来实现要求，前面挂个可识别故障的负载均衡即可，这种方式同样有需要客服的难点，即需要同时维护两套代码，两套代码还需要实现功能一致。前面的两种方式都需要对代码进行大刀阔斧的操作，这个工作量可比单纯切换大了许多。