PostgreSQL 대 MySQL : 공간 기능 비교

우리는 공간 데이터 구성 요소가있는 웹 애플리케이션을 구축하는 중입니다. 처음에 공간 데이터 비교는 주어진 점을 취하고 일치하는 겹치는 공간 다각형을 반환합니다.

우리 데이터베이스에는 일반적인 관계형 데이터베이스에서 찾을 수있는 모든 일반적인 요소를 포함하는 다른 많은 구성 요소가 있습니다.

우리는 프로젝트에서 사용할 데이터베이스 솔루션을 선택해야하는 시점에 있습니다.

모든 프로젝트 멤버는 MySQL의 구현 및 관리에 익숙하지만 모든 연구에 따르면 PostgreSQL이 특히 postGIS를 사용하는 공간 데이터와 관련하여 더 나은 솔루션이라고합니다.

우리는 응용 프로그램이 많은 동시 사용자와 함께 많은 행동을 경험할 것으로 기대합니다.

공간 데이터 구성 요소와 함께 RDBMS로 MySQL을 사용한 경험이있는 사람은 장기적인 조언 / 경험이 있습니까?

친숙 함을 제외하고 PostGIS를 사용하는 데 단점이 있습니까?

나는 MySQL에 대한 장점 / 단점에 대해 말할 수는 없지만 PostGIS 코드는 최고 (속도 / 기능면에서) 가장 성숙하고 (테스트 / 실제 노출면에서) 가장 널리 간주됩니다 ) 사용 가능

예를 들어, PGEast 2010에서 FAA의 일부 사람들은 공항 데이터베이스 (AeroNav 및 다른 사람들이 사용하여 차트 편집)를 Oracle의 Postgres / PostGIS로 변환하는 것에 대해 이야기했습니다. avationDB 사이트는 또한 포스트 그레스 (8.0)의 상단에 내장되어 있습니다.

GIS 관련 쿼리가 당신이하고있는 일의 핵심이라면 Postgres와 함께하는 것이 좋습니다. 관계형 데이터베이스에서도 일반적으로 수행하는 다른 모든 것을 확실히 처리 할 수 ​​있습니다.

MySQL에서 전환하는 데있어 Postgres 의 문서 는 최고이며, Oostgres Wiki 에는 MySQL에서 Postgres로 전환하는 방법에 대한 섹션도 있습니다 .
초기 학습 곡선은 약간 가파르고 데이터베이스와 저장 프로 시저 (MySQL 용으로 이미 작성한 경우)를 조정해야 할 수도 있지만 극복 할 수없는 작업은 아닙니다.

몇 주 안에 전환 할 수있을만큼 충분히 픽업 할 수 있어야하며, 개발 데이터베이스를 설정하면 한 달 안에 일상적인 작업에 정통 할 수 있으며 설명서에서 어디를 볼지 알고 있다고 확신 할 수 있습니다 일상적이지 않은 사람들을 위해.

매우 중요한 것들에 대해 말하면. 다음은 PostGIS가 지원하는 MySQL 및 MariaDB에는 전혀없는 목록입니다.

• 계산시 SRID, 포인트에 다른 SRID를 부여하면 다른 값을 얻을 수 있습니다. 이것은 prop 집계 함수입니다 : 내 지식을 최대한 활용하기 위해 MySQL은 공간 집계 함수를 제공하지 않습니다.

가장 가까운 이웃 : PostGIS 만 KNN을 지원합니다. 인덱스 만 사용하여 가장 가까운 점을 찾습니다 : 모든 점에서 거리를 계산할 필요가 없습니다! MySQL은 사양을 위반하고 두 값이 동일한 SRID를 갖는지 확인합니다. PostGIS는 원활한 SRID 인식을 가능하게 하는 pro4j 정의 데이터베이스와 함께 제공됩니다 . SRID를 설정하고 ST_Transform( MySQL이없는 함수)를 호출 하면 좌표가 다시 투영됩니다.

MySQL에서는 실제 SRID 값에 관계없이 SRID 0을 가정하여 모든 계산이 수행됩니다. SRID 0은 축에 지정된 단위가없는 무한 평면 데카르트 평면을 나타냅니다. 향후 계산시 지정된 SRID 값을 사용할 수 있습니다. SRID 0 동작을 보장하려면 SRID 0을 사용하여 지오메트리 값을 생성하십시오. SRID가 지정되지 않은 경우 SRID 0은 새 지오메트리 값의 기본값입니다.

• 래스터 : 래스터 세대 여기 기능의 톤이 추출있다. 히트 맵 등을 생성 할 수 있습니다.

• 지리 , PostGIS는 직교 수학을 전혀 사용하지 않는 예상치 못한 지리 유형을 지원합니다. 편평 구면에서 작동하는 관련 기능이 완전히 느립니다. 반대로 MySQL은 두 지점에서 지리적 SRS로 경계 상자를 만들 수도 없습니다.

• 벡터 지오메트리와는 달리 토폴로지 는 토포 지오메트리가 노드와 관계를 저장합니다. 노드를 움직이면 가장자리도 움직이고 새로운면이 생깁니다. 또한 가장자리를 강제로 지정하여 라우팅에 이상적입니다. PgRouting이 수행하는 작업의 100 %를 하위 지점 으로 MySQL에서 사용할 수 없으므로 그 위에 Google지도 등을 만들 수 없습니다 .

• 지오 코딩 : contrib 디렉토리에는 인구 조사 데이터를 처리하는 지오 코더 확장 이 있으며 해당 데이터를 설치하는 로더가 있습니다.

• 주소 표준화 : 쉬운 구문 분석, 저장 및 비교를 위해 주소 정규화를 처리 하는 확장 이 있습니다.

• SQL-MM 기능 단순히 찾을 수 없습니다, CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVE또는 MULTISURFACEMySQL의에.

• 코드 : PostGIS는 3dm, 3dz 및 4d 모양과 점을 지원할 수 있습니다

• MySQL은 r- 트리 인덱스 만 지원합니다. PostGIS는 r-tree (gist / gin) 및 BRIN (대형 지오메트리 테이블의 경우)을 지원합니다

• 집계 함수 : 내가 아는 한 MySQL은 공간 집계 함수를 제공하지 않습니다.

• K 가장 가까운 이웃 : Only PostGIS KNN을 지원합니다 . 인덱스 만 사용하여 가장 가까운 점을 찾으십시오. 모든 점에서 거리를 계산할 필요가 없습니다!

• 인덱싱. PostgreSQL을 사용하면 공간 인덱스 (gist / gin 인덱스)에 모든 데이터를 저장할 수 있습니다. 예를 들어, year(또는 다른 비 공간 데이터)와 같은 인덱스 geom에 저장할 수 있습니다 . 보다btree_gin 하고 btree_gist이 작업을 수행하는 방법에 대한 자세한 정보를 얻을 수 있습니다.

또한 아마도 PostGIS가 지원하는 200 개 이상의 기능 수 있습니다 .

요컨대, MySQL은 PostGIS 자체를 소유하지 않으며 그것을 알고 있습니다. PostGIS는 짐승입니다. 이 내용 중 일부를 설명하고 싶었습니다.

나는 첫 번째 답변에 대한 모든 진술에 전적으로 동의하지만 내 경험을 공유합니다-나는 국가의 국가 도로 관리국 (생산 비평가, 높은 교통 사이트)에서 이것을 만들었습니다. 웹 응용 프로그램은 MySQL과 PostgreSQL / PostGIS에 의해 제공되는 것이 좋습니다.

모든 "일반적인"것들에 대해 웹 응용 프로그램은 MySQL 기반 CMS와 완벽하게 작동합니다. 모든 공간 작업에서 동일한 웹 앱은 PostgreSQL / PostGIS 기반 사용자 정의 개발과 함께 완벽하게 작동합니다. 첫 번째 구성 요소는 정상적인 MySQL 기술로 쉽게 개발되고 유지 관리됩니다. 두 번째 구성 요소는 처음에 조금 더 많은 연구 노력이 필요했습니다.

익숙하지 않은 PostgreSQL / PostGIS에서 비용이 많이 드는 일반 항목의 전체 구현을 강요 할 필요가 없으며 MySQL에서도 지형 공간 관련 항목의 차선 구현을 강요하지 않아도됩니다. 모든 플레이어가 맞출 수있는 곳에서 플레이하게하십시오.