답변:
나는 짧은 답변이 없다는 ETL에 동의합니다. 크기 만 중요하지는 않습니다. 우리는 부하가 큰 상태에서 상당히 큰 PostgreSQL OLTP 데이터베이스 (일부 테이블> 100.000.000 행)를 실행하고 현재 자동 진공에만 의존합니다.
그러나 두 가지 중요한 점이 있습니다.
자동 진공는 것을, 합의가 될 것 같다 결코 당신이 당신의 데이터베이스에 매우 잘 정의 된 워크로드를 가지고 당신이 무엇을하는지 정확히 알지 못하면, 꺼져 없습니다. 그러나 당연히 추가 VACUUM및 / 또는 ANALYZE달리기를 할 수 있습니다.
추가 VACUUM실행을 고려하기 전에 autovacuum이 어떻게 유지되는지 확인했습니다. pg_stat_user_tables및 을 쿼리하여 테이블이 자동 진공 임계 값을 초과하는지 여부를 확인할 수 있습니다 pg_class. 그런 쿼리를 다른 스레드에 게시 했는데 관심이있을 수 있습니다 : PostgreSQL의 Aggressive Autovacuum .
불행히도, 자동 분석 임계 값에 대한 유사한 검사를 수행하는 것은 쉽지 않습니다 (즉, 현재로서는 불가능합니다). 그러나 기본적으로 autovacuum 이전의 킥을 자동 분석하면 훨씬 저렴합니다. 따라서 기본적으로 데이터베이스가 autovacuum을 유지할 수 있으면 autoanalyze도 좋습니다. 에서 마지막 자동 분석 날짜를 쿼리 할 수도 있습니다 pg_stat_user_tables.
내가 찾은 (가장 훌륭한) PostgreSQL 설명서의 일부 부분 :
Autovacuum 은 잘못 구성하지 않는 한 잘 덮을 것입니다. 다른 답변은 이미 다룹니다.
매뉴얼 VACUUM (그리고 더 중요한 것은 manual ANALYZE)에 대해 명확하게 정의 된 하나의 사례가 있습니다 : 임시 테이블 , autovacuum 악마는 고려하지 않습니다. 나는 여기에 매뉴얼을CREATE TABLE 인용 한다 :
자동 진공 데몬 에 액세스 할 수 없습니다, 따라서 진공 또는 임시 테이블을 분석 할 수 없습니다. 따라서 세션 SQL 명령을 통해 적절한 진공 및 분석 작업을 수행해야합니다. 예를 들어 임시 테이블을 복잡한 쿼리
ANALYZE에 사용하려는 경우 임시 테이블을 채운 후 임시 테이블 에서 실행하는 것이 좋습니다 .
많은 요인에 따라 그에 대한 짧은 대답은 없습니다. 시스템이 느립니까? 자동 진공이 실제로이 테이블에 닿습니까? 기타
이 주제에 대한 좋은 링크는 다음과 같습니다.
명확한 결정을 내리려면 데이터베이스 자체에 대한 이해와 진행 상황에 대한 자세한 내용이 필요합니다.
성능 저하가 나타나지 않는 한 수동으로 진공 청소를해야한다고 생각하지 않습니다. 그러나 진공 및 자동 진공 설정을 검토하고 필요에 맞게 조정하는 것이 좋습니다.
현재 설정을 보려면 다음 쿼리를 실행하십시오.
SELECT *
FROM pg_settings
WHERE name LIKE '%vacuum%'대부분의 필드는 설명이 필요하지만 여기에 문서가 있습니다 : https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html
가비지를 일관되게 청소하도록 autovacuum을 구성하는 것이 목표이지만 autovacuum을 지속적으로 실행하지 마십시오.
가장 중요한 설정은 다음과 같습니다.
임계 값은 작은 테이블에 대해 정리 프로세스가 너무 자주 트리거되는 것을 방지합니다.
매우 큰 테이블이 없으면 기본 설정이 제대로 작동합니다. 간단히 말해서, 100GB를 차지하는 테이블이 있으면 autovacuum이 트리거되기 전에 20GB의 쓰레기를 쌓을 것입니다. 따라서 일반적으로 스케일 팩터를 낮게 설정하는 것이 좋습니다. 스스로 결정해야하는 정도 현재 프로젝트에서 0.05를 사용합니다.
임계 값을 늘릴 수도 있습니다. 많은 응용 프로그램에는 자주 업데이트되는 두 개의 테이블이 있으며 50 튜플은 그다지 많지 않습니다. 1000으로 늘리면 문제가 발생하지 않지만 물론 자신의 경우를 고려해야합니다.
또한 자동 진공을 미세 조정하고 일부 테이블에 대해 다른 설정을 지정할 수 있습니다
ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);scale_factor 및 임계 값을 구성하면 괜찮을 것입니다. 또한 autovacuum_vacuum_cost_limit기본적 vacuum_cost_limit으로 200으로 설정된을 증가시킬 수 있습니다. 이는 진공의 매우 중요한 기능으로, 모든 리소스를 소모하지 않고 진공 청소기로 청소하는 동안에도 응용 프로그램이 데이터와 함께 작동 할 수 있도록합니다. 이지만 기본값이 너무 낮습니다. 1000으로 늘리면 상당한 지연이 발생하지 않지만 진공 프로세스가 훨씬 빠르게 완료됩니다.
물론 진공을 수동으로 실행할 수도 있습니다. 가장 간단한 경우에, 당신은 DB에 자주 액세스하지 않을 때 매일 밤 전체를 정리하는 간단한 cron 작업을 가질 수 있습니다
희망이 도움이됩니다!