3

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

目标是逐步从 SQL Server 迁移到 PostgreSQL（不能选择另一个 SQL Server 实例）

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

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

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

当然，也可以尝试同步数据。

哪个是最好的选择？

4

3 回答 3

13

您建议的一切都是痛苦和迁移失败的秘诀。如果你尝试使用这种方法，人们会抱怨 PostgreSQL 是多么糟糕、缓慢和不可靠。对于想要保留 SQL Server 的人来说，这将是一个伟大的政治举措，但不是迁移到 PostgreSQL 的好方法。

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

通过尝试做这样的混合，你会失去很多东西：

  • 没有外键完整性强制

  • 每一侧的数据类型的行为可能不会 100% 相同，因此数据在一侧可能正常，而在另一侧则不行。想想时间戳/日期。

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

  • 当您做任何事情而不是最琐碎的任务时，编写查询将成为一场噩梦。函数名称不同等。

  • 您会丢失或削弱许多 ACID 属性和/或必须使用两阶段提交，这会降低性能。

说真的，不要这样做。

同步数据库可能更糟——除非它是一种方式，否则它将成为丢失更新、删除的行重新出现以及更糟的方法。双向同步非常困难。

让您的应用程序能够在两台服务器上运行，但一次只能在一台服务器上运行，开始为移动做好准备。一旦你准备好在 Pg 上运行应用程序，就可以开始使用迁移的实时数据副本进行一些负载测试和可靠性测试。然后考虑迁移，但如果您发现最后一刻的问题迫使您延迟，请制定如何扭转迁移的计划。

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

于 2013-08-08T13:35:28.453 回答
4

有趣的是，我工作的公司也进行了完全相同的迁移（实际上，我们仍在逐步淘汰最后几个 MS SQL 部分）。我们采用的基本方法是将数据库功能分离到单独的区域或应用程序中。

  • 任何全新的或大量重写的应用程序都完全在 Postgres 中。这并不一定意味着应用层（在我们的例子中是 PHP）只连接到 Postgres，因为整个库或共享模块可能保留在“遗留”模式上。
  • 核心配置等核心业务数据最初保留在 MS SQL 中，通过脚本定期导出数据并将其导入只读 Postgres 目标。我们为此使用了一个简单的 XML 序列化，在发现 CSV / TSV 看似简单的选项太繁琐而无法在两个平台之间进行转换之后。我们在执行反向过程时也遇到了问题，因为导入过程比 Postgres 更容易在 MS SQL 上出现破坏性的排他锁。
  • 只能在一个地方（例如管理面板）写入的数据可以同时插入/更新到新旧数据库中。显然，这会带来有人手动创建不一致的风险，但好处是两个副本都是最新的。它还需要注意自动生成的值，例如使用SET IDENTITY_INSERT强制匹配 ID。

转换单个查询相对容易，主要问题在于 CamelCase 表和列名：SQL Server 不区分大小写但保留大小写，而 Postgres 区分大小写但会将未加引号的标识符折叠为小写。因此SELECT FooID FROM ...，不仅会查找名为 的列fooid，还会返回一个标记fooid为应用程序的字段，这将是期望FooID的。这需要审核大量现有的应用程序代码，以便它可以期待一个下划线分隔的版本，例如foo_id，这更符合 Postgres 的行为。

于 2013-08-08T17:30:27.893 回答
0

这根本不是问题。您可以将数据全部或部分移动到 PostgreSQL。您可以使用 Java、Python 或其他支持的语言在 PostgreSQL 内部编写存储函数，并创建使用这些函数的视图。您的函数必须在每次执行时连接到 MSSQL。视图名称和结构必须代表不同数据库中的 MSSQL 表。只有在这种情况下更新有点棘手，需要触发器和更多代码。通过这种方式，您可以将 PostgreSQL 连接到任何其他 SQL/NoSQL DB 供应商。它运行良好，但比仅在 PostgreSQL 中的所有数据要慢。我相信在某些情况下，从应用程序连接到两个供应商可能更简单，但这是您的选择：您有选择。

于 2013-08-08T11:46:57.623 回答