翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon Keyspaces で読み取り/書き込みスループットのキャパシティ消費量を推定する Amazon Keyspaces でデータを読み書きした際に、クエリで消費される読み取り/書き込みリクエストユニット (RRU/WRU) または読み取り/書き込みキャパシティユニット (RCU/WCU) の量は、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 CloudWatch を使用して Amazon Keyspaces の読み取りと書き込みのキャパシティ消費量を推定する](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 RRU が消費されます。 ``` pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value -----+-----+-----+-----+-----+-----+------- a | b | 1 | a | b | 60 | value_1 ``` Amazon Keyspaces はこのクエリを処理するため、2 RRU を消費して `ck3=60` と `ck3=70` の値を含む行を評価します。ただし、Amazon Keyspaces が返すのは、クエリに指定されている `WHERE` 条件が true である行、つまり値が `ck3=60` の行だけです。クエリで指定された範囲を評価するために、範囲の上限に一致する行 (この例では `ck3 = 70`) を読み取りますが、その行を結果では返しません。読み取りキャパシティの消費量は、返されたデータではなく、クエリの処理時に読み取られたデータに基づきます。 # 限定クエリの読み取りキャパシティ消費量を推定する `LIMIT` 句を使用したクエリを処理する際、Amazon Keyspaces はクエリで指定された条件と一致するデータを探すために、最大ページサイズまでの行数を読み取ります。最初のページで `LIMIT` 値を満たす十分なデータが見つからない場合、1 回以上のページ分割呼び出しが必要になることがあります。次のページの読み取りを続行するには、ページ分割トークンを使用できます。デフォルトのページサイズは 1 MB です。`LIMIT` 句の使用時に読み取りキャパシティの消費量を減らすには、ページサイズを小さくします。ページ分割の詳細については、「[Amazon Keyspaces で結果のページを分割する](paginating-results.md)」を参照してください。 例として、次のクエリを見てみましょう。 ``` SELECT * FROM my_table WHERE partition_key=1234 LIMIT 1; ``` ページサイズが設定されていない場合、Amazon Keyspaces は 1 行しか返さないとしても 1 MB 分のデータを読み取ります。Amazon Keyspaces に 1 行だけ読み取らせるには、このクエリでページサイズを 1 に設定します。その場合、Amazon Keyspaces は 1 行のみを読み取ります。ただし、Time-to-Live の設定やクライアント側のタイムスタンプに基づいて期限切れになった行がないことが前提です。 `PAGE SIZE` パラメータは、Amazon Keyspaces がクライアントに返す行数ではなく、リクエストごとにディスクから Amazon Keyspaces がスキャンする行数を決定します。Amazon Keyspaces は、指定したフィルターを適用します。たとえば、非キー列では不等式、ディスク上のデータをスキャン`LIMIT`した後では などです。を明示的に設定しない場合`PAGE SIZE`、Amazon Keyspaces はフィルターを適用する前に最大 1MB のデータを読み取ります。例えば、 を指定`LIMIT 1`せずに を使用している場合`PAGE SIZE`、Amazon Keyspaces は limit 句を適用して 1 行のみを返します。 オーバーリードを回避するには、 を減らし`PAGE SIZE`て、フェッチごとに Amazon Keyspaces がスキャンする行数を減らします。例えば、クエリ`LIMIT 5`で を定義した場合、Amazon Keyspaces がページ分割された呼び出しごとに 5～10 行のみをスキャンするように、 `PAGE SIZE`を 5～10 の値に設定します。この数を変更して、フェッチの数を減らすことができます。ページサイズより大きい制限の場合、Amazon Keyspaces は合計結果数をページ分割状態で維持します。`LIMIT` が 10,000 行の場合、Amazon Keyspaces はこれらの結果をそれぞれ 5,000 行の 2 ページで取得できます。1MB の制限は、設定されたページサイズの上限です。 # テーブルスキャンの読み取りキャパシティ消費量を推定する `ALLOW FILTERING` オプションを使用したクエリなど、結果的にテーブルのフルスキャンが実行されるクエリも、結果として返されるデータ量よりも読み取り処理量の方が多いクエリの例です。なお、読み取りキャパシティの消費量は、返されたデータではなく、読み取られたデータに基づきます。 テーブルスキャンの例として、次のオンデマンドキャパシティモードのサンプルテーブルを使用します。 ``` pk | ck | value ---+----+--------- pk | 10 | pk | 20 | value_1 pk | 30 | ``` Amazon Keyspaces でオンデマンドキャパシティモードのテーブルを作成した場合、デフォルトのパーティション数は 4 です。このサンプルテーブルでは、すべてのデータが 1 つのパーティションに保存され、残り 3 つのパーティションは空です。 このテーブルに対して、次のクエリを実行します。 ``` SELECT * from amazon_keyspaces.example_table_2; ``` このクエリの結果、テーブルスキャンが実行されます。Amazon Keyspaces がテーブルの 4 つのパーティションをすべてスキャンし、`LOCAL_QUORUM` 整合性モードで 6 RRU を消費します。まず、Amazon Keyspaces は 3 RRU を消費して、`pk=‘pk’` である 3 つの行を読み取ります。次に、さらに 3 RRU を消費して、テーブルの 3 つの空パーティションをスキャンします。このクエリではテーブルスキャンが行われるため、データが空のパーティションも含め、テーブルのすべてのパーティションがスキャンされます。 # Amazon Keyspaces で軽量トランザクションのキャパシティ消費量を推定する 軽量トランザクション (LWT) では、テーブルのデータに対して条件付きの書き込みオペレーションを実行できます。条件付きの更新オペレーションは、現在の状態を評価する条件に基づいてレコードを挿入、更新、削除する場合に便利です。 Amazon Keyspaces では、すべての書き込みオペレーションで LOCAL\$1QUORUM 整合性が必要であり、LWT の使用に追加料金はかかりません。LWTs の違いは、LWT 条件チェックの結果が の場合`FALSE`、Amazon Keyspaces は書き込みキャパシティーユニット (WCUs) または書き込みリクエストユニット (WRUs。消費WCUs/WRUsの数は、行のサイズによって異なります。 たとえば、行サイズが 2 KB の場合、失敗した条件付き書き込みは 2 つの WCUs/WRUs。行がテーブルに現在存在しない場合、オペレーションは 1 つの WCUs/WRUs。 条件チェックの失敗の原因となったリクエストの数を確認するには、CloudWatch で `ConditionalCheckFailed`メトリクスをモニタリングできます。 ## Time to Live (TTL) を使用したテーブルの LWT コストの見積もり LWTs では、クライアント側のタイムスタンプを使用しない TTL で設定されたテーブルに対して、追加の読み込みキャパシティーユニット (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 の機能上の違いについては、「[Pagination (ページ分割)](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 ``` すべての列が整数型であるテーブルの例を考えてみましょう。テーブルには、パーティションキー列が 2 つ、クラスタリング列が 2 つ、通常の列が 1 つ、静的列が 1 つあります。 ``` 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) の 2 番目の列のサイズを計算します。 ``` 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 つしかありません。 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 ``` すべての列が整数型であるテーブルの例を考えてみましょう。テーブルには、パーティションキー列が 2 つ、クラスタリング列が 2 つ、通常の列が 1 つ、静的列が 1 つあります。 ``` 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 により、静的データと非静的データに対する書き込みオペレーションが別々に計測されます。さらに、静的データと非静的データの両方を含む書き込みには、データの整合性を確保するために、基盤となる追加のオペレーションが必要です。 静的データと非静的データを混合した書き込みオペレーションを実行すると、2 つの個別の書き込みオペレーション (非静的データ用と静的データ用) が発生します。これは、オンデマンドおよび読み取り/書き込みのプロビジョンドキャパシティモードの両方に適用されます。 次の例では、静的列がある Amazon Keyspaces のテーブルのプロビジョンドスループット性能要件を計算するときに、必要な読み取りキャパシティユニット (RCU) と書き込みキャパシティユニット (WCU) を見積もる方法について説明します。次の式を使用して、静的データと非静的データの両方を含む書き込みを処理するためにテーブルで必要となるキャパシティを見積もることができます。 ``` 2 x WCUs required for nonstatic data + 2 x WCUs required for static data ``` 例えば、アプリケーションにより 1 秒あたり 27 KB のデータが書き込まれ、各書き込みに 25.5 KB の非静的データと 1.5 KB の静的データが含まれている場合、テーブルには 56 WCU (2 x 26 WCU \$1 2 x 2 WCU) が必要です。 Amazon Keyspaces で、複数の行の読み取りと同じ静的データと非静的データの読み取りが計測されます。その結果、同じオペレーション内で静的データと非静的データを読み取る場合の料金は、読み取りを実行するために処理されるデータの総サイズに基づきます。 Amazon CloudWatch でサーバーレスリソースをモニタリングする方法については、「[Amazon CloudWatch による Amazon Keyspaces のモニタリング](monitoring-cloudwatch.md)」を参照してください。 # Amazon Keyspaces でマルチリージョンテーブルのキャパシティを推定およびプロビジョニングする マルチリージョンテーブルのスループットキャパシティは、次の 2 とおりの方法で設定できます。 + オンデマンドキャパシティモード。書き込みリクエストユニット (WRU) で測定します。 + 自動スケーリングが有効なプロビジョンドキャパシティモード。書き込みキャパシティユニット (WCU) で測定します。 自動スケーリングまたはオンデマンドキャパシティモードでプロビジョンドキャパシティモードを使用すると、マルチリージョンテーブルにすべての に対してレプリケートされた書き込みを実行するのに十分なキャパシティを確保できます AWS リージョン。 **注記** いずれかのリージョンでテーブルのキャパシティモードを変更すると、すべてのレプリカのキャパシティモードが変更されます。 デフォルトでは、Amazon Keyspaces はマルチリージョンテーブルでオンデマンドモードを使用します。オンデマンドモードでは、アプリケーションが実行する読み込みおよび書き込みの予想スループットを指定する必要がありません。Amazon Keyspaces は、ワークロードがこれまでに到達実績のあるトラフィックレベルまで増減した場合は、瞬時に対応します。ワークロードのトラフィックレベルが新しいピークに達した場合も、ワークロードに対応できるよう迅速に適応します。 テーブルでプロビジョンドキャパシティモードを選択した場合は、アプリケーションに必要な 1 秒あたりの読み取りキャパシティユニット (RCU) と書き込みキャパシティユニット (WCU) の数を設定する必要があります。 マルチリージョンテーブルのスループットキャパシティのニーズを計画するには、まず各リージョンで必要な 1 秒あたりの WCU の数を見積もります。次に、テーブルのレプリケート先のすべてのリージョンでの書き込みを合計し、その合計を各リージョンのキャパシティとしてプロビジョニングします。これは、1 つのリージョンで実行されるすべての書き込みを各レプリカリージョンでも繰り返す必要があるためです。 すべてのリージョンでの書き込みを処理するにはテーブルのキャパシティが不足している場合、キャパシティの例外が発生します。さらに、リージョン間レプリケーションの待機時間が長くなります。 例えば、米国東部 (バージニア北部) で 1 秒あたり 5 回の書き込み、米国東部 (オハイオ) で 1 秒あたり 10 回の書き込み、欧州 (アイルランド) で 1 秒あたり 5 回の書き込みが予想されるマルチリージョンテーブルがある場合、米国東部 (バージニア北部）、米国東部 (オハイオ）、欧州 (アイルランド) の各リージョンでテーブルの消費量は 20 WCU になると予想されます。つまり、この例では、テーブルの各レプリカに 20 WCU をプロビジョニングする必要があります。Amazon CloudWatch を使用して、テーブルのキャパシティ消費量をモニタリングできます。詳細については、「[Amazon CloudWatch による Amazon Keyspaces のモニタリング](monitoring-cloudwatch.md)」を参照してください。 各書き込みは 1 WCU として請求されるため、この例では合計 60 WCUsが請求されます。料金の詳細については、「[Amazon Keyspaces (for Apache Cassandra) pricing (Amazon Keyspaces (Apache Cassandra 向け) の料金)](https://aws.amazon.com/keyspaces/pricing)」を参照してください。 Amazon Keyspaces 自動スケーリングを有効にしたプロビジョンドキャパシティの詳細については、「[Amazon Keyspaces 自動スケーリングでスループットキャパシティを自動的に管理する](autoscaling.md)」を参照してください。 **注記** テーブルがプロビジョンドキャパシティーモードで自動スケーリングを使用している場合、プロビジョニングされた書き込みキャパシティは、各リージョンの自動スケーリング設定の範囲内で変動させることができます。 # Amazon CloudWatch を使用して Amazon Keyspaces の読み取りと書き込みのキャパシティ消費量を推定する 読み取りと書き込みのキャパシティ消費量を推定し、モニタリングするには、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. `ALLOW FILTERING` オプションなどを使用して CQL ステートメントを実行し、テーブルのフルスキャンで消費される読み取りキャパシティユニットをダッシュボードで確認します。