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

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

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

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

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

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

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

定期払いのスキーマ設計

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

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

アクセスパターン 1 (createSubscription) を使用してサブスクリプションを最初に作成し、SKU、NextPaymentDate、NextReminderDate、PaymentDetails などの詳細を設定します。このステップでは、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 メールを送信するために必要な情報を提供します。

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

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

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

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

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

Recurring payments final schema

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

ベーステーブル

GSI-1

GSI-2

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

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