关于网易云数据库的一些猜想

博主是前端，没接触过后台，但对于一些基础概念有一点点了解

最近各大平台 抖音/网易云/b站又再做用户的独立年终总结，朋友圈铺天盖地各种晒，突然对上面的数字来了兴趣，如此庞大的用户量，他是如何做到快速统计出的数据呢？

先来看一张图：

关注一下图中数据，即用户的听歌次数是会被系统记录的，那问题来了

1，数据表长什么样？是如何关联的？这条数据是在那个表下的？

2，平台如此多的用户，肯定要保证每个用户上来都能获取到属于自己的信息，而页面等待时间其实并没有多少他是如何做的

我们来尝试解答问题进行逆推

　　第一个问题：首先数据与用户关联，我们有一张用户表，关联关系待定，其次，商品表（歌曲），再来关注下数据-次数，即每听一首歌，我们的听歌次数会被记录，这个记录可以有两种方式：一种我们直接将用户的听这个歌的次数加1，但用户表就至少千万级，我们不可能将他与所有歌曲关联为每一首歌提供听歌总次数的读写字段，数据量太大，检索也会巨慢，且无论挂在用户表中还是歌曲表中，都不现实，那我们就需要第二种，即设计一张统计表（独立），id/歌曲id/收听者id/收听时间等等，无论什么歌什么人，只要收听，都将在该表中生成一条新记录，在不同端断网听歌时也可以对记录做临时保存有网时进行上传同步（非必要），当然，这只是猜测，但这样已经能基本实现需求

　　第二个问题：对于第一个问题的推测其实我有意回避了数据量的问题，无论是用户表，歌曲表，还是后面可能存在的统计表，我都没有太过强调他的容量属性，如果统计表存在，一首火爆的歌播放量就可能爆炸，那到底如何解决查询慢的问题？我们可以做一个验证，找个不长听歌的账号，先生成一份年度报告，之后循环一首歌听上一两个小时，再生成一份报告，对比两份报告，博主很懒，并没有实验，但通过b站的年度报告上的一个信息“x年x月x日截止到x年x月x日”推测，该报告并非实时生成，即并非接口调用后触发去计算的，怎么做？如果我们在功能上线前（应该就是截止日后）将每个用户信息已经统计计算完了呢？这就极大的减轻了服务器压力

　　实现猜想：在功能上线前做定时任务，根据用户查询统计表中每个用户数据并汇总，是挂json在用户表上还是新开表都可以，但统计表（不一定只是上面提到的一张表），容量一定非常大，所有我们将定时任务分离，做多服务器部署，每个定时任务根据时间分段/用户id有规律的话也可以使用用户id分段，每个服务器只查询直接分配到分段中的内容，最终汇总到一起，甚至不需要汇总，如果前面用的分段的有一定规律，比如自增的用户id，可以将id直接解析指向对应的服务器，由单个服务器完成查询并返回结果分区管理

以上都是猜想，每做过后台，但这么干的话后台压力应该基本没有