例如“登录数据”的存储应该怎么设计
一开始系统可能不存储“登录数据”,但是没过多久产品经理要分析“单位时间内用户登录数”,那此时应该对每次用户登录请求进行记录,根据数据库是不是为业务所用分为两种方案: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
大公司一般都是建数仓,然后应用往数仓推数据。数仓对原始数据做聚合查询。
|