mysql сложные - База данных / SQL:как хранить данные о долготе / широте?




для онлайн (9)

Я бы сохранил его как целые числа ( int , 4 байта), представленные в 1 / 1,000,000th градусов. Это даст вам разрешение в несколько дюймов.

Я не думаю, что в MySQL существует встроенный пространственный тип данных.

Вопрос о производительности ...

У меня есть база данных о домах с геолокационными данными (долгота и широта).

То, что я хочу сделать, это найти лучший способ хранения локальных данных в моем MySQL (v5.0.24a) с использованием базы данных InnoDB, чтобы я мог выполнять множество запросов, где я возвращаю все домашние записи, которые находятся между x1 и x2 и 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-движок MySQL?

ОБНОВЛЕНИЕ: все еще без ответа

У меня есть 3 разных ответа ниже. Один человек говорит использовать Float . Один человек говорит, чтобы использовать INT . Один человек говорит, что использует Spatial .

Поэтому я использовал инструкцию MySQL «EXPLAIN» для измерения скорости выполнения SQL. Похоже, что абсолютно никакой разницы в выполнении SQL (выбор набора результатов) не существует, если использовать INT или FLOAT для типа данных долготы и широты.

Также представляется, что использование оператора « BETWEEN » ЗНАЧИТЕЛЬНО быстрее, чем использование операторов « > » или « < » SQL. Почти в 3 раза быстрее использовать « BETWEEN », чем использовать инструкцию « > » и « < ».

С учетом сказанного я по-прежнему считаю, что влияние производительности будет на использование Spatial, поскольку для меня это непонятно, если оно поддерживается моей версией MySQL (v5.0.24) ... а также как я могу включить ее, если она поддерживается ,

Любая помощь будет очень восприимчива


Это зависит от того, как вы используете данные. Но при грубом чрезмерном упрощении фактов десятичное число быстрее, но менее точное в приближениях. Подробнее здесь:

http://msdn.microsoft.com/en-us/library/aa223970(SQL.80).aspx

Кроме того, стандарт для координат GPS указан в ISO 6709:

en.wikipedia.org/wiki/ISO_6709


Google использует float (10,6) в своем примере «Store locator». Для меня этого достаточно.

https://.com/a/5994082/1094271

Кроме того, начиная с MySQL 5.6.x, поддержка пространственных расширений намного лучше и сопоставима с PostGIS в функциях и производительности.


float (10,6) просто отлично.

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


Поплавок (10,6)

Где широта или долгота 5555.123456?

Разве вы не имеете в виду Float (9,6)?


У меня есть та же самая схема (float (10,6)) и запрос (выбор внутри прямоугольника), и я обнаружил, что переключение db-движка из innoDB в myisam удваивает скорость для «точки в прямоугольном поиске» в таблице с 780 000 записей.

Кроме того, я преобразовал все значения lng / lat в декартовые целые числа (x, y) и создал индекс с двумя столбцами на x, y, а моя скорость переместилась от ~ 27 мс до 1,3 мс для одного и того же вида.


Проблема с использованием любого другого типа данных, кроме «пространственного» здесь, заключается в том, что ваш «прямоугольный выбор» может (как правило, это зависит от того, насколько ярким является ваша СУБД), а MySQL, безусловно, не самый яркий) оптимизируется только в одном одномерное измерение.

Система может выбрать либо индекс долготы, либо индекс широты, и использовать его для уменьшения набора строк для проверки. Но после того, как это было сделано, есть выбор: (a) выборки всех найденных строк и их сканирование и проверка на «другое измерение» или (б) выполнение аналогичного процесса в «другом измерении», а затем сопоставляя эти два набора результатов, чтобы увидеть, какие строки отображаются в обоих. Этот последний вариант не может быть реализован как таковой в вашем конкретном СУБД.

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

Конечно, верно, что индексы float (tree) по необходимости медленнее, чем целые индексы, из-за более длительного времени, которое обычно требуется для выполнения '>' на поплавках, чем для целых чисел. Но я был бы удивлен, если бы этот эффект был действительно заметен.



Через union all объединяйте все таблицы в один список.

select name
from sqlite_master 
where type='table'

union all 

select name 
from sqlite_temp_master 
where type='table'




sql mysql database performance sqlperformance