Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Desain skema pembayaran berulang di DynamoDB

Kasus penggunaan bisnis pembayaran berulang

Kasus penggunaan ini membahas penggunaan DynamoDB untuk menerapkan sistem pembayaran berulang. Model data memiliki entitas berikut: akun, langganan, dan tanda terima. Spesifikasi untuk kasus penggunaan kita meliputi hal berikut:

Diagram hubungan entitas pembayaran berulang

Ini adalah diagram relasi entitas (ERD) yang akan kita gunakan untuk desain skema sistem pembayaran berulang.

Pola akses sistem pembayaran berulang

Ini adalah pola akses yang akan kita pertimbangkan untuk desain skema pembayaran berulang.

Desain skema pembayaran berulang

Nama generik PK dan SK digunakan untuk atribut kunci guna memungkinkan penyimpanan berbagai jenis entitas dalam tabel yang sama seperti entitas akun, langganan, dan tanda terima. Pertama, pengguna membuat langganan dan setuju untuk membayar sejumlah biaya pada hari yang sama setiap bulan sebagai harga atas suatu produk. Pengguna dapat memilih salah satu hari dalam sebulan untuk memproses pembayaran. Terdapat juga pengingat yang akan dikirim sebelum pembayaran diproses. Aplikasi bekerja dengan menjalankan dua tugas batch yang berjalan setiap hari: satu tugas batch mengirimkan pengingat yang jatuh tempo hari itu dan tugas batch lainnya memproses semua pembayaran yang jatuh tempo hari itu.

Langkah 1: Tangani pola akses 1 (createSubscription)

Pola akses 1 (createSubscription) awalnya digunakan untuk membuat langganan, dan detail yang mencakup SKU, NextPaymentDate, NextReminderDate, dan PaymentDetails diatur. Langkah ini menunjukkan status tabel hanya untuk satu akun dengan satu langganan. Mungkin ada beberapa langganan dalam koleksi item jadi ini adalah one-to-many hubungan.

Langkah 2: Tangani pola akses 2 (createReceipt) dan 3 (updateSubscription)

Pola akses 2 (createReceipt) digunakan untuk membuat item tanda terima. Setelah pembayaran diproses setiap bulan, pemroses pembayaran akan menulis tanda terima kembali ke tabel dasar. Di sana, bisa ada beberapa tanda terima dalam koleksi item jadi ini adalah one-to-many hubungan. Pemroses pembayaran juga akan memperbarui item langganan (Pola akses 3 (updateSubscription)) untuk memperbarui NextReminderDate atau NextPaymentDate bulan berikutnya.

Langkah 3: Tangani pola akses 4 (getDueRemindersByDate)

Aplikasi memproses pengingat untuk pembayaran dalam batch untuk hari ini. Oleh karena itu, aplikasi perlu mengakses langganan pada dimensi yang berbeda, yaitu tanggal, bukan akun. Ini adalah kasus penggunaan yang baik untuk indeks sekunder global (GSI). Pada langkah ini kita menambahkan indeksGSI-1, yang menggunakan NextReminderDate sebagai kunci GSI partisi. Kita tidak perlu mereplikasi semua item. Ini GSI adalah indeks jarang dan item tanda terima tidak direplikasi. Kita juga tidak perlu memproyeksikan semua atribut—kita hanya perlu menyertakan subset atribut. Gambar di bawah ini menunjukkan skema GSI-1 dan memberikan informasi yang diperlukan aplikasi untuk mengirim email pengingat.

Langkah 4: Tangani pola akses 5 (getDuePaymentsByDate)

Aplikasi memproses pembayaran dalam batch untuk hari ini dengan cara yang sama seperti pengingat. Kami menambahkan GSI-2 dalam langkah ini, dan menggunakan NextPaymentDate sebagai kunci GSI partisi. Kita tidak perlu mereplikasi semua item. Ini GSI adalah indeks yang jarang karena item tanda terima tidak direplikasi. Gambar di bawah ini menunjukkan skema GSI-2.

Langkah 5: Tangani pola akses 6 (getSubscriptionsByAccount) dan 7 (getReceiptsByAccount)

Aplikasi dapat mengambil semua langganan untuk akun dengan menggunakan kueri pada tabel dasar yang menargetkan pengenal akun (thePK) dan menggunakan operator rentang untuk mendapatkan semua item di mana SK dimulai dengan “#”SUB. Aplikasi ini juga dapat menggunakan struktur query yang sama untuk mengambil semua tanda terima dengan menggunakan operator rentang untuk mendapatkan semua item di mana SK dimulai dengan “REC#”. Hal ini memungkinkan kita memenuhi pola akses 6 (getSubscriptionsByAccount) dan 7 (getReceiptsByAccount). Aplikasi menggunakan pola akses tersebut sehingga pengguna dapat melihat langganan saat ini dan tanda terima lama mereka selama enam bulan terakhir. Tidak ada perubahan pada skema tabel dalam langkah ini dan kita dapat melihat di bawah ini bagaimana kita hanya menargetkan item berlangganan dalam pola akses 6 (getSubscriptionsByAccount).

Semua pola akses dan bagaimana desain skema mengatasinya dirangkum dalam tabel di bawah ini:

Skema akhir pembayaran berulang

Berikut adalah desain skema akhir. Untuk mengunduh desain skema ini sebagai JSON file, lihat Contoh DynamoDB di. GitHub

Tabel dasar

GSI-1

GSI-2

Menggunakan No SQL Workbench dengan desain skema ini

Anda dapat mengimpor skema akhir ini ke No SQL Workbench, alat visual yang menyediakan pemodelan data, visualisasi data, dan fitur pengembangan kueri untuk DynamoDB, untuk mengeksplorasi lebih lanjut dan mengedit proyek baru Anda. Ikuti langkah-langkah berikut untuk memulai: