这是一个创建于 387 天前的主题，其中的信息可能已经有所发展或是发生改变。
例如“登录数据”的存储应该怎么设计
一开始系统可能不存储“登录数据”，但是没过多久产品经理要分析“单位时间内用户登录数”，那此时应该对每次用户登录请求进行记录，根据数据库是不是为业务所用分为两种方案：1. 在业务数据库中建 login_time_log 表，只做 append 操作； 2. 在数据分析建表，与业务数据隔离
但之后产品经理都提出了需求，对“三日内未登录过的用户进行消息推送”，那此时“用户登录时间”的数据又算是业务数据了，如果采用上述方案一，那么每次都要 SELECT * FROM login_time_log ORDER BY login_time DESC LIMIT 1，性能会不会比较差；如果采用上述方案二，那么是不是要在业务表里加一个 last_login_time 的字段，这样的话就需要额外维护，而且在一定程度上也算“数据冗余”
想向各位经验丰富见多识广的老哥们取取经🙏🙏🙏
 |
1
caihp 2023-10-31 09:08:30 +08:00
在数据分析这边建表存储每一个登录操作； 然后三日内那个的话我觉得可以先查出来在这三天登录过的用户 id ，然后给所有用户中不在这些 id 里面的用户进行消息推送
|
 |
2
ding2dong 2023-10-31 09:10:59 +08:00
分开啊，数据分析需求是多变的，不可能频繁动业务表结构的
|
 |
4
xianbing278 2023-10-31 09:44:19 +08:00
感觉你们产品经理的需求是要对用户数据指标有要求，这个应该算是基础数据吧，从基础数据出发去考虑会不会好一点
|
 |
5
julyclyde 2023-10-31 09:56:51 +08:00  1
如果仅仅是单位时间内的登录“数量”但无所谓“谁”
那其实你只需要用 redis 维护一个计数器就行了。incr 操作应该是原子的，不会因为交错执行而导致少统计 过了这个时间片之后再用计划任务去存盘也可以，比你那个附加数据表方案更优 是一个强内存、弱 IO 的做法 但是后续你又要“谁”，那就只好记在数据库里了。 不过倒不一定登录时间作为用户的附属属性；也可以用户名作为登录日志的附属啊。也就是 @caihp 推荐的这种做法 问题是就怕产品经理再改 建议跟产品经理仔细谈谈，看有什么远期规划，直接一步到位算了 |
 |
6
gejigeji 2023-10-31 09:56:52 +08:00
把业务数据同步到大数据平台
|
 |
7
piecezzz 2023-10-31 10:00:01 +08:00
2 ， 闲时把业务用户数据 copy 到数据分析，用户每次登录的数据发消息队列双写到业务库与数据分析库。你在业务库爱怎么搞怎么搞
|
|
8
piecezzz 2023-10-31 10:00:48 +08:00
说错了，是数据分析库
|
 |
9
dlmy 2023-10-31 10:01:10 +08:00 1
先按照规则圈定人员名单，然后对名单内的用户进行消息推送。
在公司中这类需求都会用 Kafka + Flink 体系去做，采集用户登录日志、走各种数据分层模型、存储人员名单、创建消息推送任务、配置消息推送模板、填充模板、消息推送审批、触发消息推送任务...... |
 |
10
lscho 2023-10-31 10:15:40 +08:00
login_time_log 表解决分析“单位时间内用户登录数”
单独建一个用户-最后登录时间表解决对“三日内未登录过的用户进行消息推送” 别想那么复杂的东西 |
 |
11
GeekGao 2023-10-31 10:26:25 +08:00
看业务扩张的规模，如果预计 1 年内不会有很大的增长，那么简单粗暴的弄。例如：写个独立的微服务扫描从库的这张表，做数据分析计算，随便你怎么加字段了，性能不会被影响很大的。
或者表重新写入 duckdb 这类的嵌入式数据库，分析逻辑自己写就行了。跟不需要引入第三方 db 服务，运维能喘口气了。 |
 |
12
pkoukk 2023-10-31 10:26:42 +08:00
看你公司规模和业务量级，没多大量级的东西根本不需要考虑这些事情，跟着需求走就完了
大公司的路数就是 9#说的，小业务根本没预算上这一套 |
 |
13
bugmakerxs 2023-10-31 10:53:31 +08:00
大公司一般都是建数仓，然后应用往数仓推数据。数仓对原始数据做聚合查询。
|
Select Language