求问各位大佬，我前端在请求后端半年、1年左右的日志数据。一般来说1年数据顶多几万条. 后端的要求是，直接丢给我原始数据，不进行排序等处理，让前端自行处理。数据不能一次性请求，要每个月每个月地发送请求，每次请求后再将拿到的数据处理后加入之前已经获取的数据中。后端给我的解释是降低后端服务器性能消耗，让前端来处理可以充分利用bs架构的优势。（原话）我的设想是后端直接在数据库拿到数据后进行初步处理之前一直是直接传入起止日期一次性获得数据, 现在要求我连续发送请求, 我提问既然需要这么做能不能后端自己先循环获得每月数据后再一次性返回, 前端做一个loading 被以上原话给驳回了. 我想问问，这种要求是否合理？服务器性能是否无法承受这种体量的数据? 各位大佬不好意思, 怪我没说全, 这个日志数据我们是用来做可视化的统计图表的, 所以一次请求拿到所有的数据我觉得是比较好的办法. 平时做日志列表的需求是做了分页的.

1.前端一个页面也挤不下半年或者一年的日志数据展示吧...（统计的数据除外）
2.既然一下子展示不完所有数据，干嘛不做分页处理呢？
3.后端不做排序让前端来做也有点说不过去。数据处理都让前端做了要后端干嘛？
4.一次性拿一年的日志数据，那是要加载多久？用户体验要不要考虑？其他用户的业务还要不要处理？

有关统计的见解：

1.目测楼主要统计的是旧数据，就是过去半年或者一年的数据
2.既然是旧数据就说明数据是写死的，不变的，统计出来的结果也是不变的，非实时的
3.这种统计的做法一般都是后端写个定时任务，夜深人静无人使用系统时将数据统计好并存入数据库
4.前端请求数据时，后端直接将数据库里的数据读出来给前端就行了

undefind_5

1.5k1297133

发布于
2019-06-03

不论数据量大小，前后端分离不是为分离而分离
后端的第一句话：对于后台数据的处理，前端后端确实都能做，但是分效率。例如一些排序功能，人家后端自己调用一个方法就能解决的，换成前端，就得哼哧哼哧的去循环比对了。所以一般的数据预处理都是后台干了再给前端；
第二句话：你们那个后台脑子不好使吧？直接一个分页加载的问题你给我整成多次队列请求？是不会搞还是不愿意搞？

所以这后台的大兄die要不是个能坐着放屁就不愿站着说话的老滑头；要不是个憨憨；要不就是在为难你

rhinel

682

发布于
2019-06-04

简单啊，用fetch流处理啊，后端一一段返回即可，边查询边返回，前端拿到一段就显示一段。