以 DTU 為基礎的購買模式的服務層Service tiers in the DTU-based purchase model

以 DTU 為基礎的購買模式的服務層是以一系列計算大小來做區分,這些等級各有一定數量的內含儲存體、一定的備份保留期和一定的價格。Service tiers in the DTU-based purchase model are differentiated by a range of compute sizes with a fixed amount of included storage, fixed retention period for backups, and fixed price. 以 DTU 為基礎的購買模型中的所有服務層級,在停機時間最短的情況之下,提供變更計算大小的彈性不過,有一段很短的時間會將連線中斷連接到資料庫,而這可以使用重試邏輯來減輕。All service tiers in the DTU-based purchase model provide flexibility of changing compute sizes with minimal downtime; however, there is a switch over period where connectivity is lost to the database for a short amount of time, which can be mitigated using retry logic. 單一資料庫和彈性集區會根據服務層級和計算大小,以每小時為單位來計費。Single databases and elastic pools are billed hourly based on service tier and compute size.

重要

SQL Database 受控執行個體不支援以 DTU 為基礎的購買模型。SQL Database managed instance does not support a DTU-based purchasing model. 如需詳細資訊,請參閱 Azure SQL Database 受控執行個體For more information, see Azure SQL Database Managed Instance.

注意

如需以虛擬核心為基礎之服務層級的相關資訊,請參閱以虛擬核心為基礎的服務層級For information about vCore-based service tiers, see vCore-based service tiers. 如需如何區分以 DTU 為基礎及以虛擬核心為基礎之服務層的相關資訊,請參閱 Azure SQL Database 購買模型For information about differentiating DTU-based service tiers and vCore-based service tiers, see Azure SQL Database purchasing models.

比較以 DTU 為基礎的服務層級Compare the DTU-based service tiers

服務層級的選擇主要視業務持續性、儲存體和效能需求而定。Choosing a service tier depends primarily on business continuity, storage, and performance requirements.

基本Basic 標準Standard 進階Premium
目標工作負載Target workload 開發與生產Development and production 開發與生產Development and production 開發與生產Development and production
執行時間 SLAUptime SLA 99.99%99.99% 99.99%99.99% 99.99%99.99%
備份保留Backup retention 7 天7 days 35 天35 days 35 天35 days
CPUCPU Low 低、中、高Low, Medium, High 中、高Medium, High
IO 輸送量 (大約)IO throughput (approximate) 1-5 每個 DTU 的 IOPS1-5 IOPS per DTU 1-5 每個 DTU 的 IOPS1-5 IOPS per DTU 每個 DTU 25 IOPS25 IOPS per DTU
IO 延遲 (大約)IO latency (approximate) 5 毫秒 (讀取),10 毫秒 (寫入)5 ms (read), 10 ms (write) 5 毫秒 (讀取),10 毫秒 (寫入)5 ms (read), 10 ms (write) 2 毫秒 (讀取/寫入)2 ms (read/write)
資料行存放區索引Columnstore indexing N/AN/A S3 和更新版本S3 and above 支援Supported
記憶體內部 OLTPIn-memory OLTP N/AN/A N/AN/A 支援Supported

注意

您可以在基本服務層級取得免費的 Azure SQL 資料庫,並搭配 Azure 免費帳戶來探索 Azure。You can get a free Azure SQL database at the Basic service tier in conjunction with an Azure free account to explore Azure. 如需相關資訊,請參閱使用您的免費 Azure 免費帳戶,建立受管理的雲端資料庫For information, see Create a managed cloud database with your Azure free account.

單一資料庫 DTU 和儲存空間限制Single database DTU and storage limits

單一資料庫的計算大小會以資料庫交易單位 (DTU) 表示,而彈性集區的計算大小則會以彈性資料庫交易單位 (eDTU) 表示。Compute sizes are expressed in terms of Database Transaction Units (DTUs) for single databases and elastic Database Transaction Units (eDTUs) for elastic pools. 如需 DTU 和 eDTU 的詳細資訊,請參閱以 DTU 為基礎的購買模型For more on DTUs and eDTUs, see DTU-based purchasing model?

基本Basic 標準Standard 進階Premium
儲存體大小上限Maximum storage size 2 GB2 GB 1 TB1 TB 4 TB4 TB
DTU 上限Maximum DTUs 55 30003000 40004000

重要

在某些情況下,您可能需要壓縮資料庫來回收未使用的空間。Under some circumstances, you may need to shrink a database to reclaim unused space. 如需詳細資訊,請參閱管理 Azure SQL Database 中的檔案空間For more information, see Manage file space in Azure SQL Database.

彈性集區 eDTU、儲存體及集區資料庫限制Elastic pool eDTU, storage, and pooled database limits

基本Basic 標準Standard 高級Premium
每個資料庫的儲存體大小上限Maximum storage size per database 2 GB2 GB 1 TB1 TB 1 TB1 TB
每個集區的儲存體大小上限Maximum storage size per pool 156 GB156 GB 4 TB4 TB 4 TB4 TB
每個資料庫的 eDTU 上限Maximum eDTUs per database 55 30003000 40004000
每個集區的 eDTU 上限Maximum eDTUs per pool 16001600 30003000 40004000
每個集區的資料庫數目上限Maximum number of databases per pool 500500 500500 100100

重要

所有區域目前均可使用進階層中超過 1 TB 的儲存體,但下列區域除外:中國東部、中國北部、德國中部、德國東北部、美國中西部、美國 DoD 區域和美國政府中部。More than 1 TB of storage in the Premium tier is currently available in all regions except: China East, China North, Germany Central, Germany Northeast, West Central US, US DoD regions, and US Government Central. 在這些區域中,進階層中的儲存空間上限為 1 TB。In these regions, the storage max in the Premium tier is limited to 1 TB. 如需詳細資訊,請參閱 P11-P15 目前的限制For more information, see P11-P15 current limitations.

重要

在某些情況下,您可能需要壓縮資料庫來回收未使用的空間。Under some circumstances, you may need to shrink a database to reclaim unused space. 如需詳細資訊,請參閱管理 Azure SQL Database 中的檔案空間For more information, see manage file space in Azure SQL Database.

DTU 基準測試DTU Benchmark

我們會使用模擬現實資料庫工作負載的基準,來校準與每個 DTU 量值相關聯的實體特性 (CPU、記憶體、IO)。Physical characteristics (CPU, memory, IO) associated to each DTU measure are calibrated using a benchmark that simulates real-world database workload.

建立基準測試結果與實際案例資料庫效能之間的關聯Correlating benchmark results to real world database performance

請務必了解,所有基準測試都只具備代表性與指標性。It is important to understand that all benchmarks are representative and indicative only. 利用基準測試應用程式達成的交易速率與利用其他應用程式可能達成的交易速率不同。The transaction rates achieved with the benchmark application will not be the same as those that might be achieved with other applications. 基準測試是由不同的交易類型集合所組成,這些類型是針對包含某個範圍的資料表和資料類型的結構描述來執行。The benchmark comprises a collection of different transaction types run against a schema containing a range of tables and data types. 雖然基準測試會執行所有 OLTP 工作負載常見的相同基本作業,但是它不代表任何特定類別的資料庫或應用程式。While the benchmark exercises the same basic operations that are common to all OLTP workloads, it does not represent any specific class of database or application. 基準測試的目標是提供資料庫相對效能的合理指南,在計算大小之間向上或向下調整時可預期此目標。The goal of the benchmark is to provide a reasonable guide to the relative performance of a database that might be expected when scaling up or down between compute sizes. 實際上,資料庫的大小和複雜度都不一樣,會遭遇到不同的工作負載混合,並以不同的方式回應。In reality, databases are of different sizes and complexity, encounter different mixes of workloads, and will respond in different ways. 例如,IO 密集的應用程式可能會更快達到 IO 臨界值,或者 CPU 密集應用程式可能會更快達到 CPU 限制。For example, an IO-intensive application may hit IO thresholds sooner, or a CPU-intensive application may hit CPU limits sooner. 任何特定的資料庫並不保證能夠在增加負載的情況下使用和基準測試相同的方式調整。There is no guarantee that any particular database will scale in the same way as the benchmark under increasing load.

基準測試和其方法會在以下詳細描述。The benchmark and its methodology are described in more detail below.

基準測試摘要Benchmark summary

基準測試可測量基本資料庫作業混合的效能,這些作業最常發生在線上交易處理 (OLTP) 工作負載中。The benchmark measures the performance of a mix of basic database operations that occur most frequently in online transaction processing (OLTP) workloads. 雖然基準測試在設計時考量到雲端運算,但是資料庫結構描述、資料母體和交易的設計都廣泛代表 OLTP 工作負載中最常使用的基本元素。Although the benchmark is designed with cloud computing in mind, the database schema, data population, and transactions have been designed to be broadly representative of the basic elements most commonly used in OLTP workloads.

架構Schema

結構描述的設計具有足夠的多樣性和複雜性才能支援廣泛的作業。The schema is designed to have enough variety and complexity to support a broad range of operations. 對包含六個資料表的資料庫執行基準測試。The benchmark runs against a database comprised of six tables. 資料表分成三個類別:固定大小、調整和成長。The tables fall into three categories: fixed-size, scaling, and growing. 有兩個固定大小資料表、三個調整資料表,和一個成長資料表。There are two fixed-size tables; three scaling tables; and one growing table. 固定大小資料表有固定數目的資料列。Fixed-size tables have a constant number of rows. 調整資料表有與資料庫效能成正比但不會在基準測試期間變更的基數。Scaling tables have a cardinality that is proportional to database performance, but doesn’t change during the benchmark. 成長資料表的大小在初始載入時類似調整資料表,但是在執行基準測試做為資料列的過程中,會插入並刪除基數變更。The growing table is sized like a scaling table on initial load, but then the cardinality changes in the course of running the benchmark as rows are inserted and deleted.

結構描述包含資料類型的混合,包括整數、數值、字元和日期/時間。The schema includes a mix of data types, including integer, numeric, character, and date/time. 結構描述包含主要和次要索引鍵,但不含任何外部索引鍵 - 也就是資料表之間沒有參考完整性條件約束。The schema includes primary and secondary keys, but not any foreign keys - that is, there are no referential integrity constraints between tables.

資料產生程式會產生初始資料庫的資料。A data generation program generates the data for the initial database. 運用各種策略產生整數和數值資料。Integer and numeric data is generated with various strategies. 在某些情況下,會在某範圍中隨機分佈值。In some cases, values are distributed randomly over a range. 在其他情況下,會隨機排列一組值以確保維護特定的分佈。In other cases, a set of values is randomly permuted to ensure that a specific distribution is maintained. 從文字的加權清單產生文字欄位以產生實際的查看資料。Text fields are generated from a weighted list of words to produce realistic looking data.

資料庫的大小是根據「縮放比例」來設定。The database is sized based on a “scale factor.” 縮放比例 (簡寫為 SF) 可決定調整和成長資料表的基數。The scale factor (abbreviated as SF) determines the cardinality of the scaling and growing tables. 如以下的<使用者與步調>一節所述,資料庫大小、使用者數目和最大效能都會根據彼此的比例進行調整。As described below in the section Users and Pacing, the database size, number of users, and maximum performance all scale in proportion to each other.

交易Transactions

工作負載包含九種交易類型,如下表所示。The workload consists of nine transaction types, as shown in the table below. 每一筆交易都設計為反白顯示資料庫引擎和系統硬體中特定的一組系統特性,與其他交易呈現高度對比。Each transaction is designed to highlight a particular set of system characteristics in the database engine and system hardware, with high contrast from the other transactions. 此方法可讓您更容易評估不同元件對整體效能的影響。This approach makes it easier to assess the impact of different components to overall performance. 例如,「頻繁讀取」交易會從磁碟產生大量的讀取作業。For example, the transaction “Read Heavy” produces a significant number of read operations from disk.

交易類型Transaction Type 描述Description
輕度讀取Read Lite SELECT;記憶體中;唯讀SELECT; in-memory; read-only
中度讀取Read Medium SELECT;大部分記憶體中;唯讀SELECT; mostly in-memory; read-only
重度讀取Read Heavy SELECT;大部分非記憶體中;唯讀SELECT; mostly not in-memory; read-only
輕度更新Update Lite UPDATE;記憶體中;讀寫UPDATE; in-memory; read-write
重度更新Update Heavy UPDATE;大部分非記憶體中;讀寫UPDATE; mostly not in-memory; read-write
輕度插入Insert Lite INSERT;記憶體中;讀寫INSERT; in-memory; read-write
重度插入Insert Heavy INSERT;大部分非記憶體中;讀寫INSERT; mostly not in-memory; read-write
DELETEDelete DELETE;記憶體中與非記憶體中的混合;讀寫DELETE; mix of in-memory and not in-memory; read-write
重度 CPUCPU Heavy SELECT;記憶體中;非常重度的 CPU 負載;唯讀SELECT; in-memory; relatively heavy CPU load; read-only

工作負載混合Workload mix

利用下列整體混合從加權分佈中隨機選取交易。Transactions are selected at random from a weighted distribution with the following overall mix. 整體混合具有大約 2:1 的讀/寫比率。The overall mix has a read/write ratio of approximately 2:1.

交易類型Transaction Type 混合 %% of Mix
輕度讀取Read Lite 3535
中度讀取Read Medium 2020
重度讀取Read Heavy 55
輕度更新Update Lite 2020
重度更新Update Heavy 33
輕度插入Insert Lite 33
重度插入Insert Heavy 22
DELETEDelete 22
重度 CPUCPU Heavy 1010

使用者與步調Users and pacing

基準測試工作負載是由一個工具觸發,它會跨一組連接提交交易,以模擬許多並行使用者的行為。The benchmark workload is driven from a tool that submits transactions across a set of connections to simulate the behavior of a number of concurrent users. 雖然所有的連接和交易都是由電腦產生,為了簡單起見,我們將這些連接視為「使用者」。Although all of the connections and transactions are machine generated, for simplicity we refer to these connections as “users.” 雖然每一位使用者都獨立於其他所有使用者操作,但是所有使用者都執行相同的步驟循環,如下所示:Although each user operates independently of all other users, all users perform the same cycle of steps shown below:

  1. 建立資料庫連接。Establish a database connection.
  2. 發出結束訊號之前請重複:Repeat until signaled to exit:
    • 隨機選取交易 (從加權分佈中)。Select a transaction at random (from a weighted distribution).
    • 執行選取的交易及測量回應時間。Perform the selected transaction and measure the response time.
    • 等候步調延遲。Wait for a pacing delay.
  3. 關閉資料庫連接。Close the database connection.
  4. [結束]。Exit.

步調延遲 (在步驟 2c) 為隨機選取,但其分佈具有 1.0 秒的平均值。The pacing delay (in step 2c) is selected at random, but with a distribution that has an average of 1.0 second. 因此每位使用者平均每秒可以產生最多一筆交易。Thus each user can, on average, generate at most one transaction per second.

調整規則Scaling rules

使用者數目取決於資料庫大小 (以縮放比例單位表示)。The number of users is determined by the database size (in scale-factor units). 每五個縮放比例單位有一名使用者。There is one user for every five scale-factor units. 由於步調延遲,一位使用者平均每秒可以產生最多一筆交易。Because of the pacing delay, one user can generate at most one transaction per second, on average.

例如,縮放比例為 500 (SF = 500) 的資料庫會有 100 位使用者,並可達到最大速率 100 TPS。For example, a scale-factor of 500 (SF=500) database will have 100 users and can achieve a maximum rate of 100 TPS. 若要觸發更高的 TPS 速率,需要更多使用者和更大的資料庫。To drive a higher TPS rate requires more users and a larger database.

測量持續時間Measurement duration

有效的基準測試執行需要至少一個小時的穩定狀態測量持續時間。A valid benchmark run requires a steady-state measurement duration of at least one hour.

計量Metrics

基準測試中的關鍵度量是輸送量和回應時間。The key metrics in the benchmark are throughput and response time.

  • 輸送量是基準測試中的基礎效能測量。Throughput is the essential performance measure in the benchmark. 每個單位時間都會在交易中報告輸送量,計算所有交易類型。Throughput is reported in transactions per unit-of-time, counting all transaction types.
  • 回應時間是效能可預測性的測量。Response time is a measure of performance predictability. 回應時間條件約束會隨服務類別而有所不同,較高等級的服務類別有更嚴格的回應時間需求,如下所示。The response time constraint varies with class of service, with higher classes of service having a more stringent response time requirement, as shown below.
服務類別Class of Service 輸送量測量Throughput Measure 回應時間需求Response Time Requirement
進階Premium 每秒交易數Transactions per second 0.5 秒時第 95 個百分位數95th percentile at 0.5 seconds
標準Standard 每分鐘交易Transactions per minute 1.0 秒時第 90 個百分位數90th percentile at 1.0 seconds
基本Basic 每小時交易Transactions per hour 2.0 秒時第 80 個百分位數80th percentile at 2.0 seconds

後續步驟Next steps