3

我有一个包含大量地理空间数据的数据库......基本上是关于成千上万人的信息，每个人都有坐标。

坐标当前存储为纬度和经度的两个浮点数，我使用一个函数来确定该记录中的坐标与我传入的坐标之间的距离......基本上是为了对我得到的结果进行排序和限制距离。这大致是函数中使用的代码。

DECLARE @earthSphereRadiusKilometers as float
DECLARE @kilometerConversionToMilesFactor as float
SELECT @earthSphereRadiusKilometers = 6366.707019
SELECT @kilometerConversionToMilesFactor = .621371

-- convert degrees to radians
DECLARE @lat1Radians float
DECLARE @lon1Radians float
DECLARE @lat2Radians float
DECLARE @lon2Radians float
SELECT @lat1Radians = (@lat1Degrees / 180) * PI()
SELECT @lon1Radians = (@lon1Degrees / 180) * PI()
SELECT @lat2Radians = (@lat2Degrees / 180) * PI()
SELECT @lon2Radians = (@lon2Degrees / 180) * PI()

-- formula for distance from [lat1,lon1] to [lat2,lon2]
RETURN ROUND(2 * ASIN(SQRT(POWER(SIN((@lat1Radians - @lat2Radians) / 2) ,2) + COS(@lat1Radians) * COS(@lat2Radians) * POWER(SIN((@lon1Radians - @lon2Radians) / 2), 2))) * (@earthSphereRadiusKilometers * @kilometerConversionToMilesFactor), 4)

存储过程需要 4 或 5 秒才能运行。

我注意到 SQL Azure 现在支持几何数据类型 ..（我创建数据库时不支持）。

所以我的问题是......我的存储过程运行速度是否会显着提高，这是否值得我花时间将其更改为使用几何数据类型？

谢谢！

史蒂文

4

3 回答 3

4

您的问题“我是否会体验到速度的显着提高...... [通过] 将事情改为使用几何数据类型？” 似乎忽略了使用专用空间数据类型实际上会减慢速度的可能性。然而，出于几个原因，这实际上可能是这种情况。

首先，请记住几何和地理数据类型不仅支持点，还支持线串和多边形。它们支持的额外复杂性意味着它们不一定使用简单的点对点距离计算。它们还支持这些类型的更大范围的内置函数，因此点的序列化值比一组经纬度坐标更复杂。这意味着几何/地理点值的检索和查询可能比原始浮点坐标数据的等效列更慢。

第二个也是更重要的因素与执行距离计算的准确性有关：

1.) 如果您有投影坐标（即 UTM、国家网格或国家平面），则坐标值在平面上以线性 (x, y) 单位测量。因此，使用基本三角法很容易计算两点之间的距离： Dist(xy) = SQRT( (x2 - x1)2 + (y2 - y1)2 ) 这是一种简单的数学方法，您不太可能看到太多无论您是自己实现还是使用几何数据类型，性能差异。

2.) 如果您有地理坐标（即纬度/经度），那么这些坐标是在椭圆体上以角度单位测量的。最常见的是 WGS84 系统使用的 WGS84 椭球。在许多情况下，您可以通过使用简单的球面计算来获得椭圆体上两点之间距离的足够近似值，就像您在存储过程中所做的那样。然而，地球的形状更像是一个压扁的球体——它在赤道处的宽度比在两极处的高度要宽，而且你的计算不允许地球变平。geography 数据类型使用椭球计算，基于提供的 SRID 的椭球模型，这必然更复杂，但会产生更准确的答案。

所以我建议如果你想提高空间数据的精度和功能，那么你应该转向空间数据类型，但不是出于性能原因。

于 2010-11-23T16:59:19.253 回答
0

我无法给您您正在寻找的是/否答案，因为我也没有使用新空间数据类型的经验。

但我能给你一些建议：

首先：您的 SP 似乎只是转换了一些地理数据。SQL Server 2008 具有使用新的地理数据类型为您执行此操作的方法。查看MSDN 地理数据类型参考上的地理实例上的OGC 方法。所以新方法至少会给你封装的好处。 对您来说特别有趣的一定是（STDistance（地理数据类型））方法，因为这似乎是您的 SP 实际在做的事情，计算从 lat1、lon1 到 lat2、lon2 的距离。我相信内置函数比自创函数更快，但如果没有测试我不会知道。
STDistance

使用 MS 流行语，空间数据类型 big plus 具有空间索引。如果您有一些包含大量空间数据的数据库（您的 SP 只是转换了一些参数），空间索引将为您带来性能提升。或引用空间数据白皮书：

SQL Server 2008 中包含的空间索引支持进一步增强了对空间数据的查询性能。您可以使用集成到 SQL Server 数据库引擎中的自适应多级网格索引来索引空间数据。

然后有一些文章建议空间索引（是一个词吗？）数据相对于普通索引的更好性能：

性能肯定得到增强... （来自SQL Server 2008 Spatial Index Performance）

然后有一些很好的图表比较了不同类型的空间数据在性能方面相互比较：SQL Server 2008 Spatial - Performance of database calls？

所以，总结一下：使用空间索引会给你带来性能提升。我不知道使用预定义的空间方法是否会给您带来显着的性能提升。

奖励：为了让您开始使用地理数据类型，我建议您阅读这篇包含大量示例的博文：Demystifying Spatial Support in SQL Server 2008。

于 2010-10-19T14:06:39.940 回答
0

我即将开始一个新的空间项目，它将在 SQL Server 2008 上运行。该应用程序将获取 Lat Lng (WGS 84) 中的点数据，并且需要操作该数据以生成线和多边形并最终将其显示在墨卡托上地图（EPSG 中的 OSM：900913）是一个矩形系统。

我们不会接收整个世界（仅欧洲部分地区）的数据，因此我们无需担心日期变更线。我倾向于将所有内容存储在 EPSG:900913 中的几何数据类型中，否则每次绘制地图时，每个点、线和多边形都必须转换为显示坐标系（我们正在绘制很多地图）。

老实说，我是 SQL Server 空间的新手，我的经验是使用 Oracle。我想我要说的是坐标系或几何类型的选择取决于您对数据的处理方式。如果您必须在坐标系之间转换大量数据（这就是您在距离计算中有效执行的操作），那么我会认为将数据存储在合适的坐标系中会更快。

那么问题来了，你有没有切换到moontear提到的原生距离功能，如果有，微软是如何实现的？毕竟距离计算在矩形系统中应该简单得多，还是我自己搞糊涂了？

于 2010-11-18T06:07:31.180 回答