Cierto juego de la compañía se conectó a la función de chat de IA de Microsoft Xiaobing a principios de enero. Para guardar registros de chat y prepararse para funciones estadísticas posteriores, se decide almacenar registros de chat en el servidor. Inicialmente, no estaba claro la cantidad de datos de chat y el uso de la función de chat por parte de los jugadores, por lo que se utilizó MySQL, que es relativamente tolerante en precio y rendimiento, como medio de almacenamiento.
Después de aproximadamente un mes de funcionamiento, la cantidad de datos en la tabla de registros de chat alcanzó los 20 millones. Luego de la retroalimentación al departamento de planificación, para controlar la cantidad de datos, se decidió limitar la cantidad de registros de chat. Cada personaje de cada jugador solo puede guardar hasta 200 registros, y cada jugador puede guardar hasta 3 registros de personajes, es decir, cada jugador solo puede guardar hasta 900 registros de chat. Luego, la lógica de procesamiento del servidor se modifica para limpiar cada 300 registros almacenados para garantizar que la cantidad de datos se controle dentro de un rango determinado.
Según los datos de retención de jugadores y juegos nuevos, se supone que el tiempo promedio de juego de cada jugador es de 10 días y que el número de jugadores nuevos está entre 2000 y 3000. Por lo tanto, habrá entre 20.000 y 30.000 nuevos datos de jugadores cada 10 días. Según el valor más alto, se pueden generar un máximo de 27 millones de datos cada 10 días y un máximo de 50 millones de datos por mes. . Calculado de esta manera, después de un mes, es posible que MySQL no pueda admitir operaciones frecuentes de lectura y escritura de datos, y es necesario ajustar el almacenamiento de los registros de chat.
Para el atributo AVG del juego, el ciclo de vida de los jugadores es relativamente corto, por lo que los jugadores se pueden dividir según su tiempo de registro, para almacenar los datos de los jugadores en tablas separadas. Específicamente, los datos se pueden dividir según el mes de registro del jugador, y la tabla correspondiente se puede utilizar para almacenar y consultar los datos. De esta manera, los datos de los jugadores se pueden transportar de manera relativamente uniforme todos los meses. La cantidad de datos que podría haber alcanzado decenas de millones ahora se puede controlar al nivel de un millón, lo que puede resolver completamente el problema actual (la cantidad de datos del chat es correlacionado positivamente con los nuevos datos, y los nuevos datos relativamente estables) .
Lo siguiente a considerar es que cuando finaliza el ciclo de vida de un jugador, sus datos seguirán almacenados en la base de datos. Cuando comience el nuevo año, los jugadores recién registrados seguirán almacenándose, por lo que dividir los datos de los jugadores es solo una medida temporal. La forma de resolver este problema es analizar el comportamiento de los jugadores una vez finalizado el ciclo de vida principal y descubrir que estos jugadores no volverán a iniciar sesión ni a chatear durante mucho tiempo. Por lo tanto, estos datos del jugador inactivo se pueden migrar a un almacenamiento de archivos distribuido económico, se registra el indicador de migración y se eliminan los registros en la tabla de la base de datos original. Utilice el método de cronometrar las tareas, que puede reducir el impacto en el negocio.
Para las operaciones de eliminación anteriores, debe prestar atención a un punto: la operación de eliminación de MySQL no liberará el espacio de la tabla. Aquí debe liberar manualmente el espacio de la tabla. Liberar manualmente un espacio de tabla grande es una operación que requiere relativamente mucho rendimiento y también bloquea los datos de la tabla. Por lo tanto, la operación de liberación debe diseñarse de acuerdo con la situación real. En el caso anterior, operamos los datos mensualmente y podemos limpiar los datos del mes anterior después de un mes. Por ejemplo, limpie la tabla de enero a principios de marzo, porque es posible que la mayoría de los jugadores activos en marzo se hayan registrado en febrero. Se puede programar su eliminación temprano en la mañana para minimizar el impacto en el negocio.
En febrero, se agregó el requisito operativo de marcar registros de chat para recibir comentarios periódicos y capacitación en inteligencia artificial. Aquí almacenamos los registros de chat de la operación de marcado de forma independiente, lo que puede facilitar estadísticas y análisis posteriores. De esta manera, también se puede evitar que las operaciones de marcado se dispersen en diferentes tablas, aumentando la complejidad del procesamiento de datos. Al mismo tiempo, dado que la cantidad de datos en la operación de marcado no será grande, también puede considerar usar una base de datos NoSQL u otras bases de datos en memoria para almacenar estos datos para mejorar la velocidad de las consultas y reducir los costos de almacenamiento.