1
snappyone 2020-06-01 20:17:47 +08:00 via Android
30 万分成每次 1000 条就好了
|
2
matrix67 2020-06-01 20:18:47 +08:00
分页
|
4
optional 2020-06-01 20:26:13 +08:00
再加一台 slave 为后台专用。
|
6
levelworm 2020-06-01 20:36:33 +08:00 via Android
说分页的未必合乎后台业务需求啊,有时候后台的确需要批量处理,你分页是方便你自己了,但是后台就得写脚本自己抓数据了。对我就这么干过。最好还是分开来,后台专门有台机器。
|
7
Jooooooooo 2020-06-01 20:38:39 +08:00
拆分数据库, 实时交易库和导出类的库分开
然后再去优化业务 |
8
857681664 2020-06-01 20:39:52 +08:00 via Android
导出可以异步放消息队列里,用独立服务处理,我的想法是这样
|
9
leaderhyh OP @Jooooooooo 目前数据库不是痛点且架构师不想动数据库
|
10
CoderGeek 2020-06-01 20:54:20 +08:00
运营与对外分离
|
11
night98 2020-06-01 20:55:10 +08:00
可以起两个服务,但是可以使用分批写入的方式,一次读取一千条左右,写到文件中,参考 http://poi.apache.org/components/spreadsheet/how-to.html#sxssf
如果说内存足够的话,只是说数据库容易被拖死的话,可以单独起一个从库专门用于后台管理系统的导出,然后使用 mysql 自带的 sql 导出到硬盘目录,再用服务器转移到对象存储等文件服务上面 |
12
Jooooooooo 2020-06-01 22:01:16 +08:00
@leaderhyh 不是动架构. 只需要多一个从库然后导出专门连这个从库就行.
|
13
yeqizhang 2020-06-01 22:11:41 +08:00
数据库倒不用分离吧,毕竟后台系统不就是操作对外的一些数据。
不针对你现在的问题来说,系统也最好分开两个系统部署不同的机器,这是前期规划没做好呀! |
14
arrow8899 2020-06-01 22:43:19 +08:00
你这里的导出可以看做是一种报表业务吧,每次导出再去计算成本太大了。通常的做法是用流式处理框架 Flink,Strom 等实时汇总,把计算成本分摊到每一次业务处理上,导出的时候直接读取就行。
|
15
namelosw 2020-06-01 23:05:58 +08:00 1
微服务挂掉,不用 SQL 全读到内存计算了?那假如你是因为内存计算卡死的话
0. 看看能不能把内存计算变成 SQL query,如果不能看下面 0. 看看能不能改成异步 Job,如果不能看下面 1. 最简单的建议单独分微服务出去 2. 如果分出去微服务接着发现数据库也是瓶颈,把数据库用 CDC 之类的弄一个同步,只用来做查询 3. 再不行就 Flint 或者 Spark,这些是大量内存计算的正规军 |
16
leaderhyh OP @Jooooooooo 这个已经做了
|
20
wangyzj 2020-06-01 23:57:47 +08:00
微服务挂掉?
内存炸了? 少量多次吧 |
21
neptuno 2020-06-01 23:59:53 +08:00 via Android
搞个从库
|
22
coderabbit 2020-06-02 01:06:53 +08:00 via Android
我 mysql 实时同步 mongo.50 万数据 20 秒左右导出。一点不拖累服务!
|
25
xuanbg 2020-06-02 08:39:18 +08:00
可以按导出需求做个小小的数仓,然后从数仓导出数据就不会影响到业务,而且导出速度也能提升到毫秒级。
|
26
ytmsdy 2020-06-02 10:19:15 +08:00 1
一次性导出 30w+的会员数量这个操作,应该是规避的高风险操作吧。
毕竟一次性导出这么多数据,除了拿出去卖,我想不到还有什么场景会用到这么多数据。 |
27
arthas2234 2020-06-02 10:42:59 +08:00
你如果是需要频繁导出的话,最好单独做一张表用来保存这些数据,到时候直接查出来就行了
|
28
zoharSoul 2020-06-02 11:25:03 +08:00
会员微服务挂掉 是什么意思?
内存溢出了? |
29
EastLord 2020-06-02 13:58:18 +08:00
流式下载不行吗
|