Amazon DynamoDBとNoSQLのシナリオ判断

DynamoDBを使う買物かご、顧客別注文、セッションの事例から、キーと読取り方を判断します。マネージドな拡張性を活かすには、どの情報をどの条件で取得するかを先に整理することが必要です。

この単元で学ぶこと

項目の識別とアクセスパターンを判断する
容量と読取り整合性の条件を選ぶ
期限・複数更新・保護の要件を整理する

本文解説

1. 顧客別の注文一覧顧客IDをパーティションキー、注文IDをソートキーとするテーブルなら、同じ顧客に異なる注文IDの項目を持てます。C01/O01とC01/O02は別の項目ですが、C01/O01を同じ主キーの別項目として二つ作る設計ではありません。どの操作が新規登録でどれが更新かをアプリで区別します。

2. 一人分を読む顧客IDが分かっている注文一覧では、キー条件を使うQueryを検討します。全顧客をScanしてから一人だけを絞る方法は不要な読取りを増やす場合があります。別の属性で頻繁に探す必要が出たら、インデックスやデータ配置を見直し、検索のたびに全走査することを当然としないようにします。

3. 属性が異なる項目一部の利用者だけ配送希望時間を持つような柔軟なデータでも、主キーは定義します。必須の業務属性や許可する値はアプリ側で検証します。スキーマの柔軟性を「どんな誤った型や欠損でも業務に支障がない」という意味に置き換えないようにします。

4. 需要の変化イベント期間だけアクセスが増える場合、On-demandやProvisionedとAuto Scaling等を比較します。総要求が増える場合だけでなく、一つの人気商品キーへ集中する場合を調べます。容量方式の選択でキーの偏り、クォータ、リトライ設計を全て省けるわけではありません。

5. 直前の更新を読む設定変更直後に確認画面へ最新の値が必要なら、対応するテーブルの強い整合性の読取り等を検討します。GSIで同じ指定ができるとは考えません。また読取りが終わった後に別の利用者が更新することはあり、強い読取りだけで未来の競合が止まるわけではありません。

6. 複数地域で利用する別リージョンでも同じアプリを使う場合にグローバルテーブルを検討します。MRECとMRSCの整合性、対応するリージョンや機能を確認します。グローバルという名称だけで全機能の無条件利用や、誤操作前の全履歴保持を保証するものではありません。

7. 有効期限と削除セッションが18時で期限切れでも、TTL処理が物理的に削除するまでは項目が残ることがあります。認証を認めるかは期限の値と現在時刻から判定します。TTLを使って不要データを減らすことと、期限後の利用を即座に止めることを分けて実装します。

8. 更新をまとめる対応する範囲で在庫の変更と注文記録を一体に扱うなら、条件式やトランザクションAPI等を検討します。通常のバッチへまとめることだけで全成功・全不成立になるとは限りません。復元用バックアップ、IAM権限、失敗時の再試行や重複防止まで含めて業務を確認します。

図解

保存・検索・有効性の設計を分ける — データが存在することだけで、現在の業務に利用してよいとは限りません。

重要ポイント

複合主キーは二値の組で一意。
GSIへ強い整合性の読取りを要求できない。
TTLとアプリの有効期限判定を分ける。

間違えやすい点

On-demandがキーの偏りを無条件に解消すると考える。
バッチとトランザクションを同一視する。

用語解説

アクセスパターン: どのキーや条件で、どのデータをどの頻度で読む・書くか。
ホットキー: 要求が特定のキーへ集中する状況の対象となるキー。
条件付き更新: 指定した条件を満たす場合だけ変更する操作。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。