Ответ 1
float (10,6) просто отлично.
Любые другие схемы свернутого хранения потребуют большего количества переводов, и математика с плавающей запятой будет довольно быстрой.
База данных /SQL: как хранить данные о долготе/широте?
Вопрос о производительности...
У меня есть база данных домов, в которых есть данные геолокации (долгота и широта).
Что я хочу сделать, это найти лучший способ хранения локальных данных в моем MySQL (v5.0.24a) с использованием базы данных InnoDB, чтобы я мог выполнять множество запросов, где я возвращаю все домашние записи которые находятся между x1 и x2 latitude и y1 и y2 longitude.
В настоящее время моя схема базы данных
---------------------
Homes
---------------------
geolat - Float (10,6)
geolng - Float (10,6)
---------------------
И мой запрос:
SELECT ...
WHERE geolat BETWEEN x1 AND x2
AND geolng BETWEEN y1 AND y2
- Это то, что я описал выше, лучший способ сохранить данных широты и долготы в MySQL с использованием Float (10,6) и выделения долготы/широты? Если нет, то что? Существуют типы Float, Decimal и даже Spatial в качестве типа данных.
- Это лучший способ выполнить SQL с точки зрения производительности? Если нет, то что?
- Использует ли другой MySQL двигатель базы данных имеет смысл?
ОБНОВЛЕНИЕ: еще без ответа
У меня есть 3 разных ответа ниже. Один человек говорит, чтобы использовать Float. Один человек говорит использовать INT. Один человек говорит использовать Spatial.
Итак, я использовал инструкцию MySQL "EXPLAIN" для измерения скорости выполнения SQL. По-видимому, при использовании INT или Float для типа данных долготы и широты существует абсолютно никакой разницы в выполнении SQL (выбор набора результатов).
Также представляется, что использование оператора < BETWEEN является СУЩЕСТВУЮЩИМ быстрее, чем использование операторов SQL > "или <". Он почти в 3 раза быстрее использовал "BETWEEN", чем использовать инструкцию ">" и "<".
С учетом сказанного я по-прежнему считаю, что влияние производительности будет связано с использованием Spatial, поскольку он неясен для меня, если он поддерживается моей версией MySQL (v5.0.24)... а также как я включаю он, если поддерживается.
Любая помощь будет очень восприимчивой
Ответы
Ответ 2
Я знаю, что вы спрашиваете о MySQL, но если пространственные данные важны для вашей компании, вам может потребоваться пересмотреть. PostgreSQL + PostGIS - также бесплатное программное обеспечение, и у них отличная репутация для эффективного управления пространственными и географическими данными. Многие используют PostgreSQL только из-за PostGIS.
Я мало знаю о пространственной системе MySQL, поэтому, возможно, он работает достаточно хорошо для вашего прецедента.
Ответ 3
Проблема с использованием любого другого типа данных, кроме "пространственного" здесь, заключается в том, что ваш "прямоугольный выбор" может (как правило, это зависит от того, насколько ярка ваша СУБД), а MySQL, безусловно, не самый яркий) оптимизированы в одном измерении.
Система может выбрать либо индекс долготы, либо индекс широты, и использовать его для уменьшения набора проверяемых строк. Но после того, как это было сделано, есть выбор: (a) выборки всех найденных строк и их сканирование и проверка на "другое измерение" или (б) выполнение аналогичного процесса в "другом измерении", а затем сопоставляя эти два набора результатов, чтобы увидеть, какие строки отображаются в обоих. Этот последний вариант не может быть реализован как таковой в вашем конкретном СУБД.
Пространственные индексы сортируют последнее "автоматически", поэтому я считаю, что можно с уверенностью сказать, что пространственный индекс даст лучшую производительность в любом случае, но также может быть, что он не значительно превзошел другие решений, и что это просто не стоит беспокоить. Это зависит от всех видов вещей, таких как объем и распределение в ваших фактических данных и т.д. И т.д.
Конечно, индексы float (tree) по необходимости медленнее, чем целые индексы, из-за более длительного времени, которое обычно требуется для выполнения ' > ' на поплавках, чем для целых чисел. Но я был бы удивлен, если бы этот эффект был действительно заметным.
Ответ 4
Я бы сохранил его как целые числа (int, 4 байта), представленные в 1/1,000,000th градусов. Это даст вам разрешение в несколько дюймов.
Я не думаю, что в MySQL есть встроенный пространственный тип данных.
Ответ 5
Поплавок (10,6)
Где широта или долгота 5555.123456?
Разве вы не имеете в виду Float (9,6)?
Ответ 6
Google использует float (10,6) в своем примере "Store locator". Это достаточно для меня, чтобы пойти с этим.
fooobar.com/questions/18909/...
Кроме того, начиная с MySQL 5.6.x, поддержка пространственных расширений намного лучше и сопоставима с PostGIS в функциях и производительности.
Ответ 7
Я нашел этот ответ полезным, может быть, он тоже может вам помочь?: Проблема Сохранение значений широты и долготы в базе данных MySQL
Ответ 8
У меня есть та же самая схема (float (10,6)) и запрос (выбор внутри прямоугольника), и я обнаружил, что переключение db-движка из innoDB в myisam удваивает скорость для "точки в прямоугольном поиске", в таблице с 780 000 записей.
Кроме того, я преобразовал все значения lng/lat в декартовые целые числа (x, y) и создал индекс с двумя столбцами на x, y, а моя скорость переместилась от ~ 27 мс до 1,3 мс для одного и того же вида.
Ответ 9
Это зависит от того, как вы используете данные. Но при грубом чрезмерном упрощении фактов десятичное число быстрее, но менее точное в приближениях. Подробнее здесь:
http://msdn.microsoft.com/en-us/library/aa223970(SQL.80).aspx
Кроме того, стандарт для GPS-координат указан в ISO 6709: