Migliori pratiche per i data store

Usa queste pratiche per organizzare e gestire dati affidabili, scalabili e osservabili durante il loro ciclo di vita.

Organizza i tuoi dati

Crea meno data store

I data store si comportano in modo simile alle tabelle nei database. Usa un piccolo e fisso insieme di data store e organizza i record al loro interno per chiave. Ad esempio, memorizza il profilo di ogni giocatore in un unico data store PlayerData invece di creare un data store per ogni giocatore.

Usa una o poche chiavi per giocatore

Memorizza i dati persistenti per ogni giocatore sotto una chiave ogni volta che i dati rientrano nel limite di dimensione dell'oggetto di 4 MB. Ad esempio, usa una chiave come User_123456 nel data store PlayerData. Questo schema riduce le richieste, ti consente di aggiornare valori correlati in modo atomico e rende più facili i rollback.

Se diverse parti dei dati di un giocatore hanno modelli di accesso diversi o si avvicinano ai limiti di dimensione o throughput per chiave, suddividi il record in un numero ridotto di chiavi deterministiche. Mantieni i dati che devono cambiare in modo atomico nella stessa chiave.

Usa modelli e prefissi di chiave statici

Costruisci i nomi delle chiavi da identificatori stabili e modelli statici, come User_{UserId}. Non usare nomi visualizzati o altri valori che possono cambiare. I modelli statici rendono le chiavi prevedibili tra server e strumenti. Per i data store, consentono anche di identificare i dati dei giocatori per il trattamento automatizzato del diritto all'oblio.

Usa prefissi per raggruppare chiavi correlate. Ad esempio, un'esperienza che supporta più profili di personaggi potrebbe usare User_123456/Profile/Warrior e User_123456/Profile/Mage. Puoi quindi passare User_123456/Profile a ListKeysAsync() per elencare i profili di quel giocatore.

Scopes sono un altro modo per suddividere un data store. Uno scope premette una stringa a ogni chiave in quell'istanza di data store, e il valore predefinito è global.

Valuta i moduli di data store

I moduli di data store di terze parti sono sempre un'opzione e, in molti casi, possono essere preferiti alla costruzione di sistemi da zero. Prima di adottarne uno, rivedi la sua proprietà, stato di manutenzione e set di funzionalità. Comprendi come accedere e migrare i tuoi dati senza il modulo.

Riduci e distribuisci le richieste

Bufferizza i dati dei giocatori in memoria

Carica i dati di un giocatore all'inizio di una sessione e mantieni una copia locale del server per il gameplay. Aggiorna la copia locale invece di inviare una richiesta al data store per ogni cambiamento. Salvala periodicamente, quando il giocatore esce, quando il server si spegne e in punti critici come l'elaborazione degli acquisti. Scegli un intervallo di salvataggio periodico che rimanga entro i tuoi limiti di richiesta e sia più breve di qualsiasi scadenza di blocco della sessione; il campione di dati dei giocatori e acquisti utilizza 180 secondi.

Scaglionare le richieste ricorrenti

Non avviare richieste ricorrenti da ogni server secondo lo stesso programma. Prima di avviare un ciclo a frequenza fissa, assegna a ciascun server o giocatore un offset iniziale casuale. Per i cicli di polling o coordinamento che non richiedono una cadenza esatta, aggiungi jitter casuale limitato a ciascun intervallo. Questi schemi distribuiscono le richieste nel tempo e riducono i picchi di traffico sincronizzati.

Ritenta in caso di errori transitori

Avvolgi le richieste in pcall() e ritenta gli errori transitori con un backoff esponenziale. Aggiungi jitter casuale a ciascun ritardo in modo che i server non ritentano simultaneamente. Limita il ritardo e il numero di tentativi e non ritentare errori causati da richieste non valide o operazioni che non possono più fornire risultati utili.

Elabora i ritentativi del data store in ordine per ciascuna chiave. Una richiesta più vecchia che ritenta dopo che una richiesta più recente ha avuto successo può sovrascrivere dati più recenti. Tieni anche conto delle scritture con esiti sconosciuti: una chiamata fallita significa che il server non ha ricevuto una risposta positiva, ma il backend potrebbe aver completato la scrittura. Per ulteriori informazioni, consulta Codici di errore e limiti del data store e Ritenti.

Preferisci UpdateAsync rispetto a SetAsync

Preferisci UpdateAsync() quando una scrittura dipende dal valore attuale o quando più server potrebbero scrivere la stessa chiave. UpdateAsync() legge l'ultimo valore nel tuo callback prima di scrivere, il che riduce le perdite di aggiornamenti. SetAsync() sovrascrive la chiave senza leggere prima e può causare incoerenza se due server scrivono contemporaneamente.

Usa SetAsync() quando crei una nuova chiave o sostituisci un valore che non dipende dal valore precedente. Per un confronto tra i due metodi, consulta Set vs update.

Suddividi le chiavi calde

Ogni chiave ha limiti di throughput di lettura e scrittura. Se un record logico raggiunge costantemente questi limiti dopo aver ridotto le richieste non necessarie, suddividilo tra chiavi deterministiche. Scegli uno shard stabile da un identificatore, come User_{UserId}_Inventory_{ShardId}, in modo che ogni server instradi gli stessi dati allo stesso shard.

La suddivisione rende più complesso mantenere la coerenza e eseguire future migrazioni. Non suddividere i dati che rientrano in una chiave e rimangono al di sotto dei suoi limiti di throughput.

Costruisci un flusso di lavoro operativo

Usa gli strumenti disponibili insieme:

1. Osserva. Usa il Dashboard di Osservabilità dei Data Store per monitorare richieste, stato delle risposte, throughput e archiviazione. Configura allerta personalizzate per metriche importanti dei data store in modo che il tuo team possa rispondere a guasti prolungati o crescita inaspettata. Le notifiche del Creator Hub ti informano anche quando l'archiviazione si avvicina o supera i limiti e includono indicazioni e link ai dashboard.
2. Ispeziona. Usa Data Stores Manager per esaminare data store, chiavi, utilizzo di archiviazione e costi stimati. Se l'esperienza ha più di 100 data store, l'elenco dei Data Store non mostra dimensioni e conteggi delle chiavi. Usa Open Cloud o il Data Stores Batch Processor per quelle metriche.
3. Rimedia. Usa Data Stores Manager per record individuali. Usa le API dei data store di Open Cloud o il Data Stores Batch Processor per flussi di lavoro ripetibili o su larga scala.
4. Scala intenzionalmente. Prima riduci l'archiviazione e le richieste non necessarie. Se l'uso legittimo supera le quote predefinite, valuta i Servizi Estesi.

Open Cloud e i server di gioco condividono il budget di richiesta a livello di esperienza. Limita la velocità degli script operativi di Open Cloud in modo che non interferiscano con il traffico in diretta.

Gestisci il ciclo di vita dei dati

Usa le versioni dei data store invece di creare una nuova chiave per ogni revisione. Solo l'ultima versione di una chiave conta per l'utilizzo di archiviazione, e le versioni ti consentono di ispezionare o ripristinare valori precedenti.

Usa memory stores per dati temporanei e in rapida evoluzione. I dati del memory store scadono automaticamente e non aggiungono all'archiviazione del data store persistente.

Elimina i dati di test quando termina il test e rimuovi i dati per eventi scaduti o funzionalità ritirate. Dopo aver contrassegnato un data store per la cancellazione, c'è un periodo di 30 giorni durante il quale puoi ripristinarlo. Dopo questi 30 giorni, Roblox elimina permanentemente il data store. Per ulteriori informazioni, consulta Data Stores Manager.

Configura il trattamento del diritto all'oblio

Configura il trattamento automatizzato del diritto all'oblio (RTBF) per i dati dei giocatori che seguono modelli statici di data store e chiave. Il RTBF automatizzato è il flusso di lavoro preferito perché Roblox applica i tuoi modelli di cancellazione quando elabora una richiesta idonea.

Se il RTBF automatizzato non supporta il tuo schema di dati, usa il webhook del diritto all'eliminazione per eseguire un flusso di lavoro di cancellazione personalizzato. Verifica che entrambi i flussi di lavoro rimuovano tutti i dati corrispondenti dei giocatori.