Progettazione dello schema dei pagamenti ricorrenti in DynamoDB

Caso d'uso aziendale dei pagamenti ricorrenti

Questo caso d'uso parla dell'utilizzo di DynamoDB per implementare un sistema di pagamenti ricorrenti. Il modello di dati ha le seguenti entità: account, sottoscrizioni e ricevute. Le specifiche del nostro caso d'uso includono quanto segue:

• Ciascun account può avere più sottoscrizioni

• La sottoscrizione ha un NextPaymentDate quando deve essere effettuato il prossimo pagamento e un NextReminderDate quando viene inviato un promemoria via e-mail al cliente

• C'è un articolo per sottoscrizione che viene archiviato e aggiornato al momento dell'elaborazione del pagamento (la dimensione media degli articoli è di circa 1 KB e la velocità effettiva dipende dal numero di account e sottoscrizioni)

• Il processore di pagamento creerà anche una ricevuta come parte del processo, che viene memorizzata nella tabella e che scadrà dopo un certo periodo di tempo utilizzando un attributo TTL

Diagramma delle relazioni tra le entità dei pagamenti ricorrenti

Questo è il diagramma delle relazioni tra entità (ERD) che utilizzeremo per la progettazione dello schema del sistema di pagamenti ricorrenti.

Schemi di accesso ai sistemi di pagamento ricorrenti

Questi sono i modelli di accesso che creeremo per la progettazione dello schema del sistema di pagamenti ricorrenti.

1. createSubscription

2. createReceipt

3. updateSubscription

4. getDueRemindersByDate

5. getDuePaymentsByDate

6. getSubscriptionsByAccount

7. getReceiptsByAccount

Progettazione dello schema dei pagamenti ricorrenti

I nomi generici PK e SK vengono utilizzati per gli attributi chiave per consentire la memorizzazione di diversi tipi di entità nella stessa tabella, ad esempio le entità account, sottoscrizione e ricevuta. L'utente crea innanzitutto un abbonamento, in cui accetta di pagare un importo lo stesso giorno di ogni mese in cambio di un prodotto. Possono scegliere in quale giorno del mese elaborare il pagamento. C'è anche un promemoria che verrà inviato prima dell'elaborazione del pagamento. L'applicazione funziona con due processi batch eseguiti ogni giorno: un processo batch invia i promemoria con scadenza quel giorno e l'altro processo batch elabora i pagamenti in scadenza quel giorno.

Fase 1: Gestire il modello di accesso 1 (createSubscription)

Il modello di accesso 1 (createSubscription) viene utilizzato per creare inizialmente l'abbonamento e vengono impostati i dettagli, tra cui SKU, NextPaymentDate, NextReminderDate e PaymentDetails. Questo passaggio mostra lo stato della tabella per un solo account con un abbonamento. Nella raccolta di articoli possono esserci più abbonamenti, quindi questa è una relazione. one-to-many

Fase 2: Gestire i modelli di accesso 2 (createReceipt) e 3 (updateSubscription) 

Il modello di accesso 2 (createReceipt) viene utilizzato per creare l'articolo della ricevuta. Dopo l'elaborazione del pagamento ogni mese, il processore di pagamento riscriverà una ricevuta nella tabella di base. Potrebbero esserci più ricevute nella collezione di articoli, quindi questa è una one-to-many relazione. Il processore di pagamento aggiornerà anche l'elemento di abbonamento (Modello di accesso 3 (updateSubscription)) da aggiornare per NextReminderDateo il NextPaymentDate per il prossimo mese.

Fase 3: Gestire il modello di accesso 4 (getDueRemindersByDate)

L'applicazione elabora i promemoria per il pagamento in batch per il giorno corrente. Pertanto l'applicazione deve accedere agli abbonamenti su una dimensione diversa: data anziché account. Questo è un buon caso d'uso per un indice secondario globale (GSI). In questo passaggio aggiungiamo l'indiceGSI-1, che utilizza NextReminderDate come chiave di GSI partizione. Non è necessario replicare tutti gli articoli. Questo GSI è un indice sparso e gli elementi delle ricevute non vengono replicati. Inoltre, non è necessario proiettare tutti gli attributi: è sufficiente includere un sottoinsieme degli attributi. L'immagine sotto mostra lo schema di GSI-1 e fornisce le informazioni necessarie all'applicazione per inviare l'e-mail di promemoria.

Fase 4: Gestire il modello di accesso 5 (getDuePaymentsByDate)

L'applicazione elabora i pagamenti in batch per il giorno corrente nello stesso modo in cui elabora  promemoria. Aggiungiamo GSI-2 questo passaggio e viene utilizzato NextPaymentDate come chiave di GSI partizione. Non è necessario replicare tutti gli articoli. Si GSI tratta di un indice scarso in quanto gli elementi delle ricevute non vengono replicati. L'immagine sotto mostra lo schema di GSI-2.

Fase 5: Gestire i modelli di accesso 6 (getSubscriptionsByAccount) e 7 (getReceiptsByAccount) 

L'applicazione può recuperare tutte le sottoscrizioni per un account utilizzando una query sulla tabella di base che ha come obiettivo l'identificatore dell'account (thePK) e utilizza l'operatore di intervallo per ottenere tutti gli elementi il cui SK inizia con «#». SUB L'applicazione può anche utilizzare la stessa struttura di query per recuperare tutte le ricevute utilizzando un operatore di intervallo per ottenere tutti gli elementi in cui SK inizia con «#». REC Questo ci consente di soddisfare i modelli di accesso 6 (getSubscriptionsByAccount) e 7 (getReceiptsByAccount). L'applicazione utilizza questi modelli di accesso in modo che l'utente possa vedere i propri abbonamenti attuali e le ricevute passate degli ultimi sei mesi. Non vi è alcuna modifica allo schema della tabella in questo passaggio e possiamo vedere di seguito come indirizziamo solo gli elementi dell'abbonamento nel modello di accesso 6 (getSubscriptionsByAccount).

Tutti i modelli di accesso e il modo in cui la progettazione dello schema li affronta sono riassunti nella tabella seguente:

Modello di accesso	Tabella GSI base//LSI	Operazione	Valore della chiave di partizione	Valore della chiave di ordinamento
createSubscription	Tabella di base	PutItem	ACC#account_id	SUB#<SUBID>#SKU<SKUID>
createReceipt	Tabella di base	PutItem	ACC#account_id	REC#<RecieptDate>#SKU<SKUID>
updateSubscription	Tabella di base	UpdateItem	ACC#account_id	SUB#<SUBID>#SKU<SKUID>
getDueRemindersByDate	GSI-1	Query	<NextReminderDate>
getDuePaymentsByDate	GSI-2	Query	<NextPaymentDate>
getSubscriptionsByConto	Tabella di base	Query	ACC#account_id	SK inizia_con «#» SUB
getReceiptsByConto	Tabella di base	Query	ACC#account_id	SK inizia_con «#» REC

Schema finale dei pagamenti ricorrenti

Di seguito sono riportate le progettazioni dello schema finale. Per scaricare questo schema come JSON file, consulta Esempi di DynamoDB su. GitHub

Tabella di base

GSI-1

GSI-2

Utilizzo di No SQL Workbench con questo schema di progettazione

Puoi importare questo schema finale in No SQL Workbench, uno strumento visivo che fornisce funzionalità di modellazione, visualizzazione dei dati e sviluppo di query per DynamoDB, per esplorare e modificare ulteriormente il tuo nuovo progetto. Per iniziare, segui queste fasi:

1. Scarica No Workbench. SQL Per ulteriori informazioni, consulta Scarica No SQL Workbench per DynamoDB.

2. Scarica il file di JSON schema sopra elencato, che è già nel formato del modello No SQL Workbench.

3. Importa il file JSON dello schema in No SQL Workbench. Per ulteriori informazioni, consulta Importazione di un modello di dati esistente.

4. Dopo averlo importato in NOSQL Workbench, puoi modificare il modello di dati. Per ulteriori informazioni, consulta Modifica di un modello di dati esistente.

5. Per visualizzare il modello di dati, aggiungere dati di esempio o importare dati di esempio da un CSV file, utilizza la funzionalità Data Visualizer di No Workbench. SQL