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

Desain skema profil game di DynamoDB

Kasus penggunaan bisnis profil game

Kasus penggunaan ini berbicara tentang penggunaan DynamoDB untuk menyimpan profil pemain untuk sistem game. Pengguna (dalam hal ini, pemain) perlu membuat profil sebelum mereka dapat berinteraksi dengan banyak game modern, terutama yang online. Profil game biasanya mencakup hal berikut:

Untuk memenuhi persyaratan akses kueri data ketat untuk aplikasi ini, kunci primer (kunci partisi dan kunci urutan) akan menggunakan nama generik (PK dan SK) agar dapat dibebani dengan berbagai jenis nilai seperti yang akan kita lihat di bawah ini.

Pola akses untuk desain skema ini adalah:

Ukuran profil game akan bervariasi di game yang berbeda. Mengompresi nilai atribut yang besar dapat membuatnya sesuai dengan batas item di DynamoDB dan mengurangi biaya. Strategi manajemen throughput akan bergantung pada berbagai faktor, seperti: jumlah pemain, jumlah game yang dimainkan per detik, dan beban kerja musiman. Biasanya untuk game yang baru diluncurkan, jumlah pemain dan tingkat popularitasnya tidak diketahui, jadi kita akan mulai dengan mode throughput sesuai permintaan.

Diagram hubungan entitas profil game

Ini adalah diagram hubungan entitas (ERD) yang akan kita gunakan untuk desain skema profil game.

Pola akses profil game

Ini adalah pola akses yang akan kita pertimbangkan untuk desain skema jaringan sosial.

Evolusi desain skema profil game

Dari penjelasan di atasERD, kita dapat melihat bahwa ini adalah tipe one-to-many hubungan pemodelan data. Dalam DynamoDB one-to-many, model data dapat diatur ke dalam koleksi item, yang berbeda dari database relasional tradisional di mana beberapa tabel dibuat dan ditautkan melalui kunci asing. Koleksi item adalah sekelompok item yang berbagi nilai kunci partisi yang sama, tetapi memiliki nilai kunci urutan yang berbeda. Dalam koleksi item, setiap item memiliki nilai kunci urutan unik yang membedakannya dari item lainnya. Dengan pertimbangan ini, mari kita gunakan pola berikut untuk nilai HASH dan RANGE untuk setiap jenis entitas.

Untuk memulai, kita menggunakan nama generik seperti PK dan SK untuk menyimpan berbagai jenis entitas dalam tabel yang sama agar model bisa tetap digunakan hingga ke depannya. Untuk keterbacaan yang lebih baik, kita dapat menyertakan prefiks untuk menunjukkan jenis data atau menyertakan atribut arbitrer yang disebut Entity_type atau Type. Dalam contoh saat ini, kita menggunakan string yang dimulai dengan player untuk menyimpan player_ID sebagai PK; gunakan entity name# sebagai prefiks SK, dan tambahkan atribut Type untuk menunjukkan jenis entitas bagian data ini. Hal ini memungkinkan kami untuk mendukung penyimpanan lebih banyak jenis entitas di masa depan, dan menggunakan teknologi canggih seperti GSI Overloading dan Sparse GSI untuk memenuhi lebih banyak pola akses.

Mari kita mulai menerapkan pola akses. Pola akses seperti menambahkan pemain dan menambahkan peralatan dapat diwujudkan melalui operasi PutItem, jadi kita dapat mengabaikannya. Dalam dokumen ini, kita akan fokus pada pola akses tipikal yang tercantum di atas.

Langkah 1: Atasi pola akses 1 (getPlayerFriends)

Kita mengatasi pola akses 1 (getPlayerFriends) dengan langkah ini. Dalam desain kita saat ini, pertemanan bersifat sederhana dan jumlah teman dalam game ini kecil. Agar simpel, kita menggunakan jenis data daftar untuk menyimpan daftar teman (pemodelan 1:1). Dalam desain ini, kita menggunakan GetItem untuk memenuhi pola akses ini. Dalam operasi GetItem, kita secara eksplisit memberikan kunci partisi dan nilai kunci urutan untuk mendapatkan item tertentu.

Namun, jika sebuah game memiliki banyak teman, dan hubungan di antara mereka rumit (seperti pertemanan menjadi dua arah dengan komponen undangan dan penerimaan), perlu menggunakan many-to-many hubungan untuk menyimpan setiap teman secara individual, untuk skala ke ukuran daftar teman yang tidak terbatas. Dan jika perubahan pertemanan melibatkan operasi pada beberapa item pada saat yang sama, transaksi DynamoDB dapat digunakan untuk mengelompokkan beberapa tindakan bersama-sama dan mengirimkannya sebagai satu atau all-or-nothing TransactWriteItemsoperasi. TransactGetItems

Langkah 2: Tangani pola akses 2 (getPlayerAllProfile), 3 (getPlayerAllItems), dan 4 (getPlayerSpecificItem)

Kita menangani pola akses 2 (getPlayerAllProfile), 3 (getPlayerAllItems), dan 4 (getPlayerSpecificItem) menggunakan langkah ini. Kesamaan ketiga pola akses ini adalah kueri rentang, yang menggunakan operasi Query. Bergantung pada ruang lingkup kueri, Kondisi Kunci dan Ekspresi Filter digunakan, yang umum digunakan dalam pengembangan praktis.

Dalam operasi Kueri, kita memberikan nilai tunggal untuk Kunci Partisi dan mendapatkan semua item dengan nilai Kunci Partisi tersebut. Pola akses 2 (getPlayerAllProfile) diimplementasikan dengan cara ini. Secara opsional, kita dapat menambahkan ekspresi kondisi kunci urutan — sebuah string yang menentukan item yang akan dibaca dari tabel. Pola akses 3 (getPlayerAllItems) diimplementasikan dengan menambahkan kondisi kunci dari kunci urutan begins_with ITEMS#. Selanjutnya, untuk menyederhanakan pengembangan sisi aplikasi, kita dapat menggunakan ekspresi filter untuk mengimplementasikan pola akses 4 (getPlayerSpecificItem).

Berikut adalah contoh kode pseudo menggunakan ekspresi filter yang memfilter item dari kategori Weapon:

filterExpression: "ItemType = :itemType" 
expressionAttributeValues: {":itemType": "Weapon"}

Jika pola aksesnya adalah melakukan kueri pada set data besar dan menyaring sejumlah besar data untuk menyimpan sebagian kecil data saja, pendekatan yang tepat adalah merancang Kunci Partisi dan Kunci Urutan DynamoDB secara lebih efektif. Misalnya, dalam contoh di atas untuk mendapatkan ItemType tertentu, jika ada banyak item untuk setiap pemain dan melakukan kueri untuk ItemType tertentu adalah pola akses yang tipikal, membawa ItemType ke SK sebagai kunci komposit merupakan hal yang lebih efisien. Model data akan terlihat seperti ini: ITEMS#ItemType#ItemId.

Langkah 3: Atasi pola akses 5 (updateCharacterAttributes) dan 6 (updateItemCount)

Kita menangani pola akses 5 (updateCharacterAttributes), dan 6 (updateItemCount) menggunakan langkah ini. Ketika pemain perlu memodifikasi karakter, seperti mengurangi mata uang, atau memodifikasi jumlah senjata tertentu dalam item mereka, gunakan UpdateItem untuk menerapkan pola akses ini. Untuk memperbarui mata uang pemain tetapi juga memastikannya tidak pernah berada di bawah jumlah minimum, kita dapat menambahkan Contoh ekspresi kondisi DynamoDB CLI untuk mengurangi saldo hanya jika saldo lebih besar dari atau sama dengan jumlah minimum. Berikut adalah contoh kode pseudo:

UpdateExpression: "SET currency = currency - :amount"
ConditionExpression: "currency >= :minAmount"

Saat melakukan pengembangan dengan DynamoDB dan menggunakan Penghitung Atom untuk mengurangi inventaris, kita dapat memastikan idempotensi menggunakan penguncian optimis. Berikut adalah contoh kode pseudo untuk Penghitung Atom:

UpdateExpression: "SET ItemCount = ItemCount - :incr" 
expression-attribute-values: '{":incr":{"N":"1"}}'

Selain itu, dalam skenario di mana pemain membeli item dengan mata uang, seluruh proses perlu mengurangi mata uang dan menambahkan item pada saat yang sama. Kita dapat menggunakan Transaksi DynamoDB untuk mengelompokkan beberapa tindakan bersama-sama dan mengirimkannya sebagai satu atau all-or-nothing TransactWriteItems operasi. TransactGetItems TransactWriteItemsadalah operasi penulisan sinkron dan idempoten yang mengelompokkan hingga 100 tindakan penulisan dalam satu operasi. all-or-nothing Tindakan tersebut diselesaikan secara atomik, sehingga semuanya berhasil atau tidak satu pun yang berhasil. Transaksi membantu menghilangkan risiko duplikasi atau hilangnya mata uang. Untuk informasi selengkapnya tentang transaksi, lihat Contoh DynamoDB transactions.

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

Skema akhir profil game

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

Tabel dasar:

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: