빠른 읽기 쿼리 성능이 필요한 대규모 지리 공간 데이터 세트를위한 새로운 시스템을 설계하는 중입니다. 따라서 누구나 다음과 같은 상황에서 필요한 DBMS, 데이터 구조 또는 다른 방법으로 필요한 성능을 달성 할 수 있다고 생각하거나 경험 / 조언이 있는지 알고 싶습니다.
처리 된 위성 레이더 데이터에서 데이터가 지속적으로 생성되며,이 데이터는 전 세계적으로 적용됩니다. 지구의 위성 해상도와 토지 범위를 기반으로 전 세계의 750 억 개의 개별 위치에서 값을 생성하는 전체 데이터 세트를 추정합니다. 단일 위성의 수명 동안 출력은 이러한 각 위치에서 최대 300 개의 값을 생성합니다 (따라서 총 22 조 개 이상의 데이터 세트). 이것은 하나의 위성에 대한 것이고 이미 몇 초 안에 궤도에 있고 다른 하나는 새로운 몇 년 안에 계획되어 있습니다. 따라서 많은 데이터가있을 것입니다! 단일 데이터 항목은 매우 단순하며 (경도, 위도, 값)으로 만 구성되지만 항목 수로 인해 단일 위성이 최대 100TB를 생성 할 것으로 예상합니다.
기록 된 데이터는 새로운 위성 획득이 처리 될 때만 증가하므로 업데이트 할 필요가 없습니다. 쓰기 성능은 중요하지 않지만 읽기 성능이 중요합니다. 이 프로젝트의 목표는 Google지도 위의 레이어와 같은 간단한 인터페이스를 통해 데이터를 시각화하는 것입니다. 여기서 각 포인트는 평균, 그라디언트 또는 시간에 따른 일부 기능에 따라 색상 값이 있습니다. (포스트 종료시 데모).
이러한 요구 사항에서 데이터베이스는 확장 가능해야하며 클라우드 솔루션을 찾고 있습니다. 시스템은 "근처에있는 포인트 (lat, lon)"및 "상자에있는 포인트 (box)"와 같은 지리 공간 쿼리를 처리 할 수 있어야하며 단일 포인트를 찾기위한 <1s의 읽기 성능과 최대 50,000 포인트 (최대 200,000 포인트가 바람직 함).
지금까지 나는 1 억 1 천 5 백만 위치에 ~ 7 억 5 천만 데이터 항목의 테스트 데이터 세트를 가지고 있습니다. postgres / postGIS 인스턴스를 시험해 보았지만 제대로 작동했지만 샤딩 가능성이 없어도 데이터가 커짐에 따라 대처할 수 없으며 mongoDB 인스턴스도 시험해 보았습니다. 샤딩을 사용하면 데이터 볼륨으로 확장하기에 충분할 수 있습니다. 나는 최근 elasticsearch에 대해 조금 배웠으므로 이것에 대한 의견은 나에게 새로운 것으로 도움이 될 것입니다.
다음은 전체 데이터 세트로 달성하고자하는 것에 대한 빠른 애니메이션입니다.
이 gif (나의 postgres 평가판)는 (6x3) 사전 계산 된 래스터 타일을 제공합니다. 각 타일은 ~ 200,000 점을 포함하고 각각을 생성하는 데 ~ 17 초가 걸립니다. 점을 클릭하면 <1s의 가장 가까운 위치에서 모든 이력 값을 가져와 그래프가 작성됩니다.
긴 게시물에 대한 사과, 모든 의견 / 조언을 환영합니다.