海量数据展示

polong 2019-10-26 12:36:00
原文地址:https://www.cnblogs.com/polong/p/11742496.html

背景

现在我们的数据量越来越来越大,往往会有短时间渲染大量数据的要求,但是往往这些数据过大难以实时处理,整体切片花费时间又过长。在这里提出一种缓存加实时处理的方案。

准备

软件环境,PostGIS(3.0.0rc2 r17909)和 PostgreSQL( 12.0, compiled by Visual C++ build 1914, 64-bit),数据是微软开源的房屋数据。PostGIS3.0相对与PostGIS 2.5大幅度提升矢量切片性能,并行环境表现更好。

预处理

预处理就是将3级到12级的矢量切片事先切好。首先获取数据12级的最大最小xyz,通过这个范围生成网格,然后和数据相交得到一一对应的关系表a。
接下来就是使用四叉树键(quadkey),四叉树有一些有意思的特性。第一,四叉树键的长度等于该瓦片所对应的图像级别;第二,每个瓦片的四叉树键的前几位和其父瓦片(上一图像级别所对应的瓦片)的四叉树键相同,下图中,第1级的 '瓦片2' 是第2级的 '瓦片20' 至 '瓦片23' 的父瓦片,第2级的 '瓦片13' 是 第3级的 '瓦片130' 至 '瓦片133' 的父瓦片。通过四叉树的这个特性把3到11级的xyz和11级的xyz建立对应关系表b,最终a和b关联可以得到三到十一级和数据的对应关系。

根据上述内容,我们就可以生成行矢量切片了,借助golang并发,千万级面数据预处理(加上gzip压缩)大概需要16分钟。

后台服务

预处理矢量切片生成完以后,使用golang把矢量切片全部加载进程序中,并且建立键值对,能够快速的判断请求的xyz在3-11级是否有数据并且存在数据时能快速获取。当数据请求大于十一级时候,我们使用数据库查询方式获取矢量切片。后台编写时候遇到问题,后端向前端传输大的矢量切片速度过慢。我通过数据切割方式解决这个问题。打个比方,吃一个西瓜,你一口吃不下。那我们是不是切成块吃就可以?切块就是数据分割这样能较快的传输又不影响数据完整性。

渲染

前台渲染使用mapbox gl加载自定义矢量切片
![]()
![]()

总结

本文方案中使用缓存少量层级提升整体渲染速度,实际前端浏览中能较为流畅。由于数据限制,方案的测试数据较为单一,可能不具有代表性。本方案预处理切片层级不宜过大,超过12级预处理性能会急剧降低。

![]()
ps:我的扣扣:371278319,有问题可以联系

参考资料:

<https://www.runoob.com/python/python-func-memoryview.html&gt;
<https://stackoverflow.com/questions/45455121/python-convert-memoryview-to-string&gt;
https://docs.objectrocket.com/redis_python_examples.html
<https://stackoverflow.com/questions/18655648/what-exactly-is-the-point-of-memoryview-in-python&gt;
https://blog.csdn.net/why_not2007/article/details/79062351
<https://www.jianshu.com/p/443719f604a2&gt;
<https://docs.microsoft.com/en-us/bingmaps/articles/bing-maps-tile-system?redirectedfrom=MSDN&gt;
<https://github.com/Microsoft/USBuildingFootprints&gt;
https://github.com/buckhx/QuadKey/blob/master/quadkey/tile_system.py
<https://github.com/CartoDB/python-quadkey&gt;
<https://www.cnblogs.com/xwgli/archive/2013/04/12/3016345.html&gt;
<https://stackoverflow.com/questions/415511/how-to-get-the-current-time-in-python&gt;
http://postgres.cn/docs/postgis-2.3/ST_SetSRID.html
https://postgis.net/docs/manual-dev/ST_TileEnvelope.html
https://postgis.net/docs/manual-dev/ST_AsMVTGeom.html
https://postgis.net/docs/ST_AsMVTGeom.html
https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames
<https://www.postgresql.org/docs/9.5/gist-builtin-opclasses.html&gt;
<https://www.postgresql.org/docs/9.5/gist-intro.html&gt;
https://blog.csdn.net/xk_zhang/article/details/52014737
<https://www.cnblogs.com/LCGIS/archive/2013/03/12/2954898.html&gt;
<https://blog.csdn.net/Happy52Wang/article/details/90022686&gt;
<https://blog.csdn.net/a624806998/article/details/87092890&gt;
<http://www.dongcoder.com/detail-1195214.html&gt;
<https://www.cnblogs.com/520zm/p/10743224.html&gt;
<https://pynative.com/psycopg2-python-postgresql-connection-pooling/&gt;
<http://initd.org/psycopg/docs/pool.html&gt;
<https://www.v2ex.com/t/351734&gt;
<https://www.cnblogs.com/kaituorensheng/p/4445418.html&gt;
<https://blog.csdn.net/kanon122500000/article/details/61198902&gt;

声明:该文章系转载,转载该文章的目的在于更广泛的传递信息,并不代表本网站赞同其观点,文章内容仅供参考。

本站是一个个人学习和交流平台,网站上部分文章为网站管理员和网友从相关媒体转载而来,并不用于任何商业目的,内容为作者个人观点, 并不代表本网站赞同其观点和对其真实性负责。

我们已经尽可能的对作者和来源进行了通告,但是可能由于能力有限或疏忽,导致作者和来源有误,亦可能您并不期望您的作品在我们的网站上发布。我们为这些问题向您致歉,如果您在我站上发现此类问题,请及时联系我们,我们将根据您的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。