SQL Оптимизация пространственного индекса для локализованных географических точек

У меня есть ~ 400 тыс. Точек интереса, которые хранятся в пространственном sql ГЕОГРАФИИ.

Я буду запрашивать эти точки с помощью PointOfInterest.STDistance (@CentralPoint) ‹@Radius, чтобы найти точки PointOfInterest в определенном радиусе от @CentralPoint, отправленного по запросу.

Я немного читал о наслоении сеток и хотел бы, чтобы кто-нибудь, знающий свое дело, порекомендовал наиболее разумный образец сетки. По умолчанию

УРОВЕНЬ_1 = СРЕДНИЙ, УРОВЕНЬ_2 = СРЕДНИЙ, УРОВЕНЬ_3 = СРЕДНИЙ, УРОВЕНЬ_4 = СРЕДНИЙ

Но моя ситуация такова, что у меня будут ТОЛЬКО интересные места в Великобритании. Несмотря на то, что мы великолепны, мы рассматриваем только относительную спецификацию terra firma, поэтому мне было интересно, есть ли лучший шаблон сетки для использования в пространственном индексе для этого случая.

Поскольку я основан на географии, я не могу использовать красивые ограничивающие рамки геометрии. Также я использую SQL Azure, который, похоже, не имеет хранимых процедур пространственной справки :(


sql optimization indexing spatial-index spatial
person BritishDeveloper    schedule 15.04.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Как и в случае с пространственным индексированием, вы в конечном итоге обнаруживаете, что тестирование различных настроек сетки на вашем наборе данных может дать результаты, отличные от результатов других. Тем не менее, я считаю, что установка Низкого на всех уровнях или Среднего, Низкого, Низкого, Низкого дает отличные результаты с Баллами из-за их упрощенного характера.

Однако, чтобы лучше всего использовать индекс, рассмотрите возможность буферизации точки и проверки пересечения. Опять же, я обнаружил, что он часто дает более стабильно низкие результаты, но проверьте его на своих данных.

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

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

Старайтесь держаться подальше от желания переключиться на геометрию, поскольку, хотя он будет давать немного более быстрые запросы, у него больше шансов дать «неправильные» результаты из-за работы с плоской моделью. Тем не менее, если расстояния поиска достаточно малы, разница не будет заметна в большинстве сценариев.

person Jon Bellamy    schedule 15.04.2014
comment
Спасибо! Пожалуйста, не могли бы вы вкратце объяснить преимущества вашего предложения о низкоуровневых сетках, поскольку я бы подумал, что более точное «высокое» звучит лучше всего, читая о них. - person BritishDeveloper; 15.04.2014
comment
@BritishDeveloper, Ну, использование низкоуровневых сеток делает индекс относительно легким и быстрым - LLLL имеет только максимум 65536 ячеек уровня 4 внутри него. Тестирование на нескольких наборах информации (включая данные Великобритании) в целом давало более высокую или равную производительности, чем другие комбинации (я перепробовал их все). Однако при работе с полигонами необходим более высокий уровень, чтобы лучше справляться со сложностью, а также экспериментировать с ячейками для каждого значения объекта. Были некоторые случаи, когда я находил MLLL или HLLL лучше, поэтому я также рекомендую попробовать их, но с 400 тыс. Строк мы говорим о вершинах 10 мс. - person Jon Bellamy; 15.04.2014