Praktik terbaik untuk menggunakan Spanner sebagai database game

Dokumen ini menjelaskan praktik terbaik untuk menggunakan Spanner sebagai database backend utama untuk penyimpanan status game. Anda dapat menggunakan Spanner sebagai pengganti database umum untuk menyimpan data autentikasi pemain dan data inventaris. Dokumen ini ditujukan untuk engineer backend game yang menangani penyimpanan status jangka panjang, serta operator dan admin infrastruktur game yang mendukung sistem tersebut dan tertarik untuk menghosting database backend mereka di Google Cloud.

Game multiplayer dan online telah berkembang sehingga memerlukan struktur database yang semakin kompleks untuk melacak data hak, status, dan inventaris pemain. Basis pemain yang terus bertambah dan kompleksitas game yang meningkat telah menyebabkan solusi database yang sulit diskalakan dan dikelola, yang sering kali memerlukan penggunaan sharding atau clustering. Melacak item dalam game yang berharga atau progres pemain yang penting biasanya memerlukan transaksi dan sulit diatasi di banyak jenis database terdistribusi.

Spanner adalah layanan database pertama yang skalabel, setingkat perusahaan, didistribusikan secara global, dan sangat konsisten yang dibuat untuk cloud guna menggabungkan manfaat struktur database relasional dengan skala horizontal non-relasional. Banyak perusahaan game menganggap Spanner sangat cocok untuk mengganti database status game dan autentikasi dalam sistem skala produksi. Anda dapat menskalakan penyimpanan atau performa tambahan menggunakan Konsol Google Cloud untuk menambahkan node. Spanner dapat menangani replikasi global secara transparan dengan konsistensi tinggi, sehingga Anda tidak perlu mengelola replika regional.

Dokumen praktik terbaik ini membahas hal-hal berikut:

  • Konsep Spanner yang penting dan perbedaannya dengan database yang biasa digunakan dalam game.
  • Kapan Spanner adalah database yang tepat untuk game Anda.
  • Pola yang harus dihindari saat menggunakan Spanner untuk game.
  • Mendesain operasi database dengan Spanner sebagai database game Anda.
  • Membuat model data dan membuat skema untuk mendapatkan performa terbaik dengan Spanner.

Terminologi

Hak
Game, ekspansi, atau pembelian dalam aplikasi milik pemain.
Informasi identitas pribadi (PII)
Dalam game, informasi yang biasanya mencakup alamat email dan informasi akun pembayaran, seperti nomor kartu kredit dan alamat penagihan. Di beberapa pasar, informasi ini mungkin mencakup nomor KTP.
Database game (DB game)
Database yang menyimpan progres dan inventaris pemain untuk game.
Database autentikasi (DB autentikasi)
Database yang menyertakan hak pemain dan PII yang digunakan pemain saat melakukan pembelian. DB autentikasi juga dikenal sebagai DB akun atau DB pemain. Database ini terkadang digabungkan dengan DB game, tetapi sering kali dipisahkan di studio atau penerbit yang memiliki beberapa judul.
Transaksi
Transaksi database—kumpulan operasi tulis yang memiliki efek semua atau tidak sama sekali. Transaksi berhasil dan semua pembaruan diterapkan, atau database dikembalikan ke status yang tidak menyertakan pembaruan transaksi apa pun. Dalam game, transaksi database paling penting saat memproses pembayaran, dan saat menetapkan kepemilikan inventaris atau mata uang dalam game yang berharga.
Sistem manajemen database relasional (RDBMS)
Sistem database berdasarkan tabel dan baris yang saling mereferensikan. SQL Server, MySQL, dan (lebih jarang) Oracle® adalah contoh database relasional yang digunakan dalam game. Metode ini sering digunakan karena dapat memberikan metodologi yang sudah dikenal dan jaminan yang kuat seputar transaksi.
Database NoSQL (DB NoSQL)
Database yang tidak terstruktur secara relasional. Database ini menjadi lebih populer dalam game karena memiliki banyak fleksibilitas saat model data berubah. Database NoSQL mencakup MongoDB dan Cassandra.
Kunci utama
Biasanya kolom yang berisi ID unik untuk item inventaris, akun pemain, dan transaksi pembelian.
Instance
Satu database. Misalnya, cluster menjalankan beberapa salinan software database, tetapi muncul sebagai satu instance ke backend game.
Node
Untuk tujuan dokumen ini, satu mesin yang menjalankan salinan software database.
Replika
Salinan kedua database. Replika sering digunakan untuk pemulihan data dan ketersediaan tinggi, atau untuk membantu meningkatkan throughput baca.
Cluster
Beberapa salinan software yang berjalan di banyak mesin yang bersama-sama muncul sebagai satu instance ke backend game. Clustering digunakan untuk skalabilitas dan ketersediaan.
Shard
Instance database. Banyak studio game menjalankan beberapa instance database homogen, yang masing-masing menyimpan subset data game. Setiap instance ini biasanya disebut sebagai shard. Sharding biasanya dilakukan untuk performa atau skalabilitas, dengan mengorbankan efisiensi pengelolaan sekaligus meningkatkan kompleksitas aplikasi. Sharding di Spanner diterapkan menggunakan pemisahan.
Bagi
Spanner membagi data Anda menjadi beberapa bagian yang disebut bagian, dengan setiap bagian dapat dipindahkan secara independen satu sama lain dan ditetapkan ke server yang berbeda. Pemisahan ditentukan sebagai rentang baris dalam tabel tingkat teratas (dengan kata lain, non-interleaved), dengan baris diurutkan berdasarkan kunci utama. Kunci awal dan akhir rentang ini disebut "batas pemisahan". Spanner secara otomatis menambahkan dan menghapus batas pemisahan, yang mengubah jumlah pemisahan dalam database. Spanner membagi data berdasarkan beban: Spanner menambahkan batas pemisahan secara otomatis saat mendeteksi beban baca atau tulis tinggi yang tersebar di antara banyak kunci dalam pemisahan.
Hotspot
Jika satu bagian dalam database terdistribusi seperti Spanner berisi kumpulan data yang menerima sebagian besar dari semua kueri yang masuk ke database. Skenario ini tidak diinginkan karena menurunkan performa.

Menggunakan Spanner untuk game

Dalam sebagian besar kasus saat Anda mempertimbangkan RDBMS untuk game, Spanner adalah pilihan yang sesuai karena dapat secara efektif mengganti DB game, DB autentikasi, atau dalam banyak kasus, keduanya.

DB Game

Spanner dapat beroperasi sebagai satu otoritas transaksional global, yang membuatnya sangat cocok untuk sistem inventaris game. Semua mata uang atau item dalam game yang dapat diperdagangkan, dijual, diberikan, atau ditransfer dari satu pemain ke pemain lain menghadirkan tantangan dalam backend game skala besar. Sering kali, popularitas game dapat melampaui kemampuan database tradisional untuk menangani semuanya dalam database satu node. Bergantung pada jenis game, database dapat mengalami kesulitan dengan jumlah operasi yang diperlukan untuk menangani beban pemain serta jumlah data yang disimpan. Hal ini sering kali menyebabkan developer game melakukan sharding database untuk performa tambahan, atau untuk menyimpan tabel yang terus bertambah. Jenis solusi ini menyebabkan kompleksitas operasional dan overhead pemeliharaan yang tinggi.

Untuk membantu mengurangi kompleksitas ini, salah satu strategi umum adalah menjalankan region game yang benar-benar terpisah tanpa cara untuk memindahkan data di antara keduanya. Dalam hal ini, item dan mata uang tidak dapat diperdagangkan antar-pemain di region game yang berbeda, karena inventaris di setiap region dipisahkan ke dalam database terpisah. Namun, penyiapan ini mengorbankan pengalaman pemain yang diinginkan, demi kesederhanaan operasional dan developer.

Di sisi lain, Anda dapat mengizinkan perdagangan lintas region dalam database yang di-shard secara geografis, tetapi sering kali dengan biaya kompleksitas yang tinggi. Penyiapan ini mengharuskan transaksi mencakup beberapa instance database, sehingga menghasilkan logika sisi aplikasi yang kompleks dan rentan error. Mencoba mendapatkan kunci transaksi di beberapa database dapat memiliki dampak performa yang signifikan. Selain itu, tidak dapat mengandalkan transaksi atomik dapat menyebabkan eksploitasi pemain seperti duplikasi item atau mata uang dalam game, yang merugikan ekosistem dan komunitas game.

Spanner dapat menyederhanakan pendekatan Anda terhadap transaksi inventaris dan mata uang. Meskipun menggunakan Spanner untuk menyimpan semua data game Anda di seluruh dunia, Spanner menawarkan transaksi baca-tulis dengan properti ACID (atomicity, konsistensi, isolasi, dan ketahanan) yang lebih kuat daripada yang tradisional. Dengan skalabilitas Spanner, data tidak perlu di-shard ke dalam instance database terpisah saat lebih banyak performa atau penyimpanan diperlukan. Sebagai gantinya, Anda dapat menambahkan lebih banyak node. Selain itu, ketersediaan tinggi dan ketahanan data yang sering kali digunakan game untuk mengelompokkan database ditangani secara transparan oleh Spanner, sehingga tidak memerlukan penyiapan atau pengelolaan tambahan.

DB Auth

DB Autentikasi juga dapat ditayangkan dengan baik oleh Spanner, terutama jika Anda ingin menstandarkan pada satu RDBMS di tingkat studio atau penayang. Meskipun DB autentikasi untuk game sering kali tidak memerlukan skala Spanner, jaminan transaksional dan ketersediaan data yang tinggi dapat membuatnya menarik. Replikasi data di Spanner bersifat transparan, sinkron, dan bawaan. Spanner memiliki konfigurasi yang menawarkan ketersediaan 99,99% ("empat sembilan") atau 99,999% ("lima sembilan"), dengan "lima sembilan" yang sesuai dengan periode tidak tersedia kurang dari lima setengah menit dalam setahun. Jenis ketersediaan ini menjadikannya pilihan yang baik untuk jalur autentikasi penting yang diperlukan di awal setiap sesi pemain.

Praktik terbaik

Bagian ini memberikan rekomendasi tentang cara menggunakan Spanner dalam desain game. Anda harus membuat model data game untuk mendapatkan manfaat dari fitur unik yang ditawarkan oleh Spanner. Meskipun Anda dapat mengakses Spanner menggunakan semantik database relasional, beberapa poin desain skema dapat membantu Anda meningkatkan performa. Dokumentasi Spanner memiliki rekomendasi desain skema mendetail yang dapat Anda tinjau, tetapi bagian berikut adalah beberapa praktik terbaik untuk DB game.

Praktik dalam dokumen ini didasarkan pada pengalaman dari penggunaan pelanggan dan studi kasus.

Menggunakan UUID sebagai ID pemain dan karakter

Tabel pemain biasanya memiliki satu baris untuk setiap pemain dan mata uang dalam game, progres, atau data lainnya yang tidak mudah dipetakan ke baris tabel inventaris terpisah. Jika game Anda memungkinkan pemain memiliki progres tersimpan terpisah untuk beberapa karakter, seperti banyak game multiplayer masif persisten yang besar, tabel ini biasanya berisi baris untuk setiap karakter. Polanya tetap sama.

Sebaiknya gunakan karakter atau ID pemain yang unik secara global (ID karakter) sebagai kunci utama tabel karakter. Sebaiknya gunakan juga Universally Unique Identifier (UUID) v4, karena UUID v4 menyebarkan data pemain di seluruh node DB dan dapat membantu Anda mendapatkan peningkatan performa dari Spanner.

Menggunakan interleaving untuk tabel inventaris

Tabel inventaris sering kali menyimpan item dalam game, seperti perlengkapan karakter, kartu, atau unit. Biasanya, satu pemain memiliki banyak item di inventarisnya. Setiap item diwakili oleh satu baris dalam tabel.

Serupa dengan database relasional lainnya, tabel inventaris di Spanner memiliki kunci utama yang merupakan ID unik secara global untuk item, seperti yang diilustrasikan dalam tabel berikut.

itemID type playerID
7c14887e-8d45 1 6f1ede3b-25e2
8ca83609-bb93 40 6f1ede3b-25e2
33fedada-3400 1 5fa0aa7d-16da
e4714487-075e 23 5fa0aa7d-16da
d4fbfb92-a8bd 14 5fa0aa7d-16da
31b7067b-42ec 3 26a38c2c-123a

Dalam contoh tabel inventaris, itemID dan playerID terpotong untuk kemudahan membaca. Tabel inventaris yang sebenarnya juga akan berisi banyak kolom lain yang tidak disertakan dalam contoh.

Pendekatan umum dalam RDBMS untuk melacak kepemilikan item adalah menggunakan kolom sebagai kunci asing yang menyimpan ID pemain pemilik saat ini. Kolom ini adalah kunci utama tabel database terpisah. Di Spanner, Anda dapat menggunakan interleaving, yang menyimpan baris inventaris di dekat baris tabel pemain terkait untuk performa yang lebih baik. Saat menggunakan tabel yang diselingi, perhatikan hal berikut:

  • Anda tidak dapat membuat objek tanpa pemilik. Anda dapat menghindari objek tanpa pemilik dalam desain game asalkan batasan diketahui sebelumnya.

Mendesain pengindeksan untuk menghindari hotspot

Banyak developer game menerapkan indeks di banyak kolom inventaris untuk mengoptimalkan kueri tertentu. Di Spanner, membuat atau memperbarui baris dengan data dalam indeks tersebut akan menghasilkan beban tulis tambahan yang sebanding dengan jumlah kolom yang diindeks. Anda dapat meningkatkan performa Spanner dengan menghapus indeks yang tidak sering digunakan, atau dengan menerapkan indeks ini dengan cara lain yang tidak memengaruhi performa database.

Dalam contoh berikut, ada tabel untuk catatan skor tertinggi pemain jangka panjang:

CREATE TABLE Ranking (
        PlayerID STRING(36) NOT NULL,
        GameMode INT64 NOT NULL,
        Score INT64 NOT NULL
) PRIMARY KEY (PlayerID, GameMode)

Tabel ini berisi ID pemain (UUIDv4), angka yang mewakili mode game, tahap, atau musim, dan skor pemain.

Untuk mempercepat kueri yang memfilter mode game, pertimbangkan indeks berikut:

CREATE INDEX idx_score_ranking ON Ranking (
        GameMode,
        Score DESC
)

Jika semua orang memainkan mode game yang sama yang disebut 1, indeks ini akan membuat hotspot tempat GameMode=1. Jika Anda ingin mendapatkan peringkat untuk mode game ini, indeks hanya memindai baris yang berisi GameMode=1, yang menampilkan peringkat dengan cepat.

Jika Anda mengubah urutan indeks sebelumnya, Anda dapat mengatasi masalah hotspot ini:

CREATE INDEX idx_score_ranking ON Ranking (
        Score DESC,
        GameMode
)

Indeks ini tidak akan membuat hotspot yang signifikan dari pemain yang bersaing dalam mode game yang sama, asalkan skor mereka didistribusikan di seluruh kemungkinan rentang. Namun, mendapatkan skor tidak akan secepat dengan indeks sebelumnya karena kueri memindai semua skor dari semua mode untuk menentukan apakah GameMode=1.

Akibatnya, indeks yang diurutkan ulang akan menyelesaikan hotspot sebelumnya pada mode game, tetapi masih memiliki ruang untuk ditingkatkan, seperti yang diilustrasikan dalam desain berikut.

CREATE TABLE GameMode1Ranking (
        PlayerID STRING(36) NOT NULL,
        Score INT64 NOT NULL
) PRIMARY KEY (PlayerID)

CREATE INDEX idx_score_ranking ON Ranking (
        Score DESC
)

Sebaiknya pindahkan mode game dari skema tabel, dan gunakan satu tabel per mode, jika memungkinkan. Dengan menggunakan metode ini, saat mengambil skor untuk mode, Anda hanya mengkueri tabel dengan skor untuk mode tersebut. Tabel ini dapat diindeks berdasarkan skor untuk pengambilan rentang skor dengan cepat tanpa bahaya hotspot yang signifikan (asalkan skor didistribusikan dengan baik). Saat penulisan dokumen ini, jumlah maksimum tabel per database di Spanner adalah 2.560, yang lebih dari cukup untuk sebagian besar game.

Database terpisah per tenant

Tidak seperti beban kerja lain, tempat kami menyarankan desain untuk multi-tenancy di Spanner dengan menggunakan nilai kunci utama yang berbeda, untuk data game, sebaiknya gunakan pendekatan konvensional database terpisah per tenant. Perubahan skema umum terjadi dengan rilis fitur game baru dalam game layanan live, dan isolasi tenant di tingkat database dapat menyederhanakan update skema. Strategi ini juga dapat mengoptimalkan waktu yang diperlukan untuk mencadangkan atau memulihkan data tenant, karena operasi ini dilakukan pada seluruh database sekaligus.

Menghindari update skema inkremental

Tidak seperti beberapa database relasional konvensional, Spanner tetap beroperasi selama pembaruan skema. Semua kueri terhadap skema lama akan ditampilkan (meskipun mungkin ditampilkan lebih lambat dari biasanya), dan kueri terhadap skema baru akan ditampilkan saat tersedia. Anda dapat mendesain proses update untuk membuat game tetap berjalan selama update skema saat berjalan di Spanner, asalkan Anda mengingat batasan sebelumnya.

Namun, jika Anda meminta perubahan skema lain saat ada perubahan yang sedang diproses, update baru akan diantrekan dan tidak akan dilakukan hingga semua update skema sebelumnya selesai. Anda dapat menghindari situasi ini dengan merencanakan update skema yang lebih besar, bukan mengeluarkan banyak update skema inkremental dalam periode yang singkat. Untuk informasi selengkapnya tentang pembaruan skema, termasuk cara melakukan pembaruan skema yang memerlukan validasi data, lihat dokumentasi pembaruan skema Spanner

Pertimbangkan akses dan ukuran database

Saat mengembangkan server game dan layanan platform untuk menggunakan Spanner, pertimbangkan cara game Anda mengakses database dan cara menentukan ukuran database untuk menghindari biaya yang tidak perlu.

Menggunakan driver dan library bawaan

Saat Anda mengembangkan aplikasi untuk Spanner, pertimbangkan cara kode Anda berinteraksi dengan database. Spanner menawarkan library klien bawaan untuk banyak bahasa populer, yang biasanya kaya fitur dan berperforma tinggi. Driver JDBC juga tersedia, yang mendukung pernyataan bahasa manipulasi data (DML) dan bahasa definisi data (DDL). Jika Spanner digunakan dalam pengembangan baru, sebaiknya gunakan Library Klien Cloud untuk Spanner. Meskipun integrasi game engine standar tidak memiliki fleksibilitas yang besar dalam pemilihan bahasa, untuk layanan platform yang mengakses Spanner, ada kasus pelanggan game yang menggunakan Java atau Go. Untuk aplikasi dengan throughput tinggi, pilih library tempat Anda dapat menggunakan klien Spanner yang sama untuk beberapa permintaan berurutan.

Mengukur ukuran database sesuai kebutuhan pengujian dan produksi

Selama pengembangan, instance Spanner satu node mungkin cukup untuk sebagian besar aktivitas, termasuk pengujian fungsional.

Mengevaluasi kebutuhan Spanner untuk produksi

Saat Anda beralih dari pengembangan ke pengujian, lalu ke produksi, Anda harus mengevaluasi ulang kebutuhan Spanner untuk memastikan game dapat menangani traffic pemain langsung.

Sebelum Anda beralih ke produksi, uji beban sangat penting untuk memverifikasi bahwa backend Anda dapat menangani beban selama produksi. Sebaiknya jalankan pengujian beban dengan beban dua kali lipat yang Anda harapkan dalam produksi untuk bersiap menghadapi lonjakan penggunaan dan kasus saat game Anda lebih populer dari yang diperkirakan.

Menjalankan pengujian beban menggunakan data sebenarnya

Menjalankan pengujian beban dengan data sintetis tidak cukup. Anda juga harus menjalankan uji beban menggunakan data dan pola akses seserupa mungkin dengan yang diharapkan dalam produksi. Data sintetis mungkin tidak mendeteksi potensi hotspot dalam desain skema Spanner Anda. Tidak ada yang lebih baik daripada menjalankan pengujian beta (terbuka atau tertutup) dengan pemain sungguhan untuk memverifikasi perilaku Spanner dengan data sungguhan.

Diagram berikut adalah contoh skema tabel pemain dari studio game yang menggambarkan pentingnya menggunakan pengujian beta untuk pengujian beban.

Daftar nama pemain dan atribut untuk pengujian beban.

Studio menyiapkan data ini berdasarkan tren dari game sebelumnya yang telah mereka operasikan selama beberapa tahun. Perusahaan mengharapkan skema tersebut dapat mewakili data dalam game baru ini dengan baik.

Setiap data pemain memiliki beberapa atribut numerik yang terkait dengannya yang melacak progres pemain dalam game (seperti peringkat, dan waktu bermain). Untuk contoh atribut yang digunakan dalam tabel sebelumnya, pemain baru diberi nilai awal 50, dan nilai ini kemudian berubah menjadi nilai antara 1 dan 100 saat pemain maju.

Studio ingin mengindeks atribut ini untuk mempercepat kueri penting selama gameplay.

Berdasarkan data ini, studio membuat tabel Spanner berikut, dengan kunci utama menggunakan PlayerID dan indeks sekunder di Attribute.

CREATE TABLE Player (
        PlayerID STRING(36) NOT NULL,
        Attribute INT64 NOT NULL
) PRIMARY KEY (PlayerID)

CREATE INDEX idx_attribute ON Player(Attribute)

Dan indeks dikueri untuk menemukan hingga sepuluh pemain dengan Attribute=23, seperti ini:

SELECT PlayerID
        FROM Player@{force_index=idx_attribute}
        WHERE Attribute = 23
        LIMIT 10

Menurut dokumentasi tentang mengoptimalkan desain skema, Spanner menyimpan data indeks dengan cara yang sama seperti tabel, dengan satu baris per entri indeks. Dalam pengujian beban, model ini melakukan tugas yang dapat diterima untuk mendistribusikan beban baca dan tulis indeks sekunder di beberapa bagian Spanner, seperti yang diilustrasikan dalam diagram berikut:

Pemain didistribusikan di seluruh bagian Spanner menurut atributnya.

Meskipun data sintetis yang digunakan dalam pengujian beban mirip dengan status steady game akhir saat nilai Attribute didistribusikan dengan baik, desain game menentukan bahwa semua pemain memulai dengan Attribute=50. Karena setiap pemain baru dimulai dengan Attribute=50, saat pemain baru bergabung, mereka akan disisipkan di bagian yang sama dari indeks sekunder idx_attribute. Artinya, update diarahkan ke bagian Spanner yang sama, sehingga menyebabkan hotspot selama periode peluncuran game. Ini adalah penggunaan Spanner yang tidak efisien.

Pemain saat peluncuran dengan atribut yang sama membuat hotspot dalam satu bagian Spanner.

Dalam diagram berikut, menambahkan kolom IndexPartition ke skema setelah peluncuran akan menyelesaikan masalah hotspot, dan pemain didistribusikan secara merata di seluruh pembagian Spanner yang tersedia. Perintah yang diperbarui untuk membuat tabel dan indeks terlihat seperti ini:

CREATE TABLE Player (
        PlayerID STRING(36) NOT NULL,
        IndexPartition INT64 NOT NULL
        Attribute INT64 NOT NULL
) PRIMARY KEY (PlayerID)

CREATE INDEX idx_attribute ON Player(IndexPartition,Attribute)

Menambahkan kolom IndexPartition ke skema akan mendistribusikan pemain secara merata saat peluncuran.

Nilai IndexPartition harus memiliki rentang terbatas untuk kueri yang efisien, tetapi juga harus memiliki rentang yang setidaknya dua kali lipat dari jumlah pemisahan untuk distribusi yang efisien.

Dalam hal ini, studio secara manual menetapkan IndexPartition antara 1 dan 6 kepada setiap pemain dalam aplikasi game.

Metode alternatifnya adalah menetapkan angka acak untuk setiap pemain, atau menetapkan nilai yang berasal dari hash pada nilai PlayerID. Lihat Yang perlu diketahui DBA tentang Spanner, bagian 1: Kunci dan indeks untuk mengetahui strategi sharding tingkat aplikasi lainnya.

Memperbarui kueri sebelumnya untuk menggunakan indeks yang ditingkatkan ini akan terlihat seperti berikut:

SELECT PlayerID
        FROM Player@{force_index=idx_attribute}
        WHERE IndexPartition BETWEEN 1 and 6
        AND Attribute = 23
        LIMIT 10

Karena tidak ada pengujian beta yang dijalankan, studio tidak menyadari bahwa mereka melakukan pengujian dengan menggunakan data dengan asumsi yang salah. Meskipun uji beban sintetis adalah cara yang baik untuk memvalidasi jumlah kueri per detik (QPS) yang dapat ditangani instance Anda, pengujian beta dengan pemain sungguhan diperlukan untuk memvalidasi skema Anda dan menyiapkan peluncuran yang sukses.

Menentukan ukuran lingkungan produksi untuk mengantisipasi permintaan puncak

Game besar sering kali mengalami puncak traffic saat peluncuran. Membuat backend yang skalabel tidak hanya berlaku untuk layanan platform dan server game khusus, tetapi juga untuk database. Dengan menggunakan solusi Google Cloud seperti App Engine, Anda dapat membuat layanan API frontend yang dapat diskalakan dengan cepat. Meskipun menawarkan fleksibilitas untuk menambahkan dan menghapus node secara online, Spanner bukanlah database penskalaan otomatis. Anda perlu menyediakan node yang memadai untuk menangani lonjakan traffic saat peluncuran.

Berdasarkan data yang dikumpulkan selama pengujian beban atau dari pengujian beta publik, Anda dapat memperkirakan jumlah node yang diperlukan untuk menangani permintaan saat peluncuran. Sebaiknya tambahkan beberapa node sebagai buffer jika Anda mendapatkan lebih banyak pemain daripada yang diharapkan. Anda harus selalu menyesuaikan ukuran database agar tidak melebihi penggunaan CPU rata-rata sebesar 65%.

Menyiapkan database sebelum peluncuran game

Sebelum meluncurkan game, sebaiknya panaskan database Anda untuk memanfaatkan fitur paralelisasi Spanner. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan database sebelum peluncuran aplikasi.

Memantau dan memahami performa

Setiap database produksi memerlukan pemantauan dan metrik performa yang komprehensif. Spanner dilengkapi dengan metrik bawaan di Cloud Monitoring. Jika memungkinkan, sebaiknya gabungkan library gRPC yang disediakan ke dalam proses backend game Anda karena library ini menyertakan pelacakan OpenCensus. Pelacakan OpenCensus memungkinkan Anda melihat trace kueri di Cloud Trace serta alat pelacakan open source lainnya yang didukung.

Di Cloud Monitoring, Anda dapat melihat detail tentang penggunaan Spanner, termasuk penyimpanan data dan penggunaan CPU. Untuk sebagian besar kasus, sebaiknya Anda mendasarkan keputusan penskalaan Spanner pada metrik penggunaan CPU ini atau latensi yang diamati. Untuk informasi selengkapnya tentang penggunaan CPU yang disarankan untuk performa yang dioptimalkan, lihat Praktik terbaik.

Spanner menawarkan paket eksekusi kueri. Anda dapat meninjau paket ini di konsol Google Cloud, dan menghubungi dukungan jika Anda memerlukan bantuan untuk memahami performa kueri.

Saat mengevaluasi performa, minimalkan pengujian siklus pendek karena Spanner memisahkan data secara transparan di balik layar untuk mengoptimalkan performa berdasarkan pola akses data Anda. Anda harus mengevaluasi performa menggunakan beban kueri yang berkelanjutan dan realistis.

Saat menghapus data, hapus baris, bukan membuat ulang tabel

Saat Anda menggunakan Spanner, tabel yang baru dibuat belum memiliki kesempatan untuk menjalani pemisahan berbasis beban atau ukuran untuk meningkatkan performa. Saat Anda menghapus data dengan menghapus tabel, lalu membuatnya ulang, Spanner memerlukan data, kueri, dan waktu untuk menentukan pemisahan yang benar untuk tabel Anda. Jika Anda berencana mengisi ulang tabel dengan jenis data yang sama (misalnya, saat menjalankan pengujian performa berturut-turut), Anda dapat menjalankan kueri DELETE pada baris yang berisi data yang tidak lagi Anda perlukan. Karena alasan yang sama, update skema harus menggunakan Cloud Spanner API yang disediakan, dan harus menghindari strategi manual, seperti membuat tabel baru dan menyalin data dari tabel lain atau file cadangan.

Memilih lokalitas data untuk memenuhi persyaratan kepatuhan

Banyak game harus mematuhi hukum lokalitas data seperti GDPR saat dimainkan di seluruh dunia. Untuk membantu mendukung kebutuhan GDPR Anda, lihat whitepaper Google Cloud dan GDPR dan pilih konfigurasi regional Spanner yang benar.

Langkah selanjutnya