# Amazon Aurora PostgreSQL에서 다수의 객체 관리
PostgreSQL 제한은 이론적이지만 데이터베이스의 객체 수가 매우 많으면 다양한 작업에서 성능에 상당한 영향을 미칠 수 있습니다. 이 설명서에서는 총 객체 수가 많을 때 여러 가지 영향을 미칠 수 있는 몇 가지 일반적인 객체 유형을 다룹니다.
다음 표에는 객체 유형과 그 잠재적 영향에 대한 요약이 있습니다.
**객체 유형 및 잠재적 영향**
| 객체 유형 | AUTOVACUUM | 논리적 복제 | 메이저 버전 업그레이드 | pg\$1dump/pg\$1restore | 일반 성능 | 인스턴스 재시작 |
| --- | --- | --- | --- | --- | --- | --- |
| [관계](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [임시 테이블](#PostgreSQL.HighObjectCount.TempTables). | x | | | | x | |
| [로깅되지 않은 테이블](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [파티션](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [임시 파일](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [시퀀스](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [대형 객체](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## 관계
PostgreSQL 데이터베이스의 테이블 수에는 구체적인 하드 제한이 없습니다. 이론적인 한도는 매우 높지만 데이터베이스 설계 중에 염두에 두어야 할 다른 실제 한도가 있습니다.
**영향: Autovacuum이 뒤처짐**
Autovacuum이 작업량에 비해 작업자가 부족하여 트랜잭션 ID 증가 또는 테이블 팽창을 따라잡는 데 어려움을 겪을 수 있습니다.
**권장 작업:** Autovacuum을 조정하여 지정된 수의 테이블과 지정된 워크로드를 제대로 따라잡기 위한 몇 가지 요소가 있습니다. 적절한 Autovacuum 설정을 결정하는 방법에 대한 제안은 [PostgreSQL Autovacuum 작업 모범 사례](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.html#AuroraPostgreSQL.BestPractices.Autovacuum)를 참조하세요. [postgres\$1get\$1av\$1diag 유틸리티](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html)를 사용하여 트랜잭션 ID 증가 문제를 모니터링합니다.
**영향: 메이저 버전 업그레이드/pg\$1dump 및 복원**
Amazon RDS는 pg\$1upgrade 실행 중에 "--link" 옵션을 사용하여 데이터 파일을 복사할 필요가 없습니다. 스키마 메타데이터는 여전히 데이터베이스의 새 버전으로 복원해야 합니다. 병렬 pg\$1restore를 사용하더라도 관계의 수가 많으면 가동 중지 시간이 늘어납니다.
**영향: 일반 성능 저하**
카탈로그 크기로 인해 일반적인 성능이 저하됩니다. 각 테이블과 연결된 열은 일반 데이터베이스 작업에 자주 사용되는 `pg_attribute`, `pg_class` 및 `pg_depend` 테이블에 추가됩니다. 특정 대기 이벤트는 표시되지 않지만 공유 버퍼 효율성은 영향을 받습니다.
**권장 작업:** 이러한 특정 테이블에 대한 테이블 팽창을 정기적으로 확인하고 가끔 이러한 특정 테이블에 대해 `VACUUM FULL`을 수행합니다. 카탈로그 테이블에서 `VACUUM FULL`에는 `ACCESS EXCLUSIVE` 잠금이 필요합니다. 즉, 작업이 완료될 때까지 다른 쿼리는 액세스할 수 없습니다.
**대략적인 임계값:** [수백만](#PostgreSQL.HighObjectCount.Note)
## 임시 테이블
임시 테이블 사용은 테스트 데이터 또는 중간 결과에 유용하며 많은 데이터베이스 엔진에서 볼 수 있는 일반적인 패턴입니다. 일부 위험을 방지하려면 PostgreSQL에서 과도한 사용의 영향을 이해해야 합니다. 각 임시 테이블 생성 및 삭제는 시스템 카탈로그 테이블에 행을 추가하며, 테이블이 팽창하면 일반적인 성능 문제가 발생합니다.
**영향: Autovacuum이 뒤처짐**
임시 테이블은 autovacuum에 의해 vacuum되지 않지만, 존재하는 동안 트랜잭션 ID를 유지하고 제거하지 않으면 랩어라운드로 이어질 수 있습니다.
**권장 작업:** 임시 테이블은 테이블을 생성한 세션 기간 동안 유지되거나 수동으로 삭제할 수 있습니다. 임시 테이블을 사용하여 장기 실행 트랜잭션을 방지하는 모범 사례는 이러한 테이블이 최대 사용 트랜잭션 ID 증가에 기여하지 못하게 합니다.
**영향: 일반 성능 저하**
카탈로그 크기로 인해 일반적인 성능이 저하됩니다. 세션이 임시 테이블을 지속적으로 생성하고 삭제할 때, 일반 데이터베이스 작업에 자주 사용되는 `pg_attribute`, `pg_class` 및 `pg_depend` 테이블에 추가됩니다. 특정 대기 이벤트는 표시되지 않지만 공유 버퍼 효율성은 영향을 받습니다.
**권장 조치:**
+ 이러한 특정 테이블에 대한 테이블 팽창을 정기적으로 확인하고 가끔 이러한 특정 테이블에 대해 `VACUUM FULL`을 수행합니다. 카탈로그 테이블에서 `VACUUM FULL`에는 `ACCESS EXCLUSIVE` 잠금이 필요합니다. 즉, 작업이 완료될 때까지 다른 쿼리는 액세스할 수 없습니다.
+ 임시 테이블이 많이 사용되는 경우 메이저 버전 업그레이드 전에 가동 중지 시간을 줄이기 위해 이러한 특정 카탈로그 테이블의 `VACUUM FULL`을 사용하는 것이 좋습니다.
**일반 모범 사례:**
+ 일반적인 테이블 표현식을 사용해 중간 결과를 생성하여 임시 테이블 사용을 줄입니다. 이렇게 하면 필요한 쿼리를 복잡해질 수 있지만 위에 나열된 영향이 제거됩니다.
+ 삭제/생성 단계를 수행하는 대신 `TRUNCATE` 명령을 사용하여 콘텐츠를 지워 임시 테이블을 재사용합니다. 이렇게 하면 임시 테이블로 인한 트랜잭션 ID 증가 문제도 제거됩니다.
**대략적인 임계값:** [수만](#PostgreSQL.HighObjectCount.Note)
## 로깅되지 않은 테이블
로깅되지 않은 테이블은 WAL 정보를 생성하지 않으므로 성능 향상을 제공할 수 있습니다. 데이터베이스 충돌 복구 중에는 잘릴 것이므로 내구성을 제공하지 않으므로 신중하게 사용해야 합니다. PostgreSQL에서는 로깅되지 않은 각 테이블이 순차적으로 잘리기 때문에 작업에 비용이 많이 듭니다. 이 작업은 로깅되지 않은 테이블 수가 적은 경우에는 속도가 빠르지만, 수천 개 단위로 계산되면 시작 중에 눈에 띄는 지연을 추가되기 시작할 수 있습니다.
**영향: 논리적 복제**
[블루/그린 배포](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html)를 포함한 논리적 복제는 WAL을 사용하여 변경 사항을 캡처하고 전송하기 때문에 로깅되지 않은 테이블은 일반적으로 논리적 복제에 포함되지 않습니다. [로깅되지 않은 테이블을 복제](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-postgresql-unlogged-tables.html#aurora-postgresql-unlogged-tables-logicalrep)하도록 Aurora PostgreSQL을 구성하는 방법에 대해 자세히 알아보세요.
**영향: 리더 노드**
로깅되지 않은 테이블은 Aurora DB 클러스터의 라이터 노드에서만 액세스할 수 있습니다. 자세한 내용은 [Aurora PostgreSQL에서 로깅되지 않은 테이블 작업](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-postgresql-unlogged-tables.html)을 확인하세요.
**일반 모범 사례:**
+ 로깅되지 않은 테이블은 표준 PostgreSQL에 비해 Aurora PostgreSQL에서 제한된 성능 이점을 제공하므로 일반 테이블이 더 적절한지 평가합니다.
**대략적인 임계값:** [수천](#PostgreSQL.HighObjectCount.Note)
## 파티션
파티셔닝은 쿼리 성능을 높이고 데이터의 논리적 구성을 제공할 수 있습니다. 이상적인 시나리오에서는 파티셔닝이 구성되어 쿼리 계획 및 실행 중에 파티션 정리를 사용할 수 있습니다. 파티션을 너무 많이 사용하면 쿼리 성능 및 데이터베이스 유지 관리에 부정적인 영향을 미칠 수 있습니다. 잘못된 설계로 인해 쿼리 계획 및 실행 성능이 부정적인 영향을 받을 수 있으므로 테이블을 분할하는 방법을 신중하게 선택해야 합니다. 파티셔닝에 대한 자세한 내용은 [PostgreSQL 설명서](https://www.postgresql.org/docs/current/ddl-partitioning.html)를 참조하세요.
**영향: 일반 성능 저하**
간혹 시간 계획 오버헤드가 증가하고 쿼리에 대한 계획이 더 복잡해져 튜닝 기회를 식별하기가 어려워집니다. PostgreSQL 18 이전 버전의 경우 워크로드가 많은 여러 파티션에 `LWLock:LockManager` 대기가 발생할 수 있습니다.
**권장 작업:** 성능 있는 쿼리 실행을 제공하는 동시에 데이터 구성을 모두 완료할 수 있는 최소 파티션 수를 결정합니다.
**영향: 유지 관리 복잡성**
파티션 수가 매우 많으면 사전 생성 및 제거와 같은 유지 관리 문제가 발생합니다. Autovacuum은 파티션을 일반적인 관계로 취급하며, 정기적인 정리를 수행해야 하므로 작업을 완료하는 데 충분한 작업자가 필요합니다.
**권장 조치:**
+ 새 파티션이 필요하고(예: 월별 기반 파티션) 이전 파티션이 롤오프될 때 워크로드가 차단되지 않도록 파티션을 미리 생성해야 합니다.
+ 모든 파티션의 일반적인 정리 유지 관리를 수행할 수 있는 Autovacuum 작업자가 충분한지 확인합니다.
**대략적인 임계값:** [수백](#PostgreSQL.HighObjectCount.Note)
## 임시 파일
위에서 언급한 임시 테이블과는 다르게 임시 파일은 복잡한 쿼리가 여러 가지 정렬 또는 해시 연산을 동시에 수행할 때 PostgreSQL에서 생성되며, 각 연산은 인스턴스 메모리를 사용하여 `work_mem` 파라미터에 지정된 값까지 결과를 저장합니다. 인스턴스 메모리가 충분하지 않은 경우 결과를 저장하기 위한 임시 파일이 생성됩니다. 임시 파일에 대한 자세한 내용은 [임시 파일 관리](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL.ManagingTempFiles.html)를 참조하세요. 워크로드에서 이러한 파일을 다수 생성하면 여러 가지 영향이 있을 수 있습니다.
**영향: FreeLocalStorage 소비**
임시 파일은 쿼리 결과가 work\$1mem에 맞지 않는 경우 PostgreSQL의 필수 부분입니다. 일반적으로 이는 문제가 없습니다. 그러나 워크로드가 이를 광범위하게 사용하는 경우 대규모 쿼리가 지속적으로 실행되고 있음을 나타내며 FreeLocalStorage가 감소하는 것을 확인할 수 있습니다. 자세한 내용은 [임시 파일 관리](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL.ManagingTempFiles.html)를 참조하세요.
**일반 모범 사례:**
+ [성능 개선 도우미](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html)를 사용하여 임시 파일 사용량을 모니터링합니다.
+ 중요한 임시 파일을 생성하는 쿼리를 조정하여 임시 파일의 총 수를 줄일 수 있는지 확인합니다.
**대략적인 임계값:** [수천](#PostgreSQL.HighObjectCount.Note)
## 시퀀스
시퀀스는 PostgreSQL에서 열을 자동 증분하는 데 사용되는 기본 객체이며 데이터의 고유성과 키를 제공합니다. 논리적 복제를 제외하고 정상 작업 중에는 결과 없이 개별 테이블에서 사용할 수 있습니다.
PostgreSQL에서 논리적 복제는 현재 시퀀스의 현재 값을 구독자에게 복제하지 않습니다. 자세한 내용은 [PostgreSQL 설명서의 등록 페이지](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)를 참조하세요.
**영향: 전환 시간 연장**
모든 유형의 구성 변경 또는 업그레이드에 [블루/그린 배포](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html)를 사용하려는 경우 많은 시퀀스가 전환에 미치는 영향을 이해하는 것이 중요합니다. 전환의 마지막 단계 중 하나는 시퀀스의 현재 값을 동기화하며, 수천 개가 있는 경우 전체 전환 시간이 늘어납니다.
**권장 작업:** 데이터베이스 워크로드에서 테이블당 시퀀스 접근 방식 대신 공유 UUID를 사용할 수 있는 경우, 전환 중에 동기화 단계가 중단됩니다.
**대략적인 임계값:** [수천](#PostgreSQL.HighObjectCount.Note)
## 대형 객체
큰 객체는 pg\$1largeobject라는 단일 시스템 테이블에 저장됩니다. 또한 각 대형 객체에는 시스템 테이블 pg\$1largeobject\$1metadata에 항목이 있습니다. 이러한 객체는 표준 관계와 크게 다르게 생성, 수정 및 정리됩니다. 대형 객체는 autovacuum에서 처리하지 않으며 vacuumlo라는 별도의 프로세스를 통해 주기적으로 정리해야 합니다. 대형 객체 관리에 대한 예제는 lo 모듈을 사용한 대형 객체 관리를 참조하세요.
**영향: 논리적 복제**
큰 객체는 현재 논리적 복제 중에 PostgreSQL에 복제되지 않습니다. 자세한 내용은 [PostgreSQL 설명서의 등록 페이지](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)를 참조하세요. [블루/그린](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) 구성에서는 블루 환경의 큰 객체가 그린 환경에 복제되지 않습니다.
**영향: 메이저 버전 업그레이드**
대형 객체가 수백만 개이고 인스턴스가 업그레이드 중에 이를 처리할 수 없는 경우 메모리 부족이 발생하여 업그레이드가 실패할 수 있습니다. PostgreSQL 메이저 버전 업그레이드 프로세스는 크게 두 단계로 구성됩니다. pg\$1dump를 통해 스키마를 덤프하는 단계와 pg\$1restore를 통해 스키마를 복원하는 단계입니다. 데이터베이스에 수백만 개의 대형 객체가 있는 경우 업그레이드 중에 pg\$1dump 및 pg\$1restore를 처리할 수 있도록 인스턴스에 충분한 메모리가 있는지 확인하고 더 큰 인스턴스 유형으로 규모를 조정해야 합니다.
**일반 모범 사례:**
+ vacuumlo 유틸리티를 정기적으로 사용하여 고립된 큰 객체를 제거합니다.
+ 데이터베이스에 대용량 객체를 저장하려면 BYTEA 데이터 유형을 사용하는 것이 좋습니다.
**대략적인 임계값:** [수백만](#PostgreSQL.HighObjectCount.Note)
## 대략적인 임계값
이 주제에 언급된 대략적인 임계값은 특정 리소스의 규모를 추정하는 데만 사용됩니다. 설명된 영향이 발생할 가능성이 더 높은 일반적인 범위를 나타내지만 실제 동작은 구체적인 워크로드, 인스턴스 크기 및 구성에 따라 달라집니다. 이러한 추정치를 초과할 수 있지만 나열된 영향을 방지하기 위해 주의 및 유지 관리를 준수해야 합니다.