链接 SQL Server 有哪些重大限制？

Question

我们的产品基于 Microsoft SQL Server。目前，我们使用了三个数据库，并且始终将它们部署在一个 SQL Server 实例上。

这三个数据库是OLTP、OLAP和审计。OLAP 数据库有大量来自 OLTP 和审计的 EOD 入站数据，使用跨数据库查询。

问题

如果我们将这三个数据库部署到单个物理服务器内的三个独立的标准版实例上，并使用 SQL Server 的链接服务器功能将它们绑定在一起：

1. 它对应用程序代码有多透明？我应该期待多少变化？
2. 到 OLAP 的入站数据为 50k-100k 行，每个 EOD 的有效负载为 200-500MB。我应该期望多少性能下降？
3. 我应该期待哪些其他重大限制？

背景

目前，我们正在向拥有 500 多个并发用户的潜在客户进行宣传。

我们正在起草服务器规范，其中包括 64 个内核和 256GB RAM。为了让 SQL Server 能够利用所有这些丰富的资源，客户必须购买企业版，而对于 SQL Server 2016，它仅在基于每核的许可中可用。

我们担心仅许可成本（64 x 7400 美元）就会让他们失望。所以我想把数据库拆分成三个标准版的实例，并把它们链接在一起，希望链接功能对应用程序代码是透明的。

Answer 1

它对应用程序代码有多透明？我应该期待多少变化？

一点都不透明。期待重大变化。

您应该为非常显着的性能下降做好准备。

分布式查询（链接服务器的框架）使用通用 OLEDB 模型，无论另一端的服务器是什么。确实，SQL Server 目标可能能够提供更完整的信息（元数据、统计信息等），但其结果仍远不及本机跨数据库操作的紧密集成或能力。

远程查询因性能低下和优化器糟糕的计划选择而享有盛誉。更改数据的语句（删除、插入、更新、合并）特别容易出现，因为基本模型通常是游标的模型。

如果您从不需要执行即席跨实例查询，您也许能够手动调整每个存储的查询以获得可接受的性能，但这是大量工作，并且不能保证成功。

对于跨例如批量操作，你会关闭使用真实批量操作好得多（bcp，BULK INSERT，SSIS ...等）比使用链接的服务器实例之间。

综上所述，对我来说，基本的想法似乎比它值得的麻烦得多。指定将在标准版的约束内工作的硬件；或者，如果客户端需要更高的性能，请获取更大的服务器并使用企业版。