Amazon Keyspaces でのテーブルの操作 - Amazon Keyspaces (Apache Cassandra 向け)
テーブルの作成マルチリージョンテーブル静的列

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Keyspaces でのテーブルの操作

このセクションでは、Amazon Keyspaces (Apache Cassandra 向け) におけるテーブルの詳しい操作方法について説明します。

Amazon Keyspaces でのテーブルの作成

Amazon Keyspaces では、テーブルの非同期的な作成や削除など、データ定義言語 (DDL) オペレーションを同期なしで実行します。で新しいテーブルの作成ステータスをモニタリングできます。これは AWS Management Console、テーブルが保留中またはアクティブなタイミングを示します。システムスキーマテーブルを使用して、新しいテーブルの作成ステータスをプログラムにより監視することもできます。

テーブルは、使用可能な状態になると、システムスキーマでアクティブとして表示されます。新しいテーブルが使用可能な状態になるタイミングをチェックするための推奨設計パターンとは、Amazon Keyspaces のシステムスキーマテーブル (system_schema_mcs.*) のポーリングです。テーブルの DDL ステートメントのリストについては、「CQL language reference」(CQL 言語リファレンス) の「テーブル」セクションを参照してください。

次のクエリはテーブルのステータスを示しています。

SELECT keyspace_name, table_name, status FROM system_schema_mcs.tables WHERE keyspace_name = 'mykeyspace' AND table_name = 'mytable';

まだ作成中で保留されているテーブルの場合、クエリの出力は次のようになります。


keyspace_name | table_name | status
--------------+------------+--------
   mykeyspace |    mytable | CREATING

テーブルが正常に作成されてアクティブになると、クエリの出力は次のようになります。


keyspace_name | table_name | status
--------------+------------+--------
   mykeyspace |    mytable | ACTIVE

Amazon Keyspaces でのマルチリージョンテーブルの操作

マルチリージョンテーブルには、次の 2 つの方法のいずれかで書き込みスループットキャパシティが設定されている必要があります。

  • 書き込みリクエストユニット (WRUsで測定されるオンデマンドキャパシティモード

  • Auto Scaling によるプロビジョンドキャパシティモード、書き込みキャパシティユニット (WCUsで測定

プロビジョンドキャパシティモードを Auto Scaling またはオンデマンドキャパシティモードで使用すると、マルチリージョンテーブルにすべての へのレプリケートされた書き込みを実行するのに十分なキャパシティを確保できます AWS リージョン。

注記

いずれかのリージョンでテーブルのキャパシティモードを変更すると、すべてのレプリカのキャパシティモードが変更されます。

デフォルトでは、Amazon Keyspaces はマルチリージョンテーブルにオンデマンドモードを使用します。オンデマンドモードでは、アプリケーションが実行すると予想される読み取りおよび書き込みスループットを指定する必要はありません。Amazon Keyspaces は、以前に到達したトラフィックレベルまで拡張または縮小されるため、ワークロードに即座に対応できます。ワークロードのトラフィックレベルが新しいピークに達すると、Amazon Keyspaces はワークロードに対応するために迅速に適応します。

テーブルにプロビジョンドキャパシティモードを選択する場合は、アプリケーションが必要とする 1 秒あたりの読み込みキャパシティユニット (RCUs) と書き込みキャパシティユニット (WCUsの数を設定する必要があります。

マルチリージョンテーブルのスループットキャパシティのニーズを計画するには、まず各リージョンに必要な 1 秒あたりの WCUs数を見積もる必要があります。次に、テーブルがレプリケートされているすべてのリージョンからの書き込みを追加し、その合計を使用して各リージョンの容量をプロビジョニングします。これは、1 つのリージョンで実行されるすべての書き込みを各レプリカリージョンでも繰り返す必要があるため、必須です。

テーブルにすべてのリージョンからの書き込みを処理するのに十分な容量がない場合、容量例外が発生します。さらに、リージョン間のレプリケーションの待機時間が長くなります。

例えば、米国東部 (バージニア北部) で 1 秒あたり 5 回の書き込み、米国東部 (オハイオ) で 10 回の書き込み、欧州 (アイルランド) で 1 秒あたり 5 回の書き込みが予想されるマルチリージョンテーブルがある場合、テーブルは各リージョンで 20 WCUs を消費することを想定する必要があります。米国東部 (バージニア北部）、米国東部 (オハイオ）、欧州 (アイルランド）。つまり、この例では、テーブルのレプリカごとに 20 WCUs をプロビジョニングする必要があります。Amazon を使用して、テーブルの容量消費をモニタリングできます CloudWatch。詳細については、「アマゾンによるアマゾンKeyspaces モニタリング CloudWatch」を参照してください。

各マルチリージョン書き込みは 1.25 倍の WCUsとして請求されるため、この例では合計 75 WCUs請求されます。料金の詳細については、「Amazon Keyspaces (for Apache Cassandra) pricing (Amazon Keyspaces (Apache Cassandra 向け) の料金)」を参照してください。

Amazon Keyspaces Auto Scaling によるプロビジョンドキャパシティの詳細については、「」を参照してくださいAmazon Keyspaces auto スケーリングでスループット容量を自動的に管理します。

注記

テーブルが Auto Scaling でプロビジョニングされたキャパシティモードで実行されている場合、プロビジョニングされた書き込みキャパシティは、各リージョンのそれらの Auto Scaling 設定内でフロートできます。

Amazon Keyspaces の静的列

クラスター化列を含む Amazon Keyspaces テーブルでは、STATIC キーワードを使用して静的列を作成できます。静的列に保存されている値は論理パーティション内のすべての行で共有されます。この列の値を更新すると、Amazon Keyspaces によりパーティション内のすべての行に変更が自動で適用されます。

このセクションでは、静的列に書き込むときのエンコードされたデータサイズを計算する方法について説明します。このプロセスは、行の非静的列にデータを書き込むプロセスとは別に処理されます。静的データのサイズクォータに加えて、静的列の読み取りオペレーションと書き込みオペレーションは、テーブルの計測とスループットキャパシティにも個別に影響します。

Amazon Keyspaces の各論理パーティションの静的列サイズの計算

このセクションでは、Amazon Keyspaces でエンコードされた静的列サイズを推定する方法について説明します。エンコードされたサイズは、請求額とクォータの使用量を計算するときに使用されます。テーブルのプロビジョンドスループット性能要件を計算するときも、エンコードされたサイズを使用する必要があります。Amazon Keyspaces 内のエンコードされた静的列サイズを計算するには、次のガイドラインを使用します。

  • パーティションには、最大 2048 バイトのデータを保存できます。パーティションキーの各キー列には、最大 3 バイトのメタデータが必要です。これらのメタデータバイトは、パーティションあたり 1 MB の静的データサイズクォータにカウントされます。静的データのサイズを計算するときには、各パーティションキー列で上限である 3 バイトのメタデータが使用されていることを想定しておくべきです。

  • データ型に基づいて、静的列データ値の生のサイズを使用します。 のデータ型の詳細については、「データ型」を参照してください。

  • メタデータのために静的データのサイズに 104 バイトを足します。

  • クラスタリング列と通常の非プライマリキー列は、静的データのサイズにはカウントされません。行内の非静的データのサイズを見積もる方法については、「Amazon Keyspaces での行サイズの計算」を参照してください。

エンコードされた静的列の合計サイズは、次の式に基づいています。

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_col1) の最初の列のサイズを計算します。

      4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes

    2. パーティションキー (pk_col2) の 2 番目の列のサイズを計算します。

      4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes

    3. 両方の列を足して、パーティションキー列の合計サイズを見積もります。

      7 bytes + 7 bytes = 14 bytes for the partition key columns

  2. 静的列のサイズを足します。この例では、整数を保存している列 (4 バイトが必要) が 1 つしかありません。

  3. 最後に、静的列データのエンコードされたサイズの合計を算出するには、プライマリキー列と静的列のバイト数を合計し、メタデータのために追加で 104 バイトを足します。

    14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes.

静的データと非静的データを同じステートメントで更新することもできます。書き込みオペレーションの合計サイズを見積もるには、まず非静的データ更新のサイズを計算する必要があります。次に、次の Amazon Keyspaces での行サイズの計算 での例に示すように、行の更新のサイズを計算し、結果を足します。

この場合、合計で 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 バイトです。

  2. Amazon Keyspaces での行サイズの計算 の手順に従い、非静的データの更新に基づいて、行のエンコードされたサイズの合計を足します。この例では、行の更新の合計サイズは 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 + 2 x 2 WCU) が必要です。

Amazon Keyspaces で、複数の行の読み取りと同じ静的データと非静的データの読み取りが計測されます。その結果、同じオペレーション内で静的データと非静的データを読み取る場合の料金は、読み取りを実行するために処理されるデータの総サイズに基づきます。

Amazon でサーバーレスリソースをモニタリングする方法については CloudWatch、「」を参照してくださいアマゾンによるアマゾンKeyspaces モニタリング CloudWatch。