GIS: PostGIS/PostgreSQL vs. MySql vs.SQL Server?
편집: Postgres를 Post와 함께 사용하고 있습니다.GIS는 몇 달째인데 만족하고 있습니다.
수백만 개의 지리 코드 기록을 분석해야 해 각각 위도와 경도가 있을 거야이 레코드에는 적어도 3종류의 데이터가 포함되어 있으며, 각 세트가 서로 영향을 미치는지 알아보려고 합니다.
이 모든 데이터에 대한 기본 데이터스토어에 가장 적합한 데이터베이스는 무엇입니까?제 바람은 이렇습니다.
- 난 DBMS에 익숙하고 Postgre에 가장 약하다.SQL, 하지만 다른 모든 것이 확인되면 기꺼이 배우겠습니다.
- GIS 질의에 적합합니다.구글 검색 결과 Postgre는SQL + 투고GIS가 가장 강할까?적어도 많은 제품들이 그것을 사용하고 있는 것 같다.MySql의 공간 확장 기능은 비교적 작은 것 같습니까?
- 저비용.SQL Server Express 2008 R2의 10GB DB 제한에도 불구하고 무료 버전의 이 제한 및 기타 제한을 감수하고 싶은지 잘 모르겠습니다.
- Microsoft와 적대적이지 않다.NET 프레임워크Connector/Net 6.3.4 덕분에 MySql은 C#과 잘 작동합니다.NET Framework 4 프로그램를 완전히 지원합니다.NET 4의 엔티티 프레임워크.비상업적인 Postgre를 찾을 수 없습니다.SQL에 상당하지만 Devart의 dotConnect for Postgre에 180달러를 지불하는 것은 반대하지 않습니다.SQL Professional Edition.
- R과 호환됩니다.이들 3개 모두 ODBC를 사용하여 R과 통신할 수 있으므로 문제가 되지 않을 수 있습니다.
MySql을 사용하여 이미 개발했지만, 필요하다면 변경할 수 있습니다.
3개의 데이터베이스를 모두 사용하여 이행하고 있기 때문에 오래된 포스트에 무언가를 추가할 수 있으면 좋겠습니다.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, 외부 키 및 공간 인덱스를 동일한 엔진에서 사용할 수 있게 된다는 것을 의미합니다.
3) 공간 기능은 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의 많은 이점을 포기하게 됩니다.
포스트기스
MySQL의 문제점을 고려하여 최종적으로 Postgis로 전환하였습니다.이 경험의 핵심은 다음과 같습니다.
1) 매우 안정적입니다.5년간 데이터 파손이 발생하지 않아 현재 centos 가상 머신에 약 25개의 Postgres/GIS 박스가 다양한 부하 수준에 놓여 있습니다.
2) 급속한 발전 속도 - 래스터, 토폴로지, 3D 지원이 최근의 예입니다.
3) 매우 활동적인 커뮤니티.Postgis irc 채널과 메일링 리스트는 뛰어난 자원입니다.Postgis 참조 매뉴얼도 훌륭합니다.http://postgis.net/docs/manual-2.0/
4) GeoServer나 GDAL 등 OSGeo의 엄브렐라 하의 다른 애플리케이션과 매우 잘 동작합니다.
5) 저장 프로시저는 기본 plpgsql(Python이나 R 등) 이외의 여러 언어로 작성할 수 있습니다.
5) Postgres는 ANSI 표준에 근접하는 것을 목적으로 하는 매우 표준 준거 풀기능 RDBMS입니다.
6) 창 기능 및 재귀 쿼리 지원 - MySQL이 아닌 SQL Server에서 지원합니다.이것에 의해, 보다 복잡한 공간 쿼리를 보다 깔끔하게 쓸 수 있게 되었습니다.
SQL Server.
SQL Server 2008의 공간 기능만을 사용해 왔습니다.이 릴리스에서는 CRS에서 다른 CRS로의 변환 지원이 부족하거나 공간 인덱스에 자체 파라미터를 추가할 필요가 있는 등 많은 문제가 해결되었습니다.
1) SQL Server의 공간 객체는 기본적으로 CLR 객체이기 때문에 구문이 거꾸로 느껴집니다.ST_Area(geom) 대신 geom이라고 씁니다.STArea()는 함수를 함께 연결하면 더욱 명확해집니다.함수 이름에 밑줄이 빠진 것은 사소한 문제일 뿐입니다.
2) SQL Server에 의해 받아들여진 무효 폴리곤이 다수 있어 ST_MakeValid 함수가 없기 때문에 다소 문제가 있을 수 있습니다.
3) Windows 전용.일반적으로 Microsoft 제품(ESRI 제품 등)은 서로 매우 잘 작동하도록 설계되어 있지만 표준 준수와 상호 운용성을 주요 목표로 하는 것은 아닙니다.Windows 전용 숍을 실행하고 있는 경우는, 이것은 문제가 되지 않습니다.
업데이트: SQL Server 2012를 사용해 본 결과 상당히 개선되었다고 할 수 있습니다.현재 양호한 지오메트리 검증 기능이 있으며, FULL GLOBE 오브젝트를 포함한 지리 데이터 타입이 지원되고 있습니다.이러한 오브젝트는 1개 이상의 반구를 차지하고 있는 오브젝트를 나타내며, 다른 오브젝트 중에서도 호(및 원)의 정확하고 콤팩트한 표현에 도움이 됩니다.링. CRS에서 다른 CRS로의 좌표 변환은 서드파티 라이브러리에서 수행해야 합니다.다만, 이것은 대부분의 애플리케이션에서는 show stopper는 아닙니다.
Postgis/MySQL과 일대일로 비교할 수 있을 만큼 큰 데이터셋과 함께 SQL Server를 사용해 본 적은 없지만, 내가 본 바로는 기능이 올바르게 작동하는 것을 볼 수 있었고, Postgis만큼 완전한 기능은 아니지만 MySQL의 제품에는 큰 개선이 있었습니다.
이렇게 장황한 답변에 죄송하고, 지난 몇 년간 제가 겪은 고통과 기쁨이 누군가에게 도움이 되기를 바랍니다.
자세한 비교에 관심이 있는 경우 "SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6" 및/또는 "SQL Server 2008 R2, Oracle 11G R2, PostgreSQL/PostgreSQL/PostGIS 1.5 Spatial Features 비교"를 권장합니다.
요점을 고려하면:
- DBMS: POST 설정에 정통합니다.Windows의 GIS 데이터베이스는 간단합니다.PgAdmin3 관리도 간단합니다.
- GIS 쿼리에 적합합니다.Post GIS는 3가지 중 가장 강력하며 Oracle Spatial만이 동등하지만 비용을 고려하면 부적격입니다.
- 저비용: 포스트용 +1확실히 GIS
- Microsoft와 적대적이지 않다.NET 프레임워크:적어도 ODBC를 통해 연결할 수 있어야 합니다(Postgres wiki 참조).
- R과의 호환성: 3가지 중 어느 것에도 문제가 없습니다.
확실히 포스트기스.그 이유는 이렇습니다.
- Postgres는 MySQL보다 성능이 월등히 우수합니다.서버는 폴트 톨러런스 기능이 강화되어 로드밸런싱, 캐싱 및 최적화를 위한 즉시 사용 가능한 도구를 갖추고 있습니다.
- 포스트지스는 GIS 앱의 표준이 되고 있다.
- 무료예요.
MySQL이 마침내 적절한 GIS 로직으로 추가된 메모입니다.
하지만 이 단계에서는 비용이나 성능에 대해 언급할 수 없습니다.
요즘 GIS 어플리케이션과 Post에서 PostGIS가 표준이 되고 있기 때문에 PostGIS가 가장 좋다.GIS는 무료입니다.성능 면에서 MySQL보다 월등히 우수합니다.
언급URL : https://stackoverflow.com/questions/3743632/gis-postgis-postgresql-vs-mysql-vs-sql-server
'programing' 카테고리의 다른 글
| MySQL SELECT를 사용하여 가상 열을 생성하는 방법 (0) | 2022.09.06 |
|---|---|
| 핸들러가 추상적이므로 인스턴스화할 수 없습니다. (0) | 2022.09.06 |
| 마리아에 대한 속편 오류DB (0) | 2022.09.06 |
| "java.net"을 해결 방법Bind Exception:이미 사용 중인 주소: JVM_Bind" 오류입니까? (0) | 2022.09.06 |
| SELECT 포함 삽입 (0) | 2022.09.06 |