Praktik terbaik untuk penyimpanan data

Gunakan praktik ini untuk mengatur dan mengelola data yang dapat diandalkan, dapat diskalakan, dan dapat diamati sepanjang siklus hidupnya.

Atur data Anda

Buat lebih sedikit penyimpanan data

Penyimpanan data berperilaku mirip dengan tabel dalam basis data. Gunakan seperangkat penyimpanan data yang kecil dan tetap, dan atur catatan di dalamnya berdasarkan kunci. Misalnya, simpan profil setiap pemain dalam satu penyimpanan data PlayerData alih-alih membuat penyimpanan data untuk setiap pemain.

Gunakan satu atau beberapa kunci per pemain

Simpan data persisten untuk setiap pemain di bawah satu kunci setiap kali data tersebut sesuai dengan batas ukuran objek 4 MB. Misalnya, gunakan kunci seperti User_123456 dalam penyimpanan data PlayerData. Pola ini mengurangi permintaan, memungkinkan Anda memperbarui nilai terkait secara atomik, dan membuat rollback lebih mudah dipahami.

Jika bagian yang berbeda dari data pemain memiliki pola akses yang berbeda atau mendekati batas ukuran atau throughput per kunci, pisahkan catatan menjadi sejumlah kecil kunci deterministik. Simpan data yang harus berubah secara atomik dalam kunci yang sama.

Gunakan pola dan awalan kunci statis

Bangun nama kunci dari pengidentifikasi yang stabil dan pola statis, seperti User_{UserId}. Jangan gunakan nama tampilan atau nilai lain yang dapat berubah. Pola statis membuat kunci dapat diprediksi di seluruh server dan alat. Untuk penyimpanan data, mereka juga memungkinkan proses otomatis hak untuk dilupakan mengidentifikasi data pemain.

Gunakan awalan untuk mengelompokkan kunci terkait. Misalnya, pengalaman yang mendukung beberapa profil karakter mungkin menggunakan User_123456/Profile/Warrior dan User_123456/Profile/Mage. Anda kemudian dapat mengirimkan User_123456/Profile ke ListKeysAsync() untuk mencantumkan profil pemain tersebut.

Scopes adalah cara lain untuk membagi penyimpanan data. Sebuah scope menambahkan string ke setiap kunci dalam instance penyimpanan data tersebut, dan defaultnya adalah global.

Evaluasi modul penyimpanan data

Modul penyimpanan data pihak ketiga selalu menjadi pilihan, dan dalam banyak kasus mungkin lebih disukai daripada membangun sistem dari awal. Sebelum mengadopsi satu, tinjau kepemilikan, status pemeliharaan, dan set fitur. Pahami cara mengakses dan memigrasi data Anda tanpa modul tersebut.

Kurangi dan distribusikan permintaan

Buffer data pemain dalam memori

Muat data pemain di awal sesi dan simpan salinan lokal server untuk gameplay. Perbarui salinan lokal alih-alih mengirimkan permintaan penyimpanan data untuk setiap perubahan. Simpan secara berkala, ketika pemain meninggalkan, ketika server dimatikan, dan pada titik kritis seperti pemrosesan pembelian. Pilih interval penyimpanan berkala yang tetap dalam batas permintaan Anda dan lebih pendek dari masa kedaluwarsa kunci sesi; contoh data pemain dan pembelian menggunakan 180 detik.

Jarakkan permintaan berulang

Jangan mulai permintaan berulang dari setiap server pada jadwal yang sama. Sebelum memulai loop frekuensi tetap, tetapkan setiap server atau pemain dengan offset awal acak. Untuk loop polling atau koordinasi yang tidak memerlukan ritme yang tepat, tambahkan jitter acak yang dibatasi ke setiap interval. Pola ini mendistribusikan permintaan seiring waktu dan mengurangi lonjakan lalu lintas yang disinkronkan.

Coba ulang kegagalan sementara

Bungkus permintaan dalam pcall() dan coba ulang kegagalan sementara dengan backoff eksponensial. Tambahkan jitter acak ke setiap penundaan sehingga server tidak mencoba ulang secara bersamaan. Batasi penundaan dan jumlah percobaan, dan jangan coba ulang kesalahan yang disebabkan oleh permintaan yang tidak valid atau operasi yang tidak dapat memberikan hasil yang berguna lagi.

Proses percobaan ulang penyimpanan data dalam urutan untuk setiap kunci. Permintaan yang lebih lama yang mencoba ulang setelah permintaan yang lebih baru berhasil dapat menimpa data yang lebih baru. Juga perhitungkan penulisan dengan hasil yang tidak diketahui: panggilan yang gagal berarti server tidak menerima respons yang berhasil, tetapi backend mungkin telah menyelesaikan penulisan. Untuk informasi lebih lanjut, lihat Kode kesalahan penyimpanan data dan batas dan Percobaan ulang.

Utamakan UpdateAsync daripada SetAsync

Utamakan UpdateAsync() ketika penulisan bergantung pada nilai saat ini atau ketika beberapa server mungkin menulis kunci yang sama. UpdateAsync() membaca nilai terbaru ke dalam callback Anda sebelum menulis, yang mengurangi pembaruan yang hilang. SetAsync() menimpa kunci tanpa membaca terlebih dahulu dan dapat menyebabkan inkonsistensi jika dua server menulis pada saat yang sama.

Gunakan SetAsync() ketika Anda membuat kunci baru atau mengganti nilai yang tidak bergantung pada nilai sebelumnya. Untuk perbandingan antara kedua metode, lihat Set vs update.

Shard kunci panas

Setiap kunci memiliki batas throughput baca dan tulis. Jika satu catatan logis secara konsisten mencapai batas ini setelah Anda mengurangi permintaan yang tidak perlu, shard itu di antara kunci deterministik. Pilih shard yang stabil dari pengidentifikasi, seperti User_{UserId}_Inventory_{ShardId}, sehingga setiap server mengarahkan data yang sama ke shard yang sama.

Sharding membuat pemeliharaan konsistensi dan melakukan migrasi di masa depan menjadi lebih kompleks. Jangan shard data yang muat dalam satu kunci dan tetap di bawah batas throughputnya.

Bangun alur kerja operasi

Gunakan alat yang tersedia bersama-sama:

1. Amati. Gunakan Dasbor Observabilitas Penyimpanan Data untuk melacak permintaan, status respons, throughput, dan penyimpanan. Konfigurasikan pemberitahuan kustom untuk metrik penyimpanan data yang penting sehingga tim Anda dapat merespons kegagalan yang berkelanjutan atau pertumbuhan yang tidak terduga. Pemberitahuan Creator Hub juga memberi tahu Anda ketika penyimpanan mendekati atau melebihi batas dan menyertakan panduan serta tautan ke dasbor.
2. Periksa. Gunakan Manajer Penyimpanan Data untuk memeriksa penyimpanan data, kunci, penggunaan penyimpanan, dan perkiraan biaya. Jika pengalaman memiliki lebih dari 100 penyimpanan data, daftar Penyimpanan Data tidak menunjukkan ukuran dan jumlah kunci. Gunakan Open Cloud atau Pengolah Batch Penyimpanan Data untuk metrik tersebut.
3. Perbaiki. Gunakan Manajer Penyimpanan Data untuk catatan individu. Gunakan API penyimpanan data Open Cloud atau Pengolah Batch Penyimpanan Data untuk alur kerja yang dapat diulang atau berskala besar.
4. Skala dengan sengaja. Pertama, kurangi penyimpanan dan permintaan yang tidak perlu. Jika penggunaan yang sah melebihi kuota default, evaluasi Layanan Diperpanjang.

Open Cloud dan server game berbagi anggaran permintaan tingkat pengalaman. Batasi laju skrip Open Cloud operasional sehingga tidak mengganggu lalu lintas langsung.

Kelola siklus hidup data

Gunakan versi penyimpanan data alih-alih membuat kunci baru untuk setiap revisi. Hanya versi terbaru dari kunci yang dihitung terhadap penggunaan penyimpanan, dan versi memungkinkan Anda memeriksa atau memulihkan nilai sebelumnya.

Gunakan penyimpanan memori untuk data sementara dan yang berubah dengan cepat. Data penyimpanan memori kedaluwarsa secara otomatis dan tidak menambah penyimpanan penyimpanan data persisten.

Hapus data uji ketika pengujian berakhir dan hapus data untuk acara yang kedaluwarsa atau fitur yang dihentikan. Setelah Anda menandai penyimpanan data untuk dihapus, ada buffer 30 hari di mana Anda dapat memulihkannya. Setelah 30 hari tersebut, Roblox akan menghapus penyimpanan data secara permanen. Untuk informasi lebih lanjut, lihat Manajer Penyimpanan Data.

Siapkan pemrosesan hak untuk dilupakan

Konfigurasikan pemrosesan otomatis hak untuk dilupakan (RTBF) untuk data pemain yang mengikuti pola penyimpanan data dan kunci statis. RTBF otomatis adalah alur kerja yang disukai karena Roblox menerapkan template penghapusan Anda saat memproses permintaan yang memenuhi syarat.

Jika RTBF otomatis tidak mendukung skema data Anda, gunakan webhook hak untuk penghapusan untuk menjalankan alur kerja penghapusan kustom. Verifikasi bahwa salah satu alur kerja menghapus semua data pemain yang cocok.