SQL性能考虑

Question

在规划SQL应用程序时，我应该记住哪些性能考虑因素？Azure存储，工作人员和web角色看起来非常可伸缩，但是如果最后他们使用的是一个数据库.看起来是瓶颈。

我试着找出关于：

1. SQL支持多少并发连接？
2. (带宽)？

但没有运气。

例如，我计划和应用程序使用非常高级别的插入，但每次都需要返回聚合函数的结果(例如:列中所有具有相同键的记录的总和)，因此不能使用表存储。

批处理是一种选择，但是时间响应也很关键，所以我担心数据库中会有大量的连接。

分片是另一种选择，但即使插入量很大，数据量也非常小，只有一个PK而没有FK的4到6个列。因此，即使1Gb的DB对于一个分区来说也是一个超支(以及过高的:D)。

在面对这类应用程序时，我应该记住哪些是性能键？

干杯。

Answer 1

实现可伸缩性和性能都非常困难，即使在云中也是如此。您的问题主要是关于可伸缩性的，因此您可能希望在设计应用程序时使您的数据“最终”保持一致，例如使用队列。工作者角色将侦听传入的插入请求，并异步执行插入。

为了减少到数据库的往返次数和优化连接池，也要确保对插入进行批处理。所以你可以一次发送100个插入件。还请记住，SQL现在支持MARS (多个活动记录集)，因此您可以在单个批处理中将多个选择返回给调用代码。使用批处理和MARS应该将数据库连接的数量减少到最低限度。

分片通常有助于读取操作；但对于插入(虽然我从未对插入进行基准测试)提供了更多帮助。所以我不确定分片会对你的需求有多大帮助。

请记住，Azure产品的设计首先是为了在多租户环境中实现可伸缩性和合理的性能，在多租户环境中，您的数据库与同一服务器上的其他人共享。因此，如果您需要强大的性能和有保证的响应时间，您可能需要重新评估您的主机选择，或者按照tijmenvdk的建议，测试Azure的性能边界。

Answer 2

如果发生任何形式的资源争用，SQL将限制您的连接(这包括沉重的负载，但也可能发生在数据库物理移动时)。节流是不确定的，这意味着你无法预测是否和何时会发生这种情况.当节流时，SQL将删除您的连接，要求您执行重试。由于底层基础结构的灵活性，支持的连接数和带宽没有“按设计”发布。尽管如此，该设置是为高可用性而不是高吞吐量而优化的。

如果爆发发生在已知的时间，您可以考虑在这些突发事件期间分片，并在爆发发生后合并数据。处理此问题的另一种方法是，只有在发生节流时才开始排队/批写写入。您可以为此使用Azure队列，并在以后使用一个worker角色来清空队列。这种“溢出机制”的优点是，如果发生节流，就会自动啮合。

作为另一种选择，您可以使用Azure表存储，并保留一个单独的运行总计表，您可以返回该表，而不是对数据执行聚合，以返回所有记录的所需和(但是，由于缺少对表的锁定，这可能比较棘手)。

很抱歉声明了显而易见的内容，但是第一步将是测试您在场景中是否遇到节流。我会给溢流液一试。