注文用の DynamoDB テーブルを作成する

はじめに

注文サービスには、注文の詳細を保存し、注文 ID で検索する場所が必要です。DynamoDB テーブルを作成して二つの型付きアイテムを保存し、梱包済みの注文を更新して、一時的な注文を削除します。最後に、無関係な参照用テーブルを保持しながら、自分のテーブルだけを削除します。

この実験は、新しい環境で独立して始まります。最初に、ターミナルコマンド、呼び出し元のアイデンティティ、リソース名を扱う AWS Foundations の実験を学んでください。/home/labex/project と準備済みの使い捨ての接続を使います。AWS View は実際のテーブルとアイテムの状態を表示します。AWS Console ではありません。

認定試験との関連

ラボの概要

注文テーブルを作成する

このステップでは、小さな注文サービス用のテーブルを作成します。DynamoDB は、すべての列のスキーマで制限された行ではなく、アイテムを保存します。テーブルは主キーを宣言し、各アイテムは追加の属性を持てます。この単純なテーブルでは、パーティションキーがアイテムを識別します。

公式 AWS CLI と使い捨ての接続は準備済みです。この作業ディレクトリを使い、次に呼び出し元を確認します。個人の認証情報は入力しないでください。

cd /home/labex/project

aws sts get-caller-identity

呼び出し元の ARN の末尾は user/dynamodb-operator です。アカウント識別子と ARN は接続を識別するもので、注文キーではありません。

order_id を String（S）のパーティションキー（HASH）として、labex-d01-orders を作成します。--attribute-definitions は、アイテムのすべてのフィールドではなく、キー属性だけを宣言します。PAY_PER_REQUEST は、プロビジョンドの読み取り・書き込みユニットではなく、オンデマンドキャパシティを選びます。AWS ではリクエストとストレージに料金が発生します。この選択は無料のストレージを意味しません。

aws dynamodb create-table \
  --table-name labex-d01-orders \
  --attribute-definitions AttributeName=order_id,AttributeType=S \
  --key-schema AttributeName=order_id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

テーブルの作成はメタデータを返します。waiter は、テーブルが利用可能になるまでサービスを繰り返し問い合わせます。最初の応答だけでリソースの準備ができたとみなすより安全です。

aws dynamodb wait table-exists --table-name labex-d01-orders

aws dynamodb describe-table \
  --table-name labex-d01-orders \
  --query 'Table.{State:TableStatus,Keys:KeySchema,Billing:BillingModeSummary.BillingMode}'

ACTIVE、order_id パーティションキー、PAY_PER_REQUEST を想定します。LabEx の 上部の AWS View を確認します。注文カードにはまだアイテムがありません。別の参照用テーブルは準備済み環境のものであり、変更せずに残す必要があります。

型付きアイテムを書き込んで読み取る

このステップでは、二つの注文を保存し、正確なキーで一つを取得します。低水準の DynamoDB API は、型付き属性を使います。文字列は S、数値は N です。N の値は JSON 文字列として表されますが、DynamoDB は数値として扱います。ここでの金額は、小さな架空の例のために整数単位を使います。

シングルクォートによって、内部の二重引用符も含め、シェルが JSON をそのまま渡せます。各 put-item は、独自のキーを持つ完全なアイテムを作成します。書き込みが成功しても通常は出力がありません。

aws dynamodb put-item \
  --table-name labex-d01-orders \
  --item '{"order_id":{"S":"O100"},"customer":{"S":"Ada"},"amount":{"N":"145"},"status":{"S":"NEW"}}'

aws dynamodb put-item \
  --table-name labex-d01-orders \
  --item '{"order_id":{"S":"O101"},"customer":{"S":"Ada"},"amount":{"N":"50"},"status":{"S":"NEW"}}'

主キーで O100 を取得します。--consistent-read は、ベーステーブルから強い整合性のある読み取りを要求し、書き込み直後の確認に役立ちます。読み取りのデフォルトは結果整合性です。

aws dynamodb get-item \
  --table-name labex-d01-orders \
  --key '{"order_id":{"S":"O100"}}' \
  --consistent-read

Item には O100、Ada、金額 145、ステータス NEW が含まれます。キー以外の属性はなくても構いませんが、必須キーがない状態は許可されません。AWS View で注文カード内の O100 を展開し、同じサービスが返す実際の型付きアイテムを確認します。

注文を更新し、一時的なアイテムを削除する

このステップでは、他のフィールドを置き換えずに O100 を変更し、一時的な注文 O101 を削除します。update-item は、キーで指定した一つのアイテムに式を適用します。SET は属性を設定します。式の名前の別名は、予約語との衝突を避けます。#state は status を表します。式の値には DynamoDB の型が付きます。

注文サービスでは、顧客の情報を維持したまま梱包情報を変更する必要があります。同じキーに対する PutItem は項目全体を置き換えますが、UpdateItem は指定した属性だけを変更します。返された customer フィールドから、ほかの注文データが維持されたことを確認できます。

--return-values ALL_NEW は、結果をすぐに確認できるよう、更新後の完全なアイテムを返します。

aws dynamodb update-item \
  --table-name labex-d01-orders \
  --key '{"order_id":{"S":"O100"}}' \
  --update-expression 'SET amount = :amount, #state = :state' \
  --expression-attribute-names '{"#state":"status"}' \
  --expression-attribute-values '{":amount":{"N":"160"},":state":{"S":"PACKED"}}' \
  --return-values ALL_NEW

返された属性では、customer の Ada が保持され、amount は 160、status は PACKED になります。

正確なキーで O101 だけを削除し、もう一度読み取ります。

aws dynamodb delete-item \
  --table-name labex-d01-orders \
  --key '{"order_id":{"S":"O101"}}' \
  --return-values ALL_OLD

aws dynamodb get-item \
  --table-name labex-d01-orders \
  --key '{"order_id":{"S":"O101"}}' \
  --consistent-read

ALL_OLD は削除したアイテムを表示します。その後の読み取りは、そのキーにアイテムが残っていないため {} を返します。これは結果がない正常な読み取りです。AWS View では O101 がなくなり、O100 には更新されたフィールドが残ります。O100 を展開し、金額とステータスを比較してください。

演習用テーブルだけを削除する

このステップでは、最終的なデータを確認した後、注文テーブルを削除します。テーブルの削除は、そのすべてのアイテムとインデックスを削除します。削除前に正確な名前を確認してください。サービスが返すすべてのテーブルをループで削除してはいけません。

aws dynamodb scan --table-name labex-d01-orders --consistent-read

最後の scan は、金額 160、ステータス PACKED の O100 だけを返します。scan は、キーで指定した一つのアイテムではなく、テーブルを調べます。より大きなアクセスパターンでは、次の実験で Query を使います。

aws dynamodb delete-table --table-name labex-d01-orders

aws dynamodb wait table-not-exists --table-name labex-d01-orders

aws dynamodb list-tables

aws dynamodb get-item \
  --table-name labex-d01-reference \
  --key '{"id":{"S":"platform"}}' \
  --consistent-read

一覧には labex-d01-reference があり、注文テーブルはありません。参照用の note は keep unchanged のままです。正常な一覧と参照用リソースの読み取りは、接続が引き続き動作することを証明します。認証やネットワークの失敗では削除を証明できません。AWS View は保持された参照用リソースだけと Orders table absent を表示します。使い捨ての接続はこの VM とともに終了します。認証情報を他の場所にコピーしないでください。

まとめ

String パーティションキーを持つオンデマンドテーブルを作成し、型付きアイテムを書き込み、強い整合性のあるキーによる読み取りを行いました。選択した属性を更新し、アイテムを削除しました。その後、演習用テーブルだけを削除し、無関係な参照用リソースが引き続き読み取れることを証明しました。これらの操作は、次の実験の複合キーによるクエリや別のアクセスパターンの基礎になります。

詳しくは、AWS 公式ドキュメントを参照してください：テーブル、項目、属性、プライマリキー。