本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 估計 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)。