테이블 당 100M 개 이상의 항목이있는 많은 테이블이있는 거대한 PostgreSQL 9.3 데이터베이스가 있습니다. 이 데이터베이스는 기본적으로 읽기 전용 (필요한 모든 테이블을 채우고 더 이상 DB에서 쓰기 작업을하지 않는 인덱스를 빌드) 및 단일 사용자 액세스 (로컬 호스트에서 여러 쿼리 실행 및 벤치 마크)입니다. 연구 목적으로 만 사용하십시오. 쿼리는 항상 정수 DB 필드에서 JOIN을 사용합니다.
아마도이 목적으로 SSD (256-512GB)를 구입할 것입니다. 이전에 DB 용 SSD를 사용하지 않았으므로 두려워해야 할 것이 있습니까? 전체 DB를 SSD 또는 인덱스에만 넣을 수 있습니까? SSD 용 PostgreSQL 조정에 필요한 특정 조언 / 자습서가 있습니까? 필자는 i7 및 32Gb의 RAM이 장착 된 훌륭한 워크 스테이션을 보유하고 있기 때문에 이에 대한 조언도 제공 할 수 있습니다.
답변:
그래서 내가 두려워해야 할 것이 있습니까?
백업이 없습니다. 다른 저장 장치와 마찬가지로 죽을 수도 있습니다. 백업을 유지하십시오.
데이터로드가 오래 걸리는 경우 데이터로드를 마친 후에는 읽기 전용 데이터베이스를 중지하고 복사하여 백업합니다. 그렇게하면 무언가 잘못되면 나중에 다시 만드는 것이 더 쉬울 것입니다.
전체 DB를 SSD 또는 인덱스에만 넣을 수 있습니까?
맞으면 전체 DB를 저장하십시오.
그렇지 않은 경우 SSD에 테이블 스페이스를 놓고이를 사용하여 인덱스와 쿼리가 많이 필요한 테이블을 원하는만큼 저장하십시오.
SSD 용 PostgreSQL 조정에 필요한 특정 조언 / 자습서가 있습니까?
SSD의 장점은 대부분 OLTP 쓰기로드입니다. 읽기 전용로드의 주요 장점은 빠른 탐색이며, slardiere가이를 다루었습니다.
effective_io_concurrency = 5SSD가 빠르고 파이프 라인이 많은 임의 읽기를 수행 할 수 있다는 사실을 반영 하도록 설정 하거나 무언가를 원할 수도 있지만 비트 맵 인덱스 스캔에만 영향을 미치며 실제로는 random_page_cost이미이를 통합합니다.
읽기 전용로드의 경우 큰 차이가 없습니다.
초기 데이터로드에 대해서는 다음을 참조하십시오.
필자는 i7 및 32Gb의 RAM이 장착 된 훌륭한 워크 스테이션을 보유하고 있기 때문에 이에 대한 조언도 제공 할 수 있습니다.
maintenance_work_mem데이터로드를 크게 설정하십시오 . 적어도을 사용 8GB합니다.
work_mem질의 작업을 위해 크게 설정하십시오 . 적절한 크기는 쿼리 복잡성에 따라 다릅니다. 시작하여 500MB거기서부터 올라갑니다.
checkpoint_segments초기 데이터로드를 위해 (대규모) 강화하십시오 .
VM 초과 커밋을 비활성화해야합니다! (PostgreSQL 매뉴얼 : http://www.postgresql.org/docs/current/static/kernel-resources.html 참조 )