postgis数据库优化_基于PostGIS的高级应用(1)--PgRouting百万级别路网查询优化

前文《基于PgRouting的GIS网络分析--数据准备》描述了如何进行数据准备工作，入门的朋友可以参考如何搭建环境，导入数据和建立索引等准备。pgrouting是postgis的插件，主要做网络分析等业务使用，一般一个地区，一个城市几万级别的路网，查询是非常快速的，但是全国路网动辄几百万，几千万的路网规模，默认查询就非常的慢了。于是，本文主要以dijkstra算法，安装pg的单机默认配置，重点阐述如何“动脑经”加速路径查询速度，而不是单纯依靠机器配置(毕竟再牛逼的机器也架不住无脑的大量运算啊)，当然本文的方法并不是非常规范和标准，但提供了一个解决问题的思路，即大量路网的复杂查询优化一定要避免全表查询，尽量减少计算！！！

一 全表路径分析查询

北京路网.png

查询路网的线数据规模：

network=# select count(*) from ways;

count

---------

1250371

(1 row)

以dijkstra算法示例查询：

规划A_B的路径查询.png

如上图：A点坐标[115.2,39.8]，B点坐标[115.4,40]，A点的附近对应道路的gid是487371，B点附近对应道路的gid是62553(gid事先查询好的，测试就不写如何获取坐标附近的道路gid)，考虑到道路有单行道的关系，所以有通行权重cost和反向权重reverse_cost ，查询语句如下：

SELECT * FROM pgr_dijkstra('SELECT gid as id,snodeid as source,enodeid as target,length::float as cost,rev_length::float as reverse_cost FROM ways

',487371,62553,true);

返回93行记录，平均耗时5.8s，但是如图可知，其实AB两点比较近，而大部分路网其实对他们的计算根本就没关系，于是我们考虑在一开始查询时就规避无效路网。

二 矩形范围过滤

矩形过滤

我们发现，AB之间范围及其附近的路网就足够分析出路径，而大量其他数据是没有任何影响作用的，我们设AB两点构成一个矩形，然后缓冲2km作为备用参与分析道路(即红色斜线部分)，语句如下：

SELECT * FROM pgr_dijkstra('SELECT gid as id,snodeid as source,enodeid as target,length::float as cost,rev_length::float as reverse_cost FROM ways

where st_intersects(geom,st_buffer(ST_PolygonFromText(''POLYGON((115.2 39.8,115.4 39.8,115.4 40,115.2 40,115.2 39.8))'',4326),0.02))

',487371,62553,true);

返回93行记录，平均耗时150 ms。

实验结果证明：与全表查询的分析结果一致，但全表查询是矩形查询耗时的 5800/150约49倍，明显优化速度还是很明显的。

矩形问题.png

但是矩形查询也存在一个问题，当AB两点的经度接近(极端情况就是一致)，那么两点只能构成一个 水平或者垂直的 线段(无法构造矩形区域)，绝大部分形成一个细长的面区域如上图，这种情况下，因不能构造矩形筛选区域，或者说构造的区域过于狭窄无法满足路径查询的要求，采用“线性过滤”会更恰当些。

三 线性范围过滤

线性过滤示意图.png<