Meilleures pratiques pour les magasins de données

Utilisez ces pratiques pour organiser et gérer des données fiables, évolutives et observables tout au long de leur cycle de vie.

Organisez vos données

Créez moins de magasins de données

Les magasins de données se comportent de manière similaire aux tables dans les bases de données. Utilisez un petit ensemble fixe de magasins de données et organisez les enregistrements à l'intérieur par clé. Par exemple, stockez le profil de chaque joueur dans un seul magasin de données PlayerData au lieu de créer un magasin de données pour chaque joueur.

Utilisez une ou quelques clés par joueur

Stockez les données persistantes pour chaque joueur sous une clé lorsque les données s'inscrivent dans la limite de taille d'objet de 4 Mo. Par exemple, utilisez une clé telle que User_123456 dans le magasin de données PlayerData. Ce modèle réduit les requêtes, vous permet de mettre à jour des valeurs connexes de manière atomique et facilite la gestion des retours en arrière.

Si différentes parties des données d'un joueur ont des modèles d'accès différents ou approchent des limites de taille ou de débit par clé, divisez l'enregistrement en un petit nombre de clés déterministes. Gardez les données qui doivent changer de manière atomique dans la même clé.

Utilisez des modèles et des préfixes de clé statiques

Construisez des noms de clés à partir d'identifiants stables et de modèles statiques, tels que User_{UserId}. N'utilisez pas de noms d'affichage ou d'autres valeurs qui peuvent changer. Les modèles statiques rendent les clés prévisibles à travers les serveurs et les outils. Pour les magasins de données, ils permettent également à un traitement automatisé du droit à l'oubli d'identifier les données des joueurs.

Utilisez des préfixes pour regrouper des clés connexes. Par exemple, une expérience qui prend en charge plusieurs profils de personnages pourrait utiliser User_123456/Profile/Warrior et User_123456/Profile/Mage. Vous pouvez ensuite passer User_123456/Profile à ListKeysAsync() pour lister les profils de ce joueur.

Les portées sont une autre façon de subdiviser un magasin de données. Une portée préfixe une chaîne à chaque clé dans cette instance de magasin de données, et la valeur par défaut est global.

Évaluez les modules de magasin de données

Les modules de magasin de données tiers sont toujours une option, et dans de nombreux cas, ils peuvent être préférés à la construction de systèmes à partir de zéro. Avant d'en adopter un, examinez sa propriété, son statut de maintenance et ses ensembles de fonctionnalités. Comprenez comment accéder et migrer vos données sans le module.

Réduisez et distribuez les requêtes

Mettez en mémoire tampon les données des joueurs

Chargez les données d'un joueur au début d'une session et gardez une copie locale sur le serveur pour le gameplay. Mettez à jour la copie locale au lieu d'envoyer une requête de magasin de données pour chaque changement. Enregistrez-la périodiquement, lorsque le joueur quitte, lorsque le serveur s'arrête, et à des points de contrôle critiques tels que le traitement des achats. Choisissez un intervalle de sauvegarde périodique qui reste dans vos limites de requêtes et est plus court que toute expiration de verrouillage de session ; l'exemple de données des joueurs et d'achats utilise 180 secondes.

Échelonnez les requêtes récurrentes

Ne commencez pas les requêtes récurrentes de chaque serveur sur le même calendrier. Avant de commencer une boucle à fréquence fixe, attribuez à chaque serveur ou joueur un décalage initial aléatoire. Pour les boucles de sondage ou de coordination qui ne nécessitent pas un rythme exact, ajoutez un jitter aléatoire borné à chaque intervalle. Ces modèles distribuent les requêtes dans le temps et réduisent les pics de trafic synchronisés.

Réessayez les échecs transitoires

Enveloppez les requêtes dans pcall() et réessayez les échecs transitoires avec un retour exponentiel. Ajoutez un jitter aléatoire à chaque délai afin que les serveurs ne réessaient pas simultanément. Limitez le délai et le nombre de tentatives, et ne réessayez pas les erreurs causées par des requêtes invalides ou des opérations qui ne peuvent plus fournir de résultats utiles.

Traitez les réessais de magasin de données dans l'ordre pour chaque clé. Une requête plus ancienne qui réessaie après qu'une requête plus récente a réussi peut écraser des données plus récentes. Prenez également en compte les écritures avec des résultats inconnus : un appel échoué signifie que le serveur n'a pas reçu de réponse réussie, mais le backend pourrait avoir terminé l'écriture. Pour plus d'informations, consultez Codes d'erreur et limites des magasins de données et Réessais.

Préférez UpdateAsync à SetAsync

Préférez UpdateAsync() lorsque l'écriture dépend de la valeur actuelle ou lorsque plusieurs serveurs pourraient écrire la même clé. UpdateAsync() lit la dernière valeur dans votre rappel avant d'écrire, ce qui réduit les mises à jour perdues. SetAsync() écrase la clé sans lire d'abord et peut causer des incohérences si deux serveurs écrivent en même temps.

Utilisez SetAsync() lorsque vous créez une nouvelle clé ou remplacez une valeur qui ne dépend pas de la valeur précédente. Pour une comparaison des deux méthodes, consultez Set vs update.

Fragmenter les clés chaudes

Chaque clé a des limites de débit de lecture et d'écriture. Si un enregistrement logique atteint systématiquement ces limites après que vous ayez réduit les requêtes inutiles, fragmenter-le à travers des clés déterministes. Choisissez un fragment stable à partir d'un identifiant, tel que User_{UserId}_Inventory_{ShardId}, afin que chaque serveur achemine les mêmes données vers le même fragment.

La fragmentation rend le maintien de la cohérence et l'exécution de futures migrations plus complexes. Ne fragmenter pas les données qui s'inscrivent dans une clé et restent en dessous de ses limites de débit.

Construisez un flux de travail opérationnel

Utilisez les outils disponibles ensemble :

1. Observez. Utilisez le Tableau de bord d'observabilité des magasins de données pour suivre les requêtes, le statut des réponses, le débit et le stockage. Configurez des alertes personnalisées pour des métriques importantes des magasins de données afin que votre équipe puisse répondre à des échecs soutenus ou à une croissance inattendue. Les notifications du Creator Hub vous informent également lorsque le stockage approche ou dépasse les limites et incluent des conseils et des liens vers des tableaux de bord.
2. Inspectez. Utilisez Data Stores Manager pour examiner les magasins de données, les clés, l'utilisation du stockage et les coûts estimés. Si l'expérience a plus de 100 magasins de données, la liste des magasins de données ne montre pas la taille et le nombre de clés. Utilisez Open Cloud ou le Data Stores Batch Processor pour ces métriques.
3. Remédiez. Utilisez Data Stores Manager pour des enregistrements individuels. Utilisez les API de magasin de données Open Cloud ou le Data Stores Batch Processor pour des flux de travail répétables ou à grande échelle.
4. Évoluez intentionnellement. Réduisez d'abord le stockage et les requêtes inutiles. Si l'utilisation légitime dépasse les quotas par défaut, évaluez les Services étendus.

Open Cloud et les serveurs de jeu partagent le budget de requêtes au niveau de l'expérience. Limitez le taux des scripts opérationnels Open Cloud afin qu'ils n'interfèrent pas avec le trafic en direct.

Gérez le cycle de vie des données

Utilisez des versions de magasin de données au lieu de créer une nouvelle clé pour chaque révision. Seule la dernière version d'une clé compte pour l'utilisation du stockage, et les versions vous permettent d'inspecter ou de restaurer des valeurs antérieures.

Utilisez des magasins de mémoire pour des données temporaires et en évolution rapide. Les données du magasin de mémoire expirent automatiquement et n'ajoutent pas au stockage du magasin de données persistant.

Supprimez les données de test lorsque les tests se terminent et retirez les données pour les événements expirés ou les fonctionnalités retirées. Après avoir marqué un magasin de données pour suppression, il y a un délai de 30 jours pendant lequel vous pouvez le restaurer. Après ces 30 jours, Roblox supprime définitivement le magasin de données. Pour plus d'informations, consultez Data Stores Manager.

Configurez le traitement du droit à l'oubli

Configurez le traitement automatisé du droit à l'oubli (RTBF) pour les données des joueurs qui suivent des modèles de magasin de données et de clé statiques. Le RTBF automatisé est le flux de travail préféré car Roblox applique vos modèles de suppression lorsqu'il traite une demande éligible.

Si le RTBF automatisé ne prend pas en charge votre schéma de données, utilisez le webhook de droit à l'effacement pour exécuter un flux de travail de suppression personnalisé. Vérifiez que l'un ou l'autre flux de travail supprime toutes les données de joueur correspondantes.