MS SQL - Использует ли тип данных геометрии, чтобы найти расстояние значительно быстрее?

Question

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

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

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)

Хранимая процедура занимает 4 или 5 секунд.

Я заметил, что SQL Azure теперь поддерживает тип данных геометрии ... (это не было при создании базы данных).

Так что мой вопрос ... я бы испыталЗначительное увеличение скорости выполнения моей хранимой процедуры, что заставило бы меня потратить время, затрачиваемое на переключение объектов на использование типа данных геометрии?

Спасибо!

Стивен

Answer 1

Ваш вопрос: "Я бы испытал значительное увеличение скорости ... [путем] изменения вещей на использование типа данных геометрии?"казалось, игнорирует возможность того, что использование выделенных пространственных типов данных может на самом деле замедлить ход событий.Тем не менее, это может иметь место по нескольким причинам.

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

Второй, и более важный фактор, относится к точности, с которой выполняется вычисление расстояния:

1.) Если у вас есть спроецированные координаты (то есть UTM, национальная сетка или плоскость штата), то значения координат измеряются в линейных (x, y) единицах на плоской плоскости.Поэтому легко вычислить расстояние между двумя точками, используя базовую тригонометрию: Dist (xy) = SQRT ((x2 - x1) 2 + (y2 - y1) 2) Это простой математический метод, и вы вряд ли увидите многоразница в производительности, независимо от того, реализуете ли вы это самостоятельно или используете геометрический тип данных.

2.) Если у вас есть географические координаты (т. е. широта / долгота), то они измеряются в угловых единицах на эллипсоиде .Чаще всего это эллипсоид WGS84, используемый системами WGS84.Во многих случаях вы можете получить достаточно хорошее приближение расстояния между двумя точками на эллипсоиде, используя вместо этого простые сферические вычисления, как вы делаете это в своей хранимой процедуре.Тем не менее, форма Земли больше напоминает сплющенную сферу - она ​​шире на экваторе, чем на полюсах, и ваш расчет не учитывает такое уплощение Земли.Географический тип данных использует эллипсоидальные вычисления, основанные на модели эллипсоида предоставленной SRID, которые обязательно более сложны, но приведут к более точному ответу.

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

Answer 2

Я собираюсь начать новый пространственный проект, который будет работать на SQL Server 2008. Приложение будет принимать точечные данные в Lat Lng (WGS 84) и должно будет манипулировать этими данными для генерации линий и многоугольников и в конечном итоге отображать их.на карте Mercator (OSM в EPSG: 900913), представляющей собой прямоугольную систему.

Мы не собираемся получать данные по всему миру (только по частям Европы), поэтому нам не нужно беспокоиться острока даты.Я склоняюсь к идее сохранения всего в геометрическом типе данных в EPSG: 900913, иначе каждая точка, линия и многоугольник должны будут преобразовываться в систему координат отображения каждый раз, когда карта рисуется (и мы много рисуемкарт).

Если честно, я новичок в пространственной SQL Server, мой опыт был с Oracle.Я предполагаю, что я говорю о том, что выбор системы координат или типа геометрии зависит от того, что вы делаете с данными.Если вам нужно преобразовать большое количество данных между системами координат (и это то, что вы эффективно делаете при расчете расстояния), я бы подумал, что хранение данных в подходящей системе координат будет быстрее.

Итак, вопросы должны быть в том, переключились ли вы на собственную функцию расстояния, о которой упоминал Moontear, и если да, то как Microsoft реализовала ее?В конце концов, вычисление расстояния в прямоугольной системе должно быть намного проще или я запутываюсь?

Answer 3

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

Но я могу дать вам несколько советов:

Прежде всего: ваш SP, кажется, просто конвертирует некоторые географические данные. В SQL Server 2008 есть методы, позволяющие сделать это с новым типом географии. Посмотрите Методы OGC для экземпляров географии в справочнике по типу данных географии MSDN . Таким образом, новые методы, по крайней мере, дадут вам преимущество инкапсуляции.
Особенно интересным для вас должен быть метод STDistance ( STDistance (тип данных географии) ), потому что кажется, что именно этим занимается ваш SP, вычисляя расстояние от lat1, lon1 до lat2, lon2 , Я считаю, что встроенная функция работает быстрее, чем функция, созданная самим собой, но без тестирования я бы не узнала.

Используя умные слова MS, большой плюс пространственных типов данных имеет пространственные индексы. Если у вас есть база данных с большим количеством пространственных данных (ваш SP просто преобразует некоторые параметры), пространственные индексы принесут вам повышение производительности. Или цитата из документа пространственных данных :

Производительность запросов относительно пространственных данные еще больше усиливаются включение поддержки пространственного индекса в SQL Server 2008. Вы можете индексировать пространственные данные с адаптивной многоуровневой сеткой индекс, который интегрирован в SQL Ядро базы данных сервера.

А затем есть несколько статей, предлагающих более высокую производительность пространственно индексированных (это слово?) Данных по сравнению с обычными индексами:

Производительность, безусловно, повышается ... (из Производительность пространственного индекса SQL Server 2008 )

И еще есть хороший график, сравнивающий различные виды удержания пространственных данных друг с другом с точки зрения производительности: SQL Server 2008 Spatial - Производительность вызовов базы данных?

Итак, подведем итог: использование пространственного индекса WILL даст вам повышение производительности. Я не знаю, даст ли вам использование заранее определенных пространственных методов значительное повышение производительности.

Бонус: для начала работы с типами данных географии я предлагаю вам прочитать этот блог с большим количеством примеров: Демистификация пространственной поддержки в SQL Server 2008 .