MS SQL - 使用几何数据类型来查找距离明显更快吗？

Posted 2023-03-27

【中文标题】MS SQL - 使用几何数据类型来查找距离明显更快吗？

【英文标题】：MS SQL - Is using geometry data type to find distance significantly faster?

【发布时间】：2010-10-19 13:19:38

【问题描述】：

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

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

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 现在支持几何数据类型..（我创建数据库时不支持）。

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

谢谢！

史蒂文

【参考方案1】：

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

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

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

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

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

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

【参考方案2】：

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

但我能给你一些建议：

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

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

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

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

性能确实得到了提升……（来自SQL Server 2008 Spatial Index Performance）

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

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

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

【讨论】：

嘿！非常感谢。很好的答案。我将继续进行更改，然后在几天后回复评论，说明速度是否有明显提高，以防万一将来有人有类似问题......我会在我发表评论后将您的答案标记为正确的答案！

嘿。我继续进行更改。虽然我相信使用地理更有效，但速度没有明显差异，所以如果其他人从“是否值得开发努力”的角度来看，我会说可能不是......但它是改变起来并不难，所以为什么不这样做呢！感谢您的帮助。

非常有趣的发现史蒂文。感谢分享！

【参考方案3】：

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

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

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

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