Azure 太容易达到数据库 CPU 限制

Question

背景简介：- 我们有一个包含以下主要组件的 SAAS 解决方案。 1. 我们有一个门户网站后端，管理员可以在其中编辑数据。 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，并发呼叫不止1个。
2. DTU为1500，并发呼叫5个及以上。
3. DTU 为 4000 且有 20 个或更多并发呼叫。

因此，我们与 Microsoft 建立了支持电话。 我们花了一个多星期的时间来调查从 sql 统计数据和索引到 web api 定价层的事情。 毕竟，在上述场景中，我们仍然找到了 SQL 数据库中 CPU 达到峰值的证据。

这导致不可避免的“重写系统的大块”之类的争论。

因此，根本问题是弹性数据库池的性能似乎无法达到标准 SQL 数据库的能力。 此外，单机数据库的性能似乎无法与虚拟服务器的性能竞争。

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

Answer 1

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

在本地环境中，我们习惯于强大的机器，这些机器足够强大，可以处理繁重的工作负载。这是因为物理机器是使用所需资源构建的，以处理具有繁重处理的大型工作负载（为它们需要处理的最大任务而不是最小任务而构建）。由于资源的过度可用性，我们经常允许效率低下的情况用于查询和底层模式。由于资源过剩，影响通常很小。

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

因此，为了改善您的情况，如果您愿意为此付费，您可以随时增加您在 Azure 中的资源。或者，您可以按照其他人的建议进行操作并优化您的查询和底层架构，并在每次执行此操作时实现成本节约。

Answer 2

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

Answer 3

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

DTU 的测量方式意味着任何真正强大的 SQL 工作都应该在 sql 数据池之外进行处理；但是数据池中的数据操作应该尽可能的流畅（索引、更新的统计数据、连接中可能的最少字段）。

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