每一分钟写入 10 万行数据,有啥好的方案吗?

2020-07-23 21:29:41 +08:00
 goodspb
这 10 万数据在接下来的 2 分钟还要操作( update )

当然 db 是 mysql,应用是 spring boot
10902 次点击
所在节点    程序员
96 条回复
reus
2020-07-24 00:35:58 +08:00
不要提前优化
shoaly
2020-07-24 00:53:26 +08:00
@goodspb 假设, 你有很多万的用户, 这 10w 是日活的话, 那么卡死你们服务器 估计不是这个每分钟一条的请求, 而是客户正常点 app 的请求, 那个比 一分钟一次来的更容易崩... 所以如果他正常用都没崩的话, 你 1 分钟搜集一次 妥妥没问题
594duck
2020-07-24 06:42:32 +08:00
V2er 们真的虎,动不动 1 秒 1667 条有什么难度,2 分钟后的 update 操作怎么弄。你们说呀,嘴巴动动真的简单。

楼主我和你说,像你这样的数据,能不 update 就不 update,另外你的 update 让大数据团队也难干活。我建议你是走流水一样的操作,这样主库不开索引 ,只管写。后面弄个几个从库只读,用来做业务查询 ,读写分离。

另外你这量级的话,计算一下数据量,我建议走 DRDS 或者类似的 mysql 集群方案,因为你要考虑到将来你的数据总量实在是太大了。

如果考虑未来增长什么的,最好直接上类 oracle 或者 microsfot sqlserver 方案。数据库成熟 ,能力强尽,只要无脑堆机器 就行。(事实证明自己上 Oracle 在五年成本里和阿里的 DRDS 相比并不贵到哪里去,你看一下 DRDS 的报价就知道了)。

同时可以测一下 Microsoft sqlserver 和 mysql 集群的能力。Sqlserver 能力非常强的。
sivacohan
2020-07-24 08:32:25 +08:00
先算下服务器的价格。
要是公司买不起服务器,你这个架构怎么做都没用。
rushssss
2020-07-24 08:50:40 +08:00
@594duck 写入不成问题,update 只要能恰当的分库分表也没什么问题,这种情况下没必要搞什么花架子,MySQL 完全可以处理,如果要聚合查询,那就弄个从库单独查就行了
cco
2020-07-24 08:59:08 +08:00
mysql 限定死,服务器没给上限,就算玩出花来也满足不了你的不确定数值的需求啊,今天 20W,明天 200W,后天 2000W 。。。。针对不同的需求选择不同的技术,没必要提前满足。迭代,迭代,迭代!
ywlvs
2020-07-24 09:27:53 +08:00
每分钟 10 万条数据,一天貌似就超过 1 亿条了噢,这已经超出我的认知范畴了。
594duck
2020-07-24 10:15:37 +08:00
@rushssss 他这数据量,随便 select 一下超出行数都直接转为全表扫描。
Varobjs
2020-07-24 10:35:01 +08:00
有什么难度吗,本地环境,30 万数据耗时 1min 左右,用的是 on duplicate 插入更新操作
Varobjs
2020-07-24 10:35:40 +08:00
而且时间包含,从 mongo 读 30 万数据的时间
ulpyxua
2020-07-24 10:45:18 +08:00
用队列+缓存,一天一用户就 100 条,太容易了。
leeg810312
2020-07-24 10:47:41 +08:00
@Varobjs 内容才几行都不看全的吗? 10 万插入的数据还要马上 update,光几十万插入性能有什么用
Vegetable
2020-07-24 10:57:37 +08:00
建议你先用土办法做出来试试性能,目测并没有太大压力,24 小时也无所谓
qiayue
2020-07-24 10:59:06 +08:00
@594duck 1 秒 1667 条数据,如果是一个 sql 语句批量插入,的确没有任何问题啊。
如果是 1667 次插入,那会有问题,如果真是这样,那就是业务设计有问题
qiayue
2020-07-24 11:00:15 +08:00
建议楼主重新梳理一下业务,是否真的有必要这样操作
xuanbg
2020-07-24 11:14:48 +08:00
优化的核心点是:为什么每分钟要生成一条数据,并且写入数据库?
1 、能不能按需生成而不是定期生成?如果可以,估计数据能少 99%。
2 、能不能汇总后写入数据库?如果可以,还能少写 99%。

两个点优化下来,每秒只用写 10 行。
goodspb
2020-07-24 11:20:26 +08:00
@xuanbg #36
@qiayue #35

本来的方案是按需生成的,用户进来页面才生成。

但是最近想上一个版本,用户不在界面也要生成(主要他选择了他想定时生成)。
然后他还能看到前 100 条记录。
qiayue
2020-07-24 11:28:21 +08:00
分库分表
312ybj
2020-07-24 11:31:51 +08:00
前两天写着玩, 把自己阿里云数据库的数据库内容扩大了下。 如果单线程,1s 最多 6 条数据插入,特别慢。 后来改了用多线程插入,单个插入,1s 100 条左右。 如果再适当优化,速度还会上去
Sasasu
2020-07-24 11:34:52 +08:00
典型的时序数据库负载,推荐 timescale,想省硬盘并且不讨厌 go 就 Influxdb 。

timescale 缺点是硬盘空间占用大,有点是内存占用小,没有不必要的多维度索引开销(表尽量简单),历史数据也可以压缩
influxdb 优点是实时压缩率高,缺点是内存占用多,启动慢,go 写的

不推荐其他监控用的数据库,性能差或者为 k8s 监控特化太多。

也可以去买按次付费的时序存储,不会很贵。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/692634

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX