MS SQL - Est-ce que le type de données de géométrie est utilisé pour trouver la distance de manière beaucoup plus rapide?

Question

J'ai une base de données qui contient beaucoup de données géospatiales ... essentiellement des informations sur 10s de milliers de personnes, avec des coordonnées pour chacun d'eux. Les coordonnées sont actuellement stockées sous forme de deux flotteurs pour la latitude et la longitude, et j'utilise une fonction pour déterminer la distance entre les coordonnées de cet enregistrement et une coordonnée que je passe ... essentiellement pour trier et limiter les résultats que je reçois par la distance. C'est à peu près le code utilisé dans la fonction.

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) 

La procédure stockée prend 4 ou 5 secondes pour s'exécuter.

J'ai remarqué que SQL Azure prend désormais en charge le type de données de géométrie .. (ce n'était pas le cas lorsque j'ai créé la base de données). Donc, ma question est ... est-ce que j'aurais une augmentation significative de la vitesse d'exécution de ma procédure stockée qui me permettrait d'investir le temps qu'il faudrait pour passer à l'utilisation du type de données géométrique?

Merci!

Steven

Answer 1

Je ne peux pas vous donner le oui/non réponse que vous cherchez, parce que j'ai aussi aucune expérience avec l'utilisation des nouveaux types de données spatiales.

Mais ce que je peux vous donner quelques conseils:

Tout d'abord: Votre SP semble convertir des données géographiques juste. SQL Server 2008 a des méthodes pour faire exactement cela pour vous avec le nouveau type de données géographiques. Regardez le OGC Methods on Geography Instances sur le MSDN geography Data Type reference. Ainsi, les nouvelles méthodes vous donneraient au moins l'avantage de l'encapsulation.
Particulièrement intéressant pour vous doit être la méthode STDistance (STDistance (geography Data Type)), car il semble que c'est ce que fait réellement votre SP, en calculant la distance de lat1, lon1 à lat2, lon2. Je crois qu'une fonction intégrée est plus rapide qu'une fonction auto-créée, mais je ne saurais pas sans test.

En utilisant MS buzzwords, les types de données spatiaux big plus ont des index spatiaux. Si vous avez une base de données avec beaucoup de données spatiales (votre SP convertit juste quelques paramètres), les index spatiaux vous apportera une augmentation des performances. Ou citant le spatial data whitepaper:

Performance des requêtes sur les données spatiales est encore renforcée par l' inclusion du soutien d'index spatial dans SQL Server 2008. Vous pouvez indexer des données spatiales avec une grille multi-niveaux adaptatif index intégré dans le moteur de base de données SQL Server .

Et puis il y a quelques articles suggérant la meilleure performance de l'espace indexé (est-ce un mot?) Les données contre les index normaux:

Performance est certainement améliorée ...(de SQL Server 2008 Spatial Index Performance)

Et puis il y a un graphe agréable comparant différents types de contenir des données spatiales contre l'autre sur le côté de la performance: SQL Server 2008 Spatial - Performance of database calls?

Donc, pour résumer cela: En utilisant un index spatial WILL vous donnera une augmentation de performance. Si l'utilisation des méthodes spatiales prédéfinies vous donnera une augmentation significative de la performance, je ne sais pas. Bonus: Pour vous aider à démarrer avec les types de données géographiques, je vous suggère de lire cet article avec beaucoup d'exemples: Demystifying Spatial Support in SQL Server 2008.

Answer 2

Je suis sur le point de démarrer un nouveau projet spatial qui sera exécuté sur SQL Server 2008. L'application prendra des données ponctuelles dans Lat Lng (WGS 84) et devra manipuler ces données pour générer des lignes et des polygones et éventuellement afficher sur une carte Mercator (OSM dans EPSG: 900913) qui est un système rectangulaire.

Nous ne recevrons pas de données pour le monde entier (seulement certaines parties de l'Europe), donc nous n'avons pas besoin de nous inquiéter de la ligne de date. Je penche pour l'idée de tout stocker dans un type de données géométrique dans EPSG: 900913 sinon chaque point, ligne et polygone devra être converti en système de coordonnées d'affichage chaque fois qu'une carte est dessinée (on tire beaucoup des cartes).

Pour être honnête, je suis nouveau à SQL Server spatial, mon expérience a été avec Oracle. Je suppose que ce que je dis est que le choix du système de coordonnées ou du type de géométrie dépend de ce que vous faites avec les données. Si vous devez convertir beaucoup de données entre systèmes de coordonnées (et c'est ce que vous faites dans le calcul de votre distance), j'aurais pensé que stocker les données dans un système de coordonnées approprié serait plus rapide. Donc, les questions doivent être alors, avez-vous passer à la fonction de distance native que moontear mentionné et si oui, comment Microsoft l'a mis en œuvre? Après tout, le calcul de la distance devrait être beaucoup plus simple dans un système rectangulaire ou est-ce que je me trompe?

Answer 3

Votre question "est-ce que j'aurais une expérience significative augmenter en vitesse ... [en] changeant les choses en utilisant le type de données de géométrie?" semblait ignorer la possibilité que l'utilisation des types de données spatiales dédiés puisse réellement ralentir les choses. Pourtant, cela peut effectivement être le cas, pour plusieurs raisons. Tout d'abord, souvenez-vous que les types de données géométriques et géographiques prennent en charge non seulement les points, mais aussi les chaînes de lignes et les polygones. La complexité supplémentaire qu'ils supportent signifie qu'ils n'utilisent pas nécessairement un calcul de distance point-à-point simpliste. Ils prennent également en charge une plus grande gamme de fonctions intégrées sur ces types, de sorte que la valeur sérialisée d'un point est plus complexe que juste un ensemble de lat, longues coordonnées. Cela signifie qu'une valeur de point géométrique/géographique peut être plus lente à extraire et interroger que les colonnes équivalentes de données de coordonnées flottantes brutes.

Le deuxième et le facteur plus important concerne la précision avec laquelle le calcul de la distance est effectuée:

1.) Si vous avez les coordonnées projetées (c.-à-UTM, National Grid ou State Plane) coordonnent ensuite les valeurs sont mesuré en unités linéaires (x, y) sur un plan plat. Par conséquent, il est facile de calculer la distance entre deux points en utilisant la trigonométrie de base: Dist (xy) = SQRT ((x2 - x1) 2 + (y2 - y1) 2) Ceci est une méthode mathématique simple et il est peu probable que voir beaucoup de différence de performance si vous l'implémentez vous-même ou en utilisant le type de données de géométrie.

2.) Si vous avez des coordonnées géographiques (c'est-à-dire Latitude/Longitude), celles-ci sont mesurées en unités angulaires sur un ellipsoïde . Le plus souvent, il s'agit de l'ellipsoïde WGS84 utilisé par les systèmes WGS84. Dans la plupart des cas, vous pouvez obtenir une approximation suffisamment bonne de la distance entre deux points de l'ellipsoïde en utilisant simplement des calculs sphériques à la place, comme vous le faites dans votre procédure stockée. Cependant, la forme de la terre ressemble plus à une sphère écrasée - elle est plus large à l'équateur qu'aux hautes, et votre calcul ne permet pas cet aplatissement de la terre. Le type de données geography utilise des calculs ellipsoïdaux, basés sur le modèle ellipsoïde du SRID fourni, qui sont nécessairement plus complexes, mais aboutiront à une réponse plus précise.

Je vous recommande que si vous voulez augmenter la précision et fonctionnalité de vos données spatiales, alors vous devez passer à l'espace des types de données, mais pas pour des raisons de performance.