SQL Optymalizowanie indeksu przestrzennego dla zlokalizowanych punktów geograficznych

Question

Posiadam ~ 400 000 punktów POI przechowywanych w GEOGRAPHY przestrzennych sql.

będę zapytań te punkty z PointOfInterest.STDistance (@CentralPoint) < @Radius do znaleźć pointofinterest w określonym promieniu z @CentralPoint przesłanym zapytaniu.

Czytałem trochę o warstwach siatek i chciałbym, aby ktoś, kto zna ich rzeczy, polecił najbardziej sensowny wzór siatki. Domyślną wartością jest

level_1 = MEDIUM, level_2 = MEDIUM, level_3 = MEDIUM, LEVEL_4 = MEDIUM

Ale moja sytuacja jest taka, że ​​będę tylko ciekawostki ciągu theUK. Pomimo tego, że jesteśmy niesamowici, zajmujemy się tylko względną specyfikacją terra firma, więc zastanawiałem się, czy istnieje lepszy wzór siatki do użycia w indeksie przestrzennym dla tego przypadku.

Opierając się na geografii Nie mogę użyć uroczo wyglądających pól ograniczających geometrię. Korzystam również z SQL Azure, który nie wydaje się mieć przestrzennej pomocy przechowywanych proców: (

Answer 1

Jak zawsze z Spatial Indexing, w końcu odkrywasz, że testowanie różnych ustawień siatki na twoim zbiorze danych może przynieść różne wyniki do To znaczy, stwierdzam, że ustawienie Low na wszystkich poziomach, lub Medium, Low, Low, Low daje świetne wyniki z Punktami z powodu ich uproszczonego charakteru:

Aby jednak najlepiej wykorzystać indeks, należy rozważyć opcjonalne buforowanie wskaż i sprawdź skrzyżowanie Ponownie, okazało się, że często daje lepsze, konsekwentnie niskie czasy wyników, ale przetestuj je na swoich danych:

DECLARE @point GEOGRAPHY = GEOGRAPHY::STPointFromText('POINT(<coords>)', 4326); 
DECLARE @radius INT = 1000; 

SELECT 
* 
FROM <table> 
WHERE <GeographyColumn>.STIntersects(@point.STBuffer(@radius)) = 1; 

Staraj się trzymać z daleka od chęci przejścia na Geometry, ponieważ przynosi to nieco szybsze zapytania, ma większą szansę na uzyskanie "nieprawidłowych" wyników z powodu pracy z modelem planarnym. To powiedziawszy, jeśli odległości wyszukiwania są wystarczająco małe, różnica nie będzie widoczna w większości scenariuszy.