Question

背景简而言之： - 我们有一个SAAS解决方案，其中包含以下主要组件。 1.我们有一个Web门户后端，管理员可以在其中编辑数据。 2.我们有一个由移动设备调用的Web API。移动设备跟踪或报告学生阅读进度

到目前为止，解决方案已托管在虚拟服务器上。现在我们将解决方案迁移到Azure框架，以便我们可以利用弹性数据库池的可伸缩性。当邮件可以异步处理时，我们正在使用事件主题来处理来自移动设备的大量帖子，但是有一些帖子需要同步处理，我们发现Azure的结构在多个并发连接方面确实很慢。

问题的一个例子： -

因此，当Azure运行如下查询时： -

SELECT q.Category, COUNT(*)
FROM Question q
JOIN Answer a
ON a.QuestionId = q.QuestionId
GROUP BY q.Category
ORDER BY q.Category

在以下所有情况下，SQL CPU均高于97％： -
1. DTU是50，并且有多个并发呼叫 2. DTU是1500，并且有5个或更多并发呼叫 3. DTU是4000并且有20个或更多并发呼叫。

所以我们与微软开了一个支持电话。我们花了一周多的时间研究从sql统计和索引到web api定价层的事情。毕竟，我们仍然提出了证据表明CPU在SQL数据库中达到了上述情况。

这导致不可避免的“重写你的系统的大块”这种论点。

因此，潜在的问题是弹性数据库池似乎无法在标准SQL数据库的能力附近执行。此外，独立数据库的性能似乎与虚拟服务器的性能无法竞争。

这非常令人沮丧，因为我们建议使用Elastic数据库池，以保持性能和增加可伸缩性。我们目前在一台虚拟服务器上运行700多个客户;并期望为每个客户创建一个分片数据库。我们的想法是，我们可以从数百个客户扩展到成千上万的客户。实际上，我们正在努力使Azure结构能够在虚拟服务器上具有的性能附近执行。所以这个问题是要问是否有任何人在使Azure以合理的速度执行重要任务方面具有丰富的经验？（最好不必重写系统的大块）

Answer 1

简而言之;事实证明，sql数据池的工作方式需要更优化的查询。

测量DTU的方式意味着任何非常强大的SQL工作都应该在sql数据池之外进行处理;但数据池内的数据操作应该尽可能顺利（索引，统计更新，连接中可能的字段最少）。

事实证明，这就是Azure的工作方式。

Answer 2

将SQL数据库迁移到云时需要转变思路。

在本地化的世界中，我们习惯于功能强大的机器，这些机器足以应对繁重的工作负载。这是因为物理机器使用所需的资源构建，以处理繁重处理的大型工作负载（为他们需要处理的最大任务而不是最小的任务而构建）。由于资源过多，我们通常会将低效率用于查询和底层模式。由于资源过剩，影响通常很小。

但是，然后你尝试将这些相同的数据库移动到Azure中，而且事情也不是很好。请记住，Azure是一种按使用付费的模型。您为Y资源支付X，当您需要更多时，您需要支付更多X以获得更多Y.由于这种模式，您必须考虑到您在数据库中所做的一切实际上都会花费您的钱。每个查询都要花钱。每一个低效率都会花费你越来越多的钱。等等。当每个月明确支付资源时，我们倾向于购买（通常是最小的任务），因为我们觉得我们正在浪费钱。这意味着当偶尔需要运行大型任务时，我们没有足够的资源来处理它并且性能下降。这使我们认为Azure成本更高但性能更差。

因此，为了改善您的情况，如果您愿意为此付费，可以随时增加Azure中的资源。或者您可以像其他人一样建议并优化您的查询和底层模式，并在每次执行时节省成本。

Answer 3

如果您在原始表中使用 nvarchar(max) 或 varchar(max) 创建弹性表，当查询包含这些字段时，这将大大减慢速度。唯一的解决方案是将这些字段限制为 varchar (x)，其中 x 是您的最大数据长度。这对我的弹性查询产生了巨大的影响，从 35 分钟到 12 秒。

Azure太容易命中数据库cpu限制

3 个答案: