本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 在 Amazon Keyspaces 中管理無伺服器資源 （適用於 Apache Cassandra)
Amazon Keyspaces (適用於 Apache Cassandra) 是無伺服器服務。Amazon Keyspaces 會將儲存體和讀取/寫入輸送量資源直接配置給資料表，而不是透過叢集中的節點部署、管理和維護工作負載的儲存和運算資源。
Amazon Keyspaces 會根據儲存在資料表中的資料自動佈建儲存體。當您寫入、更新和刪除資料時，它會擴展和縮減儲存體，而且您只需為使用的儲存體付費。資料會跨多個[可用區域](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)複寫，以提供高可用性。Amazon Keyspaces 會持續監控資料表的大小，以判斷您的儲存費用。如需 Amazon Keyspaces 如何計算資料計費大小的詳細資訊，請參閱 [估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)。
本章涵蓋 Amazon Keyspaces 中資源管理的重要層面。
+ **估算資料列大小** – 若要估算 Amazon Keyspaces 中資料列的編碼大小，請考慮分割區索引鍵中繼資料、叢集資料欄中繼資料、資料欄識別符、資料類型和資料列中繼資料等因素。此編碼的資料列大小用於計費、配額管理和佈建的輸送量容量規劃。
+ **估計容量耗**用 – 本節涵蓋如何預估範圍查詢、限制查詢、資料表掃描、輕量型交易、靜態資料欄和多區域資料表等常見案例的讀取和寫入容量耗用的範例。您可以使用 Amazon CloudWatch 來監控實際容量使用率。如需使用 CloudWatch 監控的詳細資訊，請參閱 [使用 Amazon CloudWatch 監控 Amazon Keyspaces](monitoring-cloudwatch.md)。
+ **設定讀取/寫入容量模式** – 您可以選擇兩種容量模式，以處理資料表上的讀取和寫入：
+ **隨需模式 （預設）** – 讀取和寫入輸送量的每個請求付費。Amazon Keyspaces 可以立即將容量擴展到任何先前達到的流量層級。
+ **佈建模式** – 事先指定所需的讀取和寫入容量單位數量。此模式有助於維持可預測的輸送量效能。
+ **使用自動擴展管理輸送量容量** – 對於佈建的資料表，您可以啟用自動擴展，以根據實際應用程式流量自動調整輸送量容量。Amazon Keyspaces 使用目標追蹤來增加或減少佈建容量，將使用率保持在指定的目標。
+ **有效使用高載容量** – Amazon Keyspaces 透過保留一部分未使用的輸送量來處理流量尖峰，提供高載容量。這種靈活性允許偶爾超出佈建輸送量的活動暴增。
若要疑難排解容量錯誤，請參閱 [無伺服器容量錯誤](troubleshooting.serverless.md#troubleshooting-serverless)。
**Topics**
+ [估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)
+ [預估 Amazon Keyspaces 中讀取和寫入輸送量的容量耗用](capacity-examples.md)
+ [在 Amazon Keyspaces 中設定讀取/寫入容量模式](ReadWriteCapacityMode.md)
+ [使用 Amazon Keyspaces 自動擴展自動管理輸送量容量](autoscaling.md)
+ [在 Amazon Keyspaces 中有效使用高載容量](throughput-bursting.md)
# 估計 Amazon Keyspaces 中的資料列大小
Amazon Keyspaces 提供全受管儲存，可提供單一位數毫秒的讀取和寫入效能，並持久地跨多個 AWS 可用區域存放資料。Amazon Keyspaces 會將中繼資料連接至所有資料列和主索引鍵資料欄，以支援高效率的資料存取和高可用性。
本主題提供如何估計 Amazon Keyspaces 中資料列編碼大小的詳細資訊。計算帳單和配額用量時，會使用編碼的資料列大小。在估算資料表的佈建輸送量容量需求時，您也可以使用編碼的資料列大小。
若要計算 Amazon Keyspaces 中資料列的編碼大小，您可以使用下列準則。
**Topics**
+ [估算欄的編碼大小](#calculating-row-size-columns)
+ [根據資料類型估計資料值的編碼大小](#calculating-row-size-data-types)
+ [考慮 Amazon Keyspaces 功能對資料列大小的影響](#calculating-row-size-features)
+ [選擇正確的公式來計算資料列的編碼大小](#calculating-row-size-formula)
+ [資料列大小計算範例](#calculating-row-size-example)
## 估算欄的編碼大小
本節說明如何預估 Amazon Keyspaces 中資料欄的編碼大小。
+ **一般資料欄** – 對於非主索引鍵、叢集資料欄或`STATIC`資料欄的資料欄的一般資料欄，請根據[資料類型](cql.elements.md#cql.data-types)使用儲存格資料的原始大小，並新增必要的中繼資料。在 Amazon Keyspaces 存放資料類型值和中繼資料的方式方面，資料類型和一些關鍵差異會列在下一節中。
+ **分割區索引鍵資料欄** – 分割區索引鍵最多可包含 2048 個位元組的資料。分割區索引鍵中的每個索引鍵資料欄最多需要 3 個位元組的中繼資料。計算資料列的大小時，您應該假設每個分割區索引鍵資料欄使用完整 3 個位元組的中繼資料。
+ **叢集資料欄** – 叢集資料欄最多可存放 850 個位元組的資料。除了資料值的大小之外，每個叢集資料欄最多需要中繼資料資料值大小的 20%。計算資料列的大小時，您應該為叢集資料欄資料值的每 5 個位元組新增 1 個位元組的中繼資料。
**注意**
為了支援高效查詢和內建索引，Amazon Keyspaces 會儲存每個分割區索引鍵和叢集索引鍵資料欄的資料值兩次。
+ **資料欄名稱** – 每個資料欄名稱所需的空間會使用資料欄識別符存放，並新增至存放在資料欄中的每個資料值。資料欄識別符的儲存值取決於資料表中的資料欄總數：
+ 1–62 欄：1 位元組
+ 63–124 欄：2 個位元組
+ 125–186 欄：3 個位元組
對於每個額外的 62 欄，新增 1 個位元組。請注意，在 Amazon Keyspaces 中，最多可以使用單一 `INSERT`或 `UPDATE`陳述式修改 225 個一般資料欄。如需詳細資訊，請參閱[Amazon Keyspaces 服務配額](quotas.md#table)。
## 根據資料類型估計資料值的編碼大小
本節說明如何預估 Amazon Keyspaces 中不同資料類型的編碼大小。
+ **字串類型** – Cassandra `TEXT`、 `ASCII`和 `VARCHAR`字串資料類型都存放在使用 Unicode 搭配 UTF-8 二進位編碼的 Amazon Keyspaces 中。Amazon Keyspaces 中字串的大小等於 UTF-8 編碼位元組的數量。
+ **數值類型** – Cassandra `INT`、`BIGINT`、`TINYINT`、 `SMALLINT`和 `VARINT`資料類型會以可變長度的資料值儲存在 Amazon Keyspaces 中，最多 38 個有效數字。前後的零會截去。任何這些資料類型的大小約為每兩個有效數字 1 個位元組 \$1 1 個位元組。
+ **Blob 類型** – Amazon Keyspaces `BLOB`中的 是以值的原始位元組長度存放。
+ **布林值類型** – `Boolean`值的大小`Null`為 1 位元組。
+ **集合類型** – 儲存集合資料類型的資料欄，例如 `LIST`或 `MAP`需要 3 個位元組的中繼資料，無論其內容為何。`LIST` 或 的大小`MAP`是 （資料欄 ID) \$1 總和 （巢狀元素的大小） \$1 (3 個位元組）。空白`LIST`或的大小`MAP`是 （資料欄 ID) \$1 (3 位元組）。每個個別`LIST`或`MAP`元素也需要 1 個位元組的中繼資料。
+ **使用者定義類型** – [使用者定義類型 (UDT)](udts.md) 需要 3 個位元組的中繼資料，無論其內容為何。對於每個 UDT 元素，Amazon Keyspaces 需要額外的 1 位元組中繼資料。
若要計算 UDT 的編碼大小，請從 UDT 欄位的 `field name`和 `field value` 開始：
+ **欄位名稱** – 最上層 UDT 的每個欄位名稱都是使用 識別符存放。識別符的儲存值取決於最上層 UDT 中的欄位整體數量，並且可能介於 1 到 3 個位元組之間：
+ 1–62 個欄位：1 位元組
+ 63–124 個欄位：2 個位元組
+ 125 – 欄位上限：3 個位元組
+ **欄位值** – 儲存最上層 UDT 欄位值所需的位元組取決於儲存的資料類型：
+ **純量資料類型** – 儲存所需的位元組與存放在一般資料欄中的相同資料類型相同。
+ **凍結 UDT** – 對於每個凍結巢狀 UDT，巢狀 UDT 的大小與 CQL 二進位通訊協定中的大小相同。對於巢狀 UDT，每個欄位 （包括空白欄位） 會儲存 4 個位元組，而儲存欄位的值是欄位值的 CQL 二進位通訊協定序列化格式。
+ **凍結集合**：
+ **LIST** 和 **SET** – 對於巢狀凍結 `LIST`或 `SET`，會為集合的每個元素儲存 4 個位元組，加上集合值的 CQL 二進位通訊協定序列化格式。
+ **MAP** – 對於巢狀凍結 `MAP`，每個鍵值對具有下列儲存需求：
+ 對於每個金鑰配置 4 個位元組，然後新增金鑰的 CQL 二進位通訊協定序列化格式。
+ 對於每個值配置 4 個位元組，然後新增值的 CQL 二進位通訊協定序列化格式。
+ **FROZEN 關鍵字** – 對於巢狀在凍結集合中的凍結集合，Amazon Keyspaces 不需要中繼資料的任何額外位元組。
+ **STATIC 關鍵字** – `STATIC`資料欄資料不會計入 1 MB 的資料列大小上限。若要計算靜態資料欄的資料大小，請參閱 [計算 Amazon Keyspaces 中每個邏輯分割區的靜態資料欄大小](static-columns-estimate.md)。
## 考慮 Amazon Keyspaces 功能對資料列大小的影響
本節顯示 Amazon Keyspaces 中的功能如何影響資料列的編碼大小。
+ **用戶端時間戳記** – 開啟功能時，會為每個資料列中的每個資料欄存放用戶端時間戳記。這些時間戳記大約需要 20–40 個位元組 （取決於您的資料），並對資料列的儲存和輸送量成本做出貢獻。如需用戶端時間戳記的詳細資訊，請參閱 [Amazon Keyspaces 中的用戶端時間戳記](client-side-timestamps.md)。
+ **存留時間 (TTL)** – 開啟功能時，TTL 中繼資料一列大約需要 8 個位元組。此外，也會為每個資料列的每一欄存放 TTL 中繼資料。儲存純量資料類型或凍結集合的每個資料欄，TTL 中繼資料會佔用約 8 個位元組。如果資料欄存放的集合資料類型未凍結，則集合 TTL 的每個元素都需要大約 8 個額外位元組的中繼資料。對於在啟用 TTL 時存放集合資料類型的資料欄，您可以使用下列公式。
```
total encoded size of column = (column id) + sum (nested elements + collection metadata (1 byte) + TTL metadata (8 bytes)) + collection column metadata (3 bytes)
```
TTL 中繼資料對資料列的儲存和輸送量成本有貢獻。如需 TTL 的詳細資訊，請參閱 [使用 Amazon Keyspaces 的存留時間 (TTL) 過期資料 （適用於 Apache Cassandra)](TTL.md)。
## 選擇正確的公式來計算資料列的編碼大小
本節顯示不同的公式，您可以用來估計 Amazon Keyspaces 中資料列的儲存體或容量輸送量需求。
一列資料的總編碼大小可根據您的目標，根據下列其中一個公式估計：
+ **輸送量容量** – 預估資料列的編碼大小，以評估所需的讀取/寫入請求單位 (RRUs/WRUs) 或讀取/寫入容量單位 RCUs/WCUs)：
```
total encoded size of row = partition key columns + clustering columns + regular columns
```
+ **儲存體大小** – 若要預估要預測 的資料列編碼大小`BillableTableSizeInBytes`，請新增資料列儲存體所需的中繼資料：
```
total encoded size of row = partition key columns + clustering columns + regular columns + row metadata (100 bytes)
```
**重要**
所有資料欄中繼資料，例如資料欄 ID、分割區索引鍵中繼資料、叢集資料欄中繼資料，以及用戶端時間戳記、TTL 和資料列中繼資料，都會計入 1 MB 的資料列大小上限。
## 資料列大小計算範例
請考慮下列資料表範例，其中所有資料欄都是整數類型。資料表有兩個分割區索引鍵資料欄、兩個叢集資料欄和一個一般資料欄。由於此資料表有五個資料欄，資料欄名稱識別符所需的空間為 1 位元組。
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
在此範例中，我們會在將資料列寫入資料表時計算資料的大小，如下列陳述式所示：
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1) values(1,2,3,4,5);
```
若要估計此寫入操作所需的總位元組數，您可以使用下列步驟。
1. 透過新增資料欄中存放之資料類型的位元組和中繼資料位元組，來計算分割區索引鍵資料欄的大小。對所有分割區索引鍵資料欄重複此操作。
1. 計算分割區索引鍵 (pk\$1col1) 第一欄的大小：
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. 計算分割區索引鍵 (pk\$1col2) 第二欄的大小：
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. 新增兩個資料欄，以取得分割區索引鍵資料欄的總預估大小：
```
8 bytes + 8 bytes = 16 bytes for the partition key columns
```
1. 透過新增存放在資料欄中的資料類型位元組和中繼資料位元組，來計算叢集資料欄的大小。對所有叢集資料欄重複此操作。
1. 計算叢集資料欄 (ck\$1col1) 第一欄的大小：
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. 計算叢集資料欄 (ck\$1col2) 第二欄的大小：
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. 新增兩個資料欄，以取得叢集資料欄的總預估大小：
```
6 bytes + 6 bytes = 12 bytes for the clustering columns
```
1. 新增一般資料欄的大小。在此範例中，我們只有一個資料欄存放單一數字整數，這需要 2 個位元組，資料欄 ID 為 1 個位元組。
1. 最後，若要取得總編碼資料列大小，請為所有資料欄加總位元組。若要估計儲存體的計費大小，請為資料列中繼資料新增額外的 100 個位元組：
```
16 bytes for the partition key columns + 12 bytes for clustering columns + 3 bytes for the regular column + 100 bytes for row metadata = 131 bytes.
```
若要了解如何使用 Amazon CloudWatch 監控無伺服器資源，請參閱 [使用 Amazon CloudWatch 監控 Amazon Keyspaces](monitoring-cloudwatch.md)。
# 預估 Amazon Keyspaces 中讀取和寫入輸送量的容量耗用
當您在 Amazon Keyspaces 中讀取或寫入資料時，查詢使用的讀取/寫入請求單位 (RRUs/WRUs) 或讀取/寫入容量單位 (RCUs/WCUs) 數量取決於 Amazon Keyspaces 執行查詢所需的總資料量。在某些情況下，傳回給用戶端的資料可以是 Amazon Keyspaces 必須讀取才能處理查詢的資料子集。對於條件式寫入，即使條件式檢查失敗，Amazon Keyspaces 也會使用寫入容量。
若要估計為請求處理的資料總量，您必須考慮資料列的編碼大小和資料列總數。本主題涵蓋一些常見案例和存取模式的範例，以顯示 Amazon Keyspaces 如何處理查詢，以及其如何影響容量消耗。您可以依照範例來估計資料表的容量需求，並使用 Amazon CloudWatch 來觀察這些使用案例的讀取和寫入容量耗用。
如需如何計算 Amazon Keyspaces 中資料列編碼大小的資訊，請參閱 [估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)。
**Topics**
+ [估計 Amazon Keyspaces 中範圍查詢的容量消耗](range_queries.md)
+ [預估限制查詢的讀取容量耗用量](limit_queries.md)
+ [估算資料表掃描的讀取容量耗用量](table_scans.md)
+ [預估 Amazon Keyspaces 中輕量型交易的容量消耗](lightweight_transactions.md)
+ [預估 Amazon Keyspaces 中靜態資料欄的容量耗用](static-columns.md)
+ [Amazon Keyspaces 中多區域資料表的估計和佈建容量](tables-multi-region-capacity.md)
+ [使用 Amazon Keyspaces 中的 Amazon CloudWatch 估計讀取和寫入容量消耗](estimate_consumption_cw.md)
# 估計 Amazon Keyspaces 中範圍查詢的容量消耗
若要查看範圍查詢的讀取容量耗用，我們使用下列使用隨需容量模式的範例資料表。
```
pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value
-----+-----+-----+-----+-----+-----+-------
a | b | 1 | a | b | 50 |
a | b | 1 | a | b | 60 | value_1
a | b | 1 | a | b | 70 |
```
現在在此資料表上執行下列查詢。
```
SELECT * FROM amazon_keyspaces.example_table_1 WHERE pk1='a' AND pk2='b' AND pk3=1 AND ck1='a' AND ck2='b' AND ck3 > 50 AND ck3 < 70;
```
您從查詢收到下列結果集，Amazon Keyspaces 執行的讀取操作會在`LOCAL_QUORUM`一致性模式中使用 2 RRUs。
```
pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value
-----+-----+-----+-----+-----+-----+-------
a | b | 1 | a | b | 60 | value_1
```
Amazon Keyspaces 會使用 2 RRUs 來評估具有值的資料列`ck3=70`，`ck3=60`以及處理查詢。不過，Amazon Keyspaces 只會傳回查詢中指定`WHERE`條件為 true 的資料列，也就是值為 的資料列`ck3=60`。若要評估查詢中指定的範圍，Amazon Keyspaces 會讀取符合範圍上限的資料列，在此情況下為 `ck3 = 70`，但不會傳回結果中的該資料列。讀取容量消耗是根據處理查詢時讀取的資料，而非傳回的資料。
# 預估限制查詢的讀取容量耗用量
處理使用 `LIMIT`子句的查詢時，Amazon Keyspaces 會在嘗試符合查詢中指定的條件時，讀取最大頁面大小的資料列。如果 Amazon Keyspaces 找不到符合第一頁`LIMIT`上值的足夠相符資料，則可能需要一或多個分頁呼叫。若要在下一頁繼續讀取，您可以使用分頁字符。預設頁面大小為 1MB。若要在使用 `LIMIT`子句時減少讀取容量，您可以減少頁面大小。如需分頁的詳細資訊，請參閱 [在 Amazon Keyspaces 中分頁結果](paginating-results.md)。
如需範例，讓我們來看看下列查詢。
```
SELECT * FROM my_table WHERE partition_key=1234 LIMIT 1;
```
如果您未設定頁面大小，Amazon Keyspaces 會讀取 1MB 的資料，即使只傳回 1 列給您。若要讓 Amazon Keyspaces 只讀取一列，您可以將此查詢的頁面大小設定為 1。在此情況下，如果根據Time-to-live設定或用戶端時間戳記沒有過期的資料列，Amazon Keyspaces 只會讀取一列。
`PAGE SIZE` 參數會決定 Amazon Keyspaces 從磁碟掃描每個請求的資料列數，而不是 Amazon Keyspaces 傳回用戶端的資料列數。Amazon Keyspaces 會套用您提供的篩選條件，例如非金鑰資料欄上的不等式，或掃描磁碟上的資料`LIMIT`之後的 。如果您未明確設定 `PAGE SIZE`，Amazon Keyspaces 會在套用篩選條件之前讀取最多 1MB 的資料。例如，如果您使用 `LIMIT 1`而不指定 `PAGE SIZE`，Amazon Keyspaces 可以在套用限制子句並僅傳回單一資料列之前，從磁碟讀取數千個資料列。
為了避免過度讀取，請減少 `PAGE SIZE`，以減少 Amazon Keyspaces 掃描每個擷取的資料列數。例如，如果您在查詢`LIMIT 5`中定義 ，請將 `PAGE SIZE` 設定為介於 5 - 10 之間的值，以便 Amazon Keyspaces 在每個分頁呼叫上只會掃描 5 - 10 列。您可以修改此數字以減少擷取的數量。對於大於頁面大小的限制，Amazon Keyspaces 會以分頁狀態維持總結果計數。在 10，000 個資料列`LIMIT`的 中，Amazon Keyspaces 可以在兩頁各 5，000 個資料列中擷取這些結果。1MB 限制是任何頁面大小集的上限。
# 估算資料表掃描的讀取容量耗用量
導致完整資料表掃描的查詢，例如使用 `ALLOW FILTERING`選項的查詢，是另一個處理比其傳回的結果更多讀取的查詢範例。讀取容量消耗是根據資料讀取，而不是傳回的資料。
對於資料表掃描範例，我們在隨需容量模式中使用以下範例資料表。
```
pk | ck | value
---+----+---------
pk | 10 |
pk | 20 | value_1
pk | 30 |
```
Amazon Keyspaces 預設會在隨需容量模式中建立具有四個分割區的資料表。在此範例資料表中，所有資料都存放在一個分割區中，其餘三個分割區是空的。
現在請在 資料表上執行下列查詢。
```
SELECT * from amazon_keyspaces.example_table_2;
```
此查詢會產生資料表掃描操作，其中 Amazon Keyspaces 會掃描資料表的所有四個分割區，並在`LOCAL_QUORUM`一致性模式中耗用 6 RRUs。首先，Amazon Keyspaces 會使用 3 RRUs 來讀取具有 的三列`pk=‘pk’`。然後，Amazon Keyspaces 會使用額外的 3 RRUs 來掃描資料表的三個空白分割區。由於此查詢會導致資料表掃描，Amazon Keyspaces 會掃描資料表中的所有分割區，包括不含資料的分割區。
# 預估 Amazon Keyspaces 中輕量型交易的容量消耗
輕量型交易 (LWT) 可讓您針對資料表資料執行條件式寫入操作。條件式更新操作在根據評估目前狀態的條件插入、更新和刪除記錄時非常有用。
在 Amazon Keyspaces 中，所有寫入操作都需要 LOCAL\$1QUORUM 一致性，而且使用 LWTs無需額外付費。LWTs的差異在於，當 LWT 條件檢查導致 時`FALSE`，Amazon Keyspaces 會使用寫入容量單位 WCUs) 或寫入請求單位 WRUs)。使用的 WCUs/WRUs 數量取決於資料列的大小。
例如，如果資料列大小為 2 KB，則失敗的條件式寫入會耗用兩個 WCUs/WRUs。如果資料列目前不存在於資料表中，則操作會耗用一個 WCUs/WRUs。
若要判斷導致條件檢查失敗的請求數量，您可以在 CloudWatch 中監控 `ConditionalCheckFailed` 指標。
## 預估存留時間 (TTL) 資料表的 LWT 成本
對於使用不使用用戶端時間戳記的 TTL 設定的資料表，LWTs 可能需要額外的讀取容量單位 (RCUs) 或讀取請求單位 (RRUs)。在 中使用 `IF EXISTS`或 `IF NOT EXISTS`關鍵字條件檢查結果時`FALSE`，會耗用下列容量單位：
+ RCUs/RRUs 如果資料列存在，使用的 RCUs/RRUs會根據現有資料列的大小而定。
+ RCUs/RRUs如果資料列不存在，則會使用單一 RCU/RRU。
如果評估的條件導致寫入操作成功，WCUs/WRUs會根據新資料列的大小耗用。
# 預估 Amazon Keyspaces 中靜態資料欄的容量耗用
在具有叢集資料欄的 Amazon Keyspaces 資料表中，您可以使用 `STATIC`關鍵字來建立靜態資料欄。儲存在靜態資料欄中的值會在邏輯分割區中的所有資料列之間共用。當您更新此欄的值時，Amazon Keyspaces 會自動將變更套用至分割區中的所有資料列。
本節說明如何在寫入靜態資料欄時計算資料的編碼大小。此程序與將資料寫入資料至資料列非靜態資料欄的程序分開處理。除了靜態資料的大小配額之外，靜態資料欄上的讀取和寫入操作也會獨立影響資料表的計量和輸送量容量。如需使用靜態資料欄和分頁範圍讀取結果時 Apache Cassandra 的功能差異，請參閱 [分頁](functional-differences.md#functional-differences.paging)。
**Topics**
+ [計算 Amazon Keyspaces 中每個邏輯分割區的靜態資料欄大小](static-columns-estimate.md)
+ [預估 Amazon Keyspaces 中靜態資料的讀取/寫入操作的容量輸送量需求](static-columns-metering.md)
# 計算 Amazon Keyspaces 中每個邏輯分割區的靜態資料欄大小
本節提供如何估計 Amazon Keyspaces 中靜態資料欄編碼大小的詳細資訊。當您計算帳單和配額用量時，會使用編碼大小。當您計算資料表的佈建輸送量容量需求時，也應該使用編碼的大小。若要計算 Amazon Keyspaces 中靜態資料欄的編碼大小，您可以使用下列準則。
+ 分割區索引鍵最多可包含 2048 個位元組的資料。分割區索引鍵中的每個索引鍵資料欄最多需要 3 個位元組的中繼資料。這些中繼資料位元組會計入每個分割區 1 MB 的靜態資料大小配額。計算靜態資料的大小時，您應該假設每個分割區索引鍵資料欄使用完整 3 個位元組的中繼資料。
+ 根據資料類型使用靜態資料欄資料值的原始大小。如需資料類型的詳細資訊，請參閱 [資料類型](cql.elements.md#cql.data-types)。
+ 將 104 個位元組新增至中繼資料的靜態資料大小。
+ 叢集資料欄和一般、非主索引鍵資料欄不會計入靜態資料的大小。若要了解如何預估資料列中非靜態資料的大小，請參閱 [估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)。
靜態資料欄的總編碼大小是根據下列公式：
```
partition key columns + static columns + metadata = total encoded size of static data
```
請考慮下列資料表範例，其中所有資料欄的類型皆為整數。資料表有兩個分割區索引鍵資料欄、兩個叢集資料欄、一個規則資料欄和一個靜態資料欄。
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
在此範例中，我們會計算下列陳述式的靜態資料大小：
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, static_col1) values(1,2,6);
```
若要估計此寫入操作所需的總位元組數，您可以使用下列步驟。
1. 透過新增存放在資料欄中的資料類型位元組和中繼資料位元組，來計算分割區索引鍵資料欄的大小。對所有分割區索引鍵資料欄重複此操作。
1. 計算分割區索引鍵 (pk\$1col1) 第一欄的大小：
```
4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
```
1. 計算分割區索引鍵 (pk\$1col2) 第二欄的大小：
```
4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
```
1. 新增兩個資料欄，以取得分割區索引鍵資料欄的總預估大小：
```
7 bytes + 7 bytes = 14 bytes for the partition key columns
```
1. 新增靜態資料欄的大小。在此範例中，我們只有一個靜態資料欄可存放整數 （需要 4 個位元組）。
1. 最後，若要取得靜態資料欄資料的總編碼大小，請為主索引鍵資料欄和靜態資料欄新增位元組，並為中繼資料新增額外的 104 個位元組：
```
14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes.
```
您也可以使用相同的陳述式更新靜態和非靜態資料。若要估計寫入操作的總大小，您必須先計算非靜態資料更新的大小。然後計算資料列更新的大小，如 的範例所示[估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)，並新增結果。
在這種情況下，您可以寫入總計 2 MB，1 MB 是資料列大小配額上限，而 1 MB 是每個邏輯分割區靜態資料大小上限的配額。
若要計算相同陳述式中靜態和非靜態資料更新的總大小，您可以使用下列公式：
```
(partition key columns + static columns + metadata = total encoded size of static data) + (partition key columns + clustering columns + regular columns + row metadata = total encoded size of row)
= total encoded size of data written
```
請考慮下列資料表範例，其中所有資料欄的類型皆為整數。資料表有兩個分割區索引鍵資料欄、兩個叢集資料欄、一個規則資料欄和一個靜態資料欄。
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
在此範例中，我們在將資料列寫入資料表時計算資料的大小，如下列陳述式所示：
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1, static_col1) values(2,3,4,5,6,7);
```
若要估計此寫入操作所需的總位元組數，您可以使用下列步驟。
1. 計算靜態資料的總編碼大小，如先前所示。在此範例中，它是 122 個位元組。
1. 遵循 中的步驟，根據非靜態資料的更新，新增資料列的總編碼大小大小[估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)。在此範例中，資料列更新的總大小為 134 個位元組。
```
122 bytes for static data + 134 bytes for nonstatic data = 256 bytes.
```
# 預估 Amazon Keyspaces 中靜態資料的讀取/寫入操作的容量輸送量需求
靜態資料與 Cassandra 中的邏輯分割區相關聯，而不是與個別資料列相關聯。透過跨越多個實體儲存分割區，Amazon Keyspaces 中的邏輯分割區幾乎可以不受大小限制。因此，Amazon Keyspaces 會分別測量靜態和非靜態資料的寫入操作。此外，包含靜態和非靜態資料的寫入需要額外的基礎操作才能提供資料一致性。
如果您同時執行靜態和非靜態資料的混合寫入操作，這會產生兩個不同的寫入操作，一個用於非靜態資料，另一個用於靜態資料。這同時適用於隨需和佈建的讀取/寫入容量模式。
下列範例提供詳細資訊，說明如何在計算具有靜態資料欄之 Amazon Keyspaces 中資料表的佈建輸送量需求時，預估所需的讀取容量單位 (RCUs) 和寫入容量單位 (WCUs)。您可以使用下列公式，預估資料表處理包含靜態和非靜態資料的寫入所需的容量：
```
2 x WCUs required for nonstatic data + 2 x WCUs required for static data
```
例如，如果您的應用程式每秒寫入 27 KBs的資料，且每次寫入包含 25.5 KBs 的非靜態資料和 1.5 KBs 的靜態資料，則資料表需要 56 個 WCUs (2 x 26 WCUs \$1 2 x 2 WCUs)。
Amazon Keyspaces 會測量靜態和非靜態資料的讀取，與多個資料列的讀取相同。因此，相同操作中讀取靜態和非靜態資料的價格，取決於為執行讀取而處理的資料彙總大小。
若要了解如何使用 Amazon CloudWatch 監控無伺服器資源，請參閱 [使用 Amazon CloudWatch 監控 Amazon Keyspaces](monitoring-cloudwatch.md)。
# Amazon Keyspaces 中多區域資料表的估計和佈建容量
您可以透過兩種方式之一設定多區域資料表的輸送量容量：
+ 隨需容量模式，以寫入請求單位 (WRUs測量
+ 具有自動擴展的佈建容量模式，以寫入容量單位 (WCUs測量
您可以使用佈建容量模式搭配自動擴展或隨需容量模式，以協助確保多區域資料表有足夠的容量來執行複寫寫入至所有 AWS 區域。
**注意**
變更其中一個區域中資料表的容量模式會變更所有複本的容量模式。
根據預設，Amazon Keyspaces 會針對多區域資料表使用隨需模式。使用隨需模式時，您不需要指定預期應用程式執行的讀取和寫入輸送量。Amazon Keyspaces 會在工作負載上升或下降到先前達到的任何流量層級時，立即滿足您的工作負載。如果工作負載的流量達到新的峰值，Amazon Keyspaces 會快速調整以適應工作負載。
如果您選擇資料表的佈建容量模式，則必須設定應用程式每秒所需的讀取容量單位 (RCUs) 和寫入容量單位 WCUs) 數量。
若要規劃多區域資料表的輸送量容量需求，您應該先預估每個區域每秒所需的 WCUs 數量。然後，從複寫資料表的所有區域新增寫入，並使用總和為每個區域佈建容量。這是必要的，因為在某個區域中執行的每個寫入也必須在每個複本區域中重複。
如果資料表沒有足夠的容量來處理來自所有區域的寫入，則會發生容量例外狀況。此外，區域間複寫等待時間也會增加。
例如，如果您有一個多區域資料表，其中在美國東部 （維吉尼亞北部） 預期每秒 5 次寫入、美國東部 （俄亥俄） 預期每秒 10 次寫入，而歐洲 （愛爾蘭） 預期該資料表在每個區域中使用 20 個 WCUs：美國東部 （維吉尼亞北部）、美國東部 （俄亥俄） 和歐洲 （愛爾蘭）。這表示在此範例中，您需要為每個資料表的複本佈建 20 WCUs。您可以使用 Amazon CloudWatch 監控資料表的容量消耗。如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon Keyspaces](monitoring-cloudwatch.md)。
每次寫入都會以 1 個 WCU 計費，因此您會在此範例中看到總共 60 WCUs 計費。如需定價的詳細資訊，請參閱 [Amazon Keyspaces （適用於 Apache Cassandra) 定價](https://aws.amazon.com/keyspaces/pricing)。
如需使用 Amazon Keyspaces 自動擴展佈建容量的詳細資訊，請參閱 [使用 Amazon Keyspaces 自動擴展自動管理輸送量容量](autoscaling.md)。
**注意**
如果資料表在具有自動擴展的佈建容量模式下執行，則允許佈建的寫入容量在每個區域的這些自動擴展設定內浮動。
# 使用 Amazon Keyspaces 中的 Amazon CloudWatch 估計讀取和寫入容量消耗
若要估計和監控讀取和寫入容量消耗，您可以使用 CloudWatch 儀表板。如需 Amazon Keyspaces 可用指標的詳細資訊，請參閱 [Amazon Keyspaces 指標和維度](metrics-dimensions.md)。
若要使用 CloudWatch 監控特定陳述式使用的讀取和寫入容量單位，您可以遵循下列步驟。
1. 使用範例資料建立新的資料表
1. 設定資料表的 Amazon Keyspaces CloudWatch 儀表板。若要開始使用，您可以使用 [Github](https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates) 上提供的儀表板範本。
1. 執行 CQL 陳述式，例如使用 `ALLOW FILTERING`選項，並在儀表板中檢查用於完整資料表掃描的讀取容量單位。
# 在 Amazon Keyspaces 中設定讀取/寫入容量模式
Amazon Keyspaces 有兩個讀取/寫入容量模式，用於處理資料表上的讀取和寫入：
+ 隨需 （預設）
+ 佈建
您所選擇的讀取/寫入容量模式會控制讀寫輸送量的收費方式，以及資料表輸送容量的管理方式。
**Topics**
+ [設定隨需容量模式](ReadWriteCapacityMode.OnDemand.md)
+ [設定佈建容量模式](ReadWriteCapacityMode.Provisioned.md)
+ [在 Amazon Keyspaces 中檢視資料表的容量模式](ReadWriteCapacityMode.ProvisionedThroughput.ManagingCapacity.md)
+ [變更 Amazon Keyspaces 中資料表的容量模式](ReadWriteCapacityMode.SwitchReadWriteCapacityMode.md)
+ [為 Amazon Keyspaces 中的資料表設定預熱](warm-throughput.md)
# 設定隨需容量模式
Amazon Keyspaces （適用於 Apache Cassandra) *隨需*容量模式是一種靈活的計費選項，無需規劃容量即可每秒處理數千個請求。此選項提供讀取和寫入請求pay-per-request定價，因此您只需支付使用量的費用。
當您選擇隨需模式時，Amazon Keyspaces 可以立即將資料表的輸送量容量擴展到任何先前達到的流量層級，然後在應用程式流量減少時返回。如果工作負載的流量層級達到新的峰值，服務會快速調整以增加資料表的輸送量容量。您可以為新的和現有的資料表啟用隨需容量模式。
如果以下任何一項成立，隨需模式是不錯的選擇：
+ 您建立工作負載不明的新資料表。
+ 您有無法預期的應用程式流量。
+ 您偏好僅支付您實際用量的輕鬆付費方式。
若要開始使用隨需模式，您可以使用主控台或幾行 Cassandra 查詢語言 (CQL) 程式碼建立新的資料表，或更新現有的資料表以使用隨需容量模式。如需詳細資訊，請參閱[表格](cql.ddl.table.md)。
**Topics**
+ [讀取請求單位與寫入請求單位](#ReadWriteCapacityMode.requests)
+ [峰值流量與擴展屬性](#ReadWriteCapacityMode.PeakTraffic)
+ [隨需容量模式的初始輸送量](#ReadWriteCapacityMode.InitialThroughput)
## 讀取請求單位與寫入請求單位
使用隨需容量模式資料表，您不需要指定預期應用程式預先使用的讀取和寫入輸送量。Amazon Keyspaces 會根據讀取請求單位 (RRUs) 和寫入請求單位 (WRUs)，向您收取您在資料表上執行的讀取和寫入費用。
+ 一個 *RRU* 代表大小上限為 4 KB 的資料列一個`LOCAL_QUORUM`讀取請求或兩個` LOCAL_ONE`讀取請求。如果您需要讀取大於 4 KB 的資料列，讀取操作會使用其他 RRUs。所需的 RRUs 總數取決於資料列大小，以及您想要使用或`LOCAL_QUORUM``LOCAL_ONE`讀取一致性。例如，讀取 8 KB 的資料列需要 2 個使用`LOCAL_QUORUM`讀取一致性RRUs，如果您選擇`LOCAL_ONE`讀取一致性，則需要 1 個 RRU。
+ 一個 *WRU* 代表大小上限為 1 KB 的資料列一個寫入。所有寫入都使用`LOCAL_QUORUM`一致性，而且使用輕量型交易 (LWTs) 無需額外付費。如果您需要寫入大於 1 KB 的資料列，則寫入操作會使用額外的 WRUs。所需的 WRUs 總數取決於資料列大小。例如，如果您的資料列大小為 2 KB，則需要 2 WRUs 來執行一個寫入請求。
如需支援的一致性層級的相關資訊，請參閱 [支援的 Apache Cassandra 讀取和寫入一致性層級和相關成本](consistency.md)。
## 峰值流量與擴展屬性
使用隨需容量模式的 Amazon Keyspaces 資料表會自動適應應用程式的流量。隨需容量模式會立即因應，最高達到資料表峰值流量的兩倍。例如，您應用程式的流量模式可能介於每秒 5，000 到 10，000 次`LOCAL_QUORUM`讀取之間，其中每秒 10，000 次讀取是先前的流量峰值。
透過此模式，隨需容量模式可立即容納每秒高達 20，000 次讀取的持續流量。如果您的應用程式維持每秒 20，000 次讀取的流量，該峰值會成為您先前的新峰值，讓後續流量達到每秒 40，000 次讀取。
如果您在資料表上需要超過先前峰值的兩倍，Amazon Keyspaces 會在流量增加時自動配置更多容量。這有助於確保您的資料表有足夠的輸送量容量來處理其他請求。不過，如果您在 30 分鐘內超過先前峰值的兩倍，您可能會發現輸送量容量不足錯誤。
例如，假設應用程式的流量模式在每秒 5，000 到 10，000 個強式一致讀取之間有所不同，其中每秒 20，000 個讀取是先前達到的流量峰值。在此情況下，服務建議您將流量成長至少間隔 30 分鐘，然後每秒最多 40，000 次讀取。
若要了解如何預估資料表的讀取和寫入容量耗用，請參閱 [預估 Amazon Keyspaces 中讀取和寫入輸送量的容量耗用](capacity-examples.md)。
若要進一步了解 帳戶的預設配額以及如何增加這些配額，請參閱 [Amazon Keyspaces 配額 （適用於 Apache Cassandra)](quotas.md)。
## 隨需容量模式的初始輸送量
如果您第一次建立啟用隨需容量模式的新資料表，或將現有資料表切換為隨需容量模式，則資料表會有下列先前的峰值設定，即使先前尚未使用隨需容量模式為流量提供服務：
+ 使用**隨需容量模式新建立的資料表：**先前的峰值為 2，000 WRUs 和 6，000 RRUs。您可以立即驅動高達先前峰值的兩倍。這樣做可讓新建立的隨需資料表提供高達 4，000 WRUs 和 12，000 RRUs。
+ **現有資料表切換到隨需容量模式：**先前的峰值是為資料表佈建的先前 WCUs 和 RCUs的一半，或為具有隨需容量模式的新建立資料表設定，以較高者為準。
# 設定佈建容量模式
如果您選擇*佈建的輸送量*容量模式，您可以指定應用程式所需的每秒讀取和寫入次數。這可協助您管理 Amazon Keyspaces 用量，以維持或低於定義的請求率，以維持可預測性。若要進一步了解佈建輸送量的自動擴展，請參閱 [使用 Amazon Keyspaces 自動擴展自動管理輸送量容量](autoscaling.md)。
如果符合下列任一條件，佈建的輸送量容量模式是不錯的選擇：
+ 您有可預期的應用程式流量。
+ 您執行的應用程式有一致或逐漸增多的流量。
+ 您可以預測容量需求。
## 讀取容量單位和寫入容量單位
對於佈建的輸送量容量模式資料表，您可以指定讀取容量單位 (RCUs) 和寫入容量單位 (WCUs的輸送量容量：
+ 一個 *RCU* 代表每秒一個`LOCAL_QUORUM`讀取，或每秒兩個`LOCAL_ONE`讀取，資料列大小上限為 4 KB。如果您需要讀取大於 4 KB 的資料列，則讀取操作會使用其他 RCUs。
所需的 RCUs 總數取決於資料列大小，以及您想要`LOCAL_QUORUM`還是`LOCAL_ONE`讀取。例如，如果您的資料列大小為 8 KB，則需要 2 RCUs 來維持每秒一個`LOCAL_QUORUM`讀取，如果您選擇`LOCAL_ONE`讀取，則需要 1 個 RCU。
+ 一個 *WCU* 代表最大 1 KB 的資料列每秒一個寫入。所有寫入都使用`LOCAL_QUORUM`一致性，而且使用輕量型交易 (LWTs) 無需額外付費。如果您需要寫入大於 1 KB 的資料列，則寫入操作會使用其他 WCUs。
所需的 WCUs 總數取決於資料列大小。例如，如果您的資料列大小為 2 KB，則需要 2 WCUs 來維持每秒一個寫入請求。如需如何預估資料表讀取和寫入容量耗用的詳細資訊，請參閱 [預估 Amazon Keyspaces 中讀取和寫入輸送量的容量耗用](capacity-examples.md)。
如果您的應用程式讀取或寫入較大的資料列 （最大 Amazon Keyspaces 的資料列大小上限為 1 MB)，則會耗用更多容量單位。若要進一步了解如何估計資料列大小，請參閱 [估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)。例如，假設您建立具有 6 個 RCUs和 6 個 WCUs佈建資料表。透過這些設定，您的應用程式可執行下列項目：
+ 執行每秒高達 24 KB 的`LOCAL_QUORUM`讀取 (4 KB × 6 RCUs)。
+ 執行每秒高達 48 KB 的`LOCAL_ONE`讀取 （兩倍的讀取輸送量）。
+ 每秒寫入最多 6 KB (1 KB × 6 WCUs)。
*佈建輸送量*是應用程式可以從資料表取用的最大輸送量。如果您的應用程式超過佈建的輸送量容量，您可能會發現容量不足錯誤。
例如，沒有足夠輸送量容量的讀取請求會失敗，但有`Read_Timeout`例外狀況，並會發佈到 `ReadThrottleEvents` 指標。沒有足夠輸送量的寫入請求會失敗，但有`Write_Timeout`例外狀況，並會發佈到 `WriteThrottleEvents` 指標。
您可以使用 Amazon CloudWatch 來監控佈建和實際輸送量指標，以及容量不足的事件。如需這些指標的詳細資訊，請參閱 [Amazon Keyspaces 指標和維度](metrics-dimensions.md)。
**注意**
由於容量不足而重複的錯誤可能會導致用戶端驅動程式特定的例外狀況，例如 DataStax Java 驅動程式因 而失敗`NoHostAvailableException`。
若要變更資料表的輸送量容量設定，您可以使用 AWS 管理主控台 或使用 CQL 的 `ALTER TABLE`陳述式，如需詳細資訊，請參閱 [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)。
若要進一步了解您帳戶的預設配額以及如何增加這些配額，請參閱 [Amazon Keyspaces 配額 （適用於 Apache Cassandra)](quotas.md)。
# 在 Amazon Keyspaces 中檢視資料表的容量模式
您可以在 Amazon Keyspaces 系統金鑰空間中查詢系統資料表，以檢閱資料表的容量模式資訊。您也可以查看資料表是否使用隨需或佈建的輸送量容量模式。如果資料表設定為佈建的輸送量容量模式，您可以查看為資料表佈建的輸送量容量。
您也可以使用 AWS CLI 來檢視資料表的容量模式。
若要變更資料表的佈建輸送量，請參閱 [變更 Amazon Keyspaces 中資料表的容量模式](ReadWriteCapacityMode.SwitchReadWriteCapacityMode.md)。
------
#### [ Cassandra Query Language (CQL) ]
**範例**
```
SELECT * from system_schema_mcs.tables where keyspace_name = 'mykeyspace' and table_name = 'mytable';
```
使用隨需容量模式設定的資料表會傳回下列項目。
```
{
"capacity_mode":{
"last_update_to_pay_per_request_timestamp":"1579551547603",
"throughput_mode":"PAY_PER_REQUEST"
}
}
```
使用佈建輸送量容量模式設定的資料表會傳回下列項目。
```
{
"capacity_mode":{
"last_update_to_pay_per_request_timestamp":"1579048006000",
"read_capacity_units":"5000",
"throughput_mode":"PROVISIONED",
"write_capacity_units":"6000"
}
}
```
`last_update_to_pay_per_request_timestamp` 值的測量單位為毫秒。
------
#### [ CLI ]
使用 檢視資料表的輸送量容量模式 AWS CLI
```
aws keyspaces get-table --keyspace-name myKeyspace --table-name myTable
```
對於佈建容量模式中的資料表， 命令的輸出可能看起來像這樣。
```
"capacitySpecification": {
"throughputMode": "PROVISIONED",
"readCapacityUnits": 4000,
"writeCapacityUnits": 2000
}
```
隨需模式中資料表的輸出如下所示。
```
"capacitySpecification": {
"throughputMode": "PAY_PER_REQUEST",
"lastUpdateToPayPerRequestTimestamp": "2024-10-03T10:48:19.092000+00:00"
}
```
------
# 變更 Amazon Keyspaces 中資料表的容量模式
當您將資料表從佈建容量模式切換到隨需容量模式時，Amazon Keyspaces 會對資料表和分割區的結構進行數項變更。此程序需要幾分鐘的時間。在切換期間，您的資料表會提供與先前佈建的 WCU 和 RCU 金額一致的輸送量。
當您從隨需容量模式切換回佈建容量模式時，您的資料表會提供與資料表設定為隨需容量模式時先前達到的尖峰一致的輸送量。
當您切換容量模式時，適用下列等待期間：
+ 您可以隨時將新建立的隨需模式資料表切換為佈建容量模式。不過，您只能在資料表建立時間戳記的 24 小時後將其切換回隨需模式。
+ 您可以隨時將隨需模式中的現有資料表切換為佈建容量模式。不過，您只能在 24 小時期間內將容量模式從佈建切換到隨需。
------
#### [ Cassandra Query Language (CQL) ]
**使用 CQL 變更資料表的輸送量容量模式**
1. 若要將資料表的容量模式變更為 `PROVIOSIONED` ，您必須根據工作負載預期的峰值來設定讀取容量和寫入容量單位。以下陳述式為範例。您也可以執行此陳述式來調整 資料表的讀取容量或寫入容量單位。
```
ALTER TABLE catalog.book_awards WITH CUSTOM_PROPERTIES={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 6000, 'write_capacity_units': 3000}};
```
若要使用自動調整規模設定佈建容量模式，請參閱 [在現有資料表上設定自動擴展](autoscaling.configureTable.md)。
1. 若要將資料表的容量模式變更為隨需模式，請將輸送量模式設定為 `PAY_PER_REQUEST`。下列陳述式為範例。
```
ALTER TABLE catalog.book_awards WITH CUSTOM_PROPERTIES={'capacity_mode':{'throughput_mode': 'PAY_PER_REQUEST'}};
```
1. 您可以使用下列陳述式來確認資料表的容量模式。
```
SELECT * from system_schema_mcs.tables where keyspace_name = 'catalog' and table_name = 'book_awards';
```
使用隨需容量模式設定的資料表會傳回下列項目。
```
{
"capacity_mode":{
"last_update_to_pay_per_request_timestamp":"1727952499092",
"throughput_mode":"PAY_PER_REQUEST"
}
}
```
`last_update_to_pay_per_request_timestamp` 值的測量單位為毫秒。
------
#### [ CLI ]
**使用 變更資料表的輸送量容量模式 AWS CLI**
1. 若要將資料表的容量模式變更為 `PROVIOSIONED` ，您必須根據工作負載的預期尖峰值來設定讀取容量和寫入容量單位。下列命令是此範例。您也可以執行此命令來調整 資料表的讀取容量或寫入容量單位。
```
aws keyspaces update-table --keyspace-name catalog --table-name book_awards
\--capacity-specification throughputMode=PROVISIONED,readCapacityUnits=6000,writeCapacityUnits=3000
```
若要使用自動調整規模設定佈建容量模式，請參閱 [在現有資料表上設定自動擴展](autoscaling.configureTable.md)。
1. 若要將資料表的容量模式變更為隨需模式，請將輸送量模式設定為 `PAY_PER_REQUEST`。下列陳述式為範例。
```
aws keyspaces update-table --keyspace-name catalog --table-name book_awards
\--capacity-specification throughputMode=PAY_PER_REQUEST
```
1. 您可以使用下列命令來檢閱為資料表設定的容量模式。
```
aws keyspaces get-table --keyspace-name catalog --table-name book_awards
```
隨需模式中資料表的輸出如下所示。
```
"capacitySpecification": {
"throughputMode": "PAY_PER_REQUEST",
"lastUpdateToPayPerRequestTimestamp": "2024-10-03T10:48:19.092000+00:00"
}
```
------
# 為 Amazon Keyspaces 中的資料表設定預熱
Amazon Keyspaces 會根據隨需或佈建的輸送量自動擴展儲存分割區，但對於新資料表或突然的輸送量峰值，配置所需的儲存分割區可能需要更長的時間。若要確保新的或現有的資料表有足夠的容量來支援預期的尖峰輸送量，您可以手動設定特定的*暖輸送量*值來*預先暖機*資料表。
*暖輸送量*是指 Amazon Keyspaces 資料表可立即支援的讀取和寫入操作數量。這些值預設為適用於所有新的和現有的資料表。如果您使用隨需模式，或更新佈建輸送量，Amazon Keyspaces 會確保您的應用程式能夠立即發出高達這些值的請求。
Amazon Keyspaces 會在用量增加時自動調整暖輸送量值。若要調整即將到來的尖峰事件的輸送量容量，例如當您從另一個資料庫遷移資料時，可能需要在短時間內載入 TB 的資料時，您可以手動增加資料表的暖輸送量值。這適用於計劃的尖峰事件，其中請求率可能會增加 10 倍、100 倍或更多。首先，評估目前的暖輸送量是否足以處理預期的流量。然後，如果您需要為計劃的尖峰工作負載預先暖機資料表，您可以手動增加暖輸送量值，而無需變更輸送量設定或[容量模式](ReadWriteCapacityMode.md)。
您可以預熱讀取操作、寫入操作或兩者的資料表。您可以為新的和現有的單一區域資料表和多區域資料表增加此值，而且您設定的暖輸送量設定會自動套用至多區域資料表的所有複本。您可以隨時預先暖機的 Amazon Keyspaces 資料表數量沒有限制。完成預熱的時間取決於您設定的值和資料表的大小。您可以同時提交預熱請求，這些請求不會干擾任何資料表操作。您可以將資料表預熱到該區域中帳戶的資料表配額限制。使用 [Service Quotas 主控台](https://console.aws.amazon.com/servicequotas)來檢查您目前的配額，並視需要增加配額。
Amazon Keyspaces 根據隨需用量或佈建容量調整的暖輸送量值，預設適用於所有資料表，無需額外費用。不過，如果您手動將預設暖輸送量值增加到尖峰流量事件的預暖資料表，則需支付額外費用。如需詳細資訊，請參閱 [Amazon Keyspaces 定價](https://aws.amazon.com/keyspaces/pricing/)。
以下是預暖 Amazon Keyspaces 資料表時可能會考慮的一些不同案例和最佳實務。
## 暖輸送量與非均勻存取模式
資料表的暖輸送量可能是每秒 30，000 個讀取單位和每秒 10，000 個寫入單位，但在達到這些值之前，您仍然可能會在讀取或寫入時遇到超過事件的容量。這通常是因為存在熱分割區造成。雖然 Amazon Keyspaces 可以繼續擴展以支援幾乎無限制的輸送量，但每個分割區每秒僅限 1，000 個寫入單位和每秒 3，000 個讀取單位。如果您的應用程式對資料表的一小部分分割區驅動太多流量，即使達到資料表的暖輸送量值，容量也會超過事件。我們建議您遵循 [Amazon Keyspaces 最佳實務](bp-partition-key-design.md)，以確保無縫的可擴展性並避免熱分割區。
## 佈建資料表的暖輸送量
假設佈建資料表的暖輸送量為每秒 30，000 個讀取單位和每秒 10，000 個寫入單位，但目前佈建輸送量為 4，000 RCUs 和 8，000 WCUs。您可以透過更新佈建的輸送量設定，立即將資料表的佈建輸送量擴展到 30，000 RCUs 或 10，000 個 WCUs。當您增加佈建輸送量超過這些值時，暖輸送量會自動調整為新的更高值，因為您已建立新的尖峰輸送量。例如，如果您將佈建的輸送量設定為 50，000 個 RCU，暖輸送量會提高到每秒 50，000 個讀取單位。
```
"ProvisionedThroughput":
{
"ReadCapacityUnits": 4000,
"WriteCapacityUnits": 8000
}
"WarmThroughput":
{
"ReadUnitsPerSecond": 30000,
"WriteUnitsPerSecond": 10000
}
```
## 隨需資料表的暖輸送量
新建立的隨需資料表初始暖輸送量為每秒 12,000 個讀取單位與每秒 4,000 個寫入單位。資料表可立即支援持續流量，最高可達上述層級。當您的請求超過每秒 12，000 個讀取單位或每秒 4，000 個寫入單位時，暖輸送量會自動調整為較高的值。
```
"WarmThroughput":
{
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000
}
```
## 預熱 Amazon Keyspaces 資料表的最佳實務
為 Amazon Keyspaces 資料表實作預熱時，請遵循下列最佳實務：
準確估計所需的容量
由於預熱會產生一次性成本，請根據預期的工作負載仔細計算所需的輸送量，以避免過度佈建。
考慮資料表的結構描述
資料列較大的資料表可能需要更多分割區才能達到相同的輸送量。估算預熱前需求時，請考量平均資料列大小。
監控資料表效能
預熱後，請使用 CloudWatch 指標來驗證您的資料表是否如預期處理負載。如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控預暖資料表的效能](monitor-prewarming-cloudwatch.md)。
管理配額
如果您的應用程式需要高於預設配額允許 (40，000 個 RCUs/WCUs或 2，000 個分割區） 的輸送量，則請求配額會在高流量事件之前大幅增加。若要請求提升配額，您可以使用 [Service Quotas 主控台](https://console.aws.amazon.com/servicequotas)。
最佳化成本
對於暫時高流量事件，請考慮使用預熱，而不是切換到具有高容量的佈建模式，因為它在短期事件中可能更具成本效益。如需定價的詳細資訊，請參閱 [Amazon Keyspaces 定價](https://aws.amazon.com/keyspaces/pricing/)。
**注意**
在測試階段監控應用程式的效能指標，以驗證預暖組態是否充分支援工作負載需求。
**Topics**
+ [暖輸送量與非均勻存取模式](#warm-throughput-scenarios-uneven)
+ [佈建資料表的暖輸送量](#warm-throughput-scenarios-provisioned)
+ [隨需資料表的暖輸送量](#warm-throughput-scenarios-ondemand)
+ [預熱 Amazon Keyspaces 資料表的最佳實務](#prewarming-best-practices)
+ [建立暖輸送量較高的新 Amazon Keyspaces 資料表](create-table-warm-throughput.md)
+ [提高現有 Amazon Keyspaces 資料表的暖輸送量](update-warm-throughput.md)
+ [檢視 Amazon Keyspaces 資料表的暖輸送量](view-warm-throughput.md)
+ [使用 Amazon CloudWatch 監控預暖資料表的效能](monitor-prewarming-cloudwatch.md)
# 建立暖輸送量較高的新 Amazon Keyspaces 資料表
您可以使用主控台、CQL 或 ，在建立 Amazon Keyspaces 資料表時調整暖輸送量值 AWS CLI。
------
#### [ Console ]
**如何使用熱輸送量設定建立新的資料表**
1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) 開啟 Amazon Keyspaces 主控台。
1. 在導覽窗格中，選擇 **Tables** (資料表)，然後選擇 **Create table** (建立資料表)。
1. 在**資料表詳細資訊區段的建立**資料表頁面上，選取金鑰空間，並提供新資料表的名稱。 ****
1. 在**資料欄**區段中，建立資料表的結構描述。
1. 在**主索引鍵**區段中，定義資料表的主索引鍵，然後選取選用的叢集資料欄。
1. 在**資料表設定**區段中，選擇**自訂設定**。
1. 繼續**讀取/寫入容量設定**。
1. 對於**容量模式**，您可以選擇**隨需**或**佈建**。
1. 在**資料表的預熱前**區段中，您可以視需要增加**每秒讀取單位**和**每秒寫入單位**的值，以準備資料表來處理規劃的尖峰事件。
Amazon Keyspaces 根據隨需用量或佈建容量調整的暖輸送量值，預設適用於所有資料表，無需額外費用。請注意，如果您手動增加預設暖傳輸量值來為尖峰流量事件預熱資料表，則需支付額外費用。
1. 視需要設定其他選用的資料表功能。然後選擇**建立資料表**。
------
#### [ Cassandra Query Language (CQL) ]
+ 使用下列其中一種方法建立具有暖輸送量的資料表：
+ 對於佈建模式，請建立資料表，並使用下列 CQL 語法指定讀取和寫入的預期尖峰容量：
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank))
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PROVISIONED',
'read_capacity_units': 20000,
'write_capacity_units': 10000
},
'warm_throughput': {
'read_units_per_second': 40000,
'write_units_per_second': 20000
}
};
```
+ 對於隨需模式，請建立資料表，並使用下列 CQL 語法指定預期的讀取和寫入尖峰容量：
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank))
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PAY_PER_REQUEST'
},
'warm_throughput': {
'read_units_per_second': 40000,
'write_units_per_second': 20000
}
};
```
若要確認資料表的容量設定，請參閱 [檢視 Amazon Keyspaces 資料表的暖輸送量](view-warm-throughput.md)。
------
#### [ CLI ]
1. 使用下列其中一種方法，使用 建立具有暖輸送量的資料表 AWS CLI
+ 在佈建模式中建立新的資料表，並指定新資料表讀取和寫入的預期尖峰容量值。下列陳述式是此範例。
```
aws keyspaces create-table \
--keyspace-name 'catalog' \
--table-name 'book_awards' \
--schema-definition 'allColumns=[{name=year,type=int},{name=award,type=text},{name=rank,type=int},{name=category,type=text},{name=book_title,type=text},{name=author,type=text},{name=publisher,type=text}],partitionKeys=[{name=year},{name=award}],clusteringKeys=[{name=category,orderBy=ASC},{name=rank,orderBy=ASC}]' \
--capacity-specification throughputMode=PROVISIONED,readCapacityUnits=20000,writeCapacityUnits=10000 \
--warm-throughput-specification readUnitsPerSecond=40000,writeUnitsPerSecond=20000
```
+ 在隨需模式下建立新的資料表，並指定新資料表的讀取和寫入的預期尖峰容量值。下列陳述式是此範例。
```
aws keyspaces create-table \
--keyspace-name 'catalog' \
--table-name 'book_awards' \
--schema-definition 'allColumns=[{name=year,type=int},{name=award,type=text},{name=rank,type=int},{name=category,type=text},{name=book_title,type=text},{name=author,type=text},{name=publisher,type=text}],partitionKeys=[{name=year},{name=award}],clusteringKeys=[{name=category,orderBy=ASC},{name=rank,orderBy=ASC}]' \
--warmThroughputSpecification readUnitsPerSecond=40000,writeUnitsPerSecond=20000
```
1. 命令的輸出會傳回資料表的 ARN，如下列範例所示。
```
{
"resourceArn": "arn:aws::cassandra:us-east-1:111122223333:/keyspace/catalog/table/book_awards>"
}
```
若要確認資料表的容量設定，請參閱 [檢視 Amazon Keyspaces 資料表的暖輸送量](view-warm-throughput.md)。
------
#### [ Java ]
**使用適用於 Java 的 開發套件建立新資料表。**
+ 在佈建模式中建立新的資料表，並指定新資料表讀取和寫入的預期尖峰容量值。下列程式碼範例是此範例。
```
import software.amazon.awssdk.services.keyspaces.KeyspacesClient;
import software.amazon.awssdk.services.keyspaces.model.*;
public class PreWarmingExample {
public static void main(String[] args) {
KeyspacesClient keyspacesClient = KeyspacesClient.builder().build();
// Define schema
List columns = Arrays.asList(
ColumnDefinition.builder().name("year").type("int").build(),
ColumnDefinition.builder().name("award").type("text").build(),
ColumnDefinition.builder().name("rank").type("int").build(),
ColumnDefinition.builder().name("category").type("text").build(),
ColumnDefinition.builder().name("book_title").type("text").build(),
ColumnDefinition.builder().name("author").type("text").build(),
ColumnDefinition.builder().name("publisher").type("text").build()
);
List partitionKeys = Arrays.asList(
PartitionKey.builder().name("year").build(),
PartitionKey.builder().name("award").build()
);
List clusteringKeys = Arrays.asList(
ClusteringKey.builder().name("category").orderBy("ASC").build(),
ClusteringKey.builder().name("rank").orderBy("ASC").build()
);
SchemaDefinition schema = SchemaDefinition.builder()
.allColumns(columns)
.partitionKeys(partitionKeys)
.clusteringKeys(clusteringKeys)
.build();
// Define capacity specification
CapacitySpecification capacitySpec = CapacitySpecification.builder()
.throughputMode(ThroughputMode.PROVISIONED)
.readCapacityUnits(20000)
.writeCapacityUnits(10000)
.build();
// Define warm throughput specification
WarmThroughputSpecification warmThroughput = WarmThroughputSpecification.builder()
.readUnitsPerSecond(40000L)
.writeUnitsPerSecond(20000L)
.build();
// Create table with PreWarming
CreateTableRequest request = CreateTableRequest.builder()
.keyspaceName("catalog")
.tableName("book_awards")
.schemaDefinition(schema)
.capacitySpecification(capacitySpec)
.warmThroughputSpecification(warmThroughput)
.build();
CreateTableResponse response = keyspacesClient.createTable(request);
System.out.println("Table created with ARN: " + response.resourceArn());
}
}
```
------
# 提高現有 Amazon Keyspaces 資料表的暖輸送量
您可以使用主控台、CQL 或 來增加 Amazon Keyspaces 資料表目前的暖輸送量值 AWS CLI。
------
#### [ Console ]
**如何使用主控台增加資料表的預熱設定**
1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) 開啟 Amazon Keyspaces 主控台。
1. 在導覽窗格中，選擇**資料表**，然後選擇您要更新的資料表。
1. 在資料表的**容量**索引標籤上，繼續為**資料表預熱**。
1. 在**資料表的預熱區段**中，選擇**編輯**。
1. 在**編輯資料表預暖**頁面上，您可以更新**每秒讀取單位**和**每秒寫入單位**的值。
1. 選擇**儲存變更**。您的資料表正在以指定的預熱前設定進行更新。
------
#### [ Cassandra Query Language (CQL) ]
**使用 CQL 增加資料表的暖輸送量設定**
+ 使用 `ALTER TABLE`陳述式來增加資料表的暖輸送量。下列陳述式是此範例。
```
ALTER TABLE catalog.book_awards
WITH CUSTOM_PROPERTIES = {
'warm_throughput': {
'read_units_per_second': 60000,
'write_units_per_second': 30000
}
};
```
若要確認資料表的更新容量設定，請參閱 [檢視 Amazon Keyspaces 資料表的暖輸送量](view-warm-throughput.md)。
------
#### [ CLI ]
**使用 增加資料表的預熱前設定 AWS CLI**
+ 若要增加資料表的暖通量，您可以使用 `update-table`命令。下列陳述式是此範例。
```
aws keyspaces update-table \
--keyspace-name 'catalog' \
--table-name 'book_awards' \
--warmThroughputSpecification readUnitsPerSecond=60000,writeUnitsPerSecond=30000
```
若要確認資料表的更新容量設定，請參閱 [檢視 Amazon Keyspaces 資料表的暖輸送量](view-warm-throughput.md)。
------
#### [ Java ]
**使用適用於 Java 的 SDK 更新資料表的預熱前設定。**
+ 更新資料表的暖輸送量設定。下列程式碼範例是此範例。
```
import software.amazon.awssdk.services.keyspaces.KeyspacesClient;
import software.amazon.awssdk.services.keyspaces.model.*;
public class UpdatePreWarmingExample {
public static void main(String[] args) {
KeyspacesClient keyspacesClient = KeyspacesClient.builder().build();
// Define new warm throughput specification
WarmThroughputSpecification warmThroughput = WarmThroughputSpecification.builder()
.readUnitsPerSecond(60000L)
.writeUnitsPerSecond(30000L)
.build();
// Update table with new PreWarming settings
UpdateTableRequest request = UpdateTableRequest.builder()
.keyspaceName("catalog")
.tableName("book_awards")
.warmThroughputSpecification(warmThroughput)
.build();
UpdateTableResponse response = keyspacesClient.updateTable(request);
System.out.println("Table update requested: " + response.resourceArn());
}
}
```
------
# 檢視 Amazon Keyspaces 資料表的暖輸送量
您可以使用主控台、CQL 或 檢視 Amazon Keyspaces 資料表目前的暖輸送量值 AWS CLI。
------
#### [ Console ]
**如何使用主控台檢視資料表的預熱前設定。**
1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) 開啟 Amazon Keyspaces 主控台。
1. 在導覽窗格中，選擇**資料表**，然後選擇您要檢閱的資料表。
1. 在資料表的**容量**索引標籤上，繼續為**資料表預熱**。
------
#### [ Cassandra Query Language (CQL) ]
**使用 CQL 檢視資料表的暖通量設定**
+ 若要檢視資料表的暖輸送量設定，您可以使用下列 CQL 陳述式。
```
SELECT custom_properties
FROM system_schema_mcs.tables
WHERE keyspace_name='catalog' and table_name='book_awards';
// Output:
...
custom_properties
----------------------------------------------------------------------------------
{
'warm_throughput':
{
'read_units_per_second': '40000',
'write_units_per_second': '20000',
'status': 'AVAILABLE'
}
}
...
```
------
#### [ CLI ]
**使用 檢視資料表的暖通量設定 AWS CLI**
+ 您可以使用 `get-table`命令檢視資料表的暖輸送量設定，如下列範例所示。
```
aws keyspaces get-table \
--keyspace-name 'catalog' \
--table-name 'book_awards'
```
以下顯示佈建模式中單一區域資料表的 `get-table`命令範例輸出。
```
{
"keyspaceName": "catalog",
"tableName": "book_awards",
... Existing Fields ...,
"capacitySpecificationSummary": {
"throughputMode": "PROVISIONED",
"readCapacityUnits": 20000,
"writeCapacityUnits": 10000
},
"warmThroughputSpecificationSummary": {
"readUnitsPerSecond": 40000,
"writeUnitsPerSecond": 20000,
"status": "AVAILABLE"
}
}
```
以下顯示隨需模式下單一區域資料表的範例輸出。
```
{
"keyspaceName": "catalog",
"tableName": "book_awards_ondemand",
... Existing Fields ...,
"capacitySpecification": {
"throughputMode": "PAY_PER_REQUEST"
},
"warmThroughputSpecificationSummary": {
"readUnitsPerSecond": 40000,
"writeUnitsPerSecond": 20000,
"status": "AVAILABLE"
}
}
```
------
#### [ Java ]
**使用適用於 Java 的 SDK 讀取資料表的預熱前設定。**
+ 使用 讀取資料表的暖通量值`get-table`。下列程式碼範例是此範例。
```
import software.amazon.awssdk.services.keyspaces.KeyspacesClient;
import software.amazon.awssdk.services.keyspaces.model.*;
public class GetTableWithPreWarmingExample {
public static void main(String[] args) {
KeyspacesClient keyspacesClient = KeyspacesClient.builder().build();
// Get table details including PreWarming specification
GetTableRequest request = GetTableRequest.builder()
.keyspaceName("catalog")
.tableName("book_awards")
.build();
GetTableResponse response = keyspacesClient.getTable(request);
// Access PreWarming details
if (response.warmThroughputSpecification() != null) {
WarmThroughputSpecificationSummary warmThroughputSummary = response.warmThroughputSpecification();
System.out.println("PreWarming Status: " + warmThroughputSummary.status());
System.out.println("Read Units: " + warmThroughputSummary.readUnitsPerSecond());
System.out.println("Write Units: " + warmThroughputSummary.writeUnitsPerSecond());
// Check if PreWarming is active
if (warmThroughputSummary.status().equals("AVAILABLE")) {
System.out.println("Table is fully pre-warmed and ready for high throughput");
} else if (warmThroughputSummary.status().equals("UPDATING")) {
System.out.println("Table PreWarming is currently being updated");
}
} else {
System.out.println("Table does not have PreWarming enabled");
}
}
}
```
------
# 使用 Amazon CloudWatch 監控預暖資料表的效能
Amazon Keyspaces 預暖不會引入新的 CloudWatch 指標，但您可以使用現有的 Amazon Keyspaces 指標來監控預暖資料表的效能：
SuccessfulRequestLatency
監控此指標，以確認預熱的資料表正在處理具有預期延遲的請求。
WriteThrottleEvents 和 ReadThrottleEvents
對於正確預暖的資料表，這些指標應保持低。如果您在預熱前看到容量不足錯誤，您可能需要調整暖輸送量值。
ConsumedReadCapacityUnits 和 ConsumedWriteCapacityUnits
這些指標顯示實際的容量使用量，這有助於驗證您的預暖組態是否適當。
ProvisionedReadCapacityUnits 和 ProvisionedWriteCapacityUnits
對於佈建的資料表，這些指標會顯示目前配置的容量。
您可以在 CloudWatch 主控台中檢視這些指標，或使用 CloudWatch API 進行查詢。如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon Keyspaces](monitoring-cloudwatch.md)。
# 使用 Amazon Keyspaces 自動擴展自動管理輸送量容量
許多資料庫工作負載本來就具週期性或難以事先預測。例如，假設有一個社交聯網應用程式，其中大部分使用者會在日間活動。資料庫必須能夠處理日間活動，但夜間則不需要同樣多的輸送量。
另一個範例則是正被快速採用的新行動遊戲應用程式。如果遊戲變得非常熱門，它可能會超過可用的資料庫資源，這會導致效能緩慢和客戶不滿意。這類工作負載通常需要手動介入來擴展或縮減資料庫資源，以回應不斷改變的用量。
Amazon Keyspaces （適用於 Apache Cassandra) 透過自動調整輸送量容量以回應實際的應用程式流量，協助您有效率地佈建可變工作負載的輸送量容量。Amazon Keyspaces 使用 Application Auto Scaling 服務來代表您增加和減少資料表的讀取和寫入容量。如需 Application Auto Scaling 的詳細資訊，請參閱 [Application Auto Scaling 使用者指南](https://docs.aws.amazon.com/autoscaling/application/userguide/)。
**注意**
若要快速開始使用 Amazon Keyspaces 自動擴展，請參閱 [設定和更新 Amazon Keyspaces 自動擴展政策](autoscaling.configure.md)。
## Amazon Keyspaces 自動擴展的運作方式
下圖提供 Amazon Keyspaces 自動擴展如何管理資料表輸送量容量的高階概觀。
![\[圖表顯示使用者變更 Amazon Keyspaces 資料表時涉及的不同服務。服務是 Amazon CloudWatch、Amazon SNS 和 Application Auto Scaling，它會發出 ALTER TABLE 陳述式，根據使用者的讀取或寫入用量來變更容量。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/keyspaces_auto-scaling.png)
若要啟用資料表的自動擴展，您可以建立*擴展政策*。擴展政策會指定您要擴展讀取容量或寫入容量 (或兩者)，也可為資料表或索引指定最大與最小佈建容量單位設定。
擴展政策也會定義*目標使用率*。「目標使用率」是在某時間點使用容量單位與佈建容量單位的比率，以百分比表示。自動擴展使用*目標追蹤*演算法來向上或向下調整資料表的佈建輸送量，以回應實際工作負載。這樣做可讓實際容量使用率保持在或接近您的目標使用率。
您可以為讀取和寫入容量設定介於 20% 到 90% 之間的自動擴展目標使用率值。預設目標使用率為 70%。如果您的流量快速變更，而且您希望容量更快開始擴展，您可以將目標使用率設定為較低的百分比。如果您的應用程式流量變更較慢，而且您想要降低輸送量成本，您也可以將目標使用率設定為較高的速率。
如需擴展政策的詳細資訊，請參閱《[Application Auto Scaling 使用者指南》中的 Application Auto Scaling 的目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)。 [https://docs.aws.amazon.com/autoscaling/application/userguide/](https://docs.aws.amazon.com/autoscaling/application/userguide/)
當您建立擴展政策時，Amazon Keyspaces 會代表您建立兩對 Amazon CloudWatch 警示。每對代表佈建和耗用輸送量設定的上限和下限。當資料表的實際使用率持續一段時間偏離您的目標使用率時，就會觸發這些 CloudWatch 警示。若要進一步了解 Amazon CloudWatch，請參閱 [Amazon CloudWatch 使用者指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)。
觸發其中一個 CloudWatch 警示時，Amazon Simple Notification Service (Amazon SNS) 會傳送通知給您 （如果您已啟用）。CloudWatch 警示接著會叫用 Application Auto Scaling 來評估您的擴展政策。這反過來會向 Amazon Keyspaces 發出 Alter Table 請求，以視需要向上或向下調整資料表的佈建容量。若要進一步了解 Amazon SNS 通知，請參閱[設定 Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)。
Amazon Keyspaces 會透過增加 （或減少） 資料表的佈建輸送量容量來處理 Alter Table 請求，以便接近您的目標使用率。
**注意**
Amazon Keyspaces Auto Scaling 只有在實際工作負載持續幾分鐘保持升高 （或降低） 時，才會修改佈建的輸送量設定。 目標追蹤演算法會設法長期將目標使用率保持在或接近您選擇的值。資料表的內建高載容量可應付短期遽增的活動。
## 自動擴展如何適用於多區域資料表
為了確保佈建容量模式中 AWS 區域 所有多區域資料表的所有資料表複本一律有足夠的讀取和寫入容量，建議您設定 Amazon Keyspaces 自動擴展。
當您在佈建模式中使用多區域資料表搭配自動擴展時，您無法停用單一資料表複本的自動擴展。但是，您可以調整不同區域的資料表讀取自動擴展設定。例如，您可以為複寫資料表的每個區域指定不同的讀取容量和讀取自動擴展設定。
您在指定區域中為資料表複本設定的讀取自動擴展設定會覆寫資料表的一般自動擴展設定。不過，寫入容量必須在所有資料表複本中保持同步，以確保有足夠的容量可在所有區域中複寫寫入。
Amazon Keyspaces 自動擴展 AWS 區域 會根據該區域中的用量，獨立更新每個 中資料表的佈建容量。因此，當自動擴展處於作用中狀態時，多區域資料表的每個區域中的佈建容量可能會不同。
您可以使用 Amazon Keyspaces 主控台 AWS CLI、API 或 CQL 來設定多區域資料表及其複本的自動擴展設定。如需如何建立和更新多區域資料表自動擴展設定的詳細資訊，請參閱 [更新 Amazon Keyspaces 中多區域資料表的佈建容量和自動擴展設定](tables-mrr-autoscaling.md)。
**注意**
如果您針對多區域資料表使用自動擴展，則必須一律使用 Amazon Keyspaces API 操作來設定自動擴展設定。如果您直接使用 Application Auto Scaling API 操作來設定自動擴展設定，則無法指定多區域資料表 AWS 區域 的 。這可能會導致不支援的組態。
## 使用須知
開始使用 Amazon Keyspaces 自動擴展之前，您應該注意下列事項：
+ Amazon Keyspaces 自動擴展不適用於中東 （阿拉伯聯合大公國） 區域。
+ Amazon Keyspaces 自動擴展可根據您的擴展政策，視需要增加讀取容量或寫入容量。所有 Amazon Keyspaces 配額都會保持有效，如中所述[Amazon Keyspaces 配額 （適用於 Apache Cassandra)](quotas.md)。
+ Amazon Keyspaces 自動擴展不會阻止您手動修改佈建輸送量設定。這些手動調整不會影響連接到擴展政策的任何現有 CloudWatch 警示。
+ 如果您使用主控台建立具有佈建輸送量容量的資料表，則預設會啟用 Amazon Keyspaces 自動擴展。您可以隨時修改自動擴展設定。如需詳細資訊，請參閱[關閉資料表的 Amazon Keyspaces 自動擴展](autoscaling.turnoff.md)。
+ 如果您使用 CloudFormation 建立擴展政策，您應該從 管理擴展政策， CloudFormation 以便堆疊與堆疊範本同步。如果您從 Amazon Keyspaces 變更擴展政策，則會在堆疊重設時，以 CloudFormation 堆疊範本的原始值覆寫這些政策。
+ 如果您使用 CloudTrail 監控 Amazon Keyspaces 自動擴展，您可能會在組態驗證程序中看到 Application Auto Scaling 發出的呼叫提醒。您可以使用 欄位來篩選掉這些提醒，該`invokedBy`欄位包含這些驗證檢查`application-autoscaling.amazonaws.com`的 。
# 設定和更新 Amazon Keyspaces 自動擴展政策
您可以使用 主控台、CQL 或 AWS Command Line Interface (AWS CLI) 來設定新資料表和現有資料表的 Amazon Keyspaces 自動擴展。您也可以修改自動擴展設定或停用自動擴展。
如需設定向內擴展和向外擴展冷卻時間等更進階的功能，建議您使用 CQL 或 AWS CLI 來管理 Amazon Keyspaces 擴展政策。
**Topics**
+ [設定 Amazon Keyspaces 自動擴展的許可](autoscaling.permissions.md)
+ [使用自動擴展建立新的資料表](autoscaling.createTable.md)
+ [在現有資料表上設定自動擴展](autoscaling.configureTable.md)
+ [檢視資料表的 Amazon Keyspaces 自動擴展組態](autoscaling.viewPolicy.md)
+ [關閉資料表的 Amazon Keyspaces 自動擴展](autoscaling.turnoff.md)
+ [在 Amazon CloudWatch 中檢視 Amazon Keyspaces 資料表的自動擴展活動](autoscaling.activity.md)
# 設定 Amazon Keyspaces 自動擴展的許可
若要開始使用，請確認主體具有適當的許可來建立和管理自動擴展設定。在 AWS Identity and Access Management (IAM) 中，管理 Amazon Keyspaces 擴展政策`AmazonKeyspacesFullAccess`需要 AWS 受管政策。
**重要**
`application-autoscaling:*` 需要 許可才能停用資料表上的自動擴展。您必須關閉資料表的自動擴展，才能將其刪除。
若要設定 Amazon Keyspaces 主控台存取和 Amazon Keyspaces 自動擴展的 IAM 使用者或角色，請新增下列政策。
**連接`AmazonKeyspacesFullAccess`政策**
1. 登入 AWS 管理主控台 並開啟位於 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 的 IAM 主控台。
1. 在 IAM 主控台儀表板上，選擇**使用者**，然後從清單中選擇您的 IAM 使用者或角色。
1. 在 **Summary** (摘要) 頁面上，選擇 **Add permissions** (新增許可)。
1. 選擇 **Attach existing policies directly** (直接連接現有政策)。
1. 從政策清單中，選擇 **AmazonKeyspacesFullAccess**，然後選擇**下一步：檢閱**。
1. 選擇**新增許可**。
# 使用自動擴展建立新的資料表
當您建立新的 Amazon Keyspaces 資料表時，您可以為資料表的寫入或讀取容量自動啟用自動擴展。這可讓 Amazon Keyspaces 代表您聯絡 Application Auto Scaling，將資料表註冊為可擴展的目標，並調整佈建的寫入或讀取容量。
如需如何建立多區域資料表和為資料表複本設定不同自動擴展設定的詳細資訊，請參閱 [在 Amazon Keyspaces 中使用自動擴展的佈建模式中建立多區域資料表](tables-mrr-create-provisioned.md)。
**注意**
Amazon Keyspaces 自動擴展需要存在可代表您執行自動擴展動作的服務連結角色 (`AWSServiceRoleForApplicationAutoScaling_CassandraTable`)。系統會自動建立此角色。如需詳細資訊，請參閱[使用 Amazon Keyspaces 的服務連結角色](using-service-linked-roles.md)。
------
#### [ Console ]
**使用主控台建立已啟用自動擴展的新資料表**
1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) 開啟 Amazon Keyspaces 主控台。
1. 在導覽窗格中，選擇 **Tables** (資料表)，然後選擇 **Create table** (建立資料表)。
1. 在**資料表詳細資訊區段的建立**資料表頁面上，選取金鑰空間，並提供新資料表的名稱。 ****
1. 在**資料欄**區段中，建立資料表的結構描述。
1. 在**主索引鍵**區段中，定義資料表的主索引鍵，然後選取選用的叢集資料欄。
1. 在**資料表設定**區段中，選擇**自訂設定**。
1. 繼續**讀取/寫入容量設定**。
1. 針對**容量模式**，選擇**佈建**。
1. 在**讀取容量**區段中，確認**已自動選取擴展**。
在此步驟中，您會選取資料表的最小和最大讀取容量單位，以及目標使用率。
+ **容量單位**下限 – 輸入資料表應隨時準備好支援的輸送量下限值。此值必須介於 1 和您帳戶的每秒最大輸送量配額之間 （預設為 40，000)。
+ **最大容量單位** – 輸入您要為資料表佈建的最大輸送量。此值必須介於 1 和您帳戶的每秒最大輸送量配額之間 （預設為 40，000)。
+ **目標使用**率 – 輸入介於 20% 到 90% 之間的目標使用率。當流量超過定義的目標使用率時，容量會自動擴展。當流量低於定義的目標時，會自動再次縮減規模。
**注意**
若要進一步了解 帳戶的預設配額以及如何增加這些配額，請參閱 [Amazon Keyspaces 配額 （適用於 Apache Cassandra)](quotas.md)。
1. 在**寫入容量**區段中，選擇與上一個步驟中為讀取容量定義的相同設定，或手動設定容量值。
1. 選擇 **Create Table** (建立資料表)。您的資料表是使用指定的自動擴展參數建立的。
------
#### [ Cassandra Query Language (CQL) ]
**使用 CQL 使用 Amazon Keyspaces 自動擴展建立新的資料表**
若要以程式設計方式設定資料表的自動擴展設定，您可以使用包含 Amazon Keyspaces 自動擴展參數的 `AUTOSCALING_SETTINGS`陳述式。這些參數定義了指示 Amazon Keyspaces 調整資料表佈建輸送量的條件，以及要採取哪些額外的選用動作。在此範例中，您會定義 *mytable* 的自動擴展設定。
該政策包含下列元素：
+ `AUTOSCALING_SETTINGS` – 指定是否允許 Amazon Keyspaces 代表您調整輸送量容量。需要下列值：
+ `provisioned_write_capacity_autoscaling_update`:
+ `minimum_units`
+ `maximum_units`
+ `provisioned_read_capacity_autoscaling_update`:
+ `minimum_units`
+ `maximum_units`
+ `scaling_policy` – Amazon Keyspaces 支援目標追蹤政策。若要定義目標追蹤政策，請設定下列參數。
+ `target_value` – Amazon Keyspaces 自動擴展可確保耗用容量與佈建容量的比例保持在或接近此值。您能以百分比的形式定義 `target_value`。
+ `disableScaleIn`：（選用） `boolean`指定資料表`scale-in`是否已停用或已啟用的 。此參數預設為停用。若要開啟 `scale-in`，請將 `boolean`值設定為 `FALSE`。這表示會自動為您縮減資料表的容量。
+ `scale_out_cooldown` – 橫向擴展活動會增加資料表的佈建輸送量。若要為橫向擴展活動新增冷卻時間，請為 指定以秒為單位的值`scale_out_cooldown`。如果您未指定值，預設值為 0。如需目標追蹤和冷卻時間的詳細資訊，請參閱《*Application Auto Scaling * [ Scaling 使用者指南》中的目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)。
+ `scale_in_cooldown` – 縮減活動可減少資料表的佈建輸送量。若要為縮減活動新增冷卻時間，請為 指定以秒為單位的值`scale_in_cooldown`。如果您未指定值，預設值為 0。如需目標追蹤和冷卻時間的詳細資訊，請參閱《*Application Auto Scaling * [ Scaling 使用者指南》中的目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)。
**注意**
為了進一步了解 `target_value` 如何運作，請假設您資料表的佈建輸送量設定為 200 個寫入容量單位。您決定為此資料表建立擴展政策，並將 `target_value` 設為 70 %。
現在，假設您開始將寫入流量導向該資料表，那實際的寫入輸送量就會是 150 個容量單位。耗用與佈建比率現在為 (150/200)，也就是 75%。此比率超過您的目標，因此自動擴展會將佈建的寫入容量增加到 215，使得比率為 (150 / 215) 或 69.77%，`target_value`盡可能接近您的 ，但不會超過它。
對於 *mytable*，您可以將讀取和寫入容量`TargetValue`設定為 50%。Amazon Keyspaces 自動擴展會在 5–10 個容量單位的範圍內調整資料表的佈建輸送量，以便consumed-to-provisioned比率維持在 50% 或接近 50%。對於讀取容量，您可以將 `ScaleOutCooldown`和 的值設定為 `ScaleInCooldown` 60 秒。
您可以使用下列陳述式，在啟用自動擴展的情況下建立新的 Amazon Keyspaces 資料表。
```
CREATE TABLE mykeyspace.mytable(pk int, ck int, PRIMARY KEY (pk, ck))
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PROVISIONED',
'read_capacity_units': 1,
'write_capacity_units': 1
}
} AND AUTOSCALING_SETTINGS = {
'provisioned_write_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50
}
}
},
'provisioned_read_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50,
'scale_in_cooldown': 60,
'scale_out_cooldown': 60
}
}
}
};
```
------
#### [ CLI ]
**使用 建立具有 Amazon Keyspaces 自動擴展的新資料表 AWS CLI**
若要以程式設計方式設定資料表的自動擴展設定，您可以使用 `autoScalingSpecification`動作來定義 Amazon Keyspaces 自動擴展的參數。這些參數定義了指示 Amazon Keyspaces 調整資料表佈建輸送量的條件，以及要採取哪些額外的選用動作。在此範例中，您可以定義 *mytable* 的自動擴展設定。
該政策包含下列元素：
+ `autoScalingSpecification` – 指定是否允許 Amazon Keyspaces 代表您調整容量輸送量。您可以分別為讀取和寫入容量啟用自動擴展。然後，您必須為 指定下列參數`autoScalingSpecification`：
+ `writeCapacityAutoScaling` – 最大和最小寫入容量單位。
+ `readCapacityAutoScaling` – 最大和最小讀取容量單位。
+ `scalingPolicy` – Amazon Keyspaces 支援目標追蹤政策。若要定義目標追蹤政策，請設定下列參數。
+ `targetValue` – Amazon Keyspaces 自動擴展可確保耗用容量與佈建容量的比例保持在或接近此值。您能以百分比的形式定義 `targetValue`。
+ `disableScaleIn`：（選用） `boolean`指定資料表`scale-in`是否已停用或已啟用的 。此參數預設為停用。若要開啟 `scale-in`，請將 `boolean`值設定為 `FALSE`。這表示會自動為您縮減資料表的容量。
+ `scaleOutCooldown` – 橫向擴展活動會增加資料表的佈建輸送量。若要為向外擴展活動新增冷卻時間，請為 指定以秒為單位的值`ScaleOutCooldown`。預設值為 0。如需目標追蹤和冷卻期間的詳細資訊，請參閱《*Application Auto Scaling * [ Scaling 使用者指南》中的目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)。
+ `scaleInCooldown` – 縮減活動可減少資料表的佈建輸送量。若要為縮減活動新增冷卻時間，請為 指定以秒為單位的值`ScaleInCooldown`。預設值為 0。如需目標追蹤和冷卻期間的詳細資訊，請參閱《*Application Auto Scaling * [ Scaling 使用者指南》中的目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)。
**注意**
為了進一步了解 `TargetValue` 如何運作，請假設您資料表的佈建輸送量設定為 200 個寫入容量單位。您決定為此資料表建立擴展政策，並將 `TargetValue` 設為 70 %。
現在，假設您開始將寫入流量導向該資料表，那實際的寫入輸送量就會是 150 個容量單位。耗用與佈建比率現在為 (150/200)，也就是 75%。此比率超過您的目標，因此自動擴展會將佈建的寫入容量增加到 215，因此比率為 (150 / 215) 或 69.77%，`TargetValue`盡可能接近您的 ，但不會超過它。
對於 *mytable*，您可以將讀取和寫入容量`TargetValue`設定為 50%。Amazon Keyspaces 自動擴展會在 5–10 個容量單位的範圍內調整資料表的佈建輸送量，以便consumed-to-provisioned比率維持在 50% 或接近 50%。對於讀取容量，您可以將 `ScaleOutCooldown`和 的值設定為 `ScaleInCooldown` 60 秒。
建立具有複雜自動擴展設定的資料表時，從 JSON 檔案載入自動擴展設定會很有幫助。針對下列範例，您可以從 [auto-scaling.zip](samples/auto-scaling.zip) 下載範例 JSON 檔案，並擷取 `auto-scaling.json`，並記下檔案的路徑。在此範例中，JSON 檔案位於目前的 目錄中。如需不同的檔案路徑選項，請參閱[如何從檔案載入參數](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html#cli-usage-parameters-file-how)。
```
aws keyspaces create-table --keyspace-name mykeyspace --table-name mytable
\ --schema-definition 'allColumns=[{name=pk,type=int},{name=ck,type=int}],partitionKeys=[{name=pk},{name=ck}]'
\ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=1,writeCapacityUnits=1
\ --auto-scaling-specification file://auto-scaling.json
```
------
# 在現有資料表上設定自動擴展
您可以更新現有的 Amazon Keyspaces 資料表，以開啟資料表寫入或讀取容量的自動擴展。如果您要更新目前處於隨需容量模式的資料表，則必須先將資料表的容量模式變更為佈建的容量模式。
如需如何更新多區域資料表自動擴展設定的詳細資訊，請參閱 [更新 Amazon Keyspaces 中多區域資料表的佈建容量和自動擴展設定](tables-mrr-autoscaling.md)。
Amazon Keyspaces 自動擴展需要存在可代表您執行自動擴展動作的服務連結角色 (`AWSServiceRoleForApplicationAutoScaling_CassandraTable`)。系統會自動建立此角色。如需詳細資訊，請參閱[使用 Amazon Keyspaces 的服務連結角色](using-service-linked-roles.md)。
------
#### [ Console ]
**為現有資料表設定 Amazon Keyspaces 自動擴展**
1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) 開啟 Amazon Keyspaces 主控台。
1. 選擇您要使用的資料表，然後前往**容量**索引標籤。
1. 在**容量設定**區段中，選擇**編輯**。
1. 在**容量模式下**，確定資料表使用**佈建容量**模式。
1. 選取**自動擴展**，並參閱 中的步驟 6 [使用自動擴展建立新的資料表](autoscaling.createTable.md)以編輯讀取和寫入容量。
1. 定義自動擴展設定時，請選擇**儲存**。
------
#### [ Cassandra Query Language (CQL) ]
**使用 CQL 設定具有 Amazon Keyspaces 自動擴展的現有資料表**
您可以使用現有 Amazon Keyspaces 資料表的 `ALTER TABLE`陳述式，為資料表的寫入或讀取容量設定自動擴展。如果您要更新目前處於隨需容量模式的資料表，您必須`capacity_mode`將 設定為已佈建。如果您的資料表已處於佈建容量模式，則可以省略此欄位。
在下列範例中， 陳述式會更新資料表 *mytable*，其處於隨需容量模式。陳述式會將資料表的容量模式變更為已啟用自動擴展的佈建模式。
寫入容量設定在 5–10 個容量單位的範圍內，目標值為 50%。讀取容量也會設定在 5–10 個容量單位的範圍內，目標值為 50%。對於讀取容量，您可以將 `scale_out_cooldown`和 的值設定為 `scale_in_cooldown` 60 秒。
```
ALTER TABLE mykeyspace.mytable
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PROVISIONED',
'read_capacity_units': 1,
'write_capacity_units': 1
}
} AND AUTOSCALING_SETTINGS = {
'provisioned_write_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50
}
}
},
'provisioned_read_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50,
'scale_in_cooldown': 60,
'scale_out_cooldown': 60
}
}
}
};
```
------
#### [ CLI ]
**使用 設定具有 Amazon Keyspaces 自動擴展的現有資料表 AWS CLI**
對於現有的 Amazon Keyspaces 資料表，您可以使用 `UpdateTable`操作開啟資料表寫入或讀取容量的自動擴展。
您可以使用下列命令來開啟現有資料表的 Amazon Keyspaces 自動擴展。資料表的自動擴展設定會從 JSON 檔案載入。針對下列範例，您可以從 [auto-scaling.zip](samples/auto-scaling.zip) 下載範例 JSON 檔案，並擷取 `auto-scaling.json`，並記下檔案的路徑。在此範例中，JSON 檔案位於目前的 目錄中。如需不同的檔案路徑選項，請參閱[如何從檔案載入參數](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html#cli-usage-parameters-file-how)。
如需下列範例中使用之自動擴展設定的詳細資訊，請參閱 [使用自動擴展建立新的資料表](autoscaling.createTable.md)。
```
aws keyspaces update-table --keyspace-name mykeyspace --table-name mytable
\ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=1,writeCapacityUnits=1
\ --auto-scaling-specification file://auto-scaling.json
```
------
# 檢視資料表的 Amazon Keyspaces 自動擴展組態
您可以使用 主控台、CQL 或 AWS CLI 來檢視和更新資料表的 Amazon Keyspaces 自動擴展設定。
------
#### [ Console ]
****
**使用主控台檢視自動擴展設定**
1. 選擇您要檢視的資料表，然後前往**容量**索引標籤。
1. 在**容量設定**區段中，選擇**編輯**。您現在可以修改**讀取容量**或**寫入容量**區段中的設定。如需這些設定的詳細資訊，請參閱 [使用自動擴展建立新的資料表](autoscaling.createTable.md)。
------
#### [ Cassandra Query Language (CQL) ]
**使用 CQL 檢視資料表的 Amazon Keyspaces 自動擴展政策**
若要檢視資料表自動擴展組態的詳細資訊，請使用下列命令。
```
SELECT * FROM system_schema_mcs.autoscaling WHERE keyspace_name = 'mykeyspace' AND table_name = 'mytable';
```
此命令的輸出如下所示。
```
keyspace_name | table_name | provisioned_read_capacity_autoscaling_update | provisioned_write_capacity_autoscaling_update
---------------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
mykeyspace | mytable | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 60, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 60}}} | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 0, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 0}}}
```
------
#### [ CLI ]
**使用 檢視資料表的 Amazon Keyspaces 自動擴展政策 AWS CLI**
若要檢視資料表的自動擴展組態，您可以使用 `get-table-auto-scaling-settings`操作。下列 CLI 命令為範例。
```
aws keyspaces get-table-auto-scaling-settings --keyspace-name mykeyspace --table-name mytable
```
此命令的輸出如下所示。
```
{
"keyspaceName": "mykeyspace",
"tableName": "mytable",
"resourceArn": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"autoScalingSpecification": {
"writeCapacityAutoScaling": {
"autoScalingDisabled": false,
"minimumUnits": 5,
"maximumUnits": 10,
"scalingPolicy": {
"targetTrackingScalingPolicyConfiguration": {
"disableScaleIn": false,
"scaleInCooldown": 0,
"scaleOutCooldown": 0,
"targetValue": 50.0
}
}
},
"readCapacityAutoScaling": {
"autoScalingDisabled": false,
"minimumUnits": 5,
"maximumUnits": 10,
"scalingPolicy": {
"targetTrackingScalingPolicyConfiguration": {
"disableScaleIn": false,
"scaleInCooldown": 60,
"scaleOutCooldown": 60,
"targetValue": 50.0
}
}
}
}
}
```
------
# 關閉資料表的 Amazon Keyspaces 自動擴展
您可以隨時關閉資料表的 Amazon Keyspaces 自動擴展。如果您不再需要擴展資料表的讀取或寫入容量，您應該考慮關閉自動擴展，以便 Amazon Keyspaces 不會繼續修改資料表的讀取或寫入容量設定。您可以使用 主控台、CQL 或 更新資料表 AWS CLI。
關閉自動擴展也會刪除代表您建立的 CloudWatch 警示。
若要刪除 Application Auto Scaling 用來存取 Amazon Keyspaces 資料表的服務連結角色，請遵循中的步驟[刪除 Amazon Keyspaces 的服務連結角色](using-service-linked-roles-app-auto-scaling.md#delete-service-linked-role-app-auto-scaling)。
**注意**
若要刪除 Application Auto Scaling 使用的服務連結角色，您必須停用帳戶中所有資料表的自動擴展 AWS 區域。
------
#### [ Console ]
**使用主控台關閉資料表的 Amazon Keyspaces 自動擴展**
**使用 Amazon Keyspaces 主控台**
1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) 開啟 Amazon Keyspaces 主控台。
1. 選擇您要更新的資料表，然後前往**容量**索引標籤。
1. 在**容量設定**區段中，選擇**編輯**。
1. 若要停用 Amazon Keyspaces 自動擴展，請清除**自動擴展**核取方塊。停用自動調整規模會將資料表取消註冊為 Application Auto Scaling 的可擴展目標。
------
#### [ Cassandra Query Language (CQL) ]
**使用 CQL 關閉資料表的 Amazon Keyspaces 自動擴展**
下列陳述式會關閉資料表 *mytable* 寫入容量的自動擴展。
```
ALTER TABLE mykeyspace.mytable
WITH AUTOSCALING_SETTINGS = {
'provisioned_write_capacity_autoscaling_update': {
'autoscaling_disabled': true
}
};
```
------
#### [ CLI ]
**使用 關閉資料表的 Amazon Keyspaces 自動擴展 AWS CLI**
下列命令會關閉資料表讀取容量的自動擴展。它也會刪除代表您建立的 CloudWatch 警示。
```
aws keyspaces update-table --keyspace-name mykeyspace --table-name mytable
\ --auto-scaling-specification readCapacityAutoScaling={autoScalingDisabled=true}
```
------
# 在 Amazon CloudWatch 中檢視 Amazon Keyspaces 資料表的自動擴展活動
您可以使用 Amazon CloudWatch 來監控 Amazon Keyspaces 自動擴展如何使用 資源，這會產生有關您的用量和效能的指標。遵循 [Application Auto Scaling 使用者指南](https://docs.aws.amazon.com/autoscaling/application/userguide/monitoring-cloudwatch.html)中的步驟來建立 CloudWatch 儀表板。
# 在 Amazon Keyspaces 中有效使用高載容量
Amazon Keyspaces 透過提供*高載容量*，為您的每個分割區輸送量佈建提供一些靈活性。每當您未完全使用分割區的輸送量時，Amazon Keyspaces 會保留一部分未使用的容量，以供後續輸送量暴*增*處理用量激增。
Amazon Keyspaces 目前保留最多 5 分鐘 (300 秒） 未使用的讀取和寫入容量。在偶爾高載的讀取或寫入活動期間，這些額外的容量單位可以快速耗用，甚至比您為資料表定義的每秒佈建輸送量更快。
Amazon Keyspaces 也可以使用高載容量進行背景維護和其他任務，而無需事先通知。
請注意，高載容量的詳細資訊可能會在將來有所變更。