公司在SQL Server上运行了许多应用程序。数据库有点混乱。
目标是逐步从SQL Server迁移到PostgreSQL(另一个SQL Server实例不是一个选项)
理想情况是,如果新应用程序可以连接到PostgreSQL,创建新的表结构,但仍然能够使用/与旧SQL Server中的数据交互(连接到两个数据库服务器的应用程序不是一个选项)。
外来数据包装器似乎不是一种选择,因为该技术非常不成熟,而对于PostgreSQL,外部表是只读的。
另一个疯狂的想法是从SQL Server实例连接到PostgreSQL,新的应用程序将连接到SQL Server,但使用PostgreSQL的外部数据库。那个外国数据库(我猜)可以访问主机的数据库对象。有时,开发人员会将所有新应用程序从SQL Server切换到PostgreSQL。
当然,有可能尝试同步数据。
哪个是最佳选择?
答案 0 :(得分:12)
你建议的一切都是痛苦和失败的迁移方法。如果你尝试使用这种方法,人们会咆哮并狂热地看待PostgreSQL有多糟糕,缓慢和不可靠。对于想要保留SQL Server的人来说,这是一个很好的政治举动,但不是迁移到PostgreSQL的好方法。
对于较新的Pg版本,有一个读/写外部数据包装器,但它最初只支持其他PostgreSQL服务器。由于需要翻译sqlstates和错误消息,搜索条件等等,支持MS SQL会更加困难,因此任何包装器无疑都会受到很大限制并且性能不佳。如你所说,无论如何,FDW支持目前还不成熟。
尝试做这样的混合动作,你会失去很多东西:
没有外键完整性执行
每一侧的数据类型可能不会100%相同,因此数据可以在一侧而不是另一侧。想想时间戳/日期。
高效的连接需要一个非常复杂的外部数据包装器 - 所以通常会发生的是整个表将被获取然后在本地加入。表现会很糟糕。
当你做除了最琐碎的任务之外的任何事情时,编写查询会变成一场噩梦。功能名称不同等。
您丢失或削弱了许多ACID属性和/或必须使用两阶段提交,这会影响性能。
说真的,不要这样做。
同步数据库可能更糟糕 - 除非它是一种方式,它将成为丢失更新,删除的行重新出现,更糟糕的方法。双向同步非常很难。
开始为移动准备应用,方法是让它们能够在两台服务器上运行,但一次只能运行一台。一旦你准备好在Pg上运行应用程序,就可以开始使用迁移的实时数据副本进行一些负载测试和可靠性测试。 然后考虑迁移,但如果你发现迫使你延迟的最后一分钟问题,我们计划如何扭转此举。
如果您要向应用添加全新的部分,如果他们根本不与数据库中的其他数据进行交互,那么将它们添加到Pg中可能是合理的。但这是不太可能的,当你告诉他们你现在需要跨两个独立数据库的原子快照时,你的系统管理员仍会讨厌你......
答案 1 :(得分:3)
有趣的是,我工作的公司已完成相同的迁移(实际上,我们仍在逐步淘汰最后几个MS SQL部分)。我们采用的基本方法是将数据库功能分离到单独的区域或应用程序中。
SET IDENTITY_INSERT
强制匹配ID。转换单个查询相对容易,主要问题是CamelCase表和列名:SQL Server不区分大小写但保留大小写,而Postgres区分大小写但将不带引号的标识符折叠为小写。因此,SELECT FooID FROM ...
不仅会查找名为fooid
的列,而且会向应用程序返回标记为fooid
的字段,该字段将为FooID
。这需要审计大量现有的应用程序代码,以便它能够获得一个undercore_separated版本,例如foo_id
,这更符合Postgres的行为。
答案 2 :(得分:0)
这根本不是问题。您可以将数据完全或部分移动到PostgreSQL。您可以使用Java,Python或其他一些受支持的语言在PostgreSQL中编写存储函数,并创建使用这些函数的视图。您的函数必须在每次执行时连接到MSSQL。视图名称和结构必须代表不同数据库中的MSSQL表。在这种情况下只更新有点棘手,需要触发器和更多代码。通过这种方式,您可以将PostgreSQL连接到任何其他SQL / NoSQL DB供应商。它工作得很好,但比PostgreSQL中的所有数据都慢。我相信在某些情况下,从应用程序连接到两个供应商可能会更简单,但它是您的选择:您有选择。