这是一个创建于 964 天前的主题，其中的信息可能已经有所发展或是发生改变。
数据量大概两三万左右，前端是 react + echarts （或者 d3 ），后端是 java
由于业务需求，这些数据都是有意义的，要都显示出来
我的想法是调一个接口一次性把所有数据全返回来
但是后端说微服务不能这么干，内存也装不下什么的，让我 500 条一次，手动依次获取全部数据
我就很迷茫了，以前也没这么做过不知道对不对
 |
1
aragakiyuii 2022-05-05 13:34:55 +08:00
目测数据结构不会很复杂（猜的）两三万占不了多少的
|
 |
2
rapperx2 2022-05-05 13:35:50 +08:00
怎么获取不重要，重要的是你前端怎么显示
|
 |
3
kiritoxf OP 每条数据除了一些基本信息（字符串什么的）外，还会有一个 300 多个浮点数的数组
@aragakiyuii |
 |
5
lessMonologue 2022-05-05 13:40:04 +08:00 via Android
不能自己多调用几次后端接口然后拼接起来吗
|
 |
6
murmur 2022-05-05 13:42:08 +08:00
抽样呗，3w 个点到一个图上都一坨糊了，抽到 3000 个点跟 3w 个看上去也是一坨 shi 糊
|
 |
7
ss098 2022-05-05 13:42:22 +08:00
后端确实不适合一次性输出所有数据，还是前端分页自己拼接比较好。
|
 |
8
wonderfulcxm 2022-05-05 13:44:14 +08:00 via iPhone
可以同时发几条 ajax 请求，并行下载，然后把结果组装。就好像开启了迅雷的多线程下载，肯定比一次性取全部数据快。
|
|
9
rapperx2 2022-05-05 13:44:35 +08:00
@kiritoxf 那你应该让后端一次性提供给你啊，不能只讲数量，也要看数据包大小。包大就压缩传输，几万条数据只取需要的字段能占多大内存。实在不行，缩写字段等方式，这些应该后端来思考吧
|
 |
10
nieboqiang 2022-05-05 13:51:22 +08:00
@lessMonologue 不太合理，过程过多，出错的概率越大。
|
|
11
lessMonologue 2022-05-05 13:57:18 +08:00
@nieboqiang 合理。这个也不是说类似订单状态的流转啥的多次请求，就单纯的读数据，合理的很。如果前端不想做，那就后端再写一个聚合接口拼装数据。
|
 |
12
netnr 2022-05-05 13:59:52 +08:00 via Android  3
后端字符串打包压缩为 ZIP ，前端下载解压读取解析，例大文件导出 https://www.netnr.com/run/code/5328511666506473654
|
 |
13
rabbbit 2022-05-05 14:00:48 +08:00
散点图要是全显示 30000/500, 前端请求 60 次, 要分组也是 5000 一组吧?
啥业务? 必须全部输出展示? 内网用还是外网用? 是否在意流量? 业务不同设计也不同 |
|
14
rabbbit 2022-05-05 14:03:51 +08:00
那个 300 多的数组就别一起发过来了, 用户点击的时候发 id 查吧.
|
|
15
rabbbit 2022-05-05 14:11:17 +08:00
如果做的 OA 之类的内网用根本没几个用户的系统,纯粹是后端偷懒不想加接口那就直接传 {size: 999999999} 吧.
|
|
16
kiritoxf OP |
|
17
kiritoxf OP 我现在打算用类似如下的伪代码来解决
不并发是因为后端说同时发一堆请求不好，好像对微服务有影响什么的 ``` const fetchListData = (page: number) => { getData({ page, pageSize: 5000 }).then((res) => { // 自己拼一个数组 myList.push(res.list); // 如果当前页还没到总页数，就 page+1 再获取一次 if (res.page !== res.totalPage) { fetchListData(page + 1); } else { // 初始化图表 } }) } ``` |
 |
18
falcon05 2022-05-05 14:31:13 +08:00 1
@netnr #11 web server 一般都可以配置根据 content-encoding: gzip 返回压缩后的内容，浏览器解压是也是自动的啊，为什么还要前端解压缩？
|
|
19
rabbbit 2022-05-05 14:43:35 +08:00
|
 |
20
jy02534655 2022-05-05 14:53:51 +08:00
echarts 本身是有配置支持大数据量优化的，至于怎么取数据上面已经说了
|
 |
21
itsme001 2022-05-05 15:12:42 +08:00
散点图 点超过一定量 后浏览器端会卡的。具体是多少忘了，以前遇到过。
没超过这个量让后端写个接口一次返回。 超过这个量考虑 1.做同含义的展示。后端做对应聚合。 2.server side render ，后端根据前端传参直接返回 png 。 这个问题 pyviz ，holoviz 有一篇文章写的很好。是关于大量数据展示的聚合、采样、渲染的。 我不太清楚前端情况，几个可视化库应该是有 server side render 方面的内容的。不知道具体 api 。你可以用这个关键词去搜。 可以问问做可视化的前端或者做 python 数分的。 |
 |
23
zhangleshiye 2022-05-05 17:46:35 +08:00
不是 如果不是实时性的 之间让后端弄个 redis 做缓存啊 存硬盘怎么失效呢
|
 |
24
haah 2022-05-05 17:55:17 +08:00
按照“日期范围”获取呀！一页一天不行么？
|
 |
25
potatowish 2022-05-05 19:59:31 +08:00 via iPhone 1
后端如果是 Java 可以考虑 ResponseBodyEmitter ，前端只需一次请求，后端每查询出一页数据就写入到响应，直到响应完成。并且服务端内存最多只需占用一页的数据。
|
 |
26
night98 2022-05-05 21:19:50 +08:00
websocket 或者 ssr ，你这需求一看就不靠谱，3 万数据正常屏幕平均十个点显示一个元素?抽样做吧，参考类似贝壳找房地图找房功能
|
 |
27
dcsuibian 2022-05-05 21:46:11 +08:00
楼上的学到了^_^
最近正好也有做大量数据展示，我怎么就一直没想到分块查询的思路呢。。。 |
 |
28
dqzcwxb 2022-05-05 21:47:45 +08:00
分页查询是利好前端的,你要是不想做后端巴不得不搞
|
|
29
dcsuibian 2022-05-05 22:05:59 +08:00
没画过散点图，我这边 ECharts 画折线图，20000+数据也是秒画。卡顿主要是后台数据库查询了。
你可以先试试看一次查询的，性能问题最忌讳虚空打靶。 看看后端 Java 、数据库、网速、体积、内存、js 、ECharts 到底哪个占了最大头的部分。这样才能针对性优化。 500 条数据感觉属实有点少了，跟 #13 说的至少加个 0 ，现在计算机的性能真的挺强、挺快的。 再者说也不用等返回完了再画出来吧，如果每条数据是独立的，那完全可以有的部分先画出来。我记得 ECharts 对过渡动画和在线数据更新也支持得不错的。 |
|
30
kiritoxf OP 感谢大家的回复，大家提出的建议都有参考价值。
我的情景比较特殊，应该只有 5000 一次分页的可以用，因为所有的数据都取出来后还要跑另一个东西去算横纵坐标，但是试了下非常耗时间，得放弃这么做了。 |
Select Language