데이터베이스 / SQL : 경도 / 위도 데이터를 저장하는 방법은 무엇입니까?

데이터베이스 / SQL : 경도 / 위도 데이터를 저장하는 방법은 무엇입니까?

---

성능 질문 ...

지리적 위치 데이터 (경도 및 위도)가있는 주택 데이터베이스가 있습니다.

내가 원하는 것은 InnoDB 데이터베이스 엔진을 사용하여 내 MySQL (v5.0.24a)에 위치 데이터를 저장하는 가장 좋은 방법을 찾는 것입니다. 그러면 그 사이에있는 모든 홈 레코드를 반환하는 많은 쿼리를 수행 할 수 있습니다. 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

• 위에서 설명한 것이 Float (10,6)를 사용하여 위도 및 경도 데이터를 MySQL에 저장하고 경도 / 위도를 분리하는 가장 좋은 방법입니까? 그렇지 않다면 무엇입니까? Float, Decimal 및 Spatial이 데이터 유형으로 존재합니다.
• 이것이 성능 관점에서 SQL을 수행하는 가장 좋은 방법입니까? 그렇지 않다면 무엇입니까?
• 다른 MySQL 데이터베이스 엔진을 사용하는 것이 합리적입니까?

업데이트 : 아직 답이 없음

아래에 세 가지 답변이 있습니다. 한 사람이 Float. 한 사람이 INT. 한 사람이 Spatial.

그래서 SQL 실행 속도를 측정하기 위해 MySQL "EXPLAIN"문을 사용했습니다. 사용하는 경우 SQL 실행 (결과 집합 페칭)의 절대적 차이가 존재 함을 표시 INT하거나 FLOAT위도와 경도 데이터 타입 ...

또한 " BETWEEN"문을 사용하는 것이 " >"또는 " <"SQL 문을 사용하는 것보다 훨씬 빠릅니다 . BETWEEN" >"및 " <"문 을 사용하는 것보다 " "를 사용하는 것이 거의 3 배 더 빠릅니다 .

그래도 Spatial을 사용하는 경우 성능에 어떤 영향을 미칠지 아직 확실하지 않습니다. 내 버전의 MySQL (v5.0.24)에서 지원되는지 여부와 지원되는 경우 활성화하는 방법이 명확하지 않기 때문입니다. .

어떤 도움이라도 대단히 감사하겠습니다.

---

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

다른 복잡한 저장 체계는 더 많은 변환이 필요하며 부동 소수점 수학은 매우 빠릅니다.

---

MySQL에 대해 질문하고 있다는 것을 알고 있지만 공간 데이터가 비즈니스에 중요한 경우 재고를 원할 수 있습니다. PostgreSQL + PostGIS 는 또한 무료 소프트웨어이며 공간 및 지리 데이터를 효율적으로 관리하는 것으로 명성이 높습니다. 많은 사람들이 PostGIS 때문에 PostgreSQL을 사용합니다.

그래도 MySQL 공간 시스템에 대해 잘 모르기 때문에 아마도 사용 사례에 충분히 잘 작동 할 것입니다.

---

여기서 "공간"이 아닌 다른 데이터 유형을 사용할 때의 문제는 "직사각형 선택"유형이 하나에서만 최적화 될 수 있다는 것입니다 (일반적으로 이것은 DBMS가 얼마나 밝은 지에 따라 다르며 MySQL은 일반적으로 가장 밝은 것은 아닙니다). 단일 차원.

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

공간 인덱스는 일종의 후자를 "자동"으로 수행하므로 공간 인덱스가 어떤 경우에도 최상의 성능을 제공한다고 말하는 것이 안전하다고 생각하지만 다른 솔루션보다 성능이 크게 향상되지 않을 수도 있습니다. 귀찮게 할 가치가 없다는 것입니다. 이것은 실제 데이터의 양과 분포 등과 같은 모든 종류의 것에 달려 있습니다.

실수 (트리) 인덱스가 정수 인덱스보다 필연적으로 느리다는 것은 확실히 사실입니다. 왜냐하면 일반적으로 정수보다 실수에서 '>'를 실행하는 데 더 오래 걸리기 때문입니다. 그러나이 효과가 실제로 눈에 띄면 놀랄 것입니다.

---

int1 / 1,000,000도 단위로 표현 되는 정수 ( , 4 바이트) 로 저장합니다 . 그것은 당신에게 몇 인치의 해상도를 줄 것입니다.

MySQL에는 고유 한 공간 데이터 유형이 없다고 생각합니다.

---

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

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

또한 MySQL 5.6.x부터 공간 확장 지원은 기능과 성능면에서 PostGIS와 훨씬 더 우수하고 비슷합니다.

---

플로트 (10,6)

위도 또는 경도 5555.123456은 어디에 있습니까?

대신 Float (9,6)을 의미하지 않습니까?

---

정확히 동일한 스키마 (float (10,6))와 쿼리 (사각형 내부 선택)가 있고 db 엔진을 innoDB에서 myisam으로 전환하면 테이블에서 "사각형의 포인트 조회"속도가 두 배가되는 것을 발견했습니다. 780,000 개의 레코드로.

또한 모든 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

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