是否可以使用 Microsoft SQL Server 进行横向扩展？

Question

是否可以横向扩展 SQL Server 数据库？

有一些针对故障转移群集和始终开启的解决方案，但是否有针对 SQL Server 上的负载平衡和水平分区的解决方案？

在Azure 中有一些，但在独立的 SQL Server 实例中没有...

Answer 1

你在这里有点问题：

可以在 Azure SQL DB 中扩展 READS 吗？是的。

根据您使用的服务（例如 Azure SQL DB 的活动辅助副本），您的读取工作负载可以自动扩展到多个服务器，而无需对应用程序代码进行大的更改。但是，您仍然需要在应用程序中添加一个单独的连接字符串，指定 ApplicationIntent=ReadOnly，以便他们知道将读取查询移动到可读副本是安全的。

是否可以横向扩展 Azure SQL DB 中的 WRITES？是的，如果您更改代码。

您链接到的文档Data Partitioning是一组设计指南，您可以在编写应用程序时使用这些指南。但是，这些确实是代码更改，而不是 Azure SQL DB 的一项功能，您只需像在辅助副本上翻转一样翻转即可。

由您来设计一层代码，以便当您的应用程序需要运行查询时，它连接到适当的位置。

把它想象成万维网：在 Stack Overflow，写入工作负载被隔离在 StackOverflow.com、DBA.StackExchange.com、ServerFault.com 和其他站点。但是，您，用户，必须知道哪个站点包含您要写入的数据 - 您无法在 ServerFault.com 上发布此问题的答案。该逻辑已内置于您的大脑中 - 如果您想跨多个服务器扩展写入，则需要将相同的逻辑内置于您的应用程序中。

有一段时间，Microsoft 认为他们会使用Azure SQL DB Federations为您完成这项工作，但很快就被弃用了。

SQL Server 是否可以实现相同的功能？是的。

扩展读取非常简单：

1. 购买更多 SQL Server 并将它们构建到可用性组中
2. 在您的应用程序中添加另一个连接字符串，指定 ApplicationIntent=ReadOnly
3. 利润！

扩展写入并不那么容易，并且需要更改代码，就像在 Azure SQL DB 中一样。

它们中的任何一个都做真正的负载平衡吗？不。

Azure SQL DB 和 SQL Server Always On 可用性组都没有真正平衡多个辅助节点之间的负载。您可能会遇到一种情况，其中一个副本正在运行一些糟糕的查询，而其余的则闲置。在这种情况下，您仍然可以将新查询平均分配给工作不足和工作过度的服务器。

进行真正的负载平衡——在多个副本之间保持相似的工作需求——留给读者作为练习。