公司的某款游戏在1月初接入微软小冰AI聊天功能。为了保存聊天记录并为后续的统计功能做好准备,决定将聊天记录存放在服务端。最初并不清楚聊天数据量的大小以及玩家对聊天功能的使用情况,所以采用了价格和性能相对宽容的MySQL作为存储介质。经过大约一个月的运营后,聊天记录表中的数据量已经达到了两千万条。反馈给策划部门后,为控制数据量,决定对聊天记录数量进行限制。每个玩家的每个角色最多只保存200条记录,每个玩家最多可保存3个角色的记录,即每个玩家最多只保存900条聊天记录。服务端的处理逻辑随即修改为每存储300条记录后就清理一次,以确保数据量控制在一定范围内。根据游戏的新增和玩家留存数据,假设每个玩家平均游戏时间为10天,新增的玩家数在2000至3000之间。因此,每10天会有20000至30000个新的玩家数据,按最高值计算,每10天可能会产生最高2700万条数据,每月最多可能达到5000万条数据。这样计算下来,在一个月后,MySQL可能会无法支持数据的频繁读写操作,需要对聊天记录的存储进行调整。针对游戏的AVG属性,玩家的生命周期相对较短,因此可以根据玩家的注册时间对其进行划分,从而对玩家数据进行分表存储。具体来说,可以按照玩家注册时间的月份对数据进行划分,并使用相应的表进行数据的存储和查询。这样,每个月份可以相对均匀地承载玩家数据,原本可能达到千万级别的数据量,现在可以控制在百万级别
...
继续阅读
(3)