의사 결정 매트릭스

PostgreSQL과 함께 사용해야 하는 멀티 테넌트 SaaS 파티셔닝 모델을 결정하려면 다음 의사 결정 매트릭스를 참조하십시오. 매트릭스는 다음 네 가지 파티셔닝 옵션을 분석합니다.

• 사일로 (Silo) - 테넌트별로 별도의 PostgreSQL 인스턴스 또는 클러스터

• 개별 데이터베이스와의 브리지 - 단일 PostgreSQL 인스턴스 또는 클러스터의 각 테넌트에 대한 별도의 데이터베이스입니다.

• 별도의 스키마가 있는 브리지 - 단일 PostgreSQL 인스턴스 또는 클러스터의 단일 PostgreSQL 데이터베이스의 각 테넌트에 대한 별도의 스키마입니다.

• 풀 - 단일 인스턴스 및 스키마의 테넌트용 공유 테이블입니다.

	저장고	별도의 데이터베이스가 있는 브리지	별도의 스키마가 있는 브리지	풀
사용 사례	리소스 사용을 완벽하게 제어하여 데이터를 격리하는 것이 핵심 요구 사항이며, 규모가 매우 크고 성능에 매우 민감한 테넌트가 있는 경우	데이터 격리는 핵심 요구 사항이며 테넌트 데이터의 상호 참조는 제한적이거나 전혀 필요하지 않습니다.	적당한 수의 테넌트가 있고 데이터 양이 적당합니다. 테넌트의 데이터를 상호 참조해야 하는 경우 이 모델이 선호되는 모델입니다.	테넌트당 데이터 수가 적은 다수의 테넌트
새로운 테넌트 온보딩 민첩성	매우 느느립니다. (각 테넌트마다 새 인스턴스 또는 클러스터가 필요합니다.)	약간 느느립니다. (스키마 객체를 저장하려면 각 테넌트에 대해 새 데이터베이스를 만들어야 합니다.)	약간 느느립니다. (각 테넌트가 객체를 저장하려면 새 스키마를 만들어야 합니다.)	가장 빠른 옵션. (최소 설정이 필요합니다.)
데이터베이스 연결 풀 구성 노력 및 효율성	상당한 노력이 필요합니다. (테넌트당 하나의 연결 풀) 효율성이 떨어집니다. (테넌트 간 데이터베이스 연결 공유는 없습니다.)	상당한 노력이 필요합니다. (Amazon RDS 프록시를 사용하지 않는 한 테넌트당 하나의 연결 풀 구성) 효율성이 떨어집니다. (테넌트 및 총 연결 수 간 데이터베이스 연결 공유가 없습니다. DB 인스턴스 클래스를 기반으로 모든 테넌트별로 제한됩니다.)	더 적은 노력이 필요합니다. (모든 테넌트에 대한 하나의 연결 풀 구성) 적당히 효율적입니다. (세션 풀 모드에서만SET ROLE 또는SET SCHEMA 명령을 통한 연결 재사용이 가능합니다. SET또한 명령은 Amazon RDS Proxy를 사용할 때 세션 피닝을 유발하지만 효율성을 위해 각 요청에 대해 클라이언트 연결 풀을 제거하고 각 요청에 대해 직접 연결할 수 있습니다.)	최소한의 노력이 필요합니다. 가장 효율적입니다. (모든 테넌트를 위한 하나의 연결 풀과 모든 테넌트에서 효율적인 연결 재사용. DB 인스턴스 클래스를 기반으로 제한됩니다.)
데이터베이스 유지 관리 (진공 관리) 및 리소스 사용	간단한 관리	중간 수준의 복잡 (이후 각 데이터베이스에 대해 진공 작업자를 시작해야 하기 때문에 리소스 소비가 높아질 수 있으며vacuum_naptime, 이로 인해 autovacuum Launcher CPU 사용량이 높아질 수 있습니다. 또한 각 데이터베이스의 PostgreSQL 시스템 카탈로그 테이블을 정리하는 것과 관련된 추가 오버헤드가 발생할 수 있습니다.)	대형 PostgreSQL 시스템 카탈로그 테이블 (테넌트 수와 관계에 따라 총pg_catalog 크기는 수십 GB 단위입니다. 테이블 팽창을 제어하려면 진공 청소기 관련 매개 변수를 수정해야 할 수 있습니다.)	테넌트 수와 테넌트당 데이터에 따라 테이블이 클 수 있습니다. (테이블 팽창을 제어하려면 진공 청소기 관련 매개 변수를 수정해야 할 수 있습니다.)
확장 프로그램 관리 노력	상당한 노력 (개별 인스턴스의 각 데이터베이스에 대해)	상당한 노력 (각 데이터베이스 수준에서)	최소한의 노력 (공통 데이터베이스에서 한 번)	최소한의 노력 (공통 데이터베이스에서 한 번)
배포 작업 변경	중요한 작업 (각 개별 인스턴스에 Connect 변경 사항을 롤아웃하십시오.)	중요한 작업 (각 데이터베이스 및 스키마에 Connect 변경 사항을 롤아웃하십시오.)	적당한 노력. (공통 데이터베이스에 Connect 각 스키마에 대한 변경 내용을 롤아웃합니다.)	최소한의 노력. (공통 데이터베이스에 Connect 변경 사항을 적용하십시오.)
변경 배포 — 영향 범위	최소화 (단일 테넌트가 영향을 받습니다.)	최소화 (단일 테넌트가 영향을 받습니다.)	최소화 (단일 테넌트가 영향을 받습니다.)	매우 큽니다. (모든 임차인이 영향을 받습니다.)
쿼리 성능 관리 및 작업	관리 가능한 쿼리 성능.	관리 가능한 쿼리 성능.	관리 가능한 쿼리 성능.	쿼리 성능을 유지하려면 상당한 노력이 필요할 수 있습니다. (시간이 지남에 따라 테이블 크기 증가로 인해 쿼리가 더 느리게 실행될 수 있습니다. 테이블 파티셔닝 및 데이터베이스 샤딩을 사용하여 성능을 유지할 수 있습니다.)
테넌트 간 리소스 영향	영향 (테넌트 간 리소스 공유 없음)	중간 영향 (테넌트는 인스턴스 CPU 및 메모리와 같은 공통 리소스를 공유합니다.)	중간 영향 (테넌트는 인스턴스 CPU 및 메모리와 같은 공통 리소스를 공유합니다.)	큰 영향 (테넌트는 리소스, 잠금 충돌 등의 측면에서 서로 영향을 미칩니다.)
테넌트 수준 조정 (예: 테넌트당 추가 인덱스 생성 또는 특정 테넌트에 대한 DB 매개 변수 조정)	가능한.	다소 가능한 (각 테넌트에 대해 스키마 수준 변경이 가능하지만 데이터베이스 매개변수는 모든 테넌트에서 전역적으로 적용됩니다.)	다소 가능한 (각 테넌트에 대해 스키마 수준 변경이 가능하지만 데이터베이스 매개변수는 모든 테넌트에서 전역적으로 적용됩니다.)	가능한 한 경과. (테이블은 모든 테넌트가 공유합니다.)
성능에 민감한 테넌트를 위한 노력 재조정	최소화 (밸런스를 조정할 필요가 없습니다. 이 시나리오를 처리하기 위해 서버 및 I/O 리소스를 확장하십시오.)	보통 (논리적 복제를 사용하거나 데이터베이스를 내보내는pg_dump 데 사용하지만 데이터 크기에 따라 가동 중지 시간이 길어질 수 있습니다. Amazon RDS for PostgreSQL RDS의 전송 가능한 데이터베이스 기능을 사용하여 인스턴스 간에 데이터베이스를 더 빠르게 복사할 수 있습니다.)	보통이지만 다운타임이 오래 걸릴 수 있습니다. (논리적 복제를 사용하거나 스키마를 내보내는pg_dump 데 사용하지만 데이터 크기에 따라 가동 중지 시간이 길어질 수 있습니다.)	모든 테넌트가 동일한 테이블을 공유하기 때문에 중요합니다. (데이터베이스를 분할하려면 모든 항목을 다른 인스턴스에 복사하고 테넌트 데이터를 정리하기 위한 추가 단계가 필요합니다.) 애플리케이션 로직의 변경이 필요할 가능성이 높습니다.
메이저 버전 업그레이드를 위한 데이터베이스 다운타임	표준 가동 중지 중지 중지 (PostgreSQL 시스템 카탈로그 크기에 따라 다릅니다.)	다운타임이 더 길어질 수 있습니다. (시스템 카탈로그 크기에 따라 시간이 달라집니다. PostgreSQL 시스템 카탈로그 테이블도 데이터베이스 간에 복제됩니다.)	다운타임이 더 길어질 수 있습니다. (PostgreSQL 시스템 카탈로그 크기에 따라 시간이 달라집니다.)	표준 가동 중지 중지 중지 (PostgreSQL 시스템 카탈로그 크기에 따라 다릅니다.)
관리 오버헤드 (예: 데이터베이스 로그 분석 또는 백업 작업 모니터링용)	중요한 작업	최소한의 노력.	최소한의 노력.	최소한의 노력.
테넌트 수준의 가용성	최하위. (각 테넌트에 장애가 발생하고 독립적으로 복구됩니다.)	더 높은 영향 범위. (하드웨어 또는 리소스 문제가 발생할 경우 모든 테넌트에 장애가 발생하고 함께 복구됩니다.)	더 높은 영향 범위. (하드웨어 또는 리소스 문제가 발생할 경우 모든 테넌트에 장애가 발생하고 함께 복구됩니다.)	더 높은 영향 범위. (하드웨어 또는 리소스 문제가 발생할 경우 모든 테넌트에 장애가 발생하고 함께 복구됩니다.)
테넌트 수준의 백업 및 복구 노력	최소 (각 테넌트별로 개별적으로 백업 및 복원할 수 있습니다.)	적당한 노력. (각 테넌트에 대해 논리적 내보내기 및 가져오기를 사용하십시오. 일부 코딩 및 자동화가 필요합니다.)	적당한 노력. (각 테넌트에 대해 논리적 내보내기 및 가져오기를 사용하십시오. 일부 코딩 및 자동화가 필요합니다.)	중요한 작업 (모든 임차인이 동일한 테이블을 공유합니다.)
테넌트 수준의 point-in-time 복구 노력	최소한의 노력. (스냅샷을 사용하여 특정 시점 복구를 사용하거나 Amazon Aurora Aurora에서 백트래킹을 사용하십시오.)	적당한 노력. (스냅샷 복원을 사용한 다음 내보내기/가져오기를 사용합니다. 하지만 이렇게 하면 작업 속도가 느려질 수 있습니다.)	적당한 노력. (스냅샷 복원을 사용한 다음 내보내기/가져오기를 사용합니다. 하지만 이렇게 하면 작업 속도가 느려질 수 있습니다.)	상당한 노력과 복잡성.
동일한 스키마	테넌트별로 동일한 스키마 이름.	테넌트별로 동일한 스키마 이름.	테넌트별로 서로 다른 스키마.	공통 스키마입니다.
테넌트별 사용자 지정 (예: 특정 테넌트에 대한 추가 테이블 열)	가능한.	가능한.	가능한.	복잡합니다 (모든 테넌트가 동일한 테이블을 공유하기 때문에).
객체 관계형 매핑 (ORM) 계층 (예: Ruby) 에서의 카탈로그 관리 효율성	효율적입니다 (클라이언트 연결이 테넌트별로 다르기 때문에).	효율적입니다 (클라이언트 연결이 데이터베이스에만 해당되기 때문에).	적당히 효율적입니다. (사용된 ORM, 사용자/역할 보안 모델 및search_path 구성에 따라 클라이언트가 모든 테넌트의 메타데이터를 캐시하는 경우가 있어 DB 연결 메모리 사용량이 높아지는 경우가 있습니다.)	효율적입니다 (모든 테넌트가 동일한 테이블을 공유하기 때문에).
통합된 테넌트 보고 작업	중요한 작업 (모든 테넌트의 데이터를 통합하거나 [ETL] 을 추출, 변환 및 다른 보고 데이터베이스로 로드하려면 외부 데이터 래퍼 [FDW] 를 사용해야 합니다.)	중요한 작업 (FDW를 사용하여 모든 테넌트 또는 ETL의 데이터를 다른 보고 데이터베이스로 통합해야 합니다.)	적당한 노력. (유니온을 사용하여 모든 스키마의 데이터를 집계할 수 있습니다.)	최소한의 노력. (모든 테넌트 데이터는 동일한 테이블에 있으므로 보고가 간단합니다.)
보고용 테넌트별 읽기 전용 인스턴스 (예: 구독 기반)	최소 (읽기 전용 복제본을 생성합니다.)	적당한 노력. (논리적 복제 또는AWS Database Migration Service [AWS DMS] 를 사용하여 구성할 수 있습니다.)	적당한 노력. (논리적 복제를 사용하거나 구성할AWS DMS 수 있습니다.)	복잡합니다 (모든 테넌트가 동일한 테이블을 공유하기 때문에).
데이터 격리	최하위.	상급. (PostgreSQL 역할을 사용하여 데이터베이스 수준 권한을 관리할 수 있습니다.)	상급. (PostgreSQL 역할을 사용하여 스키마 수준 권한을 관리할 수 있습니다.)	더 나쁜. (모든 테넌트가 동일한 테이블을 공유하므로 테넌트 격리를 위한 행 수준 보안 [RLS] 와 같은 기능을 구현해야 합니다.)
테넌트별 스토리지 암호화 키	가능한. (각 PostgreSQL 클러스터에는 스토리지 암호화를 위한 자체AWS Key Management Service [AWS KMS] 키가 있을 수 있습니다.)	가능한 한 경과. (모든 테넌트는 스토리지 암호화를 위해 동일한 KMS 키를 공유합니다.)	가능한 한 경과. (모든 테넌트는 스토리지 암호화를 위해 동일한 KMS 키를 공유합니다.)	가능한 한 경과. (모든 테넌트는 스토리지 암호화를 위해 동일한 KMS 키를 공유합니다.)
각 테넌트의 데이터베이스 인증에AWS Identity and Access Management (IAM) 사용	가능한.	가능한.	가능 (각 스키마에 대해 별도의 PostgreSQL 사용자를 사용하는 경우).	불가능합니다 (모든 테넌트가 테이블을 공유하기 때문에).
인프라	가장 높음 (아무것도 공유되지 않기 때문에)	보통	보통	최하위.
데이터 복제 및 스토리지 사용	모든 테넌트 중 가장 높은 집계. (PostgreSQL 시스템 카탈로그 테이블과 애플리케이션의 정적 및 공통 데이터는 모든 테넌트에서 중복됩니다.)	모든 테넌트 중 가장 높은 집계. (PostgreSQL 시스템 카탈로그 테이블과 애플리케이션의 정적 및 공통 데이터는 모든 테넌트에서 중복됩니다.)	보통 (애플리케이션의 정적 및 공통 데이터는 공통 스키마에 있고 다른 테넌트가 액세스할 수 있습니다.)	최소화 (데이터 중복 없음. 애플리케이션의 정적 데이터와 공통 데이터는 동일한 스키마에 있을 수 있습니다.)
테넌트 중심 모니터링 (문제를 일으키는 테넌트를 빠르게 파악)	최소 (각 테넌트가 개별적으로 모니터링되므로 특정 테넌트의 활동을 쉽게 확인할 수 있습니다.)	적당한 노력. (모든 테넌트가 동일한 물리적 리소스를 공유하므로 특정 테넌트의 활동을 확인하려면 추가 필터링을 적용해야 합니다.)	적당한 노력. (모든 테넌트가 동일한 물리적 리소스를 공유하므로 특정 테넌트의 활동을 확인하려면 추가 필터링을 적용해야 합니다.)	중요한 작업 (모든 테넌트가 테이블을 비롯한 모든 리소스를 공유하므로 바인드 변수 캡처를 사용하여 특정 SQL 쿼리가 속한 테넌트를 확인해야 합니다.)
중앙 집중식 관리 및 상태/활동 모니터링	상당한 노력 (중앙 모니터링 및 중앙 지휘 센터 설치).	모든 테넌트가 동일한 인스턴스를 공유하기 때문에 작업량이 적당합니다.	모든 테넌트가 동일한 인스턴스를 공유하기 때문에 작업량이 적당합니다.	최소한의 노력 (모든 테넌트가 스키마를 포함하여 동일한 리소스를 공유하기 때문)
객체 식별자 (OID) 및 트랜잭션 ID (XID) 를 한 눈에 파악할 수 있는 기회	최소화	높음. (OID, XID는 단일 PostgreSQL 클러스터 전체 카운터이기 때문에 물리적 데이터베이스를 효과적으로 정리하는 데 문제가 있을 수 있습니다.)	보통 (OID, XID는 단일 PostgreSQL 클러스터 전체 카운터이기 때문입니다).	높음. (예를 들어 단일 테이블은 out-of-line 열 수에 따라 TOAST OID 제한인 40억 개에 도달할 수 있습니다.)