在计划SQL Azure应用程序时，我应该记住哪些性能注意事项？ Azure存储，以及工作者和Web角色看起来非常可扩展，但如果最终他们使用一个数据库......它看起来像是瓶颈。
我试图找到有关的数字：
但没有运气。
例如，我正在计划和应用程序使用非常高级别的插入，但我需要每次返回聚合函数的结果（例如：列中具有相同键的所有记录的总和），所以我不能用表存储。
批处理是一种选择，但时间响应也很重要，所以我担心数据库会因为很多连接而膨胀。
Sharding是另一种选择，但即使插入量很大，数据量也非常小，4到6列有一个PK且没有FK。因此，即使1Gb数据库对于分区来说也是一种过度杀戮（以及多付费用：D）。
当我面对这类应用程序时，我应该记住哪些性能键？
干杯。
答案 0 :(得分：3)
如果发生任何形式的资源争用，SQL Azure将限制您的连接（这包括重负载，但也可能在数据库物理移动时发生）。限制是非确定性的，这意味着您无法预测是否以及何时发生这种情况。限制时，SQL Azure将断开连接，要求您执行重试。由于底层基础设施的灵活性，支持的连接数和带宽未“按设计”发布。话虽如此，该设置已针对高可用性而非高吞吐量进行了优化。
如果突发发生在已知时间，您可能会考虑在突发期间进行分片并在突发发生后合并数据。处理此问题的另一种方法是，当且仅当发生限制时才开始排队/批处理写入。您可以使用Azure队列以及辅助角色来稍后清空队列。如果发生节流，这种“溢出机制”具有自动接合的优点。
作为替代方案，您可以使用Azure表存储并保留一个单独的运行总计表，您可以向其报告，而不是对数据执行聚合以返回所有记录的所需总和（由于缺少这可能会很棘手）虽然锁定在桌子上。
表示明显的道歉，但第一步是测试你的场景中是否遇到了限制。我试试溢出解决方案。
答案 1 :(得分：3)
即使在云中，实现可扩展性和性能也非常困难。您的问题主要是关于可伸缩性，因此您可能希望以使用队列为例，使您的数据“最终”一致的方式设计应用程序。辅助角色将侦听传入的插入请求，并将异步执行插入。
要最大限度地减少到数据库的往返次数并优化连接池，请确保批量插入。所以你可以一次发送100个插入。另外请记住，SQL Azure现在支持MARS（多个活动记录集），因此您可以在一个批处理中将多个SELECT返回给调用代码。使用批处理和MARS应该将数据库连接的数量减少到最少。
Sharding通常有助于Read操作;对于插入而言并非如此（尽管我从未使用分片对插入进行基准测试）。因此，我不确定分片是否会帮助您满足您的要求。
请记住，Azure产品首先针对多租户环境中的可伸缩性和合理性能而设计，其中数据库与同一服务器上的其他人共享。因此，如果您需要有保证响应时间的强大性能，您可能需要重新评估您的主机选择，或者根据tijmenvdk的建议测试Azure的性能界限。