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 menangani penyimpanan status jangka panjang, serta operator dan admin infrastruktur game yang mendukung sistem tersebut dan tertarik untuk menghosting database backend mereka diGoogle Cloud.

Game multiplayer dan online telah berkembang sehingga memerlukan struktur database yang semakin kompleks untuk melacak data hak, status, dan inventaris pemain. Peningkatan jumlah pemain dan kompleksitas game telah menyebabkan solusi database sulit diskalakan dan dikelola, sehingga sering kali memerlukan penggunaan sharding atau pengelompokan. Pelacakan 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 menganggapnya sangat cocok untuk menggantikan database status game dan autentikasi dalam sistem skala produksi. Anda dapat menskalakan performa atau penyimpanan tambahan menggunakan konsolGoogle 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 penting Spanner dan perbedaannya dengan database yang umum digunakan dalam game.
  • Saat 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 dapat mencakup nomor KTP.
Database game (DB game)
Database yang menyimpan progres dan inventaris pemain untuk game.
Database autentikasi (DB auth)
Database yang mencakup 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—serangkaian operasi tulis yang memiliki efek semua atau tidak sama sekali. Transaksi berhasil dan semua update diterapkan, atau database dikembalikan ke status yang tidak menyertakan update apa pun dari transaksi. Dalam game, transaksi database sangat 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. Database 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 semakin 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 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, dengan mengorbankan efisiensi pengelolaan sekaligus meningkatkan kompleksitas aplikasi. Sharding di Spanner diterapkan menggunakan split.
Bagi
Spanner membagi data Anda menjadi beberapa bagian yang disebut bagian, di mana setiap bagian dapat dipindahkan secara independen satu sama lain dan ditetapkan ke server yang berbeda. Pemisahan didefinisikan sebagai rentang baris dalam tabel tingkat teratas (dengan kata lain, tidak berselang-seling), 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 yang tinggi yang tersebar di banyak kunci dalam satu pemisahan.
Hotspot
Saat satu bagian dalam database terdistribusi seperti Spanner berisi data yang menerima sebagian besar 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 tepat karena dapat secara efektif menggantikan DB game, DB autentikasi, atau dalam banyak kasus, keduanya.

DB Game

Spanner dapat beroperasi sebagai otoritas transaksional tunggal di seluruh dunia, sehingga sangat cocok untuk sistem inventaris game. Mata uang atau item dalam game apa pun yang dapat diperdagangkan, dijual, diberikan, atau ditransfer dari satu pemain ke pemain lain menimbulkan tantangan di 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 membuat developer game memecah database mereka untuk meningkatkan performa, atau 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 region tersebut. Dalam hal ini, item dan mata uang tidak dapat diperdagangkan antar-pemain di wilayah game yang berbeda, karena inventaris di setiap wilayah dipisahkan ke dalam database yang berbeda. Namun, penyiapan ini mengorbankan pengalaman pemain yang lebih baik, demi kesederhanaan developer dan operasional.

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 rumit dan rentan terhadap error. Mencoba mendapatkan kunci transaksi di beberapa database dapat berdampak signifikan pada performa. Selain itu, tidak dapat mengandalkan transaksi atomik dapat menyebabkan eksploitasi pemain seperti duplikasi item atau mata uang dalam game, yang membahayakan 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 yang lebih kuat daripada atomisitas, konsistensi, isolasi, dan ketahanan (ACID) konvensional. Dengan skalabilitas Spanner, data tidak perlu di-shard ke dalam instance database terpisah saat diperlukan performa atau penyimpanan yang lebih besar. Sebagai gantinya, Anda dapat menambahkan lebih banyak node. Selain itu, ketersediaan tinggi dan ketahanan data yang sering kali digunakan game untuk mengelompokkan database-nya ditangani secara transparan oleh Spanner, tanpa memerlukan penyiapan atau pengelolaan tambahan.

DB Auth

DB Auth juga dapat dilayani dengan baik oleh Spanner, terutama jika Anda ingin menstandardisasi satu RDBMS di tingkat studio atau penerbit. Meskipun DB autentikasi untuk game sering kali tidak memerlukan skala Spanner, jaminan transaksional dan ketersediaan data yang tinggi dapat menjadikannya 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 memodelkan data game untuk 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 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 lain yang tidak mudah dipetakan ke baris tabel inventaris diskrit. Jika game Anda memungkinkan pemain memiliki progres tersimpan yang terpisah untuk beberapa karakter, seperti banyak game multiplayer masif persisten besar, maka tabel ini biasanya berisi baris untuk setiap karakter. Pola lainnya sama.

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

Menggunakan penyisipan untuk tabel inventaris

Tabel inventaris sering kali berisi 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 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 dipangkas 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 dengan menggunakan kolom sebagai kunci asing yang menyimpan ID pemain pemilik saat ini. Kolom ini adalah kunci utama dari tabel database terpisah. Di Spanner, Anda dapat menggunakan penyisipan, yang menyimpan baris inventaris di dekat baris tabel pemain terkait untuk mendapatkan performa yang lebih baik. Saat menggunakan tabel berselang-seling, perhatikan hal berikut:

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

Mendesain pengindeksan untuk menghindari hotspot

Banyak developer game menerapkan indeks pada banyak kolom inventaris untuk mengoptimalkan kueri tertentu. Di Spanner, membuat atau memperbarui baris dengan data dalam indeks tersebut akan menghasilkan beban penulisan 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, level, 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, sehingga 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 menyelesaikan masalah hotspot sebelumnya pada mode game, tetapi masih perlu 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 yang cepat tanpa bahaya hotspot yang signifikan (asalkan skor didistribusikan dengan baik). Saat dokumen ini ditulis, jumlah maksimum tabel per database di Spanner adalah 2560, yang lebih dari cukup untuk sebagian besar game.

Database terpisah per tenant

Tidak seperti beban kerja lainnya, yang merekomendasikan desain untuk multi-tenancy di Spanner dengan menggunakan nilai kunci primer yang berbeda, untuk data game, kami merekomendasikan pendekatan konvensional berupa database terpisah per tenant. Perubahan skema umum terjadi saat merilis 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 update 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 ada perubahan yang sedang diproses, update baru akan dimasukkan dalam antrean dan tidak akan terjadi 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 waktu singkat. Untuk mengetahui 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 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 mesin game umum tidak memiliki banyak fleksibilitas 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 database sesuai 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 Anda beralih dari pengembangan ke pengujian, lalu ke produksi, Anda harus mengevaluasi kembali kebutuhan Spanner untuk memastikan game Anda dapat menangani traffic pemain aktif.

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

Menjalankan uji beban menggunakan data asli

Menjalankan uji beban dengan data sintetis tidaklah cukup. Anda juga harus menjalankan uji beban menggunakan data dan pola akses yang semirip 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 uji 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 mengilustrasikan pentingnya menggunakan uji 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 berharap skema tersebut dapat merepresentasikan data dalam game baru ini dengan baik.

Setiap catatan pemain memiliki beberapa atribut numerik yang terkait dengannya 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, 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 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 untuk mendistribusikan beban baca dan tulis indeks sekunder di beberapa pemisahan Spanner, seperti yang diilustrasikan dalam diagram berikut:

Pemain didistribusikan di seluruh pemisahan Spanner berdasarkan atributnya.

Meskipun data sintetis yang digunakan dalam uji beban serupa dengan kondisi stabil game pada akhirnya dengan nilai Attribute yang terdistribusi dengan baik, desain game menetapkan bahwa semua pemain memulai dengan Attribute=50. Karena setiap pemain baru memulai dengan Attribute=50, saat pemain baru bergabung, mereka akan dimasukkan di bagian indeks sekunder idx_attribute yang sama. Artinya, update dirutekan ke pemisahan 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 pemisahan Spanner.

Dalam diagram berikut, menambahkan kolom IndexPartition ke skema setelah peluncuran 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 jumlah pemisahan untuk distribusi yang efisien.

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

Metode alternatifnya adalah menetapkan angka acak kepada 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 lebih baik 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 sedang melakukan pengujian dengan menggunakan data yang memiliki asumsi yang salah. Meskipun uji beban sintetis adalah 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 mempersiapkan peluncuran yang sukses.

Menentukan ukuran lingkungan produksi untuk mengantisipasi permintaan puncak

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

Berdasarkan data yang Anda kumpulkan 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 dari yang diperkirakan. Anda harus selalu menentukan ukuran database berdasarkan penggunaan CPU rata-rata yang tidak melebihi 65%.

Menyiapkan database sebelum peluncuran game

Sebelum meluncurkan game, sebaiknya panaskan database Anda untuk memanfaatkan fitur paralelisme 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 mencakup 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 mengetahui informasi selengkapnya tentang penggunaan CPU yang disarankan untuk performa yang dioptimalkan, lihat Praktik terbaik.

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

Saat mengevaluasi performa, minimalkan pengujian siklus pendek karena Spanner membagi data Anda 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 bekerja dengan Spanner, tabel yang baru dibuat belum berkesempatan untuk menjalani pemisahan berbasis beban atau berbasis ukuran guna 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 uji performa berturut-turut), Anda dapat menjalankan kueri DELETE pada baris yang berisi data yang tidak lagi Anda perlukan. Dengan 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.

Pilih 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 Google Cloud dan white paper GDPR serta pilih konfigurasi regional Spanner yang benar.

Langkah berikutnya