关于热力图展示大量数据点耗时导致浏览器崩溃问题及解决方案

目录

问题描述

问题分析

解决方案

问题描述&＃xff1a;

1. Web前端在地图上加载空间数据库里存储的地块中心点时因为数据点太多从而导致页面崩溃。
2. Mybatis查询大量数据时&＃xff0c;耗时时间更长是主要原因。8万多条数据&＃xff0c;数据库查询最慢0.6s, Mybatis查询结果需要4s&＃43;。

问题分析&＃xff1a;

1. 数据点太多&＃xff0c;超过800个点时页面卡顿&＃xff0c;更多点时地图页面卡死。

        目前地图加载地块中心点时&＃xff0c;添加了作业类型、年份、地区过滤&＃xff1b;大大减小了数据量&＃xff0c;缩小了数据点范围&＃xff0c; 页面可正常加载。

1. 数据加载时间过长

        地图加载完成后&＃xff0c;等待数据展示时间过长。

解决方案&＃xff1a;

一、数据抽稀

1. 采用聚合算法、地图距离网格化、查询优化、存储过程进行数据点抽稀。

(1) 实现逻辑&＃xff1a;根据xmin、ymin、xmax、ymax值限定的最大地理范围进行纵横切分&＃xff0c;gridXcount列、gridYcount行。 将每个切分后的小块使用st_makeenvelope() 函数转换成多边形并筛选出在这个多边形内的多个地块中心点所构成的曲面的一个中心点( 这个中心点不是切分后多边形的中心点&＃xff0c;也不是某个地块中心点&＃xff0c;可以说是新生成的一个曲面中心点)&＃xff0c;然后筛选距离中心点41米以内的地块中心点1个(这里大约取5个&＃xff0c;结果集会没那么稀疏&＃xff0c;具体多少个可以按照需求和具体结果)。

(2) 函数参数&＃xff1a;

(3) 涉及到的函数&＃xff1a;

1. 使用网格将数据进行切分&＃xff0c;每次数据请求需要计算时间比较长&＃xff0c;但是抽稀后每次地块数据量变化不大&＃xff0c; 可以每日定时将抽稀完的中心点存到表里&＃xff0c;用于前端页面加载。

数据展示从之前的实时计算需要3s 减少到只需不到1s (网络比较好的情况下)。

1. 最终效果图及耗时

参考&＃xff1a;

借鉴抽稀逻辑&＃xff1a;https://blog.csdn.net/luojingweikai/article/details/88401201

Postgresql数据库学习手册&＃xff1a;http://www.postgres.cn/docs/12/index.html

Postgresl 数据库plgssql语言语法&＃xff1a;https://www.postgresql.org/docs/current/plpgsql-overview.html

PostGISx相关学习文档&＃xff1a;http://postgis.refractions.net/docs/PostGIS_FAQ.html

二、尝试Node.js解决方案

抽稀的方案没有使用时&＃xff0c;仔细研究了下接口代码&＃xff0c;发现接口耗时的主要原因是Mybatis查询返回结果耗时时间比较长&＃xff0c;讨论过后来尝试使用Node.js解决数据查询问题以及json文件读取耗时。发现Node.js 在查询空间管理数据库读取json文件耗时很短&＃xff1a;

最后也没有使用Node.js的方式&＃xff0c;因为发现Node.js 访问数据库的代码不能添加到vue项目里。

三、修改接口查询方式&＃xff1a;采用jdbc连接查询

这个也是最终解决方案&＃xff0c;不再使用Mybatis这个ORM工具、直接jdbc连接查询数据并返回需要的结果集。

耗时不到900ms, 数据点 8.7万&＃43;&＃xff0c;数据大小3.45Mb 及效果图&＃xff1a;

其实接口改好后&＃xff0c;通过postman获取数据时间是1.6s&＃43;, 数据传输时间占了一半( 大约 0.7s ), 项目部署后看到其实浏览器端对传输数据进行了压缩&＃xff0c; 从3.6Mb 压缩到了1.6Mb, 节省了不少时间。再者网速也提升了不少&＃xff0c;目前可以看到接口查询数据以及返回结果集的耗时很小很理想。