翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Keyspaces で行のサイズを推定する
Amazon Keyspaces は、1 桁ミリ秒の読み取りおよび書き込みパフォーマンスを提供し、複数の 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)に基づいてセルデータの raw サイズを使用し、必要なメタデータを追加します。Amazon Keyspaces がデータ型値とメタデータを保存する方法におけるデータ型といくつかの主な違いを次のセクションに示します。
+ **パーティションキー列** – パーティションキーには最大 2048 バイトのデータを含めることができます。パーティションキーの各キー列には、最大 3 バイトのメタデータが必要です。行のサイズを計算するときには、各パーティションキー列で上限である 3 バイトのメタデータが使用されていることを想定しておくべきです。
+ **クラスタリング列** – クラスタリング列には最大 850 バイトのデータを保存できます。データ値のサイズに加えて、各クラスタリング列のメタデータにはデータ値サイズの最大 20% が必要です。行のサイズを計算するときには、5 バイトのクラスタリング列データ値ごとに 1 バイトのメタデータを追加する必要があります。
**注記**
効率的なクエリと組み込みインデックス作成をサポートするために、Amazon Keyspaces は各パーティションキーとクラスタリングキー列のデータ値を 2 回保存します。
+ **列名** – 各列名に必要なスペースは、列識別子を使用して保存され、列に保存されている各データ値に追加されます。列識別子の格納値は、テーブル内の列の総数によって異なります。
+ 1 ～ 62 カラム: 1 バイト
+ 63 ～ 124 カラム: 2 バイト
+ 125 ～ 186 カラム: 3 バイト
62 列を追加するごとに 1 バイトを追加します。Amazon Keyspaces では、1 つの `INSERT` または `UPDATE` ステートメントで最大 225 個の標準列を変更できることに注意してください。詳細については、「[Amazon Keyspaces サービスクォータ](quotas.md#table)」を参照してください。
## データ型に基づいてデータ値のエンコードされたサイズを推定する
このセクションでは、Amazon Keyspaces のさまざまなデータ型のエンコードされたサイズを推定する方法を示します。
+ **文字列型** – Cassandra `ASCII`、`TEXT`、および `VARCHAR`文字列データ型はすべて、UTF-8 バイナリエンコーディングで Unicode を使用して Amazon Keyspaces に保存されます。Amazon Keyspaces 文字列のサイズは、UTF-8 でエンコードされたバイト数と同じです。
+ **数値型** – Cassandra `INT`、`BIGINT`、`SMALLINT`、`TINYINT`、および `VARINT` データ型は、最大 38 桁の有効数字を持つ可変長のデータ値として Amazon Keyspaces に保存されます。先頭と末尾の 0 は切り捨てられます。これらのデータ型のサイズはいずれも、有効数字 2 桁あたり約 1 バイト\$11 バイトです。
+ **Blob タイプ** – Amazon Keyspaces `BLOB`の は、値の raw バイト長で保存されます。
+ **ブール型** – `Boolean`値のサイズまたは`Null`値は 1 バイトです。
+ **コレクションタイプ** – コンテンツに関係なく、 `LIST`や などのコレクションデータ型を保存する列には 3 バイトのメタデータ`MAP`が必要です。`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 value`の `field name`と から始めます。
+ **フィールド名** – 最上位 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)。
+ **Time to Live (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 (Apache Cassandra 向け) で有効期限 (TTL) を使用してデータを期限切れにする](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 にカウントされます。
## 行サイズ計算の例
すべての列が整数型であるテーブルの例を考えてみましょう。テーブルには、パーティションキー列が 2 つ、クラスタリング列が 2 つ、通常の列が 1 つあります。このテーブルには 5 つの列があるため、列名識別子に必要なスペースは 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 番目の列のサイズを計算します。
```
(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 番目の列のサイズを計算します。
```
(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. 通常の列のサイズを足します。この例では、1 バイトが必要で列 ID が 1 バイトが必要で、余分な 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)」を参照してください。