Обратное геокодирование с помощью SQL Server

Question

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

Проблема заключается в том, что таблица, в которой "сегменты дороги (как география)" представляет собой очень большую таблицу с приблизительными 624801 строками.Обратный геокодер занимает 2 секунды на настольном компьютере, однако это слишком много времени, если учесть, что у нас на поле 1000 машин запрашивают услуги обратного геокодирования каждую минуту, это означает, что мне нужно значительно повысить производительность сервиса.Можете ли вы помочь сократить время запроса?

Заранее спасибо

SELECT TOP 1 WITH TIES *, b.GEOGraphy.STDistance(@input) AS dist 
FROM Numbers n 
JOIN UK b WITH(INDEX(spatial_geography_index)) -- index hint 
    ON b.Geography.STDistance(@input) < @start*POWER(CAST(2 AS FLOAT),n.n) 
    AND b.Geography.STDistance(@input) >= CASE 
        WHEN n = 1 THEN 
            0 
        ELSE 
            @start*POWER(CAST(2 AS FLOAT),n.n-1) 
        END 
WHERE n <= 10 
ORDER BY n   )

SELECT TOP 1 @name=Name, 
FROM NearestNeighbor 
ORDER BY n,dist

Answer 1

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

Например, есть ли у вас какая-либо информация о том, где должны находиться конкретные транспортные средства? Они бегут по обычным маршрутам? У каждого грузовика есть номер, который соотносится с конкретным регионом в данный день? Если это так, вы можете сузить поиск только по тем строкам, предоставляя диапазон, в котором вы ожидаете найти результаты (затем расширять при необходимости) ... хотя на самом деле это всего лишь расширение метода, который уже предлагает Исаак Кунин.

Исаак Кунин дает хорошее представление о том, как быстро найти геоданные , зная, что у вас есть соседние соседи , но его метод может оказаться неэффективным, если ваше пространство выборки должно значительно увеличиться до встречи с соседом. Даже тогда требуется, чтобы вы немного знали о реальности, если ваши данные ... например, насколько велика для итеративного поиска?

Суть в следующем:

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

Answer 2

Первоначально на ум приходят две идеи:

1. Я думаю, вы могли бы создать поисковый индекс (используя что-то вроде Sphinx), который позволил бы вам делать очень быстрые поиски, но вам нужно былоосторожность при создании индекса с учетом ваших потребностей.Возможно, вы захотите установить lat / lng в качестве атрибута так, чтобы всегда было одно совпадение, а затем выполнить все обратные поиски геокодов, используя lat / lng в качестве фильтров.http://sphinxsearch.com/
2. Хотите ли вы полагаться на внешний API или у вас слишком много трафика для этого?Google предоставляет здесь API обратного геокодирования: http://maps.googleapis.com/maps/api/geocode/json?latlng=40.714224,-73.961452&sensor=true_or_false