J'ai une application dans laquelle fondamentalement, j'ai une énorme table (100 millions d'enregistrements) d'informations, chaque ligne contenant une valeur lat / longue.
Je interrogeons constamment cette table pour obtenir tous les enregistrements qui correspondent à un rayon autour d'un certain point. Par exemple, "Tous les enregistrements dans un rayon de 5 miles de 39.89288, -104.919434"
Pour cela, j'ai un index sur les colonnes Lat / Long, et je reçois la "carrée de liaison" des points, puis je supprime tous les points qui tombent à l'extérieur du cercle de mon application ASP.NET, car C'était plus rapide que le calcul du cercle sur SQL Server.
Remarque: il s'agit de toutes les données sur les États-Unis, donc je considère que la Terre est à plat pour mes calculs, ce qui est suffisamment précis pour mes besoins.
Maintenant, le principal problème avec l'indice Lat / Long est qu'être "un carré" de points, et puisque j'essaie de trouver "lat entre x et y" et "long entre x et y", il peut 'T Utilisez vraiment l'indice super-efficacité, comme cela pourrait être recherché sur "une ligne" de points.
J'ai lu sur les caractéristiques spatiales de SQL 2008, mais je n'ai pas trouvé suffisamment d'informations concrètes pour savoir si cela est utile pour moi.
La question est donc la suivante: SQL 2008 a-t-il une sorte de type d'index différent qui rendra ce type de requête spécifique beaucoup plus rapidement que possible avec SQL 2005?
4 Réponses :
trouvé ceci:
pour SQL 2008:
http: // blogs. Laythathant.com/index.php/datamgmt/datanesign/sql-server-2008-proximity-search-with-th
Apparemment, il est possible
Remarque: La version SQL 2005 de cet article ne fonctionne pas trop bien. J'ai essayé ce genre de choses et cela fonctionne mieux pour simplement obtenir la place de SQL Server, puis cogner le cercle dans votre propre code.
Plus de liens d'intérêt:
http://msdn.microsoft.com/en-us/library/bb964712. Aspx
(Enfin une explication !!)
et une requête d'échantillon ...
Apparemment, c'est comment faire la recherche que je veux (points dans un cercle de 5 milles): (locgeog est la colonne de géographie) étrangement , cependant, cela dirige bien plus lentement que ma vieille requête régulière (7 fois plus lente), donc je fais évidemment encore quelque chose de très faux.
Oui, cela peut être très bien fait avec les données spatiales SQL 2008. Il y a une certaine expertise / essais et erreurs (?) Dans la définition de l'indexation spatiale au niveau de la masse droite, mais après cela, il est supposé que ce soit grand (relayé-moi par des amis, je ne l'ai pas utilisé en production moi-même). < / p>
Pour vos besoins (LAT / LON), vous allez wan the Geo type graphique et pas la métrique Geo . Je pense que les indices spatiaux configurent un type d'indexation «triangle de bornissement imbriqué» qui constitue une amélioration du type de préconditionnement «Coffre à bordure» que nous étions forcés de faire en SQL sans elle.
OK, je vous suggère de commencer à Postez à Grant Fritchey's "Home of the Scary DBA" de Fritchey (dites-lui que je vous ai envoyé si vous voulez poser des questions :-)). C'est une bonne explication de certaines analyses de performance et de réglage des indices spatiaux qu'il commençait à apprendre et comprend également des liens vers de nombreux autres matériaux.
Oui! Découvrez Cet article sur les index spatiaux. Vous verrez que ces types d'index fonctionnent mieux que l'approche «rectangle indexée». En outre, non seulement vous serez capable de faire une interrogation efficacement pour "point près d'un autre point", mais faites toutes les autres sortes d'opérations géographiques. Voici une liste complète de toutes les méthodes disponibles sur le type.
Vous savez, je faisais des questions de lat / longitude à Starbucks il y a environ 5 ans ...
Et fondamentalement, nous voulions corréler les magasins dans des centres de distribution. Je travaillais dans leur service d'opérations et ils ne pouvaient honnêtement pas dire quel magasin a été fourni par un entrepôt particulier.
Alors j'ai fini par venir avec cet algorithme de "cercle magique".
Fondamentalement, ils ont eu un tas de requêtes qui ressemblaient à ceci: Sélectionnez * à partir de table1, tableau2 où udfdistance (table1.lat, table1.long, table2.lat, table2.long)> = 250
J'ai fini par venir avec quelque chose de vraiment similiaire, mais il a couru beaucoup plus vite
Sélectionnez * à partir de table1, tableau2 où udfdistance (table1.lat, table1.long, table2.lat, table2.long)> = 250 et table1.lat entre (table2.lat - 1) et (table2.lat + 1) et table1.long entre (Table2.Long - 1) et (Table2.Long + 1)
Fondamentalement, n'essayez pas de comparer deux points géographiques s'il y avait plus de 1 degré (lat et longue) différence entre les deux.
En d'autres termes - il a utilisé des indices relationnels normaux pour filtrer beaucoup de valeurs, puis le calcul de la distance UDF avait beaucoup moins d'informations à traiter.
espère que cela aide, je vais essayer d'aider à clarifier si j'ai besoin de
Bonne question! J'ai fait quelque chose de très semblable à ce que vous faites maintenant dans SQL2005, je serais donc intéressé d'entendre ce que les gens montent avec