Nice programing

GIS : PostGIS / PostgreSQL vs. MySql vs. SQL Server?

nicepro 2020. 11. 17. 21:03
반응형

GIS : PostGIS / PostgreSQL vs. MySql vs. SQL Server?


편집 : 저는 PostGIS와 함께 Postgres를 몇 달 동안 사용해 왔으며 만족합니다.

각각 위도와 경도가있는 수백만 개의 지오 코딩 된 레코드를 분석해야합니다. 이 기록에는 적어도 세 가지 유형의 데이터가 포함되어 있으며 각 세트가 다른 세트에 영향을 미치는지 확인하려고합니다.

이 모든 데이터의 기본 데이터 저장소에 가장 적합한 데이터베이스는 무엇입니까? 내 소망은 다음과 같습니다.

  • DBMS에 익숙합니다. 나는 PostgreSQL에 가장 약하지만 다른 모든 것이 확인되는지 배우고 싶습니다.
  • GIS 쿼리와 잘 작동합니다. Google 검색에 따르면 PostgreSQL + PostGIS가 가장 강력 할 수 있습니까? 적어도 많은 제품이 그것을 사용하는 것 같습니다. MySql의 Spatial Extensions가 비교적 최소한으로 보입니까?
  • 저렴한 비용. SQL Server Express 2008 R2의 10GB DB 제한에도 불구하고이 제한 사항과 무료 버전의 다른 제한 사항을 준수하고 싶은지 잘 모르겠습니다.
  • Microsoft .NET Framework와 적대적이지 않습니다. Connector / Net 6.3.4 덕분에 MySql은 C # 및 .NET Framework 4 프로그램에서 잘 작동합니다. .NET 4의 Entity Framework를 완벽하게 지원합니다. PostgreSQL Professional Edition 용 Devart의 dotConnect에 180 달러를 지불하는 것에 반대하지는 않지만 비상업적 PostgreSQL에 상응하는 항목을 찾을 수 없습니다.
  • R과 호환됩니다. 이 세 가지 모두 ODBC를 사용하여 R과 통신 할 수 있으므로 문제가되지 않을 수 있습니다.

이미 MySql을 사용하여 일부 개발을 수행했지만 필요한 경우 변경할 수 있습니다.


철저한 비교에 관심이있는 경우 "SQL Server 2008 Spatial, PostgreSQL / PostGIS 1.3-1.4, MySQL 5-6" 및 / 또는 "SQL Server 2008 R2, Oracle 11G R2, PostgreSQL / PostGIS 1.5 Spatial 비교"를 권장합니다. Boston GIS의 기능 " .

포인트 고려 :

  • 저는 DBMS에 익숙 합니다. Windows에서 PostGIS 데이터베이스를 설정하는 것은 쉽고 PgAdmin3 관리를 사용하는 것도 간단합니다.
  • GIS 쿼리와 잘 작동합니다. PostGIS는 확실히 세 가지 중에서 가장 강력하며 Oracle Spatial 만 비교할 수 있지만 비용을 고려하면 실격입니다.
  • 저렴한 비용 : 확실히 PostGIS의 경우 +1
  • Microsoft .NET Framework와 적대적이지 않음 : 최소한 ODBC를 통해 연결할 수 있어야합니다 ( Postgres 위키 참조 ).
  • R과 호환 가능 : 세 가지 중 어느 것도 문제가되지 않아야합니다.

세 가지 데이터베이스를 모두 사용하고 마이그레이션을 수행 했으므로 이전 게시물에 뭔가를 추가 할 수 있기를 바랍니다. 10 년 전 저는 GML에서 공간 데이터베이스로 거대한 4 억 5 천만 개의 공간 객체 데이터 셋을 넣는 임무를 받았습니다. 저는 MySQL과 Postgis를 사용해보기로 결정했습니다. 당시에는 SQL Server에 공간이 없었고 시작 분위기가 작았 기 때문에 MySQL이 적합 해 보였습니다. 그 후 저는 MySQL에 참여했고, 몇 번의 컨퍼런스에 참석 / 발언했으며, 최종적으로 버전 5.5로 출시 된 MySQL의 GIS 호환 기능에 대한 베타 테스트에 크게 참여했습니다. 이후 저는 공간 데이터를 Postgis로 마이그레이션하고 회사 데이터 (공간 요소 포함)를 SQL Server로 마이그레이션하는 작업에 참여했습니다. 이것이 제 결과입니다.

MySQL

1). 안정성 문제. 5 년 동안 몇 가지 데이터베이스 손상 문제가 발생했습니다. 인덱스 파일에서 myismachk를 실행해야만 해결할 수 있습니다.이 프로세스는 4 억 5 천만 행 테이블에서 24 시간 이상 걸릴 수 있습니다.

2). 최근까지만 MyISAM 테이블 만 공간 데이터 유형을 지원했습니다. 이것은 거래 지원을 원한다면 운이 없다는 것을 의미합니다. InnoDB 테이블 유형은 이제 공간 유형을 지원하지만 공간 데이터 세트의 일반적인 크기를 고려할 때 인덱스가 아닌 공간 유형은 그다지 유용하지 않습니다. http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html을 참조 하십시오. 컨퍼런스에 참석 한 저의 경험은 공간이 사후 고려 사항이라는 것이 었습니다. 복제, 파티셔닝 등을 구현했습니다. 하지만 공간에서는 작동하지 않습니다. 편집 : 다가오는 5.7.5 릴리스에서 InnoDB는 마침내 공간 열에 대한 인덱스를 지원할 것입니다. 즉, ACID, 외래 키 및 공간 인덱스를 마침내 동일한 엔진에서 사용할 수있게됩니다.

삼). 공간 기능은 Postgis 및 SQL Server 공간에 비해 매우 제한적입니다. 내가 가장 자주 실행하는 쿼리 중 하나 인 전체 지오메트리 필드에 대해 작동하는 ST_Union 함수는 아직 없습니다. 즉, 작성할 수 없습니다.

select attribute, ST_Union(geom) from some_table group by some_attribute

GIS 컨텍스트에서 매우 유용합니다. Select ST_Union(geom1, const_geom) from some_table즉, 기하학 중 하나가 하드 코딩 된 상수 기하학은 비교에서 약간 제한적입니다.

4). 래스터를 지원하지 않습니다. db 내에서 결합 된 벡터-래스터 분석을 수행 할 수 있다는 것은 매우 유용한 GIS 기능입니다.

5). 한 공간 참조 시스템에서 다른 공간 참조 시스템으로의 변환을 지원하지 않습니다.

6). Oracle이 인수 한 이후로 공간은 실제로 보류되었습니다.

전반적으로 MySQL에 공평하게 보이기 위해 몇 년 동안 웹 사이트, WMS 및 일반 공간 처리를 지원했으며 쉽게 설정할 수있었습니다. 단점은 데이터 손상이 문제 였고 MyISAM 테이블을 사용해야하므로 RDBMS의 많은 이점을 포기하게됩니다.

Postgis

MySQL과 관련된 문제를 감안할 때 궁극적으로 Postgis로 전환했습니다. 이 경험의 핵심 포인트입니다.

1). 극도의 안정성. 5 년 동안 데이터 손상이 없었으며 이제 다양한 수준의 부하에서 centos 가상 머신에 약 25 개의 Postgres / GIS 상자가 있습니다.

2). 빠른 개발 속도-래스터, 토폴로지, 3D 지원이 최근 사례입니다.

삼). 매우 활동적인 커뮤니티. Postgis irc 채널과 메일 링리스트는 훌륭한 리소스입니다. Postgis 참조 설명서도 훌륭합니다. http://postgis.net/docs/manual-2.0/

4). GeoServer 및 GDAL과 같은 OSGeo 우산 아래의 다른 응용 프로그램과 매우 잘 작동합니다.

5). 저장 프로시 저는 Python 또는 R과 같은 기본 plpgsql을 제외하고 여러 언어로 작성할 수 있습니다.

5). Postgres는 ANSI 표준에 가깝게 유지하는 것을 목표로하는 매우 표준을 준수하고 모든 기능을 갖춘 RDBMS입니다.

6). MySQL이 아닌 SQL Server에서 창 함수 및 재귀 쿼리를 지원합니다. 이로 인해 더 복잡한 공간 쿼리 작성이 더 깔끔해졌습니다.

SQL 서버.

저는 SQL Server 2008 공간 기능 만 사용했으며, 해당 릴리스의 많은 성가심 (한 CRS에서 다른 CRS 로의 변환에 대한 지원 부족, 공간 인덱스에 고유 한 매개 변수 추가 필요성)이 해결되었습니다.

1). As spatial objects in SQL Server are basically CLR objects, the syntax feels backwards. Instead of ST_Area(geom) you write geom.STArea() and this becomes even more obvious when you chain functions together. The dropping of the underscore in function names is merely a minor annoyance.

2). I have had a number of invalid polygons that have been accepted by SQL Server, and the lack of a ST_MakeValid function can make this a bit painful.

3). Windows only. In general, Microsoft products (like ESRI ones) are designed to work very well with each other, but don't always have standard's compliance and interoperability as primary objectives. If you are running a windows only shop, this is not an issue.

UPDATE: having played a bit with SQL Server 2012, I can say that it has been improved significantly. There is now a good geometry validation function, there is good support for the Geography data type, including a FULL GLOBE object, which allows representing objects that occupy more than one hemisphere and support for Compound Curves and Circular Strings which is useful for accurate and compact representations of arcs (and circles) among other things. Transforming coordinates from one CRS to another still needs to be done in 3rd party libraries, though this is not a show stopper in most applications.

I haven't used SQL Server with large enough datasets to compare one on one with Postgis/MySQL, but from what I have seen the functions behave correctly, and while not quite as fully featured as Postgis, it is a huge improvement on MySQL's offerings.

Sorry for such a long answer, I hope some of the pain and joy I have suffered over the years might be of help to someone.


PostGis definitely. Here's why.

  1. Postgres is far superior to MySQL in performance. Server is more fault tolerant, has out of the box tools for load-balancing, caching and optimization.
  2. PostGIS is becoming a standard in GIS apps.
  3. It's free.

Just an note that MySQL has finally added in proper GIS logic.

http://dev.mysql.com/doc/refman/5.6/en/functions-for-testing-spatial-relations-between-geometric-objects.html

But I can't comment on cost or performance at this stage


PostGIS is best because it is becoming a standard in GIS applications these days and PostGIS is free. It is far superior to MySQL in performance

참고URL : https://stackoverflow.com/questions/3743632/gis-postgis-postgresql-vs-mysql-vs-sql-server

반응형