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 bagi engineer backend game yang mengerjakan 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 online dan multiplayer telah berkembang sehingga memerlukan struktur database yang semakin kompleks untuk melacak hak, status, dan data inventaris pemain. Mengembangkan basis pemain dan meningkatkan kompleksitas game telah menghasilkan solusi database yang merupakan tantangan untuk diskalakan dan dikelola, yang sering kali mengharuskan penggunaan sharding atau pengelompokan. Melacak item dalam game yang berharga atau progres pemain yang penting biasanya memerlukan transaksi dan sulit untuk diatasi di banyak jenis database terdistribusi.

Spanner adalah layanan database tingkat perusahaan yang skalabel, terdistribusi secara global, dan sangat konsisten yang dibangun untuk cloud agar dapat menggabungkan manfaat struktur database relasional dengan skala horizontal non-relasional. Banyak perusahaan game merasa sangat cocok untuk mengganti database autentikasi dan status game dalam sistem skala produksi. Anda dapat melakukan penskalaan untuk mendapatkan performa atau penyimpanan tambahan menggunakan Konsol Google Cloud untuk menambahkan node. Spanner dapat menangani replikasi global secara transparan dengan konsistensi kuat, sehingga Anda tidak perlu mengelola replika regional.

Dokumen praktik terbaik ini membahas hal berikut:

Konsep dan perbedaan penting Spanner dari database yang biasa digunakan dalam game.
Jika Spanner adalah database yang tepat untuk game Anda.
Pola yang harus dihindari saat menggunakan Spanner untuk game.
Merancang operasi database dengan Spanner sebagai database game Anda.
Pemodelan data Anda dan buat 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 ID nasional.
Database game (DB game): Database yang menyimpan progres pemain dan inventaris untuk game.
Database autentikasi (DB auth): Database yang menyertakan hak pemain dan PII yang digunakan pemain saat melakukan pembelian. DB autentikasi juga disebut 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 pengaruh semuanya atau tidak sama sekali. Transaksi akan berhasil dan semua update berlaku, atau database dikembalikan ke status yang tidak menyertakan update transaksi. Dalam game, transaksi database paling penting saat memproses pembayaran, dan saat menetapkan kepemilikan mata uang atau inventaris dalam game yang berharga.
Sistem manajemen database relasional (RDBMS): Sistem database yang didasarkan pada tabel dan baris yang saling mereferensikan satu sama lain. SQL Server, MySQL, dan (lebih jarang) Oracle® adalah contoh database relasional yang digunakan dalam game. Metode ini sering digunakan karena dapat memberikan metodologi yang familier dan jaminan kuat seputar transaksi.
Database NoSQL (NoSQL DB): Database yang tidak terstruktur secara relasi. Database ini menjadi lebih populer dalam game karena memiliki banyak fleksibilitas saat model data berubah. Database NoSQL meliputi MongoDB dan Cassandra.
Kunci utama: Biasanya berupa kolom yang berisi ID unik untuk item inventaris, akun pemain, dan transaksi pembelian.
Instance: Satu database. Misalnya, cluster menjalankan beberapa salinan software database, tetapi akan muncul sebagai satu instance ke backend game.
Node: Untuk tujuan dokumen ini, satu mesin yang menjalankan salinan software database.
Replika: Salinan database kedua. Replika sering digunakan untuk pemulihan data dan ketersediaan tinggi, atau untuk membantu meningkatkan throughput baca.
Cluster: Beberapa salinan software yang berjalan di banyak komputer yang bersama-sama muncul sebagai satu instance ke backend game. Pengelompokan 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, sehingga mengorbankan efisiensi pengelolaan sekaligus meningkatkan kompleksitas aplikasi. Sharding di Spanner diimplementasikan menggunakan pemisahan.
Bagi: Spanner membagi data Anda menjadi beberapa bagian yang disebut pemisahan. Setiap bagian dapat berpindah secara independen satu sama lain dan ditetapkan ke server yang berbeda. Pemisahan didefinisikan sebagai rentang baris di tabel level atas (dengan kata lain, tidak disisipi), yang mana baris tersebut diurutkan berdasarkan kunci utama. Kunci awal dan akhir rentang ini disebut "batas terpisah". Spanner secara otomatis menambahkan dan menghapus batas pemisahan, yang mengubah jumlah bagian dalam database. Spanner membagi data berdasarkan beban: Spanner menambahkan batas pemisahan secara otomatis saat mendeteksi penyebaran beban baca atau tulis yang tinggi di antara banyak kunci dalam pemisahan.
Hotspot: Jika satu bagian dalam database terdistribusi seperti Spanner berisi data yang menerima sebagian besar semua kueri yang mengarah ke database. Skenario ini tidak diinginkan karena menurunkan performa.

Menggunakan Spanner untuk game

Pada umumnya, ketika Anda mempertimbangkan RDBMS untuk game, Spanner adalah pilihan yang tepat karena dapat secara efektif mengganti DB game, DB autentikasi, atau dalam banyak kasus, keduanya.

DB Game

Spanner dapat beroperasi sebagai satu otoritas transaksional di seluruh dunia, sehingga sangat cocok untuk sistem inventaris game. Setiap mata uang atau item dalam game yang dapat diperdagangkan, dijual, dihadiahkan, atau ditransfer dari satu pemain ke pemain lainnya menghadirkan tantangan dalam backend game berskala besar. Sering kali, popularitas game dapat melampaui kemampuan database tradisional untuk menangani semuanya dalam database satu node. Bergantung pada jenis game, database dapat kesulitan dengan jumlah operasi yang diperlukan untuk menangani beban pemain serta jumlah data yang tersimpan. Hal ini sering kali membuat developer game melakukan sharding database untuk mendapatkan performa tambahan, atau menyimpan tabel yang terus berkembang. 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 memindahkan data di antara region tersebut. Dalam hal ini, item dan mata uang tidak dapat diperdagangkan antara pemain di region game yang berbeda karena penemuan di setiap wilayah dipisahkan ke dalam database yang terpisah. Namun, penyiapan ini mengorbankan pengalaman pemain yang diinginkan, demi kesederhanaan developer dan operasional.

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

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

DB Auth

DB Auth juga dapat dilayani dengan baik oleh Spanner, terutama jika Anda ingin menstandarkan satu RDBMS di tingkat studio atau penayang Anda. 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 99,99% ("empat sembilan") atau 99,999% ("lima sembilan") ketersediaan, dengan "lima sembilan" yang berarti kurang dari lima setengah menit ketidaktersediaan dalam setahun. Jenis ketersediaan ini menjadikannya pilihan yang baik untuk jalur autentikasi kritis yang diperlukan di awal setiap sesi pemain.

Praktik terbaik

Bagian ini memberikan rekomendasi tentang cara menggunakan Spanner dalam desain game. Penting untuk membuat model data game agar dapat memanfaatkan 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 berisi 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 lain yang tidak mudah dipetakan ke baris tabel inventaris terpisah. Jika game Anda memungkinkan pemain memiliki progres tersimpan yang terpisah untuk beberapa karakter, seperti banyak game multiplayer berskala besar yang persisten, tabel ini biasanya berisi baris untuk setiap karakter. Polanya sama.

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

Menggunakan penyisipan untuk tabel inventaris

Tabel inventaris sering kali menyimpan item dalam game, seperti perlengkapan karakter, kartu, atau unit. Biasanya, satu pemain memiliki banyak item dalam 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 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 dipotong agar mudah dibaca. 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 dari tabel {i>database<i} yang 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 sisipan, perhatikan hal berikut:

Anda harus mempertahankan total data di baris pemain dan semua baris inventaris turunannya di bawah ~4 GiB. Pembatasan ini biasanya bukan masalah dengan desain model data yang sesuai.
Anda tidak dapat membuat objek tanpa pemilik. Anda dapat menghindari objek tanpa pemilik dalam desain game asalkan batasannya diketahui sebelumnya.

Desain pengindeksan untuk menghindari hotspot

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

Pada contoh berikut, ada tabel untuk data skor tinggi 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, panggung, atau season, serta 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 dengan 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 menyelesaikan masalah hotspot ini:

CREATE INDEX idx_score_ranking ON Ranking (
        Score DESC,
        GameMode
)

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

Akibatnya, indeks yang diurutkan ulang menyelesaikan hotspot sebelumnya pada mode game, tetapi masih dapat 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 suatu mode, Anda hanya membuat kueri tabel yang berisi skor untuk mode tersebut di dalamnya. Tabel ini dapat diindeks berdasarkan skor untuk pengambilan rentang skor yang cepat tanpa bahaya hotspot yang signifikan (asalkan skor didistribusikan dengan baik). Pada saat dokumen ini ditulis, jumlah maksimum tabel per database di Spanner adalah 2.560, jumlah yang lebih dari cukup untuk sebagian besar game.

Database terpisah per tenant

Tidak seperti workload lain, di mana kami merekomendasikan untuk mendesain multitenancy di Spanner dengan menggunakan nilai kunci utama yang berbeda, untuk data game, kami merekomendasikan pendekatan database terpisah per tenant yang lebih konvensional. Perubahan skema sering terjadi pada rilis fitur game baru di game layanan live, dan isolasi tenant pada tingkat database dapat menyederhanakan update skema. Strategi ini juga dapat mengoptimalkan waktu yang diperlukan untuk mencadangkan atau memulihkan data tenant, karena operasi ini dijalankan di 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 agar game tetap berjalan selama update skema saat berjalan di Spanner, asalkan Anda memperhatikan batasan sebelumnya.

Namun, jika Anda meminta perubahan skema lain saat skema sedang diproses, update yang baru akan dimasukkan ke dalam antrean dan tidak akan terjadi sampai semua update skema sebelumnya telah selesai. Anda dapat menghindari situasi ini dengan merencanakan update skema yang lebih besar, bukan menerbitkan banyak update skema inkremental dalam jangka waktu singkat. Untuk mengetahui informasi selengkapnya tentang pembaruan skema, termasuk cara melakukan pembaruan skema yang memerlukan validasi data, lihat Dokumentasi pembaruan skema Spanner

Mempertimbangkan akses dan ukuran database

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

Menggunakan driver dan library native

Saat mengembangkan aplikasi di Spanner, pertimbangkan bagaimana kode Anda berinteraksi dengan database. Spanner menawarkan library klien native 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 dalam pemilihan bahasa, untuk layanan platform yang mengakses Spanner, ada beberapa 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.

Menyesuaikan ukuran database dengan kebutuhan pengujian dan produksi

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

Mengevaluasi kebutuhan Spanner untuk produksi

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

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

Menjalankan pengujian beban menggunakan data nyata

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

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

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 ini mewakili data dalam game baru ini dengan baik.

Setiap kumpulan data pemain memiliki beberapa atribut numerik terkaitnya yang melacak progres pemain dalam game (seperti peringkat dan waktu bermain). Untuk atribut contoh yang digunakan dalam tabel sebelumnya, pemain baru diberi nilai awal 50, lalu 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 pada Attribute.

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

CREATE INDEX idx_attribute ON Player(Attribute)

Kemudian, 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 uji beban, model ini melakukan tugas yang dapat diterima dalam mendistribusikan beban baca dan tulis indeks sekunder ke beberapa bagian Spanner, seperti yang diilustrasikan dalam diagram berikut:

Pemain yang didistribusikan di seluruh Spanner akan dipisahkan berdasarkan atributnya.

Meskipun data sintetis yang digunakan dalam uji beban mirip dengan keadaan stabil game 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. Ini berarti update diarahkan ke pemisahan Spanner yang sama, yang menyebabkan hotspot selama jendela peluncuran game. Ini adalah penggunaan Spanner yang tidak efisien.

Pemain yang melakukan 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 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 membuat kueri yang efisien, tetapi juga harus memiliki rentang yang setidaknya dua kali lipat jumlah bagian untuk distribusi yang efisien.

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

Metode alternatifnya adalah dengan 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 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 uji beta yang dijalankan, studio ini tidak menyadari bahwa mereka melakukan pengujian menggunakan data dengan asumsi yang salah. Meskipun pengujian beban sintetis merupakan cara yang baik untuk memvalidasi jumlah kueri per detik (QPS) yang dapat ditangani instance Anda, uji beta dengan pemain sungguhan diperlukan untuk memvalidasi skema Anda dan menyiapkan peluncuran yang sukses.

Menyesuaikan ukuran lingkungan produksi untuk mengantisipasi permintaan yang tinggi

Game besar sering kali mengalami puncak traffic saat peluncuran. Pembuatan 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 membangun layanan API frontend yang dapat ditingkatkan skalanya dengan cepat. Meskipun Spanner menawarkan fleksibilitas untuk menambahkan dan menghapus node secara online, Spanner bukanlah database penskalaan otomatis. Anda perlu menyediakan node yang cukup untuk menangani lonjakan traffic saat peluncuran.

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

Menyiapkan database sebelum peluncuran game

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

Memantau dan memahami performa

Setiap database produksi memerlukan metrik performa dan pemantauan yang komprehensif. Spanner dilengkapi dengan metrik bawaan di Cloud Monitoring. Jika memungkinkan, sebaiknya sertakan library gRPC yang disediakan ke dalam proses backend game Anda karena library ini menyertakan pelacakan OpenCensus. Pelacakan OpenCensus memungkinkan Anda melihat rekaman aktivitas kueri di Cloud Trace serta alat pelacakan open source lain 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 Anda pada metrik penggunaan CPU atau latensi yang diamati ini. Untuk mengetahui informasi selengkapnya tentang penggunaan CPU yang disarankan untuk performa yang dioptimalkan, lihat Praktik terbaik.

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

Saat Anda mengevaluasi performa, lakukan pengujian siklus singkat seminimal mungkin karena Spanner secara transparan membagi data Anda di balik layar untuk mengoptimalkan performa berdasarkan pola akses data Anda. Anda harus mengevaluasi performa menggunakan pemuatan kueri yang berkelanjutan dan realistis.

Saat menghapus data, hapus baris, bukan membuat ulang tabel

Saat Anda menggunakan Spanner, tabel yang baru dibuat belum memiliki peluang untuk menjalani pemisahan berbasis beban atau berbasis ukuran guna meningkatkan performa. Saat menghapus data dengan melepas 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 diperlukan. Untuk alasan yang sama, pembaruan 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.

Pilih lokalitas data untuk memenuhi persyaratan kepatuhan

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

Langkah selanjutnya

Baca cara Bandai Namco Entertainment menggunakan Spanner dalam peluncuran Dragon Ball Legends yang sukses.
Tonton sesi Cloud Next '18 tentang Mengoptimalkan Aplikasi, Skema, dan Desain Kueri di Spanner.
Baca panduan kami tentang Bermigrasi dari DynamoDB ke Spanner.