逐渐从SQL Server迁移到PostgreSQL

Question

公司有许多在SQL Server上运行的应用程序.数据库有点混乱.

目标是逐步从SQL Server迁移到PostgreSQL(另一个SQL Server实例不是一个选项)

一个理想的场景是,如果新的应用程序可以连接到PostgreSQL,创建一个新的表结构,但仍然能够使用/与来自旧版SQL Server的数据交互(连接到两个数据库服务器的应用程序不是一个选项).

外部数据包装器似乎不是一种选择,因为该技术非常不成熟,在PostgreSQL的情况下,外部表是只读的.

另一个疯狂的想法是从SQL Server实例连接到PostgreSQL,新的应用程序将连接到SQL Server,但使用PostgreSQL的外部数据库.那个外国数据库(我猜)可以访问主机的数据库对象.有时,开发人员会将所有新应用程序从SQL Server切换到PostgreSQL.

当然,有可能尝试同步数据.

哪个是最好的选择？

Answer 1

你建议的一切都是痛苦和失败的迁移方法.如果你尝试使用这种方法,人们会咆哮并狂热地看待PostgreSQL有多糟糕,缓慢和不可靠.对于想要保留SQL Server的人来说,这是一个很好的政治举动,但不是迁移到PostgreSQL的好方法.

对于较新的Pg版本,有一个读/写外部数据包装器,但它最初只支持其他PostgreSQL服务器.由于需要翻译sqlstates和错误消息,搜索条件等,因此支持MS SQL会更加困难,因此任何包装器无疑都会受到很大限制并且性能不佳.如你所说,无论如何,FDW的支持在这一点上还不成熟.

尝试做这样的混合动作,你会失去很多东西:

• 没有外键完整性执行

• 每一侧的数据类型可能不会100%相同,因此数据可以在一侧而不是在另一侧.想想时间戳/日期.

• 高效的连接需要一个极其复杂的外部数据包装器 - 所以通常会发生的是整个表将被获取然后在本地加入.表现会很糟糕.

• 当你做除了最琐碎的任务之外的任何事情时,编写查询变成了一场噩梦.功能名称不同等

• 您丢失或削弱了许多ACID属性和/或必须使用两阶段提交,这会影响性能.

说真的,不要这样做.

同步数据库可能更糟糕 - 除非它是单向的,它将成为丢失更新,删除的行重新出现,更糟糕的一个方法.双向同步非常困难.

开始为移动准备应用程序,方法是让它们能够在两台服务器上运行,但一次只能运行一台.一旦你准备好在Pg上运行应用程序,就可以开始使用迁移的实时数据副本进行一些负载测试和可靠性测试.然后想想迁移,但对如何,如果你发现强迫你延迟最后一分钟的问题扭转迁移计划.

如果你要向应用程序添加全新的部分,如果他们根本不与数据库中的其他数据交互,那么将它们放在Pg中可能是合理的.但这是不太可能的,当你告诉他们你现在需要跨两个独立数据库的原子快照时,你的系统管理员仍然会讨厌你...