微软Azure解密-Azure SQL的DTU和eDTU介绍

1、 Microsoft Azure解密Azure SQL的DTU和eDTU介绍Azure SQL使用了数据库事务单位（DTU）和弹性数据库事务单位（eDTU）来作为一个计量单位。但是DTU和eDTU是什么鬼啊？DTU是一个资源度量单位，表示保证可用于单一数据库服务层内特定性能级别的单个Azure SQL数据库的资源。DTU是一定比例的CPU、内存和数据I/O以及事务日志I/O的混合度量值，该比例由OLTP基准工作负荷决定（OLTP基准工作负荷代表真实的OLTP工作负荷）。这段话说起来非常的难于理解的，所谓的一定比例的CPU、内存和数据库I/O这个就摸不着头了。 然后这些资源的比例又是按照OLTP

2、的基准工作负荷来决定。OLTP基准工作负荷这个又是一个新东西，参见：/documentation/articles/sql-database-benchmark-overview/DTU简单理解就是衡量Azure提供的SQL服务计算能力的一个指标。这个指标越大，SQL的计算能力越强。如100个DTU比5个DTU就应该是强20倍。而DTU的性能评估，可以参看下表：可以从上表上对应于本地数据库的性能采集的指标，可以估算出应该使用什么样级别的AzureSQL。 当然服务层选择后仍然可以进行更改。对于自己应用应该用多大规模的DTU，可以进行详细的评估，可以使用下面工具Azure SQL Databas

3、e DTU Calculator：/关于如何评估，等有机会再写一篇。所以，DTU这个鬼来说就理解为Azure数据库的性能评估单位 。那么问题又来了，什么是eDTU，DTU虽然不太好理解，但是从构架来说，不外乎就是为应用提供数据库服务，也即是我们常用的模型，使用起来也简单。我们称之为单一数据库。要理解eDTU我们先要讲讲什么是Azure弹性数据库。但是在云的时代就有一个典型的问题存在：所有应用几乎都会有峰值和低谷。而单一数据库一旦分配，资源就已经提供，没有高峰和低谷的区别。那么如何解决这样的问题呢。通常有两个选项：(1) 基于高峰使用情况过度设置资源，因此需要支付额外的费用，或者 (2) 为了节

4、省成本而采用低配，但在高峰期间会出现性能下降而导致客户满意度降低。弹性数据库就是为了解决这样的问题而诞生。弹性池通过确保数据库在需要时获得所需的性能资源来解决此问题。它们在可预测的预算内提供简单的资源分配机制。这样理解，我们可以创建一个弹性的数据库池，而多个数据库使用这个池，充分利用池的资源。池很适合具有特定使用模式的大量数据库。对于给定的数据库，此模式的特征是低平均使用量与相对不频繁的使用高峰。可以加入池的数据库越多，就可以节省更多的成本。具体取决于应用程序使用模式，你可能会看到与使用两个S3数据库相同的成本节约。下图显示了一个数据库示例，该数据库有大量的闲置时间，但也会定期出现活动高峰。这

5、是适合池的使用模式：在所示的五分钟时间段内，DB1高峰最高达到90个DTU，但其整体平均使用量低于五个DTU。在单一数据库中，运行此工作负荷需要S3性能级别，但在低活动期间，大多数资源都处在未使用的状态。池可让这些未使用的DTU跨多个数据库共享，因此减少了所需的DTU数和总体成本。以上一个示例为基础，假设有其他数据库具有与DB1类似的使用模式。在接下来的两个图形中，4个数据库和20个数据库的使用量分层放在相同的图形上，以说明随时间推移，它们的使用率非重叠的性质：在上图中，黑线表示跨所有20个数据库的聚合DTU使用量。其中表明聚合DTU使用量永远不会超过100个DTU，并指出20个数据库可以在此时间段内共享100个eDTU。相比于将每个数据库放在单一数据库的S3性能级别，这会导致DTU减少20倍，价格降低13倍。由于以下原因，此示例很理想：每一数据库之间的高峰使用量和平均使用量有相当大的差异。每个数据库的高峰使用量在不同时间点发生。eDTU将在多个数据库之间共享。池的价格取决于池的eDTU。尽管池的eDTU单位价格比单一数据库的DTU单位价格多1.5倍，但池eDTU可由多个数据库共享，因而所需的eDTU