数据库迁移：从 SQL Server 到 PostgreSQL _数据库

作者 | 何蔚
一、背景在这个数字化时代，企业的复杂业务逻辑运转需要依赖复杂的业务服务来完成。这些业务服务通常会经历变更、拆分、合并和上云等过程，最终与一些商业软件和云平台深度融合。
以之前服务过的客户为例，他们的系统多年来一直在.NET生态和Azure云上运行，并与微软系数据库系统进行绑定。但是，随着市场的变化，客户想要摆脱对单一商业软件和云平台的依赖，以便在续约谈判中争取更多优惠，而不是被厂商随意操纵。他们面临的其中一个挑战是必须将数据库系统迁移到PostgreSQL，以节省许可费用并迁移到更优惠的云平台。

二、技术挑战在过去十几年中，该客户在SQL Server积累了大量的用户数据、系统数据，业务代码和测试代码也是面向SQL Server和SQL Server Compact（SQL CE）编写的。我们为客户梳理出如下的技术挑战：
【数据库迁移：从 SQL Server 到 PostgreSQL】

T-SQL转换
自动化测试数据的迁移
高效加载测试数据

三、T-SQL转换T-SQL转换的具体策略需要从以下几个角度来综合考量：

交付计划
T-SQL的形态
T-SQL的数量

1.交付计划业务侧的用户数据是否迭代迁移、开发侧的代码能否迭代修改，将会直接决定T-SQL转换的交付计划，也会决定有几种方言的SQL会同时存在。

文章插图

以我们的客户为例，各个产品线十多年的代码混杂在一起，难以清晰拆分。此外，用户数据量庞大，迁移至新数据库系统需要耗费数月时间。因此，我们采取了一次性交付代码的策略，并同时支持对两种数据库系统（多方言SQL）的访问。
2.T-SQL的形态以我们的客户为例， T-SQL以两种形态存在于代码库中：

XML资源文件(resx)中的完整T-SQL
代码逻辑中的T-SQL片段

为了实现多方言SQL的切换并根据用户数据动态访问不同的数据库系统，我们基于.Net的XML资源文件设计了以下流程。

文章插图

在客户已有上下文和开发流程下，这个T-SQL改写流程具有以下优点：

采用客户开发人员熟悉的XML资源文件机制，降低理解和推广的成本。
不引入额外的工具库即可达到切换SQL方言的功能，减少了改造的隐形成本，如升级老旧的库、框架带来的连锁升级问题。
Resx文件之间的单向覆盖，减少了需维护SQL的总数量，同时方便扩展至其它方言SQL 。
对原始SQL文件不做改动，从而避免对运行中的业务造成影响。
运行时的SQL方言由用户数据动态决定，待用户数据全部迁移后，原始T-SQL和原始Embeded T-SQL可以直接删除，无须再修改代码。

3.T-SQL的数量如果SQL的总数量较少，可以考虑手动改写，因为开发自动化工具不一定划算。
在我们的案例中，需要在一个交付周期内转换超过600个SQL，长度甚至达到数十行，如果手动改写不仅费时，而且容易出错。因此，我们团队为客户量身定制了转换工具，集成了第三方开源库JOOQ 。该工具可以直接读取资源文件中的SQL语句，自动逐条转换，并生成PostgreSQL版的资源文件。开发人员将代码中的SQL整理到资源文件后，使用该工具转换SQL的平均速度可以达到每条1-2秒。
特别强调，在企业中使用第三方开源库和框架，必须根据开源许可证确认其允许商业使用。否则，将会给企业带来法律风险。
四、自动化测试数据的迁移完善的自动化测试是一张安全网，帮助企业第一时间发现破坏性修改。当SQL从一种方言转换到另一种方言之后，基于旧数据库系统运行的测试，对于新方言SQL就不再适用。为多种数据库系统而维护几套业务逻辑完全相同的测试，会极大增加测试的维护成本。而且随着时间的推移，多套测试数据将会变得不再完全一致。