PostgreSQL 데이터베이스에 대량의 날씨 모델 데이터가 있습니다. 이 기계에는 8 개의 코어와 16GB의 RAM이 있습니다. PostGIS 2.1과 함께 PostgreSQL 9.3을 실행하고 있습니다. 각 테이블에는 다양한 날씨 데이터 (온도, 이슬점, 바람 등)가 있습니다. 각 테이블에는 위도, 경도, 점 지오메트리, 표고, 모델이 관련된 날짜-시간 및 1-2 개의 관심 데이터 값이 있습니다. 데이터는 주로 시간과 고도별로 경계 상자에 대해 쿼리됩니다. 테이블 당 약 145,757,360 개의 행이 있습니다 (이전보다 오래된 데이터는 더 이상 관련이 없습니다). 대략 테이블의 크기가 인덱스가없는 약 10GB 인 것으로 추정합니다. (데이터 당 52 바이트의 데이터와 행당 23 바이트의 오버 헤드). 새 모델 데이터를 사용할 수있게되면 데이터가 정기적으로 업데이트 / 삽입됩니다. 노트 :
그래서 저는이 두 가지 계획을보고 있습니다 :
- 포인트 지오메트리에 대한 추가 인덱스를 사용하여 (날짜 시간, 고도)를 기준으로 인덱스하고 클러스터링하십시오. 오래된 행을 삭제하고 진공 / 분석을 실행하며 클러스터를 다시 작성하는 일반 크론 작업을 실행하십시오.
- 날짜 시간별로 분할 한 다음 지오메트리에 대한 색인을 사용하여 테이블 당 고도별로 클러스터 및 색인합니다. 일반 cron 작업을 실행하여 새 테이블을 추가하고 이전 테이블을 삭제하십시오.
더욱이,
- 따라서 테이블을 삭제하는 것이 훨씬 효율적이며 삭제 및 진공 청소기로 청소한다는 것을 알고 있습니다. 그러나 그렇지 않으면 성능이 향상됩니까?
- 관련되지 않은 것으로 삭제 될 때까지 모든 테이블이 균등하게 업데이트되고 선택 될 때 파티션이 적절합니까?
데이터를 제공 할 때 선택 항목이 클러스터형 인덱스보다 빠를까요? 한 번에 여러 번 요청하면 답변이 변경됩니까?
감사합니다. 필요한 데이터를 모두 입력했으면합니다. 알려주지 않으면 추가하겠습니다.
"위도, 경도, 점 형상, 표고"조합이 반복됩니다. 그렇다면 다른 테이블로 정규화하면 공간이 절약 될 수 있습니다.
—
AK
조금만. PostGIS 지오메트리는 이진 배열이며 사람이 읽을 수 없습니다. 출력에서 해당 값을 파생시킬 수는 있었지만 클러스터링 할 수 없었습니다. GeoHash를 사용하여 클러스터링 할 수는 있지만 위도보다 더 읽을 수는 없습니다. 그러나 공간이 문제가되지는 않습니다. 그들은 내가 채울 수있는만큼 테라 바이트를 제공했습니다. 문제는 빠른 속도로 테라 바이트를 쿼리 할 수 없다는 것입니다. 데이터베이스 자체는 거래가 거의 없습니다. 두 개의 스크립트 만 쓰기 권한을 갖습니다. 다른 모든 것은 엄격하게 읽기 전용입니다.
—
bshender
크레이그 : 그들은 그들이 나올 때 그들과 함께 실험하기를 기대하는 것 같습니다. 그래도 9.3의 설정에 대한 생각이 있습니까?
—
bshender
두 가지 정보를 제공해 주시겠습니까? 1) 삽입 속도 또는 쿼리 속도 중 가장 중요한 것은 무엇입니까? 2) 가장 일반적인 쿼리는 무엇입니까?
—
Thomas Kejser
xmin또는xmax등 기능이있어 수 많은 더 편리과 같은 일을 할 것입니다 MINMAX 인덱스라는 아마 당신을 흥분 9.4으로 그것을 만들 수가.