问一个数据库对业务数据存储的问题

[gitrebase]

例如“登录数据”的存储应该怎么设计

一开始系统可能不存储“登录数据”，但是没过多久产品经理要分析“单位时间内用户登录数”，那此时应该对每次用户登录请求进行记录，根据数据库是不是为业务所用分为两种方案：1. 在业务数据库中建 login_time_log 表，只做 append 操作； 2. 在数据分析建表，与业务数据隔离

但之后产品经理都提出了需求，对“三日内未登录过的用户进行消息推送”，那此时“用户登录时间”的数据又算是业务数据了，如果采用上述方案一，那么每次都要 SELECT * FROM login_time_log ORDER BY login_time DESC LIMIT 1，性能会不会比较差；如果采用上述方案二，那么是不是要在业务表里加一个 last_login_time 的字段，这样的话就需要额外维护，而且在一定程度上也算“数据冗余”

想向各位经验丰富见多识广的老哥们取取经🙏🙏🙏

[caihp]

在数据分析这边建表存储每一个登录操作； 然后三日内那个的话我觉得可以先查出来在这三天登录过的用户 id ，然后给所有用户中不在这些 id 里面的用户进行消息推送

[ding2dong]

分开啊，数据分析需求是多变的，不可能频繁动业务表结构的

[gitrebase]

@caihp 如果登录数据存储在数据分析那边的话，“三天登录过的用户 id”不就要在数据分析那边查了吗

[xianbing278]

感觉你们产品经理的需求是要对用户数据指标有要求，这个应该算是基础数据吧，从基础数据出发去考虑会不会好一点

[julyclyde]

如果仅仅是单位时间内的登录“数量”但无所谓“谁”
那其实你只需要用 redis 维护一个计数器就行了。incr 操作应该是原子的，不会因为交错执行而导致少统计
过了这个时间片之后再用计划任务去存盘也可以，比你那个附加数据表方案更优
是一个强内存、弱 IO 的做法

但是后续你又要“谁”，那就只好记在数据库里了。
不过倒不一定登录时间作为用户的附属属性；也可以用户名作为登录日志的附属啊。也就是 @caihp 推荐的这种做法

问题是就怕产品经理再改
建议跟产品经理仔细谈谈，看有什么远期规划，直接一步到位算了

[gejigeji]

把业务数据同步到大数据平台

[piecezzz]

2 ， 闲时把业务用户数据 copy 到数据分析，用户每次登录的数据发消息队列双写到业务库与数据分析库。你在业务库爱怎么搞怎么搞

[piecezzz]

说错了，是数据分析库

[dlmy]

先按照规则圈定人员名单，然后对名单内的用户进行消息推送。

在公司中这类需求都会用 Kafka + Flink 体系去做，采集用户登录日志、走各种数据分层模型、存储人员名单、创建消息推送任务、配置消息推送模板、填充模板、消息推送审批、触发消息推送任务......

[lscho]

login_time_log 表解决分析“单位时间内用户登录数”

单独建一个用户-最后登录时间表解决对“三日内未登录过的用户进行消息推送”

别想那么复杂的东西

[GeekGao]

看业务扩张的规模，如果预计 1 年内不会有很大的增长，那么简单粗暴的弄。例如：写个独立的微服务扫描从库的这张表，做数据分析计算，随便你怎么加字段了，性能不会被影响很大的。
或者表重新写入 duckdb 这类的嵌入式数据库，分析逻辑自己写就行了。跟不需要引入第三方 db 服务，运维能喘口气了。

[pkoukk]

看你公司规模和业务量级，没多大量级的东西根本不需要考虑这些事情，跟着需求走就完了
大公司的路数就是 9#说的，小业务根本没预算上这一套

[bugmakerxs]

大公司一般都是建数仓，然后应用往数仓推数据。数仓对原始数据做聚合查询。