Azure SQL的DTU和eDTU到底是个什么鬼

Azure SQL 使用了数据库事务单位 (DTU) 和弹性数据库事务单位 (eDTU)来作为一个计量单位。

但是DTUeDTU是什么鬼啊

官方文档这样解释来着:

DTU 是一个资源度量单位,表示保证可用于单一数据库服务层内特定性能级别的单个 Azure SQL 数据库的资源。 DTU是一定比例的 CPU、内存和数据 I/O以及事务日志 I/O的混合度量值,该比例由 OLTP基准工作负荷决定(OLTP基准工作负荷代表真实的 OLTP工作负荷)。

这段话说起来非常的难于理解的,所谓的一定比例的CPU、内存和数据库I/O这个就摸不着头了。 然后这些资源的比例又是按照OLTP的基准工作负荷来决定。OLTP基准工作负荷这个又是一个新东西,参见:https://www.azure.cn/documentation/articles/sql-database-benchmark-overview/

 

其实DTU简单理解就是衡量Azure提供的SQL服务计算能力的一个指标。这个指标越大,SQL的计算能力越强。如100DTU5DTU就应该是强20倍。


Azure SQL的DTU和eDTU到底是个什么鬼_第1张图片

DTU的性能评估,可以参看下表:

 

服务层

基本

S0

S1

S2

S3

P1

P2

P4

P6

P11

P15

最大 DTU

5

10

20

50

100

125

250

500

1000

1750

4000

最大数据库大小

2 GB

250 GB

250 GB

250 GB

250 GB

500 GB

500 GB

500 GB

500 GB

1 TB

1 TB

最大内存 OLTP 存储

不适用

不适用

不适用

不适用

不适用

1 GB

2 GB

4 GB

8 GB

14 GB

32 GB

最大并发辅助进程数

30

60

90

120

200

200

400

800

1600

2400

6400

最大并发登录数

30

60

90

120

200

200

400

800

1600

2400

6400

最大并发会话数

300

600

900

1200

2400

30000

30000

30000

30000

30000

30000

可以从上表上对应于本地数据库的性能采集的指标,可以估算出应该使用什么样级别的AZURE SQL。 当然服务层选择后仍然可以进行更改。

 

对于自己应用应该用多大规模的DTU,可以进行详细的评估,可以使用下面工具

Azure SQL Database DTU Calculator

关于如何评估,等有机会在写一篇

 

所以,DTU这个鬼来说就理解为Azure数据库的性能评估单位 。

那么问题又来了什么是eDTU,DTU虽然不太好理解,但是从构架来说,不外乎就是为应用提供数据库服务,也即是我们常用的模型,使用起来也简单。我们称之为单一数据库。要理解eDTU我们先要讲讲什么是Azure 弹性数据库。

但是在云的时代就有一个典型的问题存在:所有应用几乎都会有峰值和低谷。而单一数据库一旦分配,资源就已经提供,没有高峰和低谷的区别。那么如何解决这样的问题呢。通常有两个选项:(1) 基于高峰使用情况过度设置资源,因此需要支付额外的费用,或者 (2) 为了节省成本而采用低配,但在高峰期间会出现性能下降而导致客户满意度降低。

弹性数据库就是为了解决这样的问题而诞生。弹性池通过确保数据库在需要时获得所需的性能资源来解决此问题。它们在可预测的预算内提供简单的资源分配机制。

其实这样理解,我们可以创建一个弹性的数据库池,而多个数据库使用这个池,充分利用池的资源。池很适合具有特定使用模式的大量数据库。对于给定的数据库,此模式的特征是低平均使用量与相对不频繁的使用高峰。可以加入池的数据库越多,就可以节省更多的成本。具体取决于应用程序使用模式,你可能会看到与使用两个 S3 数据库相同的成本节约。

 下图显示了一个数据库示例,该数据库有大量的闲置时间,但也会定期出现活动高峰。这是适合池的使用模式:

Azure SQL的DTU和eDTU到底是个什么鬼_第2张图片

在所示的五分钟时间段内,DB1 高峰最高达到 90 个 DTU,但其整体平均使用量低于五个 DTU。在单一数据库中,运行此工作负荷需要 S3 性能级别,但在低活动期间,大多数资源都处在未使用的状态。

池可让这些未使用的 DTU 跨多个数据库共享,因此减少了所需的 DTU 数和总体成本。

 

以上一个示例为基础,假设有其他数据库具有与 DB1 类似的使用模式。在接下来的两个图形中,4 个数据库和 20 个数据库的使用量分层放在相同的图形上,以说明随时间推移,它们的使用率非重叠的性质:

Azure SQL的DTU和eDTU到底是个什么鬼_第3张图片

Azure SQL的DTU和eDTU到底是个什么鬼_第4张图片

在上图中,黑线表示跨所有 20 个数据库的聚合 DTU 使用量。其中表明聚合 DTU 使用量永远不会超过 100 个DTU,并指出 20 个数据库可以在此时间段内共享 100 个 eDTU。相比于将每个数据库放在单一数据库的 S3 性能级别,这会导致 DTU 减少 20 倍,价格降低 13倍。

 

由于以下原因,此示例很理想:

•每一数据库之间的高峰使用量和平均使用量有相当大的差异。

•每个数据库的高峰使用量在不同时间点发生。

•eDTU 将在多个数据库之间共享。

 

池的价格取决于池的 eDTU。尽管池的 eDTU 单位价格比单一数据库的 DTU 单位价格多 1.5 倍,但池eDTU 可由多个数据库共享,因而所需的 eDTU 总数更少。定价方面和 eDTU 共享的这些差异是池可以提供成本节省可能性的基础。

 

所以eDTU一个池化DTU的概念,单一数据库性能可以动态的进行调节,而池中的数据库也可以进行添加删除。

 

更多相关信息和详细信息可以参考如下:

https://www.azure.cn/documentation/services/sql-databases/

 

 

你可能感兴趣的:(技术文章,SQL,Server,Azure)