| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 13. 성능효율 팁 | Fast Forward | Next |
데이터베이스에 데이터를 초기 투입하기 위해서, 대량의 테이블 삽입 조작을 실시할 필요있습니다. 본 절에서는 이 작업을 효율적이도록 몇가지 제안을 포함하고 있습니다.
자동 처리을 무효로 하고, 마지막에 1회만 처리합니다 (보통 SQL에서는 이것은BEGIN를 개시시에, COMMIT를 마지막으로 발행하는 것을 의미합니다. 클라이언트용 라이브러리 안에는 이것을 마지막에 실행하는 것도 있습니다. 그 경우는 원하는 대로 라이브러리가 가고 있는지를 확인해야 합니다). 각 삽입 조작을 분리해서 처리하도록 허락했다면, PostgreSQL은 추가된 각 행에 대해 많은 작업을 해야 합니다. 1개의 트랜잭션으로 모든 삽입을 실시하는 것의 1개의 이점은 1개 행의 삽입이 실패했을 경우, 그 시점까지 삽입된 모든 행이 롤백(rollback) 되는 것입니다. 그 결과, 일부만이 로드된 데이터의 대처가 문제되진 않습니다.
단일 커맨드로 모든 행을 로드하기 위해서 일련의INSERT커맨드는 아니고, COPY 를 사용해 주십시요. COPY커맨드는 행을 대량으로 로드하는 것에 최적화되고 있습니다. 이 커맨드는 INSERT에 비해 유연성이 부족하고 있지만, 대량의 데이터 로드에 있어서의 오버헤드를 매우 적습니다. COPY커맨드로 테이블에 데이터를 투입하는 경우, 커맨드는 1개이므로, 자동 처리를 무효로 할 필요는 없습니다.
COPY를 사용할 수 없는 경우, 준비된INSERT문을 PREPARE 을 사용해 작성하고, 필요 몇 차례만EXECUTE를 실행하는 편이 좋을 것입니다. 이것에 의해, 반복해서 행해지는 INSERT의 해석과 계획 작성의 오버헤드를 피하게 됩니다.
COPY를 사용한 대량 행의 로드는 거의 모든 경우에 대해, INSERT를 사용하는 로드보다 빠릅니다. 비록 복수의INSERT커맨드를 단일 트랜잭션에 정리했다고 해도, 또 그 때PREPARE를 사용했다고 해도 말입니다.
새롭게 작성한 테이블을 로드할 때, 가장 빠른 방법은 테이블을 작성하고, COPY를 사용한 일괄 로드를 실시해, 그 테이블에 필요한 인덱스를 작성하는 것입니다. 기존의 데이터에 대한 인덱스를 작성하는 편이, 각 행이 로드 될 때 단계적으로 갱신하는 것보다 더 빠릅니다.
기존의 테이블에 대량의 데이터를 추가하고 있다면, 인덱스를 삭제해 테이블을 로드하고, 그 후에 인덱스를 재작성하는 편이 좋을지도 모릅니다. 물론, 다른 유저로부터 보면, 인덱스가 존재하지 않는 동안 데이터베이스의 성능은 악화됩니다. 또한, 유일한 인덱스를 삭제하기 전에는 숙고해야 합니다. 일관성 제약에 의한 에러 검사가 그 기간 행해지지 않기 때문입니다.
인덱스의 경우와 같이, 외부 키 제약은 행마다 검사하는 것보다 효율적으로 "정리해"검사할 수 있습니다. 따라서, 외부 키 제약을 삭제해, 데이터를 로드, 그리고 제약을 재작성하는 방법은 유용할 것입니다. 반복하지만, 데이터 로드의 속도와 제약이 존재하지 않는 동안의 에러 검사가 없으며, trade off가 필요합니다.
대규모 데이터를 로드할 때maintenance_work_mem설정 변수를 일시적으로 늘리는 것으로 성능을 향상시킬 수 있습니다. 이는 CREATE INDEX커맨드와ALTER TABLE ADD FOREIGN KEY의 속도 향상에 도움이 됩니다. COPY자체에는 그다지 도움이 되지 않으므로, 이 조언은 위의 기법의 다른 한쪽 또는 양쪽 모두를 사용하고 있을 때에만 유용합니다.
대규모 데이터를 로드할 때checkpoint_segments설정 변수를 일시적으로 늘리는 것으로 고속화할 수 있습니다. 대량의 데이터를PostgreSQL에 로드하는 것으로, 보통의 체크 포인트의 빈도(checkpoint_timeout설정 변수에 의해 지정됩니다)보다 빈번하게 체크 포인트가 발생하기 때문에입니다. 체크 포인트가 발생하면, 모든 더티 페이지(디스크에 미기입의 변경이 끝난 메모리페이지)는 디스크에 돌아가야 합니다. 대량의 데이터 로드 시에 일시적으로checkpoint_segments를 증가시키는 것으로, 필요한 체크 포인트 수를 줄일 수 있습니다.
테이블 내의 데이터 분포를 크게 변경했을 때는 매회, ANALYZE 를 실행하는 것을 강하게 권합니다. 이는 테이블에 대량의 데이터를 정리해 로드하는 경우도 포함됩니다. ANALYZE(또는 VACUUM ANALYZE)를 실행하는 것으로, 확실히 planner가 테이블에 관한 최신의 통계 정보를 가질 수 있습니다. 통계 정보가 존재하지 않는 또는 오래된 경우, planner는 그 테이블에 대한 쿼리의 성능을 해치게 하는 허술한 쿼리 계획을 선택할 가능성이 있습니다.
pg_dump로 생성되는 덤프 스크립트는 자동으로 위의 가이드 라인의 전부가 아닌, 일부를 적용합니다. pg_dump덤프를 할 수 있는 한 빠르게 리로드 하려면, 더욱 수동으로 할 것이 요구욉니다. (이것들은 작성 시에 적용하는 것은 아니고, 덤프를 복원 할 때 적용하는 것입니다. pg_dump의 어케이브 파일로부터pg_restore를 사용해 로드할 때도 같은 것을 적용할 수 있습니다. )
디폴트에서는 pg_dump는 COPY를 사용합니다. 스키마와 데이터의 덤프 전체를 생성하는 경우, 인덱스와 외부 키 제약을 작성하기 전에 데이터를 로드하는 것에 주의해 주십시요. 그러므로, 이 경우, 가이드 라인의 몇 개는 자동으로 행해집니다. 남겨진 작업은 덤프 스크립트를 로딩하기 전에 maintenance_work_mem 및 checkpoint_segments를 적절한(즉 보통보다 큰) 값으로 설정하고 난 후에 ANALYZE 이 작동됩니다.
데이터만의 덤프도COPY커맨드를 사용하지만, 인덱스의 삭제와 재작성을 실시하지 않습니다. 또한, 보통은 외부 키 제약을 변경하지 않습니다. [1] 따라서, 데이터만의 덤프를 로드할 때, 위의 기법을 사용하고 싶으면 스스로 인덱스와 외부 키를 삭제, 재작성해야 합니다. 데이터를 로드할 때checkpoint_segments를 늘리는 일도 유용합니다. 그러나 maintenance_work_mem를 늘리는 것은 생각하지 말아 주십시요. 이는 다음에 인덱스와 외부 키를 수동으로 재작성할 때 실시하는 편이 좋을 것입니다. 또한, 실행한 다음에ANALYZE를 실시하는 것을 잊지 말아 주십시요.
| [1] |
--disable-triggers옵션을 사용해, 외부 키를 무효화 시킬 수 있습니다. 그러나 이것은 외부 키 제약을 늦추는 것이 아니라, 제거한다는 것을 주의해 주십시요. 그리고 이것을 사용할 경우, 부정한 데이터를 삽입할 수 있습니다. |