Base de données/SQL: comment stocker des données de longitude / latitude?
question de Performance ...
j'ai une base de données des maisons qui ont des données de géolocalisation (longitude et latitude).
ce que je veux faire est de trouver le meilleur moyen de stocker les données de localisation dans mon MySQL (v5.0.24 a) en utilisant le moteur de base de données InnoDB pour que je puisse effectuer beaucoup de requêtes où je retourne tous les enregistrements de la maison qui sont entre x1 et x2 latitude et y1 et y2 longitude .
maintenant, mon le schéma de la base de données est
---------------------
Homes
---------------------
geolat - Float (10,6)
geolng - Float (10,6)
---------------------
et ma requête est:
SELECT ...
WHERE geolat BETWEEN x1 AND x2
AND geolng BETWEEN y1 AND y2
- est ce que j'ai décrit ci-dessus la meilleure façon de stocker le données de latitude et de longitude dans MySQL en utilisant le flotteur (10,6) et en séparant la longitude / latitude? Si non, qu'est-ce que? Il existe Float, décimal et même Spatial comme un type de données.
- Est-ce la meilleure façon d'effectuer la Du point de vue de la performance? Si non, qu'est-ce que?
- utilise un MySQL différent moteur de base de données logique?
mise à jour: Toujours sans réponse
j'ai 3 réponses différentes ci-dessous. Une personne dit d'utiliser Float . Une personne dit d'utiliser INT . Une personne dit d'utiliser Spatial .
J'ai donc utilisé la déclaration MySQL" expliquer " pour mesurer la vitesse D'exécution SQL. Il semble qu'absolument aucune différence en SQL l'exécution (ensemble de résultats) existe si vous utilisez INT ou FLOAT pour le type de données longitude et latitude..
il apparaît également que l'utilisation du " BETWEEN " statement est beaucoup plus rapide que l'utilisation du " > " ou " < " SQL statements. Il est presque 3 fois plus rapide d'utiliser " BETWEEN "que d'utiliser le" > " et " < ".
cela étant dit, Je ne suis toujours pas sûr de ce que la l'impact sur les performances le serait si J'utilisais Spatial car je ne sais pas s'il est supporté par ma version de MySQL (v5.0.24) ... ainsi que la façon dont je l'active si elle est prise en charge.
toute aide serait grandement appréciée
9 réponses
float (10,6) est très bien.
tous les autres schémas de stockage alambiqués nécessiteront plus de traduction, et les calculs à virgule flottante sont très rapides.
je sais que vous posez des questions sur MySQL, mais si les données spatiales sont importantes pour votre entreprise, vous voudrez peut-être reconsidérer. PostgreSQL + PostGIS sont également des logiciels libres, et ils ont une grande réputation pour la gestion efficace de données géographiques et spatiales. Beaucoup de gens utilisent PostgreSQL uniquement à cause de PostGIS.
Je ne sais pas grand chose sur le système spatial MySQL cependant, alors peut-être qu'il fonctionne assez bien pour votre de cas d'utilisation.
le problème avec l'utilisation d'un autre type de données que" spatial "ici est que votre type de" sélection rectangulaire " peut (généralement, cela dépend de la luminosité de votre SGBD - et MySQL n'est certainement pas généralement le plus brillant) être optimisé dans une seule dimension.
le système peut choisir l'indice de longitude ou l'indice de latitude, et utiliser cela pour réduire l'ensemble des lignes à inspecter. Mais après avoir fait cela, il y a un choix de: (A) les lignes et le balayage de ceux-ci et le test pour l ' "autre dimension", ou (b) faire le processus similaire sur l ' "autre dimension" et puis en assortissant ces deux ensembles de résultats pour voir quelles lignes apparaissent dans les deux. Cette dernière option ne peut pas être implémentée en tant que telle dans votre moteur de SGBD particulier.
les indices spatiaux font en quelque sorte ce dernier "automatiquement", donc je pense qu'on peut dire qu'un indice spatial donnera la meilleure performance dans tous les cas, mais il se peut aussi que il ne dépasse pas de manière significative les autres solutions, et que ce n'est pas la peine de s'embêter. Cela dépend de toutes sortes de choses comme le volume et la distribution de vos données etc. etc.
il est certainement vrai que les index float (tree) sont nécessairement plus lents que les index entiers, en raison du temps plus long qu'il faut généralement pour exécuter '>' sur les floats qu'il ne le fait sur les entiers. Mais je serais surpris si cet effet était réellement perceptible.
je le stockerais comme des entiers ( int , 4-octets) représentés en 1/1 000 000 th degrés. Qui vous donnerait une résolution de quelques centimètres.
Je ne pense pas qu'il y ait de type de données spatiales intrinsèques dans MySQL.
Float (10,6)
Où est la latitude ou la longitude 5555.123456?
ne voulez-vous pas dire flottant(9,6) à la place?
Google utilise float (10,6) dans son exemple "Store locator". C'est assez pour moi d'aller avec qui.
https://stackoverflow.com/a/5994082/1094271
aussi, commençant MySQL 5.6.x, spatial extensions support est beaucoup mieux et comparable à PostGIS en termes de fonctionnalités et de performances.
j'ai trouvé cette réponse utile, peut-être cela peut vous aider aussi?: Problème de Stockage des valeurs de Latitude et Longitude des bases de données MySQL
j'ai exactement le même schéma (float(10,6)) et la requête (sélection à l'intérieur d'un rectangle) et j'ai trouvé que la commutation du moteur db de innoDB à myisam doublé la vitesse pour un" point dans la recherche rectangle " dans un tableau avec 780 000 enregistrements.
de plus, j'ai converti toutes les valeurs lng/lat en entiers cartésiens (x,y) et j'ai créé un index à deux colonnes sur les x,y et ma vitesse est passée de ~27 ms à 1.3 ms pour la même recherche.
Cela dépend vraiment de la façon dont vous utilisez les données. Mais dans une simplification grossière des faits, décimal est plus rapide mais moins précis dans les approximations. Plus d'informations ici:
http://msdn.microsoft.com/en-us/library/aa223970 (SQL.80).aspx
en outre, la norme pour les coordonnées GPS est spécifiée dans la norme ISO 6709: