Amazon Aurora PostgreSQL에서 다수의 객체 관리 - Amazon Aurora
관계임시 테이블로깅되지 않은 테이블파티션임시 파일시퀀스대형 객체대략적인 임계값

Amazon Aurora PostgreSQL에서 다수의 객체 관리

PostgreSQL 제한은 이론적이지만 데이터베이스의 객체 수가 매우 많으면 다양한 작업에서 성능에 상당한 영향을 미칠 수 있습니다. 이 설명서에서는 총 객체 수가 많을 때 여러 가지 영향을 미칠 수 있는 몇 가지 일반적인 객체 유형을 다룹니다.

다음 표에는 객체 유형과 그 잠재적 영향에 대한 요약이 있습니다.

객체 유형 및 잠재적 영향
객체 유형 AUTOVACUUM 논리적 복제 메이저 버전 업그레이드 pg_dump/pg_restore 일반 성능 인스턴스 재시작
관계 x x x x
임시 테이블. x x
로깅되지 않은 테이블 x x
파티션 x
임시 파일 x
시퀀스 x
대형 객체 x x

관계

PostgreSQL 데이터베이스의 테이블 수에는 구체적인 하드 제한이 없습니다. 이론적인 한도는 매우 높지만 데이터베이스 설계 중에 염두에 두어야 할 다른 실제 한도가 있습니다.

영향: Autovacuum이 뒤처짐

Autovacuum이 작업량에 비해 작업자가 부족하여 트랜잭션 ID 증가 또는 테이블 팽창을 따라잡는 데 어려움을 겪을 수 있습니다.

권장 작업: Autovacuum을 조정하여 지정된 수의 테이블과 지정된 워크로드를 제대로 따라잡기 위한 몇 가지 요소가 있습니다. 적절한 Autovacuum 설정을 결정하는 방법에 대한 제안은 PostgreSQL Autovacuum 작업 모범 사례를 참조하세요. postgres_get_av_diag 유틸리티를 사용하여 트랜잭션 ID 증가 문제를 모니터링합니다.

영향: 메이저 버전 업그레이드/pg_dump 및 복원

Amazon RDS는 pg_upgrade 실행 중에 "--link" 옵션을 사용하여 데이터 파일을 복사할 필요가 없습니다. 스키마 메타데이터는 여전히 데이터베이스의 새 버전으로 복원해야 합니다. 병렬 pg_restore를 사용하더라도 관계의 수가 많으면 가동 중지 시간이 늘어납니다.

영향: 일반 성능 저하

카탈로그 크기로 인해 일반적인 성능이 저하됩니다. 각 테이블과 연결된 열은 일반 데이터베이스 작업에 자주 사용되는 pg_attribute, pg_class 및 pg_depend 테이블에 추가됩니다. 특정 대기 이벤트는 표시되지 않지만 공유 버퍼 효율성은 영향을 받습니다.

권장 작업: 이러한 특정 테이블에 대한 테이블 팽창을 정기적으로 확인하고 가끔 이러한 특정 테이블에 대해 VACUUM FULL을 수행합니다. 카탈로그 테이블에서 VACUUM FULL에는 ACCESS EXCLUSIVE 잠금이 필요합니다. 즉, 작업이 완료될 때까지 다른 쿼리는 액세스할 수 없습니다.

대략적인 임계값: 수백만

임시 테이블

임시 테이블 사용은 테스트 데이터 또는 중간 결과에 유용하며 많은 데이터베이스 엔진에서 볼 수 있는 일반적인 패턴입니다. 일부 위험을 방지하려면 PostgreSQL에서 과도한 사용의 영향을 이해해야 합니다. 각 임시 테이블 생성 및 삭제는 시스템 카탈로그 테이블에 행을 추가하며, 테이블이 팽창하면 일반적인 성능 문제가 발생합니다.

영향: Autovacuum이 뒤처짐

임시 테이블은 autovacuum에 의해 vacuum되지 않지만, 존재하는 동안 트랜잭션 ID를 유지하고 제거하지 않으면 랩어라운드로 이어질 수 있습니다.

권장 작업: 임시 테이블은 테이블을 생성한 세션 기간 동안 유지되거나 수동으로 삭제할 수 있습니다. 임시 테이블을 사용하여 장기 실행 트랜잭션을 방지하는 모범 사례는 이러한 테이블이 최대 사용 트랜잭션 ID 증가에 기여하지 못하게 합니다.

영향: 일반 성능 저하

카탈로그 크기로 인해 일반적인 성능이 저하됩니다. 세션이 임시 테이블을 지속적으로 생성하고 삭제할 때, 일반 데이터베이스 작업에 자주 사용되는 pg_attribute, pg_class 및 pg_depend 테이블에 추가됩니다. 특정 대기 이벤트는 표시되지 않지만 공유 버퍼 효율성은 영향을 받습니다.

권장 조치:

  • 이러한 특정 테이블에 대한 테이블 팽창을 정기적으로 확인하고 가끔 이러한 특정 테이블에 대해 VACUUM FULL을 수행합니다. 카탈로그 테이블에서 VACUUM FULL에는 ACCESS EXCLUSIVE 잠금이 필요합니다. 즉, 작업이 완료될 때까지 다른 쿼리는 액세스할 수 없습니다.

  • 임시 테이블이 많이 사용되는 경우 메이저 버전 업그레이드 전에 가동 중지 시간을 줄이기 위해 이러한 특정 카탈로그 테이블의 VACUUM FULL을 사용하는 것이 좋습니다.

일반 모범 사례:

  • 일반적인 테이블 표현식을 사용해 중간 결과를 생성하여 임시 테이블 사용을 줄입니다. 이렇게 하면 필요한 쿼리를 복잡해질 수 있지만 위에 나열된 영향이 제거됩니다.

  • 삭제/생성 단계를 수행하는 대신 TRUNCATE 명령을 사용하여 콘텐츠를 지워 임시 테이블을 재사용합니다. 이렇게 하면 임시 테이블로 인한 트랜잭션 ID 증가 문제도 제거됩니다.

대략적인 임계값: 수만

로깅되지 않은 테이블

로깅되지 않은 테이블은 WAL 정보를 생성하지 않으므로 성능 향상을 제공할 수 있습니다. 데이터베이스 충돌 복구 중에는 잘릴 것이므로 내구성을 제공하지 않으므로 신중하게 사용해야 합니다. PostgreSQL에서는 로깅되지 않은 각 테이블이 순차적으로 잘리기 때문에 작업에 비용이 많이 듭니다. 이 작업은 로깅되지 않은 테이블 수가 적은 경우에는 속도가 빠르지만, 수천 개 단위로 계산되면 시작 중에 눈에 띄는 지연을 추가되기 시작할 수 있습니다.

영향: 논리적 복제

블루/그린 배포를 포함한 논리적 복제는 WAL을 사용하여 변경 사항을 캡처하고 전송하기 때문에 로깅되지 않은 테이블은 일반적으로 논리적 복제에 포함되지 않습니다. 로깅되지 않은 테이블을 복제하도록 Aurora PostgreSQL을 구성하는 방법에 대해 자세히 알아보세요.

영향: 리더 노드

로깅되지 않은 테이블은 Aurora DB 클러스터의 라이터 노드에서만 액세스할 수 있습니다. 자세한 내용은 Aurora PostgreSQL에서 로깅되지 않은 테이블 작업을 확인하세요.

일반 모범 사례:

  • 로깅되지 않은 테이블은 표준 PostgreSQL에 비해 Aurora PostgreSQL에서 제한된 성능 이점을 제공하므로 일반 테이블이 더 적절한지 평가합니다.

대략적인 임계값: 수천

파티션

파티셔닝은 쿼리 성능을 높이고 데이터의 논리적 구성을 제공할 수 있습니다. 이상적인 시나리오에서는 파티셔닝이 구성되어 쿼리 계획 및 실행 중에 파티션 정리를 사용할 수 있습니다. 파티션을 너무 많이 사용하면 쿼리 성능 및 데이터베이스 유지 관리에 부정적인 영향을 미칠 수 있습니다. 잘못된 설계로 인해 쿼리 계획 및 실행 성능이 부정적인 영향을 받을 수 있으므로 테이블을 분할하는 방법을 신중하게 선택해야 합니다. 파티셔닝에 대한 자세한 내용은 PostgreSQL 설명서를 참조하세요.

영향: 일반 성능 저하

간혹 시간 계획 오버헤드가 증가하고 쿼리에 대한 계획이 더 복잡해져 튜닝 기회를 식별하기가 어려워집니다. PostgreSQL 18 이전 버전의 경우 워크로드가 많은 여러 파티션에 LWLock:LockManager 대기가 발생할 수 있습니다.

권장 작업: 성능 있는 쿼리 실행을 제공하는 동시에 데이터 구성을 모두 완료할 수 있는 최소 파티션 수를 결정합니다.

영향: 유지 관리 복잡성

파티션 수가 매우 많으면 사전 생성 및 제거와 같은 유지 관리 문제가 발생합니다. Autovacuum은 파티션을 일반적인 관계로 취급하며, 정기적인 정리를 수행해야 하므로 작업을 완료하는 데 충분한 작업자가 필요합니다.

권장 조치:

  • 새 파티션이 필요하고(예: 월별 기반 파티션) 이전 파티션이 롤오프될 때 워크로드가 차단되지 않도록 파티션을 미리 생성해야 합니다.

  • 모든 파티션의 일반적인 정리 유지 관리를 수행할 수 있는 Autovacuum 작업자가 충분한지 확인합니다.

대략적인 임계값: 수백

임시 파일

위에서 언급한 임시 테이블과는 다르게 임시 파일은 복잡한 쿼리가 여러 가지 정렬 또는 해시 연산을 동시에 수행할 때 PostgreSQL에서 생성되며, 각 연산은 인스턴스 메모리를 사용하여 work_mem 파라미터에 지정된 값까지 결과를 저장합니다. 인스턴스 메모리가 충분하지 않은 경우 결과를 저장하기 위한 임시 파일이 생성됩니다. 임시 파일에 대한 자세한 내용은 임시 파일 관리를 참조하세요. 워크로드에서 이러한 파일을 다수 생성하면 여러 가지 영향이 있을 수 있습니다.

영향: FreeLocalStorage 소비

임시 파일은 쿼리 결과가 work_mem에 맞지 않는 경우 PostgreSQL의 필수 부분입니다. 일반적으로 이는 문제가 없습니다. 그러나 워크로드가 이를 광범위하게 사용하는 경우 대규모 쿼리가 지속적으로 실행되고 있음을 나타내며 FreeLocalStorage가 감소하는 것을 확인할 수 있습니다. 자세한 내용은 임시 파일 관리를 참조하세요.

일반 모범 사례:

  • 성능 개선 도우미를 사용하여 임시 파일 사용량을 모니터링합니다.

  • 중요한 임시 파일을 생성하는 쿼리를 조정하여 임시 파일의 총 수를 줄일 수 있는지 확인합니다.

대략적인 임계값: 수천

시퀀스

시퀀스는 PostgreSQL에서 열을 자동 증분하는 데 사용되는 기본 객체이며 데이터의 고유성과 키를 제공합니다. 논리적 복제를 제외하고 정상 작업 중에는 결과 없이 개별 테이블에서 사용할 수 있습니다.

PostgreSQL에서 논리적 복제는 현재 시퀀스의 현재 값을 구독자에게 복제하지 않습니다. 자세한 내용은 PostgreSQL 설명서의 등록 페이지를 참조하세요.

영향: 전환 시간 연장

모든 유형의 구성 변경 또는 업그레이드에 블루/그린 배포를 사용하려는 경우 많은 시퀀스가 전환에 미치는 영향을 이해하는 것이 중요합니다. 전환의 마지막 단계 중 하나는 시퀀스의 현재 값을 동기화하며, 수천 개가 있는 경우 전체 전환 시간이 늘어납니다.

권장 작업: 데이터베이스 워크로드에서 테이블당 시퀀스 접근 방식 대신 공유 UUID를 사용할 수 있는 경우, 전환 중에 동기화 단계가 중단됩니다.

대략적인 임계값: 수천

대형 객체

큰 객체는 pg_largeobject라는 단일 시스템 테이블에 저장됩니다. 또한 각 대형 객체에는 시스템 테이블 pg_largeobject_metadata에 항목이 있습니다. 이러한 객체는 표준 관계와 크게 다르게 생성, 수정 및 정리됩니다. 대형 객체는 autovacuum에서 처리하지 않으며 vacuumlo라는 별도의 프로세스를 통해 주기적으로 정리해야 합니다. 대형 객체 관리에 대한 예제는 lo 모듈을 사용한 대형 객체 관리를 참조하세요.

영향: 논리적 복제

큰 객체는 현재 논리적 복제 중에 PostgreSQL에 복제되지 않습니다. 자세한 내용은 PostgreSQL 설명서의 등록 페이지를 참조하세요. 블루/그린 구성에서는 블루 환경의 큰 객체가 그린 환경에 복제되지 않습니다.

영향: 메이저 버전 업그레이드

대형 객체가 수백만 개이고 인스턴스가 업그레이드 중에 이를 처리할 수 없는 경우 메모리 부족이 발생하여 업그레이드가 실패할 수 있습니다. PostgreSQL 메이저 버전 업그레이드 프로세스는 크게 두 단계로 구성됩니다. pg_dump를 통해 스키마를 덤프하는 단계와 pg_restore를 통해 스키마를 복원하는 단계입니다. 데이터베이스에 수백만 개의 대형 객체가 있는 경우 업그레이드 중에 pg_dump 및 pg_restore를 처리할 수 있도록 인스턴스에 충분한 메모리가 있는지 확인하고 더 큰 인스턴스 유형으로 규모를 조정해야 합니다.

일반 모범 사례:

  • vacuumlo 유틸리티를 정기적으로 사용하여 고립된 큰 객체를 제거합니다.

  • 데이터베이스에 대용량 객체를 저장하려면 BYTEA 데이터 유형을 사용하는 것이 좋습니다.

대략적인 임계값: 수백만

대략적인 임계값

이 주제에 언급된 대략적인 임계값은 특정 리소스의 규모를 추정하는 데만 사용됩니다. 설명된 영향이 발생할 가능성이 더 높은 일반적인 범위를 나타내지만 실제 동작은 구체적인 워크로드, 인스턴스 크기 및 구성에 따라 달라집니다. 이러한 추정치를 초과할 수 있지만 나열된 영향을 방지하기 위해 주의 및 유지 관리를 준수해야 합니다.