빠른 (<1s) 읽기 쿼리 성능을 갖춘 대규모 (22 조 개 이상의 항목) 지리 공간 데이터 세트


20

빠른 읽기 쿼리 성능이 필요한 대규모 지리 공간 데이터 세트를위한 새로운 시스템을 설계하는 중입니다. 따라서 누구나 다음과 같은 상황에서 필요한 DBMS, 데이터 구조 또는 다른 방법으로 필요한 성능을 달성 할 수 있다고 생각하거나 경험 / 조언이 있는지 알고 싶습니다.

처리 된 위성 레이더 데이터에서 데이터가 지속적으로 생성되며,이 데이터는 전 세계적으로 적용됩니다. 지구의 위성 해상도와 토지 범위를 기반으로 전 세계의 750 억 개의 개별 위치에서 값을 생성하는 전체 데이터 세트를 추정합니다. 단일 위성의 수명 동안 출력은 이러한 각 위치에서 최대 300 개의 값을 생성합니다 (따라서 총 22 조 개 이상의 데이터 세트). 이것은 하나의 위성에 대한 것이고 이미 몇 초 안에 궤도에 있고 다른 하나는 새로운 몇 년 안에 계획되어 있습니다. 따라서 많은 데이터가있을 것입니다! 단일 데이터 항목은 매우 단순하며 (경도, 위도, 값)으로 만 구성되지만 항목 수로 인해 단일 위성이 최대 100TB를 생성 할 것으로 예상합니다.

기록 된 데이터는 새로운 위성 획득이 처리 될 때만 증가하므로 업데이트 할 필요가 없습니다. 쓰기 성능은 중요하지 않지만 읽기 성능이 중요합니다. 이 프로젝트의 목표는 Google지도 위의 레이어와 같은 간단한 인터페이스를 통해 데이터를 시각화하는 것입니다. 여기서 각 포인트는 평균, 그라디언트 또는 시간에 따른 일부 기능에 따라 색상 값이 있습니다. (포스트 종료시 데모).

이러한 요구 사항에서 데이터베이스는 확장 가능해야하며 클라우드 솔루션을 찾고 있습니다. 시스템은 "근처에있는 포인트 (lat, lon)"및 "상자에있는 포인트 (box)"와 같은 지리 공간 쿼리를 처리 할 수 ​​있어야하며 단일 포인트를 찾기위한 <1s의 읽기 성능과 최대 50,000 포인트 (최대 200,000 포인트가 바람직 함).

지금까지 나는 1 억 1 천 5 백만 위치에 ~ 7 억 5 천만 데이터 항목의 테스트 데이터 세트를 가지고 있습니다. postgres / postGIS 인스턴스를 시험해 보았지만 제대로 작동했지만 샤딩 가능성이 없어도 데이터가 커짐에 따라 대처할 수 없으며 mongoDB 인스턴스도 시험해 보았습니다. 샤딩을 사용하면 데이터 볼륨으로 확장하기에 충분할 수 있습니다. 나는 최근 elasticsearch에 대해 조금 배웠으므로 이것에 대한 의견은 나에게 새로운 것으로 도움이 될 것입니다.

다음은 전체 데이터 세트로 달성하고자하는 것에 대한 빠른 애니메이션입니다. 7 억 5 천만 데이터 항목의 시각화를 제공하는 Tileserver

이 gif (나의 postgres 평가판)는 (6x3) 사전 계산 된 래스터 타일을 제공합니다. 각 타일은 ~ ​​200,000 점을 포함하고 각각을 생성하는 데 ~ 17 초가 걸립니다. 점을 클릭하면 <1s의 가장 가까운 위치에서 모든 이력 값을 가져와 그래프가 작성됩니다.

긴 게시물에 대한 사과, 모든 의견 / 조언을 환영합니다.

답변:


4

위치별로 파쇄 할 수 있습니다. 지구본을 그리드로 분할하고 하나의 서버에서 해당 그리드의 각 사각형을 갖습니다. 클라우드를 언급 했으므로 클라우드에 적합합니다. 물론 여러 서버의 결과를 수동으로 병합해야합니다.

그렇게하면 원하는 데이터베이스 솔루션을 사용할 수 있습니다. 자체적으로 확장 할 필요는 없습니다.

개별 제곱에는 다른 양의 데이터가 있습니다. 클라우드이기 때문에 서로 다른 크기의 머신을 사용하거나 동일한 머신에 여러 개의 작은 샤드를 배치 할 수 있습니다.

이 샤딩 체계는 각 쿼리가 샤드를 거의 터치하지 않기 때문에 수행하는 쿼리 종류에 좋습니다. 각 쿼리에 대해 모든 샤드를 터치해야하므로 시간별 샤딩이 더 나쁩니다. 무작위 샤딩도 같은 문제가 있습니다.

쿼리 패턴이 샤딩 구성표에 잘 맞기 때문에 이것은 샤딩이 쉬운 경우입니다.

실제로, 나는 이것을 위해 데이터베이스가 전혀 필요하지 않은지 궁금합니다. 지구본을 1000x1000 타일 이하로 분할하고 각 타일마다 Blob 저장소에 하나의 플랫 파일을 가질 수 있습니다. Blob Storage는 1M Blob을 전혀 신경 쓰지 않습니다.

이 스토리지 체계를 사용하면 개념적으로 쿼리를 쉽게 실행할 수 있습니다. 여러 그리드 해상도로 데이터를 중복 저장할 수도 있습니다.


지역별 샤딩은 MongoDB에서 살펴본 접근법이며, MongoDB Atlas의 적시 릴리스와 함께 현재 사전 계산 된 집계 값을 사용하여 그 방향으로 기울고 있습니다. 현재 필요한 복제본 / 샤드 서버 수를 잘 모르므로 비용이 문제가 될 수 있습니다. BLOB 스토리지 사용에 대한 귀하의 제안도 흥미롭고 귀하는이를 제안하는 두 번째 사람입니다. 그러나 BLOB를 사용하는 것은 완전히 새로운 것이므로 더 알고 싶은 유용한 정보가 있습니까? 답변 주셔서 감사합니다.
Azwok

얼룩은 사용하기가 쉽지 않습니다. 직렬화, 쿼리, 트랜잭션, 백업, HA, DA와 같은 데이터베이스 기능을 구현해야 할 경우 복잡성이 발생합니다. 이것은 모두 가능하지만 현명하지는 않습니다. Blob을 Postgres 테이블에 저장할 수 있습니다. 직렬화 및 쿼리를 제외한 모든 것을 자동화합니다. 성능은 Blob Storage보다 좋으며 훨씬 저렴합니다. Blob과 VM은 비용으로 청구되지 않으며 마진이 좋습니다 (증거 : 로컬 웹호 스터는 클라우드와 동일한 컴퓨팅 성능으로 3-5 배 적은 비용을 청구합니다. 이는 높은 클라우드 마진을 의미합니다).
usr

동일한 몽고 인스턴스에서 여러 샤드를 실행할 수 있습니다. 당신은 "overshard"할 수 있습니다. 그렇게하면 서버의 균형을 맞출 수 있습니다.
usr

1
공간 기능이 전혀 필요하지 않습니다. 앱에서 모든 것을 계산할 수 있습니다. 직사각형에 대한 모든 데이터를 쿼리하는 기능 만 있으면됩니다. 지구본을 그리드 (또는 여러 해상도 그리드)로 수동으로 분할하면됩니다. 귀하의 DB는 내가 생각하는 공간을 지원할 필요가 없습니다.
usr

8

읽기 쿼리는 얼마나 최신 상태입니까?

맵에 가장 최근의 측정 값 만 표시해야하는 경우 시간별로 데이터베이스를 분할 할 수 있습니다. 이렇게하면지도에 대한 쿼리로드가 줄어 듭니다.

주어진 포인트의 이력에 대해, 이력을 보여주는 x와 y로 두 번째 상점을 보유 할 수 있습니다. 기록 데이터가 변경되지 않으므로 야간 새로 고침 / 업데이트로 수행 할 수 있습니다.

그런 다음 다른 확대 / 축소 수준의지도와 통합하기 위해 더 거친 해상도로 평균을 사전 계산할 수 있습니다. 이렇게하면 큰지도 영역에 대해 검색 할 포인트 수가 줄어 듭니다 (축소). 더 작은 영역을 쿼리하는 맵을 더 확대하려면 더 정밀한 해상도가 사용됩니다. 실제로 속도를 높여야하는 경우 타일을 얼룩으로 계산하여 응용 프로그램에서 해석 할 수 있습니다.

여기에는 집계 정보의 일부 재 계산이 포함되므로 쿼리 결과에 약간의 대기 시간이 있습니다. 허용되는 대기 시간 양에 따라 이러한 종류의 접근 방식을 사용하여 읽기를 최적화 할 수 있습니다.

좋아, 그래서 포인트는 시간이 지남에 따라 평균 계산해야합니다. 이 계산으로 래스터 값을 쿼리하기 위해 미리 계산할 수 있기 때문에 실제 쿼리는 22 조 개 항목에서 상당히 많이 떨어졌습니다.


읽기 쿼리에는 약간의 지연 (1 일 또는 2 일)이있을 수 있으므로 일괄 처리는 유효한 옵션입니다. 특정 위치에서 새로운 값은 6 일마다 가장 빠른 속도 (다음 위성 패스)에만 추가됩니다. 지도의 출력은 최신 값일뿐만 아니라 해당 위치에있는 값의 전체 기록 (예 : 평균 또는 그라디언트 또는 사용자 정의 함수)을 기반으로 계산됩니다. 축소 수준을 높이려면 이미 클러스터링 / 피라미드 구조로 작업하여 타일 (쿼리)에 200,000 (또는 50,000) 이상의 위치 항목이 없도록 평균 값을 가진 테이블 / 컬렉션을 갖습니다.
Azwok

사전 계산 집계가 핵심이라고 생각합니다. 시간 계산은 여전히 ​​일괄 처리 할 수 ​​있습니다. 이것이 OLAP 시스템이 빠른 쿼리 성능을 얻는 방법이며 이런 종류의 접근 방식이 필요할 것입니다. 쿼리에 하루 전의 데이터를 가지고 살 수있는 경우 특히 적합합니다.
ConcernedOfTunbridgeWells

계산 된 평균값을 쿼리하는 경우 몇 개의 이산 위치에서 샘플을 수집합니까? 즉, 최고 수준의 줌에서 실제 비트 맵의 ​​해상도는 얼마입니까?
ConcernedOfTunbridgeWells

사전 계산 된 집계가 갈 가능성이 매우 높다는 데 동의합니다. 가장 높은 확대 / 축소에서 계산 된 평균은 영역에 대한 평균이 아니며 1 개 위치에서 시간에 따른 값의 평균입니다. 축소 할 때만 쿼리 / 타일에 위치 포인트가 너무 많지 않도록 영역을 평균화하는 별도의 테이블 / 컬렉션이 있습니다 (최대 50,000-200,000). 타일의 최대 해상도는 256x256 픽셀입니다.
Azwok

3

두 가지 클래스의 쿼리가있는 것처럼 들립니다. 하나는 현재보기 창에있는 위치를 이해하고 다른 하나는 해당 지점에 대한 원하는 통계를 제공합니다. 내 제안은 각각에 대해 별도의 특수 도구를 사용하는 것입니다.

모든 측정이 동일한 75Bn 포인트 세트와 관련이 있다고 가정합니다. 이러한 위도 / 경도는 일단 설정되면 정적입니다. 일회성 비용으로 그룹화, 집계 및 색인을 생성 할 수 있습니다. 따라서 지역 및 확대 / 축소 수준별로 샤딩을 제안합니다. 각 샤드의 크기는 각 GIS 인스턴스에서 얻을 수있는 성능에 따라 결정됩니다.

GIS는 시계열 데이터베이스로 전달되는 일련의 포인트를 반환합니다. 측정 된 값을 유지하고 집계를 수행합니다. KDB 는 내가 알고있는 것입니다. 이는 증권 거래를 목표로하며, 시나리오보다 키는 적지 만 키당 더 많은 데이터 포인트가 있습니다.

키 값을 GIS 서버에서 시계열 DB로 전송하는 비용이 있습니다. 내 가설은이 비용이 작업 별 시계열 DB에서 더 빠른 처리를 통해 상환된다는 것입니다. 이 질문에 따르면 단일 인스턴스가 모든 데이터를 보유 할 수 없으므로 일부 서버 간 트래픽이 불가피 해 보입니다. 구성 요소 의 상대적 속도 를 고려할 때 캐시 된 데이터가있는 원격 서버에 키 집합을 보내는 것이 로컬 디스크에서 데이터를 읽는 것보다 빠를 것 같습니다.

포인트 찾기와 가치 계산 부분이 서로 로컬에있을 수 있다면 물론 응답 속도가 더 빨라질 것입니다. 내 (제한된) 이해는 주어진 지점에 가장 가까운 N 개의 이웃을 찾는 것이 사소한 작업이라는 것입니다. 이것이 특정 소프트웨어를 사용하여 수행하도록 제안한 이유입니다. 포인트 찾기를 다음으로 줄일 수있는 경우

where latitude between x1 and x2
and logitude between y1 and y2

그 부분은 가치 저장 소프트웨어에 의해 처리 될 수 있으며 GIS는 아키텍처에서 제거됩니다.

나는 그런 시스템을 구현하지 않았다. 나는 정말로 여기서 크게 생각하고 있습니다. 페타 바이트 규모에서는 상용 솔루션이 없습니다. 그러나 많은 위성 데이터 제공 업체가 있으므로 문제를 다루기 쉽습니다. 행운을 빕니다.


동의, 두 가지 클래스가 있습니다. 1) 여러 위치에서 단일 값을 표시하고 2) 한 위치에서 모든 역사적인 값을 가져옵니다. 모든 측정은 동일한 수십억 개의 위치와 관련이 있으며, 유일한 변경은 각 지점에서 역사적인 값의 수입니다. 당신이 언급 한 이유 때문에, 지역별 쉐딩은 내가보고있는 접근법입니다. 반환 된 값을 별도의 시계열 DB에 전달하는 것을 고려하지 않았습니다. 제안을 오해하지 않는 한 선택하고 시계열 데이터베이스로 전송하면 실행 가능한 옵션을 만들기에는 시간이 너무 많이 걸릴 것이라고 생각했을 것입니다.
Azwok
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.