这是学习笔记的第 2042 篇文章

  今天和业务同学聊一个数据存储需求，也想出了几种不同的方案，可以作为工作中的一些参考。 

  需求的场景类似这样：比如我们在微信端使用不同的手机进行登录，那么这些设备的信息和时长是需要关注的。这个需求看起来使用频率不高，但是实际的数据情况是有很大的理解偏差。 总体来说这是一个写入远大于读的场景。

 业务需求是统计一个周期时间（比如90天）以内的资源使用情况。比如今天是20190101，那么90天的话是在20190401，如何存储这些数据呢。

整体的设计上是按照分布式存储的方案，设定一些数据分片。

    我们设想了如下的几种场景来考虑实现：

    比如对外就是一张表，但是数据是按照日期的方式来存储的。

如果要统计设备的使用情况，则需要对所有天数的数据进行统计聚合。

如果是90天，那这个复杂度就会大大增加，而且如果要做数据清理，这个复杂度是很高的。

 从DBA的角度来说，为了使得数据粒度更可控，建议是按照日期的方式来进行分表设计的，类似如下的方式：

但是这种方式解决不了一类问题，那就是做聚合统计。

对此我们提出了两类解决方案，一类方案如下：

数据还是按照日期为单位的表来存储，但是需要额外补充一张表data_latest，这个表维护的是最新的设备统计数据，比如周期为20190101~20190401，则这一条记录里面会维护这个信息。

如果有周期调整，有了其他的周期数据，那么这个数据可以定向修改。这样一来数据写入只在以日期为单位的表中进行，而数据查询则在最新的表中。而累积数据的统计则是通过定时任务通过T+1的模式进行处理的。

我们也想出了另外一种方式，即对已有的日期为单位的表新增一个字段 累计值。

这样一来每天的新增表中都会包含上一天的累计增量值，也是按照T+1的模式进行统计的。 

整个数据存储的方式类似下面的形式：

其实第一种日期表+状态表的方式更加灵活，而第二种方式更加简洁，从业务同学的反馈来说，他们更倾向于第二种方式。