2011-09-08 45 views
0

对于我们的客户之一,我们提供了一个系统,用于从用户邮政编码位置检索最近的N个地标。 我们有一个数据库,包含所有可用的邮政编码(650,000+)以及相应的坐标(经度和纬度)以及全国400多个地标。在地图上优化搜索

现在我们使用的是从寻找最近ñ地标

以下过程
  1. 检索选定邮编
  2. 的纬度和经度通过使用获取所有的地标坐标
  3. 令他们地理距离公式
  4. 取最接近的N + 2个地标,并使用以下过程获得与它们的实际距离
    • 检查是否坐标之间的距离存储在距离缓存表
    • 如果不是去一个地图引擎,检索缓存中的
  5. 的距离,并将其存储重新排序列表,并返回前N个最接近的地标

问题是我们需要从数据库访问角度和第三方访问都优化这一点。

我们试图缓存所有邮编到距离最近的M个地标的距离,但该表会获得额外的6Gb数据,并且需要大约250天的时间才能填充,因为请求需要约30秒。

我们正在考虑对数据进行分区并将紧密邮编编组在一起,但这会使确切的距离无效。

什么优化解决方案,你看到在这种情况下。 谢谢。

回答

1

你可以尝试重复的方法。

  1. 选择通过所有结果作为你的“半径”
  2. 去使用,并挑选唯一的+值 - 半径水平和垂直方向(根据地理位置
  3. 如果没有足够的行返回,增加“半径”并再次开始
  4. 现在执行距离计算,并使用一个PriorityQueue,以尽量减少在这种计算中使用的号码,并选择所需的项目
+0

这是具有里程碑意义的aprox的距离很好的优化,但是我们需要确切的道路距离,因此额外的步骤,以第三方供应商是仍然需要。 – Pasman

+0

噢,你可以保持这种优化,只有半径比实际要求的大3倍,但如果要达到7英里以外的点,你需要行驶21英里以上。对于距离计算,你的缓存方法非常好,但是找到距离提供者的距离的30秒看起来非常缓慢...... – Kurru

+0

我想它会成为你的最佳改进 – Kurru

1

这应该在数据库 - 水平来完成。ÿ ou应该使用具有地理扩展名的数据库作为SQL Server 2008 R2,或者优秀的开源选择PostGre SQL和PostGIS扩展。有了那些你存储地理BLOB而不是坐标,并且有许多内置的函数可以计算出地理位置,为你处理第2步到第5步。

我建议你从这里开始: http://postgis.refractions.net/

问候

+0

问题是我们需要通过公路距离进行精确的旅行,这就是为什么我们在最后一步依靠谷歌地图和雅虎地图。数据库部分运行非常流畅。这很可能是创建高速缓存的问题,所以我们不需要去Google/Yahoo – Pasman