Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

DynamoDB での定期払いスキーマの設計

フォーカスモード
DynamoDB での定期払いスキーマの設計 - Amazon DynamoDB

定期払いのビジネスユースケース

このユースケースでは、DynamoDB を使用して定期払いシステムを実装する方法について説明します。データモデルには、アカウント、サブスクリプション、領収書のエンティティがあります。このユースケースの詳細は次のとおりです。

  • アカウントごとに複数のサブスクリプションを持つことができます。

  • サブスクリプションは、次の支払いを処理する必要があるときは NextPaymentDate、E メールによるリマインダーをお客様に送信するときは NextReminderDate です。

  • サブスクリプションには、支払いが処理されると、保存および更新される項目があります (平均の項目サイズは約 1 KB で、スループットはアカウントとサブスクリプションの数によって異なります)。

  • 支払いプロセッサは、処理の一環として領収書も作成します。領収書は、テーブルに保存され、TTL 属性を使用して一定期間後に期限切れになるように設定されます。

定期払いエンティティ関係図

これは、定期払いシステムのスキーマ設計に使用するエンティティ関係図 (ERD) です。

エンティティとしてアカウント、サブスクリプション、領収書を示す定期払いシステムの ERD。

定期払いシステムのアクセスパターン

これらは、定期払いシステムのスキーマ設計で検討するアクセスパターンです。

  1. createSubscription

  2. createReceipt

  3. updateSubscription

  4. getDueRemindersByDate

  5. getDuePaymentsByDate

  6. getSubscriptionsByAccount

  7. getReceiptsByAccount

定期払いのスキーマ設計

一般的な名前である PK や SK は、アカウント、サブスクリプション、領収書などの異なる種類のエンティティを同じテーブルに保存するためのキー属性に使用します。ユーザーは最初にサブスクリプションを作成します。サブスクリプションにより、ユーザーは製品の代金として毎月同じ日に金額を支払うことに同意します。月内のどの日に支払いを処理するかは、ユーザーが選択できます。支払いを処理する前にリマインダーも送信されます。このアプリケーションは、毎日 2 つのバッチジョブを実行することで機能します。1 つのバッチジョブでは、当日を期限とするリマインダーを送信し、もう 1 つのバッチジョブでは、当日を支払期日とするすべての支払いを処理します。

ステップ 1: アクセスパターン 1 (createSubscription) に対処する

アクセスパターン 1 (createSubscription) を使用してサブスクリプションを最初に作成し、SKUNextPaymentDateNextReminderDatePaymentDetails などの詳細を設定します。このステップでは、1 つのサブスクリプションで 1 つのアカウントに限り、テーブルの状態を表示します。項目コレクションには複数のサブスクリプションを含めることができるため、これは 1 対多リレーションシップになります。

アカウントのサブスクリプションの詳細を示すテーブル設計。

ステップ 2: アクセスパターン 2 (createReceipt) と 3 (updateSubscription) に対処する

アクセスパターン 2 (createReceipt) を使用して領収書項目を作成します。毎月支払いを処理すると、支払いプロセッサは領収書をベーステーブルに書き戻します。項目コレクションには複数の領収書を含めることができるため、これは 1 対多リレーションシップです。支払いプロセッサは、サブスクリプション項目 (アクセスパターン 3 (updateSubscription)) も更新し、翌月の NextReminderDate または NextPaymentDate に変更します。

次のサブスクリプションのリマインダー日付を示す領収書の詳細とサブスクリプション項目の更新。

ステップ 3: アクセスパターン 4 (getDueRemindersByDate) に対処する

アプリケーションは、当日の支払いのリマインダーをバッチで処理します。そのため、アプリケーションは別のディメンション (アカウントではなく日付) でサブスクリプションにアクセスする必要があります。これは、グローバルセカンダリインデックス (GSI) に適したユースケースです このステップでは、インデックス GSI-1 を追加し、NextReminderDate を GSI パーティションキーとして使用します。すべての項目をレプリケートする必要はありません。この GSI はスパースインデックスであり、領収書項目はレプリケートされません。また、すべての属性を射影する必要はなく、属性の一部を含めるだけで済みます。次の図に示す GSI-1 のスキーマは、アプリケーションがリマインダー E メールを送信するために必要な情報を提供します。

アプリケーションからリマインダー E メールを送信する先の E メールアドレスなどの詳細を示す GSI-1 スキーマ。

ステップ 4: アクセスパターン 5 (getDuePaymentsByDate) に対処する

アプリケーションは、リマインダーの場合と同じように、当日の支払いをバッチで処理します。このステップでは GSI-2 を追加し、NextPaymentDate を GSI パーティションキーとして使用します。すべての項目をレプリケートする必要はありません。GSI はスパースインデックスであり、領収書項目はレプリケートされません。次の図は GSI-2 のスキーマを示しています。

支払いを処理するための詳細を示す GSI-2 スキーマ。NextPaymentDate は GSI-2 のパーティションキーです。

ステップ 5: アクセスパターン 6 (getSubscriptionsByAccount) と 7 (getReceiptsByAccount) に対処する

アプリケーションは、ベーステーブルでアカウント識別子 (PK) をターゲットとするクエリを使用して、アカウントのすべてのサブスクリプションを取得できます。また、範囲演算子を使用して SK が「SUB#」で始まるすべての項目を取得できます。また、アプリケーションは、同じクエリ構造を使用してすべての領収書を取得し、範囲演算子を使用して SK が「REC#」で始まるすべての項目を取得できます。これにより、アクセスパターン 6 (getSubscriptionsByAccount) と 7 (getReceiptsByAccount) に対処できます。これらのアクセスパターンをアプリケーションで使用することで、ユーザーは現在のサブスクリプションと過去 6 か月間の領収書を確認できます。このステップでは、テーブルスキーマに変更はありません。アクセスパターン 6 (getSubscriptionsByAccount) でサブスクリプション項目だけをターゲットにする方法は次の表で確認できます。

ベーステーブルに対するクエリオペレーションの結果。特定のアカウントのサブスクリプションを示します。

すべてのアクセスパターンと各アクセスパターンにスキーマ設計で対処する方法を次の表にまとめています。

アクセスパターン ベーステーブル/GSI/LSI 操作 パーティションキー値 ソートキー値
CreateSubscription ベーステーブル PutItem ACC#account_id SUB#<SUBID>#SKU<SKUID>
createReceipt ベーステーブル PutItem ACC#account_id REC#<RecieptDate>#SKU<SKUID>
updateSubscription ベーステーブル UpdateItem ACC#account_id SUB#<SUBID>#SKU<SKUID>
getDueRemindersByDate GSI-1 Query <NextReminderDate>
getDuePaymentsByDate GSI-2 Query <NextPaymentDate>
getSubscriptionsByAccount ベーステーブル Query ACC#account_id SK begins_with “SUB#”
getReceiptsByAccount ベーステーブル Query ACC#account_id SK begins_with “REC#”

Recurring payments final schema

最終的なスキーマ設計は次のとおりです。このスキーマ設計を JSON ファイルとしてダウンロードするには、GitHub の DynamoDB の例を参照してください。

ベーステーブル

アカウント情報と、そのサブスクリプションや領収書の詳細を示すベーステーブル設計。

GSI-1

E メールアドレスや NextPaymentDate などのサブスクリプションの詳細を示す GSI-1 スキーマ。

GSI-2

PaymentAmount や PaymentDay などの支払いの詳細を示す GSI-2 スキーマ。

このスキーマ設計での NoSQL Workbench の使用

この最終スキーマを、DynamoDB のデータモデリング、データ視覚化、クエリ開発機能を提供するビジュアルツールである NoSQL Workbench にインポートして、新しいプロジェクトを詳しく調べたり編集したりできます。使用を開始するには、次の手順に従います。

  1. NoSQL Workbench をダウンロードします。詳細については、「DynamoDB 用の NoSQL Workbench のダウンロード」を参照してください。

  2. 上記の JSON スキーマファイルをダウンロードします。このファイルは既に NoSQL Workbench モデル形式になっています。

  3. JSON スキーマファイルを NoSQL Workbench にインポートします。詳細については、「既存のデータモデルのインポート」を参照してください。

  4. NOSQL Workbench にインポートしたら、データモデルを編集できます。詳細については、「既存のデータモデルの編集」を参照してください。

  5. データモデルの視覚化、サンプルデータの追加、CSV ファイルからのサンプルデータのインポートを行うには、NoSQL Workbench のデータビジュアライザー機能を使用します。

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.