Un certain jeu de la société a été connecté à la fonction de chat Microsoft Xiaoice AI début janvier. Afin de sauvegarder les enregistrements de discussion et de préparer les fonctions statistiques ultérieures, il est décidé de stocker les enregistrements de discussion sur le serveur. Au départ, la quantité de données de chat et l'utilisation de la fonction de chat par les joueurs n'étaient pas claires, c'est pourquoi MySQL, qui est relativement tolérant en termes de prix et de performances, a été utilisé comme support de stockage.
Après environ un mois de fonctionnement, la quantité de données dans le tableau des enregistrements de discussion a atteint 20 millions. Après retour au service planning, afin de contrôler la quantité de données, il a été décidé de limiter le nombre d'enregistrements de chat. Chaque personnage de chaque joueur ne peut enregistrer que jusqu'à 200 enregistrements, et chaque joueur peut enregistrer jusqu'à 3 enregistrements de personnage, c'est-à-dire que chaque joueur ne peut enregistrer que jusqu'à 900 enregistrements de discussion. La logique de traitement du serveur est ensuite modifiée pour nettoyer tous les 300 enregistrements stockés afin de garantir que la quantité de données est contrôlée dans une certaine plage.
Selon les données sur les nouveaux jeux et la rétention des joueurs, on suppose que la durée moyenne de jeu de chaque joueur est de 10 jours et que le nombre de nouveaux joueurs est compris entre 2 000 et 3 000. Par conséquent, il y aura 20 000 à 30 000 nouvelles données de joueurs tous les 10 jours. Selon la valeur la plus élevée, un maximum de 27 millions de données pourront être générées tous les 10 jours, et un maximum de 50 millions de données pourront être générées par mois. . Calculé de cette manière, après un mois, MySQL pourrait ne plus être en mesure de prendre en charge les opérations fréquentes de lecture et d'écriture de données, et le stockage des enregistrements de discussion doit être ajusté.
Pour l'attribut AVG du jeu, le cycle de vie des joueurs est relativement court, les joueurs peuvent donc être répartis en fonction de leur durée d'inscription, afin de stocker les données des joueurs dans des tableaux séparés. Plus précisément, les données peuvent être divisées en fonction du mois d'inscription du joueur, et le tableau correspondant peut être utilisé pour stocker et interroger les données. De cette façon, les données des joueurs peuvent être transportées de manière relativement uniforme chaque mois. La quantité de données qui aurait pu atteindre des dizaines de millions peut désormais être contrôlée au niveau d'un million, ce qui peut résoudre complètement le problème actuel (la quantité de données de discussion est positivement corrélées avec les nouvelles données, et les nouvelles données relativement stables) .
La prochaine chose à considérer est que lorsque le cycle de vie d'un joueur se termine, ses données seront toujours stockées dans la base de données. Au début de la nouvelle année, les joueurs nouvellement inscrits continueront d'être stockés, le découpage des données des joueurs n'est donc qu'une mesure temporaire. La façon de résoudre ce problème est d'analyser le comportement des joueurs après la fin du cycle de vie principal et de constater que ces joueurs ne se connecteront pas et ne discuteront plus pendant une longue période. Par conséquent, ces données de joueurs inactifs peuvent être migrées vers un stockage de fichiers distribué bon marché, l'indicateur de migration est enregistré et les enregistrements de la table de base de données d'origine sont supprimés. Utilisez la méthode de chronométrage des tâches, ce qui peut réduire l’impact sur l’entreprise.
Pour les opérations de suppression ci-dessus, vous devez faire attention à un point, l'opération mysql delete delete ne libérera pas l'espace table. Ici, vous devez libérer manuellement l'espace table. La libération manuelle d'un grand espace table est une opération relativement gourmande en performances et verrouille également les données de la table. Par conséquent, l’opération de libération doit être conçue en fonction de la situation réelle. Dans le cas ci-dessus, nous exploitons les données sur une base mensuelle et nous pouvons nettoyer les données du mois précédent au bout d'un mois. Par exemple, videz le tableau de janvier début mars, car la plupart des joueurs actifs en mars se sont peut-être inscrits en février. Il peut être programmé pour être supprimé tôt le matin afin de minimiser l'impact sur l'entreprise.
En février, l'exigence opérationnelle consistant à marquer les enregistrements de discussion a été ajoutée pour des commentaires réguliers et une formation en IA. Ici, nous stockons indépendamment les enregistrements de discussion de l’opération de marquage, ce qui peut faciliter les statistiques et les analyses ultérieures. De cette manière, on peut également éviter que les opérations de marquage soient dispersées dans différentes tables, augmentant ainsi la complexité du traitement des données. Dans le même temps, étant donné que la quantité de données dans l'opération de marquage ne sera pas importante, vous pouvez également envisager d'utiliser une base de données NoSQL ou d'autres bases de données en mémoire pour stocker ces données afin d'améliorer la vitesse des requêtes et de réduire les coûts de stockage.