Как хранить географические местоположения с внешними ключами?
В настоящее время я занимаюсь разработкой приложения для определения местоположения. Одна из основных функций приложения - определение местоположения точек на основе критериев поиска и определение местоположения точек в заданном диапазоне из одной точки.
Очевидным выбором было хранить значения lat/lon как числа с плавающей точкой или целые числа, но я нашел пространственные типы данных в MySQL и начал копать. К сожалению, если я прав, пространственные индексы поддерживаются только в MyISAM, который не поддерживает внешние ключи (что мне нужно).
Итак, что будет лучше (и быстрее) - хранить широту / долготу как обычные числа или использовать тип POINT без индекса?
2 ответа
Редактировать. Чтобы ответить на вопрос в вашем названии, короче говоря, вы не можете, без некоторых хакеров (см. Ниже). Однако я столкнулся с этим сегодня, когда отвечал на другой вопрос о MySQL, http://mysqlserverteam.com/innodb-spatial-indexes-in-5-7-4-lab-release/. Я понятия не имею, когда он будет запущен, но если вы сможете ждать так долго, у вас наконец-то появятся внешние ключи и пространственные индексы в одном и том же движке в MySQL. Дальнейшие исследования показывают, что на самом деле пространственные индексы будут выпущены в MySQL 5.7.5, что может показаться неизбежным, хотя это помечено как веховой выпуск.
Что касается вашего другого вопроса, это будет зависеть от размера вашей таблицы, но наличие составного индекса по широте и долготе, сохраненного в виде чисел с плавающей запятой, значительно превзойдет полное сканирование таблицы по неиндексированной точке за пределами простого подсчета строк - к сожалению, я не могу дать вам точные цифры, но в прошлый раз, когда я пробовал это на нескольких миллионах строк, мы смотрели на порядки.
РЕДАКТИРОВАТЬ: хотя это и отвечает на ваш оригинальный вопрос, как уже говорилось, пространственный индекс в Point значительно превзойдет составной индекс в широте / долготе, а также позволит вам использовать пространственные функции MySQL. Однако, как вы указали, это будет работать только в MyISAM, поэтому вы все еще застряли, если хотите, чтобы пространственные индексы, типы геометрии и внешние ключи были все сразу, пока InnoDB не добавит пространственную индексацию, которая находится в конвейере, как указано в вышеуказанная ссылка.
Здесь есть предложение: https://dba.stackexchange.com/questions/49307/spatial-index-on-an-innodb-table о том, как сохранить ваши пространственные данные в InnoDB и MyISAM, выполнить пространственный поиск в MyISAM, а затем присоединение к общему ключу и запрос атрибутов в InnoDB, но это кажется довольно хакерским и неэффективным, и есть вопросы о различном поведении блокировки между двумя движками и о том, как это может работать в масштабе.
Это будет хороший день, когда InnoDB наконец-то поддержит пространственную индексацию, это было много лет в ожидании.
Вы можете использовать вместо Quadkey. Переведите значения x и y в двоичный файл, а затем объедините двоичные файлы. Точки сортируются по z-кривой, то есть кривой монстров. Обладает очень хорошими пространственными свойствами. Вы можете проверить верхнюю границу с помощью самых значимых битов.