고성능 웹 애플리케이션을위한 최고의 GIS 시스템-PostGIS vs MongoDB

위치 데이터를 기반으로 웹 / 모바일 애플리케이션을 작업 중입니다. 이미 MongoDB에 익숙하기 때문에 mongo의 지형 공간 색인 생성이 내 요구에 매우 적합하다는 것을 알았습니다. 주로 간단한 / 짧은 위치 지점을 다루고 있으므로 Mongo 2d 인덱싱이 좋습니다.

그 길을 따라 안정적이고 성숙한 방법으로 PostGIS를 선택했습니다. 그리고 그 멋진 기능 세트. 그러나 내 주요 관심사는 내 데이터가 위치에 크게 의존하기 때문에 성능입니다 (대부분의 DB 호출의 70-80 %가 위치를 처리합니다).

나는 foursquare와 같은 고성능 웹 앱에서 이미 사용했기 때문에 mongo를 좋아합니다. 그러나 PostGIS는 주로 정부 / 기업 프로젝트 (주로 웹 / 모바일 앱이 아닌)에서 사용되는 것을 보았습니다. 웹 / 모바일 앱에 적합한 GIS DB를 선택하기 위해 지금 당황한 적이 있습니까? 어떤 제안이 있습니까?

— 라 메쉬 벨
소스

postgres / postgis로 공간 인덱스를 생성하면 좋은 성능을 볼 수 있습니다. 그러나 MongoDB에 더 만족한다면 계속하십시오.

— Mapperz

답변:

쓰기로드 (들어오는 데이터 스트림)가 제한없이 잠재적으로 증가 할 수 있다면 (웹 프로젝트의 성공으로 인해 쓰기 량이 증가하면 성장이 증가하는 경우) Mongo와 함께하십시오. 단일 하이 엔드 서버의 기능을 넘어 서면 PostGIS / PostgreSQL에 병목 현상이 발생합니다.

대량의 읽기로드 (마스터 / 슬레이브 복제) 및 대량의 데이터 크기 (테이블 분할)에 적합한 PostGIS / PostgreSQL 솔루션을 설계 할 수 있지만 쓰기로드는 어렵습니다. PostGIS의 훨씬 더 큰 기능 세트 및 코드 성숙도 인 Mongo 및 PostGIS에 대한 사례를 이미 제시 했으므로 다른 문제와 균형을 맞 춥니 다.

— 폴 램지
소스

"MongoDB는 웹 규모입니다"라는 것을 기억하십시오. xtranormal.com/watch/6995033/mongo-db-is-web-scale

— Paul Ramsey

그래, 나도 알아.. 그것은 정말

— 재밌었다 (

글쎄, 당신은 항상 할 수 떨어져 = fsync를 돌려서 "webscale")

— 라기 Yaser Burhum을

PostgresXC는 이제 완전한 트랜잭션 보장과 다중 노드 쿼리 실행을 갖춘 쓰기 병렬 시스템을 제공 할 수 있습니다. 볼만한 가치가있는 벨트 및 멜빵 (OLAP 및 OLTP). 그리고 PostGIS를 지원합니다.

— 폴 램지

그러나 PostgresXC / XL을 선택하면 패키지를 직접 유지 관리해야합니다. 공식적으로 Fedora / Redhat에서만 사용할 수있는 우분투 애호가는 수동으로 컴파일하는 데 시간을 소비해야합니다.

— 라비 쿠마르

몇 년 동안 PostGIS를 사용해 왔으며 최근에 MongoDB를 사용하여 특정 사용 사례를 처리하는 방법을 조사하기 시작했습니다. 레코드마다 다양한 수의 태그가있는 OSM 데이터와 같이 스파 스 필드가있는 포인트 데이터를 처리하고 있었으며 MongoDB에는 스키마가 없으므로이 기능이 적합합니다. 이 데이터 샘플을 각 DB의 인스턴스에로드했는데 이것이 내가 찾은 것입니다.

포인트 데이터의 간단한 저장 및 검색을 위해 Mongo가 잘 작동하는 것으로 보입니다. 경계 상자 지리 공간 쿼리가 제대로 작동하는 것으로 보이며 전반적인 성능이 매우 우수하다는 것을 알았습니다. mongoimport 도구를 사용하면 TSV 또는 CSV 파일에서 복합 2D 좌표 필드를 정의 할 수 없다는 것을 알았지 만 설정 및 시작이 매우 쉽습니다. JSON을 생성하는 스크립트를 작성하는 것은 쉽지 않기 때문에 큰 문제가되지 않았습니다. 현재 가장 큰 단점은 지리 공간 영역의 다른 어떤 것도 기본적으로 데이터를 읽을 수 없다는 것입니다. https://github.com/springmeyer/mapnik-mongo에 실험적인 Mapnik 데이터 소스 플러그인이있는 것으로 보이지만 이것이 내가 찾을 수있는 전부입니다.

반면 PostGIS는 (적어도 나에게는) 설정하는 데 약간 더 오래 걸리지 만 위에서 언급했듯이 즉시 더 많은 기능을 제공합니다. 훨씬 더 정교한 공간 분석 기능을 제공 할뿐만 아니라 다른 많은 응용 프로그램 및 라이브러리에서도 기본적으로 지원됩니다. Mapserver, Mapnik, QGis, GDAL 등 등등. PostGIS는 단순한 저장 및 검색 시스템이 아니라 진정한 GIS 시스템입니다.

성능이 향상되는 한 두 시스템 모두에서 데이터를 매우 빠르게 검색 할 수 있습니다. 그러나 PostGIS가 인덱스의 존재로 더 많은 이점을 얻은 것 같습니다. MongoDB는 전체 데이터 세트를 한 번에 나에게 반환하는 데 약간 빠르며 (2 백만 레코드) 처음으로 인덱스를 사용한 쿼리를 반환 할 때 약간 느립니다. 캐싱에 사용하는 메커니즘을 정확히 알지 못하지만 MongoDB에서 쿼리를 반복하면 결과가 두 번째로 훨씬 빨리 돌아 오는 것을 알 수 있습니다. PostGIS에서 비슷한 것을 보았지만 같은 정도는 아닙니다. 또한 MongoDB를 실행하면 PostGIS보다 내 컴퓨터의 메모리 사용량이 훨씬 높은 것으로 나타났습니다.

따라서 결론은 기본 지리 공간 저장 및 분석 시스템으로 PostGIS를 제거하지 않을 것이지만 특정 유형의 프로젝트 (예 : 이미지 타일 및 / 또는 포인트 데이터를 표시하는 웹 맵)의 경우 MongoDB 사용을 고려할 수 있습니다 내 데이터 저장소로.

알았다

— 라거
소스

mongo는 기본 지리 데이터를 처리하는 매우 좋은 옵션입니다. 현재 더 간단한 구형 및 경계 상자 쿼리를 수행하고 있으며 잘 수행하고 있습니다. 추가하고 싶은 한 가지 더 Solr lucene은 기본 지리 함수를 몽고로 제공하며 패싯 쿼리와 함께 사용할 때도 매우 빠릅니다. currenlty는

— mongo

@RameshVel 당신은 solr lucene에 대해 더 말할 수 있습니까?

— rkm

@rashad, elasticsearch (다운로드, 추출 및 완료)를 설치하고 Geo DSL 쿼리로 재생할 수 있습니다. 매우 기본적이지만 지리뿐만 아니라 검색 / 패싯도 원하는 경우 사용할 수 있습니다.

— 라비 쿠마

Mongo의 메모리 사용과 관련하여 Mongo는 인덱스와 데이터를 메모리에 가져 오기 위해 OS 파일 캐시에 전적으로 의존한다는 것을 지적 할 가치가 있습니다 .'mongo 메모리 버퍼 / 인덱스 캐시 '라는 개념이 없으므로 시도하거나 볼 수 있습니다. 오히려 OS는 모든 데이터 파일이 캐시 된 시점까지 사용 가능한 모든 RAM을 사용합니다.

— 패트릭 베일
소스