入库思考
- 因此对于game_log 这种日志数据, 直接来一条,就记录一条,没啥争议的!
- 对于game 在做数据库同步的时候,难免会设计到修改和删除,对于clickhouse这种数据库,修改和事务简直是天敌,因此,在设计表结构的时候,直接不对数据做修改和删除,所有binlog过来的全部都是新增。
这样子数据能回放任意时刻,这对存储需求就比较大了。如何合并,备份数据也就成了关键,其实仔细想想也并不难,无非就是全量保存和最新量的生成。最新量就是根据某些特定的字段进行去重,最容易想到的就是 server_id 和role_id,因为在目前游戏中,一个玩家从登录创建了账号开始,每进入一个游戏服就是创建一个role_id ,因此sid和rid是衡量玩家唯一的最基础的属性值。按照小说的三要素,时间、地点、人物。这里人物有了,地点在这里体现的并不那么明显,还有就是时间,因为脚本基本上都是按照天来跑,因此还要加上日期概念,所以对于存储的大数据仓库的表中,(rid,sid,binlog_es) 是可以作为主键也比较适合作为主键。当然有些数据建表还是需要灵活的对待。
数据库结构
有了上面的思考,例如:在01-02号凌晨,会对0