海量数据展现

背景

    如今咱们的数据量愈来愈来越大，每每会有短期渲染大量数据的要求，可是每每这些数据过大难以实时处理，总体切片花费时间又过长。在这里提出一种缓存加实时处理的方案。

准备

    软件环境，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,有问题能够联系

参考资料：

www.runoob.com/python/pyth… stackoverflow.com/questions/4… docs.objectrocket.com/redis_pytho… stackoverflow.com/questions/1… blog.csdn.net/why_not2007… www.jianshu.com/p/443719f60… docs.microsoft.com/en-us/bingm… github.com/Microsoft/U… github.com/buckhx/Quad… github.com/CartoDB/pyt… www.cnblogs.com/xwgli/archi… stackoverflow.com/questions/4… postgres.cn/docs/postgi… postgis.net/docs/manual… postgis.net/docs/manual… postgis.net/docs/ST_AsM… wiki.openstreetmap.org/wiki/Slippy… www.postgresql.org/docs/9.5/gi… www.postgresql.org/docs/9.5/gi… blog.csdn.net/xk_zhang/ar… www.cnblogs.com/LCGIS/archi… blog.csdn.net/Happy52Wang… blog.csdn.net/a624806998/… www.dongcoder.com/detail-1195… www.cnblogs.com/520zm/p/107… pynative.com/psycopg2-py… initd.org/psycopg/doc… www.v2ex.com/t/351734 www.cnblogs.com/kaituorensh… blog.csdn.net/kanon122500…