本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 帳單在 Aurora DSQL 中的運作方式
使用 Amazon Aurora DSQL 時，您只需為所使用的項目付費，無需預付費用。本節說明 Aurora DSQL 如何計量您的資料庫活動，並將其轉換為 AWS 帳單上的費用。如需依區域列出的目前定價，請參閱 [Aurora DSQL 定價頁面](https://aws.amazon.com/rds/aurora/dsql/pricing/)。
**Topics**
+ [計量的運作方式](#billing-how-metering-works)
+ [DPU 元件計量說明](#billing-dpu-components)
+ [多區域計費](#billing-multiregion-write-dpu)
+ [使用 CloudWatch 監控 DPU 用量](#billing-cloudwatch-monitoring)
+ [使用 EXPLAIN ANALYZE VERBOSE 提高成本意識](#billing-explain-analyze)
+ [成本估算最佳實務](#billing-best-practices)
## 計量的運作方式
與收取佈建容量費用的傳統資料庫不同，Aurora DSQL 只會收取實際執行的工作費用。Aurora DSQL 會測量兩個主要元件：以分散式處理器 (DPUs) 測量的資料庫活動，以及以 GiB 月測量的儲存。
DPUs會測量系統執行 SQL 工作負載的工作量，並包含單一區域叢集的三個元件：運算 DPUs、讀取 DPUs 和寫入 DPUs。多區域叢集會產生額外的MultiRegion寫入 DPU 元件。如需詳細資訊，請參閱[多區域計費](#billing-multiregion-write-dpu)。
下表摘要說明 Aurora DSQL 用來計量資料庫活動的元件。在帳單上，您只會看到兩個明細項目：一個用於儲存，另一個用於 DPU，這是每個個別元件的總和。
| 計量單位 | 活動類型 | 測量 |
| --- | --- | --- |
| 運算 DPU | 查詢處理 | CPU 時間 |
| 讀取 DPU | 從資料庫讀取資料 | 從儲存體讀取的位元組數 |
| 寫入 DPU | 將資料寫入資料庫 | 寫入儲存體的位元組 |
| 儲存 | 資料表儲存 | GiB-月 |
## DPU 元件計量說明
對於每筆交易，Aurora DSQL 會將總 DPU 計算為三個元件的總和：運算 DPU、讀取 DPU 和寫入 DPU。下列各節說明 Aurora DSQL 如何計量每個元件。
```
Total DPU = ComputeDPU + ReadDPU + WriteDPU
```
### ComputeDPU
運算 DPUs是使用執行查詢所花費的總處理時間來測量，包括聯結、函數、彙總、排序和查詢規劃。由於部分查詢可以平行處理，因此運算 DPU 會反映所有處理時間的總和，而不是查詢的時鐘時間。
下列公式摘要說明如何計算運算 DPUs：
```
ComputeDPU = Total Compute time (in seconds)
```
### WriteDPU
對於每筆交易，Aurora DSQL 會測量寫入 DPUs 的寫入總位元組數。寫入 DPUs包含寫入基礎資料表的總資料，以及任何次要索引。Aurora DSQL 會將寫入基礎資料表的每個資料列和小於 128 個位元組的次要索引計費，就好像是 128 個位元組一樣。Aurora DSQL 會計費寫入小於 1，024 個位元組的寫入交易，就好像寫入 1，024 個位元組一樣。
**注意**
寫入操作也會產生 ReadDPU 費用，因為 Aurora DSQL 會在寫入之前讀取主索引鍵來驗證唯一性。
下列公式顯示計算寫入 DPUs的步驟：
**步驟 1：計算寫入的位元組**
```
Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written
```
**步驟 2：計算 WriteDPU**
```
WriteDPU = max(Bytes Written, 1024) × 0.00004883
```
### ReadDPU
對於每筆交易，Aurora DSQL 會依據從儲存體讀取的總位元組數來測量讀取 DPUs。讀取 DPUs包含從基礎資料表讀取的資料，以及任何次要索引。
**每個分割區最小值：**Aurora DSQL 會測量每個儲存分割區的讀取位元組，而不是每一列。如果對儲存分割區的讀取請求傳回少於 128 個位元組，Aurora DSQL 會將其四捨五入至 128 個位元組。例如，如果您的查詢從 4 個分割區讀取，一個分割區讀取 200 個位元組，另一個分割區讀取 50 個位元組，則三個 50 個位元組的讀取會四捨五入至 128 個位元組，導致總計 200 \+ 128 \+ 128 \+ 128 = 584 個位元組計費。
**交易下限：**Aurora DSQL 會針對總計讀取少於 2，048 個位元組的讀取交易計費，就好像讀取 2，048 個位元組一樣。
下列公式顯示計算讀取 DPUs的步驟：
**步驟 1：計算位元組讀取**
```
Bytes Read = # of rows read × size of each row
```
**注意**
實際位元組讀取取決於您的資料在儲存分割區之間的分佈方式，因為每個分割區的 128 位元組下限會套用每個分割區。如果您的所有資料列大小都超過 128 個位元組，您可以直接將讀取的資料列數乘以每一列的大小。
**步驟 2：計算 ReadDPU**
```
ReadDPU = max(Bytes Read, 2048) × 0.00000183105
```
### 計費範例
下列範例示範 Aurora DSQL 如何計算常見操作DPUs。這些範例中的成本值使用 us-east-1 區域價格。如需其他區域的定價，請參閱 [Aurora DSQL 定價頁面](https://aws.amazon.com/rds/aurora/dsql/pricing/)。
#### 範例：簡易點查詢 （讀取）
此範例示範適用於交易下限的點查詢 ReadDPU 計算。
**結構描述：**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
```
**查詢：**
```
SELECT * FROM orders WHERE customer_id = 'cust-12345';
```
**案例：**查詢會傳回 5 個資料列，每個約 100 個位元組。假設所有資料列都位於一個儲存分割區中，讀取的總位元組數為 5 × 100 = 500 位元組。由於 500 個位元組超過每個分割區的 128 個位元組下限，因此不會套用每個分割區的下限。
**計算 ReadDPU：**
```
ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
```
交易下限為 2，048 個位元組，因為 500 < 2，048。
**總交易成本：**
假設查詢執行時間為 3 毫秒 (0.003 秒）：
```
ComputeDPU: 0.003
ReadDPU: 0.00375
WriteDPU: 0.0
-------------------
Total DPU: 0.00675
```
#### 範例：篩選範圍掃描 （讀取）
**結構描述：**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
-- Table contains 100 orders for customer 'cust-12345'
```
**查詢：**
```
SELECT * FROM orders
WHERE customer_id = 'cust-12345'
AND total_amount > 500.00;
```
**案例：**查詢會掃描 100 個資料列的客戶 'cust-12345'，但`total_amount > 500.00`篩選條件會將結果減少為僅傳回 10 個資料列。掃描所有 100 列的 Aurora DSQL 帳單。假設所有資料列都位於一個儲存分割區中，讀取的總位元組數為 100 × 100 = 10，000 個位元組。
**計算 ReadDPU：**
```
ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831
```
由於 10，000 個位元組超過 2，048 個位元組的交易下限，因此會使用實際的位元組讀取。
**交易總成本：**
假設查詢執行時間為 8 毫秒 (0.008 秒）：
```
ComputeDPU: 0.008
ReadDPU: 0.01831
WriteDPU: 0.0
-------------------
Total DPU: 0.02631
```
**重要**
為了將 ReadDPU 成本降至最低，請設計查詢和索引以僅掃描您需要的資料列。在此範例中，在 上新增索引`(customer_id, total_amount)`可能會允許查詢掃描較少的資料列。
#### 範例：單一插入 （讀取和寫入）
**結構描述：**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
```
**查詢：**
```
INSERT INTO orders (customer_id, total_amount, status)
VALUES ('cust-67890', 150.00, 'pending');
```
**案例：**插入 1 列，大約 100 個位元組。
**WriteDPU 計算：**
*步驟 1 - 計算寫入的位元組：*
```
1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes
```
*步驟 2 - 計算 WriteDPU：*
```
WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05
```
自 128 < 1，024 起，交易最少 1，024 個位元組適用。
**ReadDPU （主要金鑰檢查）：**
Aurora DSQL 會讀取主索引鍵索引，以在寫入之前驗證唯一性。這會產生交易最低讀取費用。
```
ReadDPU = 0.00375 (transaction minimum)
```
**交易總成本：**
假設查詢執行時間為 8 毫秒 (0.008 秒）：
```
ComputeDPU: 0.008
ReadDPU: 0.00375
WriteDPU: 0.05
-------------------
Total DPU: 0.06175
```
#### 範例：大量插入 （讀取和寫入）
**結構描述：**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
```
**查詢：**
```
INSERT INTO orders (customer_id, total_amount, status)
VALUES
('cust-001', 100.00, 'pending'),
('cust-002', 150.00, 'pending'),
... -- 100 rows total
('cust-100', 200.00, 'pending');
```
**案例：**插入 100 個資料列，每個資料列大約 100 個位元組。
**WriteDPU 計算：**
*步驟 1 - 計算寫入的位元組：*
```
100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes
```
*步驟 2 - 計算 WriteDPU：*
```
WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625
```
**ReadDPU （主要金鑰檢查）：**
Aurora DSQL 會讀取每一列的主索引鍵索引，以驗證唯一性。假設所有 100 個金鑰查詢都位於一個儲存分割區中，讀取的總位元組數為 100 × 16 位元組 (UUID) = 1，600 位元組：
```
ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
```
自 1，600 < 2，048 起，交易下限為 2，048 個位元組。
**交易總成本：**
假設查詢執行時間為 80 毫秒 (0.08 秒）：
```
ComputeDPU: 0.08
ReadDPU: 0.00375
WriteDPU: 0.625
-------------------
Total DPU: 0.70875
```
## 多區域計費
除了標準運算、讀取和寫入 DPU 之外，多區域叢集還會產生額外的MultiRegion寫入 DPUs元件。本節僅適用於多區域叢集。單一區域叢集不會產生此費用。
MultiRegion Write DPUs會測量寫入對等區域的總位元組數。由於 Aurora DSQL 會同步複寫您寫入對等區域的資料，因此MultiRegion寫入 DPU 值等同於寫入 DPU。Aurora DSQL 會在發出寫入的區域中收取此 DPU 的費用，而不是在對等區域中。
```
MultiRegionWriteDPU = WriteDPU
```
## 使用 CloudWatch 監控 DPU 用量
Aurora DSQL 會將用量指標發佈至 Amazon CloudWatch，讓您近乎即時地監控用量。
### 可用的 DPU 指標
**DPU 指標**
| CloudWatch 指標 | Description | 維度 |
| --- | --- | --- |
| WriteDPU | 寫入用量元件 | ClusterId |
| ReadDPU | 讀取用量元件 | ClusterId |
| ComputeDPU | 查詢處理元件 | ClusterId |
| MultiRegionWriteDPU | 多區域複寫 （僅限多區域叢集） | ClusterId |
| TotalDPU | 所有 DPU 元件的總和 | ClusterId |
### 檢視 DPU 指標
**在 CloudWatch 中檢視 DPU 指標**
1. 開啟 [CloudWatch 主控台](https://console.aws.amazon.com/cloudwatch)。
1. 導覽至**指標**，然後是 **AuroraDSQL**，然後是 **ClusterId**。
1. 選取您的叢集和您要監控的 DPU 指標。
**提示**
使用 DPU 指標**的總和**統計資料來查看一段時間的總用量。新增 **LAST** 標籤以查看最新的值。
### 其他可觀測性指標
如需 Aurora DSQL 指標和監控功能的完整清單，請參閱[Aurora DSQL 的監控和記錄](monitoring-overview.md)。
**可觀測性指標**
| 指標 | Description |
| --- | --- |
| ClusterStorageSize | 目前的儲存體大小，以位元組為單位 |
| TotalTransactions | 執行的交易總數 |
| ReadOnlyTransactions | 執行的唯讀交易 |
| QueryTimeouts | 超過時間限制的查詢 |
| OccConflicts | 由於 OCC 衝突而中止的交易 |
| BytesWritten | 寫入儲存體的原始位元組 |
| BytesRead | 從儲存體讀取的原始位元組 |
## 使用 EXPLAIN ANALYZE VERBOSE 提高成本意識
Aurora DSQL 延伸`EXPLAIN ANALYZE VERBOSE`到在輸出結束時包含陳述式層級的 DPU 用量預估。這可讓您立即查看查詢成本，協助您識別工作負載成本驅動因素、調整查詢效能，以及更好地預測資源用量。
**注意**
您必須使用 `EXPLAIN ANALYZE VERBOSE`（搭配 VERBOSE) 來查看 DPU 預估值。`EXPLAIN ANALYZE` 沒有 VERBOSE 的純 不會顯示 DPU 資訊。
### 範例 1：SELECT 查詢
```
EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;
```
```
QUERY PLAN
----------------------------------------------------
Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1)
Output: id, context
-> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Projections: id, context
-> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Query Identifier: qymgw1m77maoe
Planning Time: 11.415 ms
Execution Time: 4.528 ms
Statement DPU Estimate:
Compute: 0.01607 DPU
Read: 0.04312 DPU
Write: 0.00000 DPU
Total: 0.05919 DPU
```
在此範例中，SELECT 陳述式會執行純索引掃描，因此大部分成本來自讀取 DPU (0.04312)，代表從儲存和運算 DPU (0.01607) 擷取的資料，反映用於處理和傳回結果的運算資源。由於查詢不會修改資料，因此沒有寫入 DPU。總 DPU (0.05919) 是運算 \+ 讀取 \+ 寫入的總和。
### 範例 2：INSERT 查詢
```
EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');
```
```
QUERY PLAN
----------------------------------------------------
Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1)
-> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1)
Output: "*VALUES*".column1, "*VALUES*".column2
Query Identifier: jtkjkexhjotbo
Planning Time: 0.068 ms
Execution Time: 0.543 ms
Statement DPU Estimate:
Compute: 0.01550 DPU
Read: 0.00307 DPU (Transaction minimum: 0.00375)
Write: 0.01875 DPU (Transaction minimum: 0.05000)
Total: 0.03732 DPU
```
此陳述式主要執行寫入，因此大部分成本都與寫入 DPU 相關聯。運算 DPU (0.01550) 代表處理和插入值所完成的工作。讀取 DPU (0.00307) 反映次要系統讀取 （用於目錄查詢或索引檢查）。
請注意讀取和寫入 DPUs 旁的括號中顯示的交易下限。這些最小值適用於交易層級，這表示整個交易的總讀取或寫入 DPU 絕不會小於這些值。如果您使用 `EXPLAIN ANALYZE VERBOSE` 來預測成本，而且這是交易中唯一的陳述式，請使用交易最小值，而不是原始陳述式預估值。如果交易包含多個陳述式，則下限會套用至所有陳述式的彙總。由於在計費套用交易層級下限時`EXPLAIN ANALYZE VERBOSE`報告陳述式層級預估，因此這些值可能不會完全符合 CloudWatch 指標或帳單資料。
### 使用 DPU 資訊進行最佳化
每個陳述式 DPU 預估可讓您在執行時間之外最佳化查詢的強大方式。常用案例包括：
+ **成本感知：**了解查詢相對於其他查詢的成本。
+ **結構描述最佳化：**比較索引或結構描述變更對效能和資源效率的影響。
+ **預算規劃：**根據觀察到的 DPU 用量估計工作負載成本。
+ **查詢比較：**依其相對 DPU 耗用量評估替代查詢方法。
### 解譯 DPU 資訊
使用來自 的 DPU 資料時，請記住下列最佳實務`EXPLAIN ANALYZE VERBOSE`：
+ **以方向使用：**將報告的 DPU 視為了解查詢*相對*成本的方式，而不是與 CloudWatch 指標或帳單資料完全相符。因為`EXPLAIN ANALYZE VERBOSE`報告陳述式層級成本，而 CloudWatch 彙總交易層級活動，所以預期會有差異。CloudWatch 也包含`EXPLAIN ANALYZE VERBOSE`刻意排除的背景操作 （例如非同步 ANALYZE 或壓縮） 和交易額外負荷 (`BEGIN`/`COMMIT`)。
+ **使用代表性資料測試概念驗證：**執行概念驗證以評估成本時，請確定您的資料表包含與您預期生產工作負載類似的資料磁碟區和分佈。無論是否來自 `EXPLAIN ANALYZE VERBOSE`或 CloudWatch 指標，以空白或稀疏填入的資料表為基礎的 DPU 預估都不會反映實際成本。
+ 在分散式系統中，跨**執行的 DPU 變異性是正常**的，不表示錯誤。快取、執行計畫變更、並行、非同步 ANALYZE 等背景操作或資料分佈中的轉移等因素都可能導致相同的查詢消耗不同的資源，從一個執行到下一個執行。
+ **批次小型操作：**如果您的工作負載發出許多小型陳述式，請考慮在單一交易中將其批次處理為較大的寫入操作 （修改每次交易不得超過 10 MB，但讀取僅限於 5 分鐘交易逾時）。這會攤銷更多工作的交易最小值，並產生更有意義的成本預估。
+ **用於調校，而非計費：** 中的 DPU 資料`EXPLAIN ANALYZE VERBOSE`專為成本感知、查詢調校和最佳化而設計。它不是帳單等級指標。一律依賴 CloudWatch 指標或每月帳單報告，以取得授權成本和用量資料。
## 成本估算最佳實務
+ 在**最佳化之前進行監控：**在做出最佳化決策之前，使用 CloudWatch 指標來了解您目前的使用模式。如需詳細資訊，請參閱[使用 CloudWatch 監控 DPU 用量](#billing-cloudwatch-monitoring)。
+ **專注於交易效率：**由於最低金額適用於交易層級，因此請同時批次相關操作，以攤銷最低費用。
+ 在**開發期間使用 EXPLAIN ANALYZE VERBOSE：**在開發期間`EXPLAIN ANALYZE VERBOSE`對關鍵查詢執行 ，以了解其成本特性。執行概念驗證以評估成本時，請針對具有代表性資料磁碟區和分佈的資料表進行測試 - 根據空白或稀疏填入的資料表預估不會反映生產成本。如需詳細資訊，請參閱[使用 EXPLAIN ANALYZE VERBOSE 提高成本意識](#billing-explain-analyze)。
+ **設定 CloudWatch 警示：**在 DPU 指標上建立警示，以收到非預期用量峰值的通知。