Um determinado jogo da empresa foi conectado à função de bate-papo Microsoft Xiaobing AI no início de janeiro. Para salvar os registros do chat e preparar-se para funções estatísticas subsequentes, foi decidido armazenar os registros do chat no servidor. Inicialmente, não estava claro sobre a quantidade de dados de chat e o uso da função de chat pelos jogadores, então o MySQL, que é relativamente tolerante em preço e desempenho, foi usado como meio de armazenamento.
Após cerca de um mês de operação, a quantidade de dados na tabela de registros de chat atingiu 20 milhões. Após feedback ao departamento de planejamento, para controlar a quantidade de dados, foi decidido limitar o número de registros de chat. Cada personagem de cada jogador só pode salvar até 200 registros, e cada jogador pode salvar até 3 registros de personagens, ou seja, cada jogador só pode salvar até 900 registros de chat. A lógica de processamento do servidor é então modificada para limpar a cada 300 registros armazenados para garantir que a quantidade de dados seja controlada dentro de um determinado intervalo.
De acordo com os dados de novos jogos e retenção de jogadores, presume-se que o tempo médio de jogo de cada jogador seja de 10 dias e o número de novos jogadores esteja entre 2.000 e 3.000. Portanto, haverá 20.000 a 30.000 novos dados de jogadores a cada 10 dias. De acordo com o valor mais alto, um máximo de 27 milhões de dados podem ser gerados a cada 10 dias, e um máximo de 50 milhões de dados podem ser gerados por mês . Calculado desta forma, após um mês, o MySQL pode não ser capaz de suportar operações frequentes de leitura e gravação de dados, e o armazenamento dos registros de bate-papo precisa ser ajustado.
Para o atributo AVG do jogo, o ciclo de vida dos jogadores é relativamente curto, portanto os jogadores podem ser divididos de acordo com o tempo de registro, de forma a armazenar os dados dos jogadores em tabelas separadas. Especificamente, os dados podem ser divididos de acordo com o mês de registro do jogador, e a tabela correspondente pode ser usada para armazenar e consultar os dados. Desta forma, os dados dos jogadores podem ser transportados de forma relativamente uniforme todos os meses. A quantidade de dados que pode ter atingido dezenas de milhões pode agora ser controlada ao nível de um milhão, o que pode resolver completamente o problema atual (a quantidade de dados de chat é correlacionado positivamente com os novos dados, e os novos dados relativamente estáveis) .
A próxima coisa a considerar é que quando o ciclo de vida de um jogador terminar, seus dados ainda estarão armazenados no banco de dados. Quando o novo ano começar, os jogadores recém-registrados continuarão a ser armazenados, portanto, dividir os dados dos jogadores é apenas uma medida temporária. A maneira de resolver esse problema é analisar o comportamento dos jogadores após o término do ciclo de vida principal e descobrir que esses jogadores não farão login e conversarão novamente por um longo tempo. Portanto, esses dados do jogador inativo podem ser migrados para armazenamento de arquivos distribuído barato, e o sinalizador de migração é registrado e os registros na tabela do banco de dados original são excluídos. Use o método de cronometragem de tarefas, que pode reduzir o impacto nos negócios.
Para as operações de exclusão acima, você deve prestar atenção a um ponto: a operação de exclusão do mysql não liberará o espaço de tabela. Aqui você precisa liberar manualmente o espaço de tabela. A liberação manual de um grande espaço de tabela é uma operação que exige um desempenho relativamente intenso e também bloqueia os dados da tabela. Portanto, a operação de liberação precisa ser projetada de acordo com a situação real. No caso acima, operamos os dados mensalmente e podemos limpar os dados do mês anterior após um mês. Por exemplo, limpe a tabela de Janeiro no início de Março, porque a maioria dos jogadores activos em Março podem ter-se registado em Fevereiro. Ele pode ser programado para ser excluído no início da manhã para minimizar o impacto no negócio.
Em fevereiro, foi adicionado o requisito operacional de marcação de registros de bate-papo para feedback regular e treinamento de IA. Aqui armazenamos os registros de chat da operação de marcação de forma independente, o que pode facilitar estatísticas e análises subsequentes. Dessa forma, também é possível evitar que as operações de marcação fiquem dispersas em diferentes tabelas, aumentando a complexidade do processamento dos dados. Ao mesmo tempo, como a quantidade de dados na operação de marcação não será grande, você também pode considerar o uso de um banco de dados NoSQL ou outros bancos de dados na memória para armazenar esses dados, a fim de melhorar a velocidade da consulta e reduzir os custos de armazenamento.