데이터베이스/SQL: 경도/위도 데이터 저장 방법

데이터베이스/SQL: 경도/위도 데이터 저장 방법

퍼포먼스 질문...

나는 지리 위치 데이터(경도 및 위도)를 가진 주택 데이터베이스를 가지고 있다.

InnoDB 데이터베이스 엔진을 사용하여 MySQL(v5.0.24a)에 위치 데이터를 저장하는 가장 좋은 방법을 찾아서 x1에서 x2 사이의 모든 홈 레코드를 반환하는 많은 쿼리를 수행할 수 있도록 합니다.latitude및 y1 및 y2longitude.

지금 제 데이터베이스 스키마는

---------------------
Homes   
---------------------
geolat - Float (10,6)
geolng - Float (10,6)
---------------------

그리고 제가 묻고 싶은 것은

SELECT ... 
WHERE geolat BETWEEN x1 AND x2
AND geolng BETWEEN y1 AND y2

• 위에서 설명한 위도 및 경도 데이터를 Float(10,6)를 사용하여 경도/위도를 구분하여 MySQL에 저장하는 것이 가장 좋은 방법입니까?그렇지 않다면, 뭐가?데이터 유형으로는 Float, Decimal 및 Spatial이 있습니다.
• 이것이 퍼포먼스의 관점에서 SQL을 실행하는 최선의 방법입니까?그렇지 않다면, 뭐가?
• 다른 MySQL 데이터베이스 엔진을 사용하는 것이 의미가 있습니까?

업데이트: 아직 답변이 없습니다.

아래 3가지 답변이 있습니다.한 사람이 쓰라고 한다.Float한 분이 쓰라고 하시네요.INT한 분이 쓰라고 하시네요.Spatial.

그래서 MySQL "DEPLINE" 문을 사용하여 SQL 실행 속도를 측정했습니다.SQL 실행(결과 세트 가져오기)에는 전혀 차이가 없는 것으로 보입니다.INT또는FLOAT경도 및 위도 데이터 유형의 경우..

또, 「」를 사용하고 있는 것 같습니다.BETWEEN" 스테이트먼트가 " 를 사용하는 것보다 훨씬 빠릅니다.>" 또는<" SQL 문."를 사용하는 것이 3배 가까이 빠릅니다.BETWEEN"를 사용하는 것보다">" 및 "<" 스테이트먼트.

그러나 Spatial이 MySQL의 실행 버전(v5.0.24)에서 지원되는지 여부 및 지원되는지 여부는 불분명하기 때문에 Spatial을 사용할 경우 성능에 미치는 영향에 대해서는 아직 알 수 없습니다.

어떤 도움이라도 대단히 감사합니다.

float(10,6)도 괜찮습니다.

그 외의 복잡한 스토리지 스킴에서는, 보다 많은 번역이 필요하게 되어, 부동 소수점의 계산은 고속입니다.

MySQL에 대해 질문하시는 건 알지만, 공간 데이터가 비즈니스에 중요하다면 재고해 보는 것이 좋습니다.포스트그레SQL + 투고GIS는 또한 무료 소프트웨어이며 공간 및 지리적 데이터를 효율적으로 관리할 수 있다는 평판이 높습니다.많은 사람들이 Postgre를 사용한다.SQL은 PostGIS에만 해당됩니다.

MySQL 공간 시스템에 대해서는 잘 모르기 때문에 사용 예에 맞게 사용할 수 있을 것입니다.

여기서 "spacial"이 아닌 다른 데이터 유형을 사용할 때의 문제는 DBMS의 밝기에 따라 달라지며 MySQL은 일반적으로 가장 밝지 않은 하나의 차원에서만 최적화될 수 있다는 것입니다.

시스템은 경도 지수 또는 위도 지수 중 하나를 선택하고 이를 사용하여 검사할 행 집합을 줄일 수 있습니다.그러나 이 작업을 수행한 후에는 (a) 발견된 모든 행을 가져오고 스캔하여 "다른 차원"을 테스트하거나, (b) "다른 차원"에서 동일한 프로세스를 수행한 후 두 결과 세트를 일치시켜 두 행이 모두 표시되는지 확인할 수 있습니다.후자의 옵션은 특정 DBMS 엔진에서 구현되지 않을 수 있습니다.

공간 인덱스는 후자를 "자동"으로 하기 때문에 어떤 경우에도 공간 인덱스가 최고의 성능을 제공한다고 해도 무방할 것 같지만 다른 솔루션보다 크게 뛰어나지 않은 경우도 있을 수 있으며, 그럴 필요가 없습니다.이는 실제 데이터의 양이나 분포 등 모든 것에 따라 달라집니다.

플로트(트리) 인덱스는 정수 인덱스에 비해 플로트에서 '>'를 실행하는 데 시간이 오래 걸리기 때문에 정수 인덱스보다 느릴 수밖에 없습니다.하지만 이 효과가 실제로 눈에 띈다면 놀랄 것이다.

Google은 "Store locator" 예에서 float(10,6)를 사용합니다.그것으로 충분합니다.

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

또한 MySQL 5.6.x부터는 공간 확장 지원이 Post에 비해 훨씬 향상되었습니다.기능과 퍼포먼스의 GIS.

정수로 저장합니다.int, 4바이트)는 1/1,000,000번째 도로 표시됩니다.그것은 몇인치의 해상도를 줄것이다.

나는 MySQL에 어떠한 본질적인 공간 데이터 형식이라고 생각하지 않습니다.

플로트(10,6)

어디나 5555.123456 longitude 운신의 폭은?

대신 Float(9,6)을 의미하지 않나요?

동일한 스키마(float(10,6)와 쿼리(사각형 내 선택)를 가지고 있는데, 780,000개의 레코드가 있는 테이블에서 db엔진을 innoDB에서 myisam으로 전환하면 "point in rectangle look-up"의 속도가 두 배로 빨라집니다.

또한 모든 lng/lat 값을 데카르트 정수(x,y)로 변환하고 x,y에 2컬럼 인덱스를 생성했으며, 동일한 룩업에 대해 속도가 최대 27ms에서 1.3ms로 향상되었습니다.

데이터를 어떻게 사용하느냐에 따라 다릅니다.그러나 사실을 지나치게 단순화하면 십진법이 더 빠르지만 정확성은 떨어진다.자세한 내용은 이쪽:

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

또한 GPS 좌표의 표준은 ISO 6709에 명시되어 있습니다.

http://en.wikipedia.org/wiki/ISO_6709

나는 당신이 이 문제를 극복했을 거란 걸 알아요.누군가 지리 위치 데이터를 저장하려고 할 경우를 대비해서 이 질문에 다른 접근 방식을 추가하려고 합니다.위도 및 경도 정보를 지오해시로 인코딩할 수 있습니다.필요한 정밀도로 검색할 수 있는 접두사이기 때문입니다.쿼리를 시작 및 종료 접두사로 변환하여 프레픽스 검색을 수행할 수 있습니다.LIKE문의합니다.

언급URL : https://stackoverflow.com/questions/1370170/database-sql-how-to-store-longitude-latitude-data