분할은 데이터베이스 시스템과 분산 컴퓨팅에서 여러 서버나 노드에 데이터를 수평으로 분할하는 데 사용되는 기술입니다. 여기에는 대규모 데이터베이스나 데이터 세트를 분할이라고 하는 더 작고 관리하기 쉬운 부분으로 나누는 작업이 포함됩니다. 분할에는 데이터의 하위 집합이 포함되어 있으며 분할이 함께 전체 데이터 세트를 형성합니다.
Azure Database for PostgreSQL 유연한 서버 인스턴스의 탄력적 클러스터는 행 기반 및 스키마 기반의 두 가지 유형의 데이터 분할을 제공합니다. 각 옵션에는 고유한 장단점이 있으므로 애플리케이션 요구 사항에 가장 적합한 방식을 선택할 수 있습니다.
행 기반 분할
단일 데이터베이스 공유 스키마 모델의 분할 테이블은 행 기반 분할이라고도 하며, 테넌트는 동일한 테이블 내에서 행으로 공존합니다. 테넌트는 테이블을 수평으로 분할할 수 있는 배포 열을 정의하여 결정됩니다.
행 기반 분할은 하드웨어 효율성이 가장 높은 방법입니다. 테넌트는 클러스터의 노드 간에 조밀하게 구성되어 분산됩니다. 하지만 이 방식을 사용하려면 스키마의 모든 테이블에 배포 열이 있는지 확인해야 하며 애플리케이션의 모든 쿼리가 해당 열을 기준으로 필터링되어야 합니다. 행 기반 분할은 IoT 워크로드와 하드웨어 사용에서 최고의 이익을 달성하는 데 효과적입니다.
이점:
- 최고 성능입니다.
- 노드당 최고의 테넌트 밀도입니다.
단점
- 스키마 수정이 필요합니다.
- 애플리케이션 쿼리 수정이 필요합니다.
- 모든 테넌트가 동일한 스키마를 공유해야 합니다.
스키마 기반 분할
스키마 기반 분할은 공유 데이터베이스, 별도의 스키마 모델이며, 스키마가 데이터베이스 내에서 논리적 분할이 됩니다. 다중 테넌트 앱은 테넌트별 스키마를 사용하여 테넌트 차원에 따라 쉽게 분할할 수 있습니다. 쿼리 변경은 필요하지 않으며 테넌트를 전환할 때 적절한 search_path를 설정하려면 애플리케이션에 약간의 수정만 필요합니다. 스키마 기반 분할은 마이크로 서비스와 행 기반 분할을 적용하는 데 필요한 변경을 적용할 수 없는 애플리케이션을 배포하는 ISV(독립 소프트웨어 공급업체)에 이상적인 솔루션입니다.
이점:
- 테넌트는 이기종 스키마를 가질 수 있습니다.
- 스키마 수정은 필요하지 않습니다.
- 애플리케이션 쿼리 수정은 필요하지 않습니다.
- 스키마 기반 분할 SQL 호환성은 행 기반 분할에 비해 우수합니다.
단점
- 행 기반 분할에 비해 노드당 테넌트 수가 적습니다.
분할 장단점
| 스키마 기반 분할 | 행 기반 분할 | |
|---|---|---|
| 다중 테넌트 모델 | 테넌트당 별도의 스키마 | 테넌트 ID 열이 있는 공유 테이블 |
| Citus 버전 | 12.0+ | 모든 버전 |
| Vanilla PostgreSQL과 비교한 추가 단계 | 없음, 구성만 변경됨 | 각 테이블에서 create_distributed_table을 사용하여 테넌트 ID별로 테이블을 배포하고 배치합니다. |
| 테넌트의 수 | 1-10k | 1-1 M+ |
| 데이터 모델링 요구 사항 | 분산 스키마 전체에 외래 키가 없음 | 각 테이블에 테넌트 ID 열(분산 열, 분할 키라고도 함)을 포함하고 기본 키, 외래 키에 포함해야 함 |
| 단일 노드 쿼리에 대한 SQL 요구 사항 | 쿼리당 단일 분산 스키마 사용 | 조인 및 WHERE 절에는tenant_id 열이 포함되어야 합니다. |
| 병렬 테넌트 간 쿼리 | 아니요 | 예 |
| 테넌트별 사용자 지정 테이블 정의 | 예 | 아니요 |
| 액세스 제어 | 스키마 권한 | 스키마 권한 |
| 테넌트 간 데이터 공유 | 예, 참조 테이블을 사용합니다(별도의 스키마에서). | 예, 참조 테이블을 사용합니다. |
| 분할 격리에 대한 테넌트 | 모든 테넌트는 정의에 따라 자체 분할 그룹을 갖습니다. | isolate_tenant_to_new_shard를 통해 특정 테넌트 ID에 자체 분할 그룹을 제공할 수 있습니다. |