API 的设计问题

2016-11-28 09:19:43 +08:00
 hujianxin

大家好,我需要在数据库获取十几万条数据,然后通过得到的这些数据,计算得到十几个参数(统计计算:方差、极差等)。

现在的任务是,需要从前端得到这所有的十几万条数据,以及另外计算得到的十几个参数。其宗问题是,在数据库中获取数据的过程非常慢,大约的两分钟。

现在我有几种解决方案:

  1. 后端得到这十几万条数据,后端提供一个 api ,用来处理前端的 get 请求,将这些数据发送到前端,然后在前端计算另外的十几个参数。这里有可能占用内存较大,而且需要客户端来完成计算。
  2. 后端得到这十几万条数据,然后将这些数据存储为一个类的类变量。后端提供多个 api ,首先要有得到十几万条结果数据的 api ,还要有另外的十几个 api 用来分别得到另外十几个参数,也就是说例如需要得到方差的时候,使用类里面存储的十几万条结果实时计算得到。这个设计的问题,可能是这十几万条数据比较占用内存,在后端长期驻留。
  3. 后端同样提供多个 api ,像上面一样。但是,那十几条参数的 api 都不涉及计算,而是在获取十几万条结果数据的 api 里面计算得到,然后存储到类的私有变量里面。十几条参数的 api 仅仅是这些似有成员的 getter 就可以。这个设计的问题可能是不统一,因为前端必须先调用获取十几万条结果的 api ,才能调用其他的 api ,否则得到的结果是假的结果。但是这个设计对内存友好,因为只是在一个函数里面存储了十几万条数据,等出了这个函数就垃圾回收了。
  4. 最后一种方案是只提供一个 api ,这个 api 返回一个 json 。 json 里面除了提供十几万条结果数据之外,还提供另外的十几个参数。

描述的可能比较麻烦,非常感谢大家能为我指点迷津!感谢

2933 次点击
所在节点    程序员
26 条回复
sagaxu
2016-11-28 09:29:21 +08:00
4 最好
sarices
2016-11-28 09:31:38 +08:00
大量数据还是服务端运算吧,毕竟浏览器效率提不上去
lslqtz
2016-11-28 09:32:19 +08:00
只提供一个 api ,这个 api 返回一个 json 。只提供另外的十几个参数。
返回几十万条太费资源,浏览器也容易卡死。
这属于在服务端计算,那么大的数量,建议不要传给客户端耗费带宽。
kimchan
2016-11-28 09:35:27 +08:00
同三楼...json 把十几万条数据返回......真的大丈夫?
jimzhong
2016-11-28 09:50:38 +08:00
用任务队列吧,前端先把数据上传给后端,后端开始计算。前端定期 poll 计算状态,直到取得结果。
十几万条数据交给前端浏览器算会消耗很多内存的。
lrh3321
2016-11-28 10:24:34 +08:00
对实时性要求不高的话就提前算好,存另一个表里,然后定时更新
sagaxu
2016-11-28 10:33:09 +08:00
@lslqtz 需求里客户端需要那十几万条数据的,不然也不会傻到发送给客户端了。除了分页慢慢传,还能有什么办法?
just4test
2016-11-28 10:39:39 +08:00
能描述下是什么业务场景需要把这些数据放在客户端吗?我觉得这个设计从根本上就有问题。
hujianxin
2016-11-28 10:49:11 +08:00
@lslqtz @kimchan 谢谢回复,我打算压缩之后在传送,这个应该可以接受吧
hujianxin
2016-11-28 10:49:35 +08:00
@jimzhong 谢谢,任务队列这个我了解一下去
hujianxin
2016-11-28 10:50:35 +08:00
@sagaxu @just4test 客户要求我们做数据可视化,将数据的分布情况显示到网页上,请教一下,有好的方法,不需要将数据传到前端吗?感谢
just4test
2016-11-28 10:53:35 +08:00
另外,考虑到这十几万条数据数据的更新频率(业务上不可能,也做不到要求完全实时的最新数据。毕竟从查数据库到返回结果也要十多分钟),可以把楼主说的第 4 项的返回值存成一个静态文件,还可以 zip 一下。然后提供一个接口返回该 zip 的下载地址即可。按业务需求,每隔一段时间生成一个新文件(不马上把旧的删除,因为可能还有客户端正在下载该旧文件),然后那个接口指向新文件的下载地址。



@sarices
@sagaxu
@lslqtz
我还是觉得楼主的设计从根本上就有问题。
kimchan
2016-11-28 10:53:47 +08:00
@hujianxin 具体是怎么个压缩法? 如果压缩后还是很大. 浏览器渲染会很慢. 任务队列是个方法. 另外. 计算结果是否可以放缓存? 还是说计算结果会经常变?
tomczhen
2016-11-28 10:53:54 +08:00
x-y problem
shibingsw
2016-11-28 10:59:00 +08:00
x-y problem
just4test
2016-11-28 10:59:57 +08:00
@hujianxin 你觉得可视化需要在一个页面里描绘十几万个点吗?
听说过抽样和统计吗?
如果觉得抽样统计还不能满足需求,就在服务器上把图画好了再发过去。
windyboy
2016-11-28 11:00:30 +08:00
从前端获得十几万条数据是什么意思?
Bryan0Z
2016-11-28 11:09:12 +08:00
几十万条数据压缩一下,也就几兆啊,为啥不能传…
scys
2016-11-28 11:52:24 +08:00
不要小看前端处理能力 -_-
---

感觉是不复杂的数据结构:大数据性能测试
http://www.supcan.cn/solution/server17.htm
scys
2016-11-28 11:58:05 +08:00
感觉楼主要考虑的是后端缓存,前端考虑的是绘制的程度,你确定要绘制那么精细的图表?
没讲过那么精细的图表就是,如果有了缓存,你就可以抽样,比如 1/2 这样返回。
你的 IO 压力减少了,同时各个函数间如果同意用一分缓存,连内存压力也减少了。
前端也能减少数据获取量,你的 CDN 也能减少传输量了。

---
你究竟遇到啥问题,好像和你数量级没啥关系就是。

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

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

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

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

© 2021 V2EX