Best practice per l'utilizzo di Cloud Spanner come database per i videogiochi

Questo documento descrive le best practice per l'utilizzo di Spanner come principale per l'archiviazione dello stato dei giochi. Puoi utilizzare Spanner al posto di database comuni per archiviare l'inventario e i dati di autenticazione dei giocatori e i dati di Google Cloud. Questo documento è destinato ai tecnici del backend di gioco che lavorano a lungo termine archiviazione dello stato nonché operatori e amministratori dell'infrastruttura di gioco che li supportano e sono interessati a ospitare il proprio database di backend in Google Cloud.

I giochi multiplayer e online si sono evoluti e ora richiedono una maggiore complessità strutture di database per il monitoraggio dei diritti dei giocatori, dello stato e dei dati di inventario. La crescita della base di giocatori e la complessità del gioco hanno portato alla creazione di database scalabili e gestibili, spesso richiedono l'utilizzo di partizionare o il clustering. Il monitoraggio di elementi in-game di valore o dei progressi critici dei giocatori in genere richiede transazioni ed è difficile da aggirare in molti tipi di o Microsoft SQL Server.

Spanner è il primo strumento scalabile di livello enterprise a livello globale un servizio di database distribuito e a elevata coerenza creato per il cloud combinare i vantaggi della struttura di database relazionale con una scala orizzontale. Molte società di videogiochi l'hanno trovata adatta a sostituire sia sui database di stato dei giochi sia di autenticazione nei sistemi di produzione. Tu scalare per ottenere ulteriori prestazioni o spazio di archiviazione utilizzando nella console Google Cloud per aggiungere nodi. Spanner può gestire in modo trasparente la replica globale con elevata coerenza, devi gestire le repliche a livello di regione.

Questo documento di best practice illustra i seguenti argomenti:

• Concetti importanti di Spanner e differenze rispetto comunemente usati nei giochi.
• Quando Spanner è il database giusto per il tuo gioco.
• Pattern da evitare quando si utilizza Spanner per i giochi.
• Progetta le operazioni di database con Spanner come nel database del gioco.
• Modellazione dei dati e creazione di uno schema per ottenere le prestazioni migliori con Spanner.

Terminologia

Diritti

Giochi, espansioni o acquisti in-app appartenenti a un giocatore.

Informazioni che consentono l'identificazione personale (PII)

Nei giochi, le informazioni che in genere includono indirizzo email e pagamento dati dell'account, quali il numero della carta di credito e l'indirizzo di fatturazione. Nel in alcuni mercati, queste informazioni potrebbero includere il numero del documento di identità.

Database di giochi (DB di gioco)

Un database contenente i progressi dei giocatori e l'inventario di un gioco.

Database di autenticazione (DB di autenticazione)

Un database che include i diritti dei giocatori e le PII che i giocatori da utilizzare per effettuare un acquisto. Il database di autenticazione è anche noto come database dell'account o player. A volte questo database viene combinato con il database di gioco, spesso vengono separati in studi cinematografici o editori che hanno titoli.

Transazione

Una transazione di database: un insieme di operazioni di scrittura con effetto tutto o niente. Se la transazione ha esito positivo e tutti gli aggiornamenti vengono applicati, oppure viene restituito a uno stato che non include nessuno degli aggiornamenti la transazione. Nei giochi, le transazioni dei database sono fondamentali quando durante l'elaborazione dei pagamenti e l'assegnazione della proprietà di preziose inventario o valuta.

Sistema di gestione di database relazionali (RDBMS)

Un sistema di database basato su tabelle e righe che fanno riferimento l'una all'altra. SQL Server, MySQL e (meno comunemente) Oracle® sono esempi di modelli usati nei giochi. Vengono utilizzati di frequente perché possono fornire metodologie familiari e forti garanzie per le transazioni.

Database NoSQL (DB NoSQL)

Database che non sono strutturati in modo relazionale. Questi database vengono diventando più popolare nei giochi perché offrono molta flessibilità quando cambia il modello dei dati. I database NoSQL includono MongoDB e Cassandra.

Chiave primaria

Di solito la colonna che contiene l'ID univoco degli elementi dell'inventario, del player e transazioni di acquisto.

Istanza

Un unico database. Ad esempio, un cluster esegue più copie software di database, ma appare come una singola istanza per il backend del gioco.

Nodo

Ai fini del presente documento, un'unica macchina che esegue una copia software di database.

Replica

Una seconda copia di un database. Le repliche vengono utilizzate di frequente per il recupero dei dati e l'alta disponibilità o per aumentare la velocità effettiva di lettura.

Cluster

Più copie del software in esecuzione su molte macchine che insieme come singola istanza al backend del gioco. Il clustering è utilizzato scalabilità e disponibilità.

Shard

Un'istanza di un database. Molte case di produzione giochi eseguono diverse istanze di database omogenee, ognuna delle quali contiene un sottoinsieme del gioco e i dati di Google Cloud. Ognuna di queste istanze è comunemente definita shard. Lo sharding viene in genere eseguito per le prestazioni o la scalabilità, sacrificando l'efficienza nella gestione e l'aumento della complessità delle app. Lo sharding in Spanner viene implementato utilizzando split.

Suddividi

Spanner suddivide i dati in blocchi denominati divisioni, dove le singole i segmenti possono spostarsi in modo indipendente l'uno dall'altro e vengono assegnati server diversi. Una divisione è definito come un intervallo di righe in una riga di primo livello (in altre parole, senza interleaving), in cui le righe sono ordinate in base alla chiave primaria. La le chiavi di inizio e fine di questo intervallo sono denominate "confini della suddivisione". Spanner aggiunge e rimuove automaticamente confini della suddivisione, che cambia il numero di suddivisioni nel database. Spanner Suddivide i dati in base al carico: aggiunge automaticamente dei confini della suddivisione quando rileva un'elevata diffusione del carico di lettura o scrittura tra molte chiavi in una suddivisione.

Hotspot

Quando una singola suddivisione in un database distribuito come Spanner contiene record che ricevono una gran parte di tutte le query per configurare un database. Questo scenario non è consigliabile perché le prestazioni peggiorano.

Utilizzo di Spanner per i giochi

Nella maggior parte dei casi in cui prendi in considerazione un RDBMS per il tuo gioco, Spanner è una scelta appropriata perché può efficacemente sostituire il database di gioco, il database di autenticazione o, in molti casi, entrambi.

Database di gioco

Spanner può operare come un'unica piattaforma autorevole, il che lo rende un ottimo abbinamento per i sistemi di inventario dei giochi. Qualsiasi valuta o articolo in-game che può essere scambiato, venduto, regalato o in altro modo il trasferimento da un giocatore all'altro rappresenta una sfida in un gioco su larga scala di backend. Spesso, la popolarità di un gioco può superare quella di un database tradizionale la capacità di gestire tutto in un database a nodo singolo. In base al tipo di al gioco, il database può avere difficoltà con il numero di operazioni necessarie sia il caricamento del player sia la quantità di dati archiviati. Spesso è il primo passo agli sviluppatori di eseguire lo sharding del loro database per migliorare le prestazioni o in continua crescita. Questo tipo di soluzione porta alla complessità operativa in termini di costi di manutenzione.

Per aiutare a mitigare questa complessità, una strategia comune è eseguire completamente regioni di gioco separate e non è possibile spostare dati da una all'altra. In questo caso, gli elementi e valuta non possono essere scambiati tra giocatori di regioni di gioco diverse, gli inventari in ogni regione sono separati in database separati. Tuttavia, questo di sviluppo sacrifica l'esperienza preferita del giocatore, in favore dello sviluppatore e e semplicità operativa.

D'altra parte, puoi consentire le compravendita tra regioni in una regione con sharding, ma spesso a un costo di complessità elevato. Questa configurazione richiede su più istanze di database, il che genera un processo complesso e soggetto a errori la logica lato applicazione. Tentativo di ottenere blocchi delle transazioni su più database può avere un impatto significativo sulle prestazioni. Inoltre, non poter fare affidamento transazioni atomiche possono portare a exploit dei giocatori come la valuta in-game o la duplicazione di articoli, danneggiare l'ecosistema e la community del gioco.

Spanner può semplificare l'approccio all'inventario e alla valuta transazioni. Anche quando usi Spanner per archiviare tutto il gioco di dati di tutto il mondo, offre transazioni di lettura/scrittura con più potente rispetto ai tradizionali componenti di atomicità, coerenza, isolamento e durabilità (ACID) proprietà. Con la scalabilità di Spanner, significa che i dati non richiede lo sharding in istanze di database separate quando le prestazioni o l'archiviazione necessarie; puoi invece aggiungere altri nodi. Inoltre, l'alta disponibilità e la resilienza dei dati per cui i giochi spesso nel cluster, i cui database sono gestiti in modo trasparente da Spanner, non richiedono alcuna configurazione o gestione aggiuntiva.

Database autorizzazioni

I database di autenticazione possono essere gestiti bene anche da Spanner, soprattutto se vuoi standardizzare su un singolo RDBMS a livello di studio o publisher. Sebbene i database di autenticazione per i giochi spesso non richiedano la scalabilità Spanner, le garanzie transazionali e l'alta disponibilità dei dati può renderlo convincente. La replica dei dati in Spanner è trasparente, sincrona e integrata. Spanner ha configurazioni che offrono 99,99% ("quattro nove") o 99,999% ("cinque nove") di disponibilità, con "cinque nove" corrispondenti a meno di cinque minuti e mezzo di indisponibilità da un anno. Questo tipo di disponibilità lo rende una buona scelta il percorso di autenticazione critico richiesto all'inizio di ogni player durante la sessione.

Best practice

Questa sezione fornisce suggerimenti su come utilizzare Spanner la progettazione del gioco. È importante modellare i dati di gioco per trarre vantaggio le funzionalità uniche offerte da Spanner. Anche se puoi accedere Spanner usando la semantica del database relazionale, alcuni schemi i punti di progettazione possono aiutarti ad aumentare le tue prestazioni. Spanner la documentazione consigli dettagliati sulla progettazione dello schema che puoi esaminare, ma le seguenti sezioni sono alcune best practice per i giochi database.

Le procedure illustrate in questo documento si basano sulle esperienze sull'utilizzo dei clienti e sui case study.

Utilizza gli UUID come ID player e carattere

Nella tabella dei giocatori in genere è presente una riga per ogni giocatore e il relativo in-game valuta, avanzamento o altri dati difficilmente mappabili a inventario discreto righe della tabella. Se il gioco consente ai giocatori di avere a disposizione i progressi salvati separati per diversi personaggi, come molti grandi giochi multiplayer di massa permanenti, questa tabella in genere contiene invece una riga per ogni carattere. Lo schema in tutti gli altri casi è lo stesso.

Ti consigliamo di utilizzare un carattere o un identificatore giocatore (carattere) univoco globale ID) come chiave primaria della tabella di caratteri. Ti consigliamo inoltre di utilizzare UUID (Universally Unique Identifier) v4, perché distribuisce i dati dei giocatori tra i nodi DB e può aiutarti a ottenere delle prestazioni grazie a Spanner.

Utilizzare l'interfoliazione per le tabelle dell'inventario

La tabella dell'inventario contiene spesso articoli in-game, come l'equipaggiamento dei personaggi, carte o unità. In genere, un singolo giocatore ha molti elementi nel suo inventario. Ogni elemento è rappresentato da una singola riga nella tabella.

Analogamente ad altri database relazionali, una tabella di inventario Spanner ha una chiave primaria che è un identificatore univoco globale dell'elemento, come illustrato nella tabella seguente.

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

Nella tabella dell'inventario di esempio, i valori itemID e playerID sono troncati per la leggibilità. Una tabella di inventario effettiva conterrà anche molte altre colonne che non sono inclusi nell'esempio.

Un approccio tipico in un RDBMS per il monitoraggio della proprietà degli elementi consiste nell'utilizzare una colonna come chiave esterna contenente l'ID giocatore dell'attuale proprietario. Questa colonna indica chiave primaria di una tabella di database separata. In Spanner, puoi utilizzare interleaving, che memorizza le righe dell'inventario vicino alla riga della tabella dei giocatori associata per migliorare delle prestazioni. Quando utilizzi le tabelle con interleaving, tieni presente quanto segue:

• Non puoi generare un oggetto senza un proprietario. Puoi evitare l'assenza di proprietario a condizione che la limitazione sia nota in anticipo.

Progetta l'indicizzazione per evitare gli hotspot

Molti sviluppatori di giochi implementano indici in molti campi dell'inventario per ottimizzare determinate query. In Spanner, la creazione o l'aggiornamento di una riga contenente dati nell'indice genera scritture aggiuntive carico proporzionale al numero di colonne indicizzate. Puoi migliorare Prestazioni di Spanner eliminando gli indici che non vengono utilizzati frequentemente o implementando questi indici in altri modi che non influiscono sulle prestazioni del database.

Nell'esempio seguente, è presente una tabella per i punteggi migliori dei giocatori a lungo termine. record:

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

Questa tabella contiene l'ID player (UUIDv4), un numero che rappresenta un modalità di gioco, fase o stagione e il punteggio del giocatore.

Nota: l'archiviazione dei punteggi dei giocatori nel database, come mostrato in questo esempio, non è una l'approccio più adatto per mantenere le classifiche dal vivo aggiornate di frequente. Per in questo caso d'uso consigliamo un'implementazione in memoria utilizzando Redis, e salvando periodicamente i punteggi migliori nell'archiviazione a lungo termine, se necessario.

Per velocizzare le query che filtrano per la modalità di gioco, considera la classe seguente indice:

CREATE INDEX idx_score_ranking ON Ranking (
        GameMode,
        Score DESC
)

Se tutti utilizzano la stessa modalità di gioco chiamata 1, questo indice crea un hotspot dove GameMode=1. Se vuoi ottenere una classifica per questa modalità di gioco, l'indice analizza solo le righe contenenti GameMode=1, restituendo rapidamente il ranking.

Se modifichi l'ordine dell'indice precedente, puoi risolvere questo hotspot problema:

CREATE INDEX idx_score_ranking ON Ranking (
        Score DESC,
        GameMode
)

Questo indice non creerà un hotspot significativo da parte dei giocatori che competono nel stessa modalità di gioco, a condizione che i punteggi siano distribuiti tra le possibili intervallo. Tuttavia, ottenere i punteggi non sarà veloce come con l'indice precedente poiché la query analizza tutti i punteggi in tutte le modalità per determinare se GameMode=1.

Di conseguenza, l'indice riordinato risolve l'hotspot precedente in modalità di gioco, ma ha ancora margini di miglioramento, come illustrato nella struttura che segue.

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

CREATE INDEX idx_score_ranking ON Ranking (
        Score DESC
)

Ti consigliamo di rimuovere la modalità di gioco dallo schema della tabella e di utilizzare una sola tabella per modalità, se possibile. Utilizzando questo metodo, quando recuperi i punteggi per un esegui una query solo su una tabella con i punteggi per quella modalità. Questa tabella può essere indicizzato dal punteggio per il rapido recupero di intervalli di punteggi senza un pericolo significativo di hotspot (a condizione che i punteggi siano ben distribuiti). Al momento della stesura di questo documento, il numero massimo di tabelle per database in Spanner è 2560, più che sufficiente per la maggior parte dei giochi.

Database separati per tenant

A differenza di altri carichi di lavoro, in cui consigliare la progettazione per l'architettura multi-tenancy in Spanner utilizzando coppie chiave-valore primarie diverse; per i dati relativi ai giochi, consigliamo approccio convenzionale di database separati per tenant. Le modifiche allo schema sono comuni con il rilascio di nuove funzionalità dei giochi nel servizio live e l'isolamento dei tenant a livello di database può semplificare gli aggiornamenti dello schema. Questa strategia consente anche di ottimizzare il tempo necessario per eseguire il backup o il ripristino di un del tenant, poiché queste operazioni vengono eseguite su un intero database una volta sola.

Evita gli aggiornamenti incrementali dello schema

A differenza di alcuni database relazionali convenzionali, Spanner rimane operativo durante gli aggiornamenti dello schema. Tutte le query sullo schema precedente vengono (anche se potrebbero essere restituiti meno rapidamente del solito) e le query rispetto al nuovo schema vengono restituiti man mano che diventano disponibili. Puoi progettare il processo di aggiornamento per mantenere il gioco in esecuzione durante gli aggiornamenti dello schema quando è in esecuzione Spanner, purché tu tenga a mente i vincoli precedenti.

Se però richiedi un'altra modifica dello schema mentre ne esiste una nuova elaborato, il nuovo aggiornamento viene messo in coda e non avrà luogo fino a Gli aggiornamenti dello schema sono stati completati. Puoi evitare questa situazione pianificando una pianificazione più ampia aggiornamenti dello schema, invece di inviare molti aggiornamenti incrementali dello schema in un breve punto. Per ulteriori informazioni sugli aggiornamenti dello schema, incluso come eseguire una aggiornamento dello schema che richiede la convalida dei dati, vedi Documentazione sull'aggiornamento dello schema di Spanner

Valuta l'accesso e le dimensioni del database

Quando sviluppi il tuo server di gioco e i servizi della piattaforma da utilizzare Spanner, considera come il gioco accede al database e come dimensioni del database per evitare costi inutili.

Usa driver e librerie integrati

Quando sviluppi in base a Spanner, considera come il codice si interfaccia con il database. Spanner offre librerie client integrate per molti linguaggi diffusi, che sono in genere ricchi di funzionalità e performanti. Sono disponibili anche driver JDBC che supportano DML (Data Manipulation Language) e DDL (Data Definition Language). Nei casi in cui Spanner utilizzate nel nuovo sviluppo, consigliamo di usare le librerie client di Cloud Spanner. Sebbene le tipiche integrazioni di motore grafico non molta flessibilità nella selezione della lingua, per i servizi di piattaforma che accedono Spanner, ci sono casi di clienti di videogiochi che usano Java o Go. Per applicazioni ad alta velocità effettiva, seleziona una libreria in cui sia possibile utilizzare lo stesso client Spanner per più richieste sequenziali.

Dimensiona il database in base alle esigenze di test e produzione

Durante lo sviluppo, è probabile che un'istanza Spanner a nodo singolo sufficiente per la maggior parte delle attività, inclusi i test funzionali.

Avviso: non è consigliabile utilizzare un'istanza con nodo singolo in un ambiente di produzione con giocatori dal vivo. Prima di inserire il traffico in tempo reale in un ambiente di produzione, consulta nella sezione su Considerazioni sulle dimensioni per la produzione.

Valuta le esigenze di Spanner per la produzione

Quando passi dallo sviluppo al test e poi alla produzione, è importante rivalutare Spanner per assicurare che può gestire il traffico di giocatori live.

Prima di passare alla produzione, i test di carico sono fondamentali per verificare di un backend è in grado di gestire il carico durante la produzione. Consigliamo di eseguire test di carico con il doppio del carico previsto in produzione per prepararti ai picchi e nei casi in cui il tuo gioco è più popolare del previsto.

Esegui test di carico utilizzando dati reali

L'esecuzione di un test di carico con dati sintetici non è sufficiente. Dovresti anche eseguire test di carico utilizzando dati e pattern di accesso il più vicino possibile a ciò che ci si aspetta in produzione. I dati sintetici potrebbero non rilevare potenziali hotspot la progettazione dello schema Spanner. Non c'è niente di meglio che eseguire una versione beta test (aperto o chiuso) con giocatori reali per verificare come Spanner utilizza dati reali.

Il seguente diagramma è un esempio di schema di una tabella dei giocatori di uno studio di giochi che illustra l'importanza di utilizzare i beta test per i test di carico.

Lo studio ha preparato questi dati in base alle tendenze di un gioco precedente che aveva per un paio d'anni. L'azienda si aspettava che lo schema rappresentasse in questa nuova partita.

Ogni record di un giocatore è associato ad alcuni attributi numerici che tiene traccia dei progressi del giocatore nel gioco (come livello e tempo di gioco). Per attributo di esempio utilizzato nella tabella precedente, ai nuovi player viene assegnato un 50, che diventa poi un valore compreso tra 1 e 100 come che il giocatore avanza.

Lo studio vuole indicizzare questo attributo per velocizzare le query importanti durante il gameplay.

In base a questi dati, lo studio ha creato quanto segue: Tabella Spanner con una chiave primaria che utilizza PlayerID e un oggetto indice secondario su Attribute.

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

CREATE INDEX idx_attribute ON Player(Attribute)

E l'indice è stato sottoposto a query per trovare fino a dieci giocatori con Attribute=23, nel seguente modo:

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

In base alla documentazione sull'ottimizzazione della progettazione dello schema, Spanner Archivia i dati di indice come le tabelle, con una riga per voce di indice. Nei test di carico, questo modello esegue un job accettabile di distribuzione dell'oggetto secondario dell'indice, in lettura e scrittura, su più suddivisioni di Spanner, illustrato nel seguente diagramma:

Sebbene i dati sintetici utilizzati nel test di carico siano simili alla stabilità finale stato del gioco in cui i valori di Attribute sono ben distribuiti, il gioco il design richiede che tutti i giocatori inizino con Attribute=50. Poiché ogni nuovo giocatore inizia con Attribute=50, quando si uniscono nuovi giocatori vengono inseriti la stessa parte dell'indice secondario idx_attribute. Ciò significa che gli aggiornamenti instradato alla stessa suddivisione Spanner, causando un hotspot durante finestra di avvio del gioco. Si tratta di un uso non efficiente di Spanner.

Nel diagramma seguente, l'aggiunta di una colonna IndexPartition allo schema dopo il lancio risolve il problema dell'hotspot e i player vengono distribuiti uniformemente le suddivisioni Spanner disponibili. Il comando aggiornato per la creazione la tabella e l'indice hanno il seguente aspetto:

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)

Il valore IndexPartition deve avere un intervallo limitato per eseguire query efficienti. ma dovrebbe anche avere un intervallo che sia almeno il doppio del numero di suddivisioni per una distribuzione efficiente.

In questo caso, lo studio ha assegnato manualmente a ogni giocatore un IndexPartition tra 1 e 6 nell'applicazione di gioco.

Metodi alternativi potrebbero essere l'assegnazione di un numero casuale a ciascun giocatore, oppure assegnando un valore derivato da un hash al valore PlayerID. Consulta Cosa devono sapere i database su Spanner, parte 1: chiavi e indici per altre strategie dello sharding a livello di applicazione.

L'aggiornamento della query precedente per utilizzare questo indice migliorato ha il seguente aspetto:

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

Poiché non è stato eseguito alcun beta test, lo studio non si è reso conto che stava eseguendo il test utilizzando dati con ipotesi errate. Sebbene i test di carico sintetico siano una buona per convalidare il numero query al secondo (QPS) che l'istanza è in grado di gestire, è necessario un beta test con giocatori reali per convalidare lo schema e prepara un lancio di successo.

Dimensionare l'ambiente di produzione per anticipare il picco della domanda

I giochi principali spesso registrano un picco di traffico al momento del lancio. Creazione di un e scalabile, non solo si applica servizi della piattaforma e server di gioco dedicati, ma anche ai database. L'utilizzo di soluzioni Google Cloud come App Engine, puoi creare servizi API frontend con possibilità di scale up rapidi. Anche se Spanner offre la flessibilità di aggiungere e rimuovere nodi online, non è un database con scalabilità automatica. Devi eseguire il provisioning di un numero di nodi sufficiente a gestire un picco di traffico al momento del lancio.

In base ai dati raccolti durante i test di carico o da qualsiasi versione beta pubblica Test, puoi stimare il numero di nodi necessari per gestire le richieste avviare l'applicazione. È buona norma aggiungere alcuni nodi come buffer nel caso in cui del previsto. Devi sempre dimensionare il database in base a di oltre il 65% di utilizzo medio della CPU.

Riscalda il database prima del lancio del gioco

Prima di lanciare il gioco, ti consigliamo di preparare il tuo database per delle funzionalità di parallelizzazione di Spanner. Per ulteriori informazioni, consulta Riscaldamento del database prima dell'avvio dell'applicazione.

Monitorare e comprendere il rendimento

Qualsiasi database di produzione richiede un monitoraggio e prestazioni complete metrics. Spanner include metriche integrate in Cloud Monitoring. Ove possibile, consigliamo di incorporare le librerie gRPC fornite il processo di backend del gioco, perché queste librerie includono Tracciamento di OpenCensus. Il tracciamento OpenCensus consente di visualizzare le tracce delle query in Cloud Trace e altri strumenti di tracciamento open source supportati.

In Cloud Monitoring puoi visualizzare i dettagli Utilizzo di Spanner, inclusi l'utilizzo della CPU e dell'archiviazione dei dati. Per la maggior parte personalizzati, consigliamo di basare le decisioni di scalabilità di Spanner su questa metrica di utilizzo della CPU o sulla latenza osservata. Per ulteriori informazioni consigliato l'utilizzo della CPU per prestazioni ottimizzate, consulta Best practice.

Offerte Spanner piani di esecuzione delle query. Puoi rivedere questi piani nella console Google Cloud, e contatta l'assistenza se hai bisogno di aiuto per comprendere le prestazioni delle query.

Quando valuti il rendimento, mantieni al minimo i test del ciclo breve perché Spanner suddivide i dati in background in modo trasparente per ottimizzare le prestazioni in base ai pattern di accesso ai dati. Dovresti valutare le prestazioni grazie a carichi di query realistici e sostenuti.

Quando rimuovi i dati, elimina le righe anziché creare nuovamente le tabelle

Quando lavori con Spanner, le tabelle appena create non hanno hanno ancora avuto l'opportunità di essere sottoposti a una suddivisione basata sul carico o sulle dimensioni per migliorare delle prestazioni. Quando elimini i dati eliminando una tabella e poi ricreandola, Spanner ha bisogno di dati, query e tempo per determinare la soluzione corretta i segmenti per la tabella. Se hai intenzione di ricompilare una tabella con lo stesso tipo di dati (ad esempio, quando si eseguono test del rendimento consecutivi), è possibile esegui invece una query DELETE sulle righe contenenti i dati che non ti servono più. Per per lo stesso motivo, gli aggiornamenti dello schema devono utilizzare l'API Cloud Spanner fornita e dovrebbe evitare una strategia manuale, come la creazione di una nuova tabella e la copia i dati di un'altra tabella o di un file di backup.

Seleziona una località dei dati per soddisfare i requisiti di conformità

Molti giochi devono rispettare Leggi sulla località dei dati come il GDPR quando suonato in tutto il mondo. Per supportare le tue esigenze relative al GDPR, consulta le White paper su Google Cloud e GDPR e seleziona il token Configurazione regionale di Spanner.

Passaggi successivi

• Scopri come Bandai Namco Entertainment ha utilizzato Spanner nel lancio di Dragon Ball Legends.
• Guarda la sessione Cloud Next '18 su Ottimizzazione di applicazioni, schemi e progettazione di query su Spanner
• Leggi la nostra guida su Migrazione da DynamoDB a Spanner.