많은 INSERTS 및 bytea 업데이트를 위해 PostgreSQL 최적화

우리가 가진 것 (소프트웨어) :

• 기본 구성의 PostrgeSQL 9.3 (변경 사항 없음 postgresql.conf)
• 윈도우 7 64 비트

하드웨어:

• 인텔 코어 i7-3770 3.9GHz
• 32GB RAM
• WDC WD10EZRX-00L4HBAta 드라이브 (1000Gb, SATA III)

따라서 DB aprox에로드해야합니다. bytea 열이있는 100.000.000 개의 행 및 LOB가없는 더 간단한 500.000.000 개의 행 첫 번째 테이블 에는 2 개의 인덱스 (길이 13, 19)와 두 번째 테이블에는 2 개의 인덱스 (18, 10 길이)가 있습니다. 각 테이블에 대한 ID 생성 순서도 있습니다.varcharvarchar

현재 이러한 작업은 50 개의 JDBC 배치 크기와 병렬로 8 개의 연결로 수행됩니다. 아래 그림은 시스템로드를 보여줍니다 postgresql. 프로세스에 무부하입니다 . 24 시간 동안 로딩 한 후 10.000.000 개의 행만 로딩했는데 결과는 매우 느립니다.

다음 PostrgreSQL과 같은 목적으로 구성 조정에 도움을 요청합니다 .

1)이 양의 데이터를 매우 빠르게로드하려면 한 번만 작동하므로 임시 구성이 될 수 있습니다.

2) 조인 및 정렬없이 인덱스에 의해이 두 테이블에 적당한 수의 SELECT를 수행하기위한 프로덕션 모드의 경우.

대한 insert성능을 참조 PostgreSQL의 성능 삽입 가속화 와 PostgreSQL을에 대량 삽입 .

에 대한 JDBC 일괄 처리로 시간을 낭비하고 있습니다 insert. PgJDBC는 insert배치 와 관련하여 유용한 작업을 수행하지 않으며 각 문만 실행합니다 . <-새로운 PgJDBC 버전에서는 더 이상 사실이 아니며, 이제 왕복 시간을 크게 줄이기 위해 준비된 명령문을 일괄 처리 할 수 ​​있습니다. 그러나 여전히 낫습니다.

COPY대신 사용하십시오 . 참조 PgJDBC 배치 사본 과를 CopyManager. 동시 로더 수 : 작업이 디스크 I / O 바운드 인 경우 디스크 당 몇 개를 목표로합니다. 아마 당신이 원하는 것이 여덟 일 것입니다.

"제작 모드"의 경우 데이터 샘플을로드하고 실행할 쿼리를 설정하고 explain analyze성능을 조사 하는 데 사용 하는 것이 좋습니다 . 테스트 목적으로 만 enable_매개 변수를 사용하여 다른 계획 선택을 탐색하십시오. 쿼리 플래너의 비용 매개 변수 (설정 random_page_cost, seq_page_cost, effective_cache_size적절하게 시스템 등), 및 확인 shared_buffers적당한 값으로 설정된다. auto_explain모듈, log_min_duration_statement설정, pg_stat_statements확장 등을 사용하여 시뮬레이션 된 프로덕션 워크로드를 추가 할 때 계속 모니터링하십시오 .

자세한 내용은 PostgreSQL 사용자 매뉴얼을 참조하십시오. explain analyze쿼리 실행 세부 사항 등에 더 구체적인 문제가 있으면 여기에서 다시 튀어 나올 것을 제안합니다 .