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 database di backend principale per l'archiviazione dello stato dei giochi. Puoi utilizzare la modalità 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 fino a richiedere strutture di database sempre più complesse per monitorare i diritti, lo stato e i dati di inventario dei giocatori. La crescita della base di giocatori e la crescente complessità dei giochi hanno portato a soluzioni di database difficili da scalare e gestire, che spesso richiedono l'utilizzo di sharding o clustering. Il monitoraggio di oggetti in-game di valore o dell'avanzamento critico del giocatore in genere richiede transazioni ed è difficile aggirare il problema in molti tipi di database distribuiti.

Spanner è il primo servizio di database scalabile di livello enterprise a elevata coerenza distribuito su scala globale, espressamente concepito per il cloud allo scopo di combinare i vantaggi della struttura dei database relazionali con la scalabilità orizzontale non relazionale. Molte aziende di giochi lo hanno trovato adatto a sostituire sia i database di stato del gioco sia quelli 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 sulle best practice illustra quanto segue:

• Concetti importanti di Spanner e differenze 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, informazioni che in genere includono indirizzo email e dati dell'account di pagamento, ad esempio un numero di carta di credito e l'indirizzo di fatturazione. Nella in alcuni mercati, queste informazioni potrebbero includere il numero del documento di identità.

Database di giochi (DB di giochi)

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 DB auth è noto anche come DB account o DB 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 che hanno un effetto tutto o niente. La transazione riesce e tutti gli aggiornamenti vengono applicati oppure il database viene riportato a uno stato che non include nessuno degli aggiornamenti della transazione. Nei giochi, le transazioni di database sono più importanti durante l'elaborazione dei pagamenti e l'assegnazione della proprietà di inventario o valuta in-game di valore.

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 database relazionali utilizzati 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

In genere, la colonna che contiene l'ID univoco per gli articoli di inventario, gli account dei giocatori e le transazioni di acquisto.

Istanza

Un singolo 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 contribuire ad 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 viene utilizzato per la scalabilità e la 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 solitamente eseguito per migliorare le prestazioni o la scalabilità, sacrificando l'efficienza della gestione e aumentando la complessità dell'app. Lo sharding in Spanner viene implementato utilizzando le suddivisioni.

Suddividi

Spanner suddivide i dati in blocchi chiamati split, in cui i singoli split possono spostarsi indipendentemente l'uno dall'altro e essere assegnati a 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 per chiave primaria. La le chiavi di inizio e fine di questo intervallo sono chiamate "confini della suddivisione". Spanner aggiunge e rimuove automaticamente i confini di partizione, modificando 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 grande parte di tutte le query inviate al database. Questo scenario è indesiderato perché le prestazioni peggiora.

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, perciò si tratta di un prodotto adatto eccezionale per i sistemi di inventario dei giochi. Qualsiasi moneta o articolo in-game che può essere scambiato, venduto, regalato o comunque trasferito da un giocatore all'altro rappresenta una sfida per i backend dei giochi su larga scala. Spesso, la popolarità di un gioco può superare quella di un database tradizionale di gestire tutto in un database a nodo singolo. A seconda del tipo di gioco, il database può avere difficoltà con il numero di operazioni necessarie per gestire il carico dei giocatori e la quantità di dati archiviati. Spesso, gli sviluppatori di giochi scelgono di suddividere il database per migliorare le prestazioni o per archiviare tabelle in continua crescita. Questo tipo di soluzione comporta complessità operativa e un elevato overhead di manutenzione.

Per contribuire ad attenuare questa complessità, una strategia comune è eseguire regioni di gioco completamente separate senza alcun modo per spostare i dati da una all'altra. In questo caso, gli oggetti e la valuta non possono essere scambiati tra giocatori di regioni di gioco diverse, perché gli inventari di ogni regione sono suddivisi in database distinti. Tuttavia, questo di sviluppo sacrifica l'esperienza preferita del giocatore, in favore dello sviluppatore e e semplicità operativa.

D'altra parte, puoi consentire scambi tra regioni in un database suddiviso geograficamente, ma spesso a un costo di complessità elevato. Questa configurazione richiede che le transazioni si estendano a più istanze di database, il che comporta una logica lato applicazione complessa e soggetta a errori. 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 atomi di atomicità, coerenza, isolamento e durabilità (ACID) proprietà. Grazie alla scalabilità di Spanner, i dati non devono essere suddivisi in istanze di database separate quando è necessario un maggiore rendimento o spazio di archiviazione. 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 un singolo RDBMS a livello di studio o publisher. Sebbene i database di autenticazione per i giochi spesso non richiedano la scalabilità di Spanner, le garanzie transazionali e l'elevata disponibilità dei dati possono renderlo interessante. 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" che corrispondono a meno di cinque minuti e mezzo di mancata disponibilità in un anno. Questo tipo di disponibilità lo rende una buona scelta per il percorso di autenticazione critico richiesto all'inizio di ogni sessione del player.

Best practice

Questa sezione fornisce consigli su come utilizzare Spanner nel design dei giochi. È importante modellare i dati del 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 altrimenti è lo stesso.

Ti consigliamo di utilizzare un carattere o un identificatore giocatore (carattere) univoco a livello 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'interlacciamento per le tabelle di inventario

La tabella dell'inventario contiene spesso gli articoli in-game, come attrezzature, carte o unità dei personaggi. 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 di inventario di esempio, itemID e playerID sono troncati per migliorare 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 il separazione in file, che memorizza le righe di inventario vicino alla riga della tabella dei giocatori associata per migliorare le prestazioni. Quando utilizzi tabelle interlacciate, tieni presente quanto segue:

• Non puoi generare un oggetto senza un proprietario. Puoi evitare oggetti senza proprietario nel design del gioco, a condizione che la limitazione sia nota in anticipo.

Progetta l'indicizzazione per evitare gli hotspot

Molti sviluppatori di giochi implementano indici in molti dei campi dell'inventario per ottimizzare determinate query. In Spanner, la creazione o l'aggiornamento di una riga con dati contenuti in quell'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 giocatore (UUIDv4), un numero che rappresenta una modalità di gioco, una fase o una stagione e il punteggio del giocatore.

Nota: memorizzare i punteggi dei giocatori nel database come mostrato in questo esempio non è un approccio adatto per mantenere una classifica in tempo reale aggiornata di frequente. Per questo caso d'uso, consigliamo un'implementazione in memoria che utilizzi Redis e, se necessario, il salvataggio periodico dei punteggi elevati in uno spazio di archiviazione a lungo termine.

Per velocizzare le query che filtrano in base alla modalità di gioco, valuta il seguente indice:

CREATE INDEX idx_score_ranking ON Ranking (
        GameMode,
        Score DESC
)

Se tutti giocano alla stessa modalità di gioco chiamata 1, questo indice crea un hotspot dove GameMode=1. Se vuoi ottenere un ranking per questa modalità di gioco, l'indice esamina 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 per i giocatori che gareggiano nella stessa modalità di gioco, a condizione che i loro punteggi siano distribuiti nell'intervallo possibile. 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 spostare la modalità di gioco dallo schema della tabella e di utilizzare una tabella per modalità, se possibile. Se utilizzi questo metodo, quando recuperi i punteggi per una modalità, esegui una query solo su una tabella contenente i punteggi per quella modalità. Questa tabella può essere indicizzato dal punteggio per un 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 può anche ottimizzare il tempo necessario per eseguire il backup o il ripristino dei dati di un tenant, poiché queste operazioni vengono eseguite contemporaneamente su un intero database.

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.

Tuttavia, se richiedi un'altra modifica dello schema mentre ne è in corso una, il nuovo aggiornamento viene messo in coda e non verrà eseguito finché non saranno stati completati tutti gli aggiornamenti dello schema precedenti. 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

Considera 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.

Utilizzare driver e librerie integrati

Quando sviluppi per Spanner, tieni conto di come il codice interagisce 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 le istruzioni DML (Data Manipulation Language) e DDL (Data Definition Language). Nei casi in cui Spanner utilizzate nel nuovo sviluppo, consigliamo di utilizzare le librerie client di Cloud Spanner. Sebbene le tipiche integrazioni di motore grafico non molta flessibilità nella scelta della lingua, per i servizi di piattaforma che accedono Spanner, ci sono casi di clienti di videogiochi che usano Java o Go. Per le applicazioni a velocità effettiva elevata, 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 un solo nodo sia sufficiente per la maggior parte delle attività, inclusi i test funzionali.

Avviso: sconsigliamo un'istanza a un solo nodo in un ambiente di produzione con giocatori in tempo reale. Prima di inserire il traffico in tempo reale in un ambiente di produzione, consulta la sezione relativa alle considerazioni relative alle 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. Ti consigliamo di eseguire test di carico con il doppio del carico previsto in produzione per prepararti agli picchi di utilizzo e ai casi in cui il tuo gioco è più popolare del previsto.

Esegui test di carico utilizzando dati reali

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 un test beta (aperto o chiuso) con utenti reali per verificare il comportamento di Spanner con 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 bene i dati di questo nuovo gioco.

A ogni record del giocatore sono associati alcuni attributi numerici che monitorano i progressi del giocatore nel gioco (ad esempio il ranking e il 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 utilizzo inefficiente 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 della tabella e dell'indice è il seguente:

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 query efficienti, ma deve anche avere un intervallo almeno doppio rispetto al 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 Informazioni che i DBA devono conoscere su Spanner, parte 1: chiavi e indici per scoprire di più sulle strategie di sharding a livello di applicazione.

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

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 di eseguire 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 più importanti spesso registrano il picco di traffico al momento del lancio. Creazione di un il backend scalabile non si applica solo ai servizi di piattaforma e ai giochi ma anche ai database. L'utilizzo di soluzioni Google Cloud come App Engine, puoi creare servizi API frontend che possono fare rapidamente lo scale up. 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 tu abbia più giocatori 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 Eseguire l'inizializzazione del database prima del lancio dell'applicazione.

Monitorare e comprendere il rendimento

Qualsiasi database di produzione richiede metriche complete di monitoraggio e prestazioni. 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 monitoraggio OpenCensus ti consente di visualizzare le tracce delle query in Cloud Trace, nonché altri strumenti di monitoraggio 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 utilizzo della CPU suggerito per prestazioni ottimizzate, consulta Best practice.

Spanner offre piani di esecuzione delle query. Puoi esaminare questi piani nella console Google Cloud e contattare l'assistenza se hai bisogno di aiuto per comprendere il rendimento delle query.

Quando valuti le prestazioni, riduci al minimo i test a ciclo breve perché Spanner suddivide in modo trasparente i dati dietro le quinte 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é ricreare 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 le prestazioni dei dispositivi. 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 prevedi di rieseguire il popolamento di una tabella con lo stesso tipo di dati (ad esempio quando esegui test di rendimento consecutivi), puoi eseguire una query DELETE sulle righe contenenti i dati che non ti servono più. Per lo stesso motivo, gli aggiornamenti dello schema devono utilizzare l'API Cloud Spanner fornita ed evitare una strategia manuale, come la creazione di una nuova tabella e la copia dei dati da un'altra tabella o da 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 di Cloud Next '18 su Ottimizzazione di applicazioni, schemi e progettazione delle query su Spanner.
• Leggi la nostra guida sulla migrazione da DynamoDB a Spanner.