이 문서에서는 온라인 트랜잭션 처리 (OLTP) 및 온라인 분석 처리 (OLAP) 워크로드 모두에 대해 PostgreSQL용 AlloyDB 인스턴스의 크기를 조정하기 위한 워크로드 및 배포 권장사항을 제공합니다.
개요
데이터베이스 성능을 개선하기 위해 PostgreSQL용 AlloyDB는 다음과 같은 기본 제공 기능을 제공합니다.
자동 메모리 관리
적응형 자동 진공 청소
최적화된 내장 성능 설정
복제 지연이 낮음
확장 작업 중에 기본 노드의 경우 1초 미만의 다운타임, 읽기 풀 노드의 경우 다운타임이 없는 무중단 유지보수
성능을 위해 PostgreSQL용 AlloyDB 인스턴스를 조정하려면 다음을 관리해야 합니다.
기본 인스턴스 및 읽기 풀 인스턴스의 크기를 올바르게 조정
성능에 영향을 미치는 플래그 업데이트
크기 조정 고려사항
PostgreSQL용 AlloyDB 인스턴스의 크기를 조정하기 전에 다음을 확인하세요.
워크로드 유형: OLTP, OLAP 또는 HTAP
성능 요구사항: 지연 시간 및 처리량 요구사항
예상 데이터 크기: PostgreSQL용 AlloyDB에 저장할 데이터의 크기 및 활성 데이터 세트 크기
워크로드 규모: 시간이 지남에 따라 데이터 크기가 증가하거나 성장하는 경우
OLTP 작업
PostgreSQL용 AlloyDB 데이터베이스를 영역 인스턴스 (단일 노드) 또는 고가용성 인스턴스 (각 영역에 두 개의 노드)로 배포할 수 있습니다. 선택적으로 지리적으로 분산된 워크로드 또는 재해 복구 (DR)를 위해 다른 리전에 읽기 풀 인스턴스와 보조 클러스터를 추가할 수도 있습니다.
PostgreSQL용 AlloyDB는 분리된 컴퓨팅 및 스토리지가 있는 클라우드 규모의 분산 아키텍처를 사용하여 배포됩니다. 쓰기 작업은 쓰기 앞서 로그 (WAL) 파일이 리전 스토리지에 유지되는 즉시 승인되며, 블록 구체화는 스토리지로 오프로드됩니다.
마찬가지로 다중 계층 캐시 아키텍처를 사용하면 데이터가 버퍼 캐시, 초고속 캐시, 지능형 스토리지 엔진 사이에 자동으로 배치됩니다. PostgreSQL용 AlloyDB에서 사용되는 이 다중 계층 캐시 아키텍처로 인해 초당 입력 및 출력 작업 (IOP)은 다른 데이터베이스 시스템과 비교하는 PostgreSQL용 AlloyDB의 컨텍스트와 관련이 없습니다.
하지만 초당 트랜잭션 수(TPS)/분당 트랜잭션 수 (TPM)를 사용하면 PostgreSQL용 AlloyDB에서 처리할 수 있는 데이터 양을 이해하는 데 의미 있는 비교를 할 수 있습니다.
기본 크기 조정 측정항목은 TPS입니다. 필요한 PostgreSQL용 AlloyDB 크기를 추정하려면 다음 단계를 따르세요.
기존 워크로드 식별 자체 관리 PostgreSQL 또는 기타 상업용 데이터베이스에서 마이그레이션하는 경우 기존 워크로드의 TPS 값이 이미 있을 수 있습니다.
쿼리를 분석합니다. 워크로드에서 가장 중요한 쿼리를 식별하고 성능 요구사항을 확인합니다.
HammerDB 또는 pgbench와 같은 도구를 사용합니다. 이러한 도구는 PostgreSQL용 AlloyDB의 벤치마킹을 지원하고 머신 크기가 TPS 요구사항을 충족하는지 확인하는 데 도움이 됩니다.
적절한 PostgreSQL용 AlloyDB 크기를 선택합니다. 현재 데이터 크기와 향후 성장 기대치를 고려하세요.
머신 크기 가이드라인
다음 예시 표에는 읽기-쓰기 비율이 읽기 약 65%, 쓰기 35% 인 TPC-C 벤치마킹 데이터에 대한 권장사항이 나와 있습니다. AlloyDB for PostgreSQL 인스턴스의 크기를 조정할 때는 운영체제 예약 오버헤드를 방지하기 위해 안정적인 상태의 CPU 사용률이 약 60~70% 가 되도록 해야 합니다. 이를 통해 클라이언트 애플리케이션의 리소스 사용량 급증에 대비할 수 있습니다.
vCPU/Mem
권장 트랜잭션/초 범위 (30% 캐시됨)
권장 작업 데이터 크기 (최대 총 크기 128TB)
권장 max_connections
2 / 16GB
최대 1,000개
최대 100GB
1000
4 / 32GB
최대 2,500
최대 250GB
2000
8/ 64GB
최대 4,000
최대 500GB
4000
16 / 128GB
최대 8,000
최대 1TB
5000
32 / 256GB
최대 14,000
최대 3TB
5000
64 / 512GB
최대 20,000
최대 8TB
5000
96 / 768GB
최대 25,000
최대 16TB
5000
128 / 864GB
20,000개 초과
최대 32TB
5000
배포 유형
워크로드에 따라 PostgreSQL용 AlloyDB를 기본 인스턴스로만 또는 읽기 풀 인스턴스가 있는 기본 인스턴스로 배포할 수 있습니다.
지연 시간에 민감한 읽기가 있는 경우 읽기 쿼리를 읽기 풀 인스턴스로 오프로드하는 것이 좋습니다. 모든 읽기 풀 인스턴스에서 최대 20개의 노드를 구성할 수 있습니다. 자세한 내용은 읽기 풀 인스턴스 만들기를 참고하세요.
데이터베이스가 두 개 이상인 경우(예: 동일한 인스턴스에 CRM 또는 재무가 있는 경우) 여러 읽기 풀 인스턴스를 구성합니다. 이 전략을 사용하면 효과적인 캐싱과 쿼리 성능에 도움이 됩니다.
요구사항에 따라 기본 인스턴스와 읽기 풀 인스턴스의 크기를 다르게 지정할 수 있습니다. 읽기 풀 인스턴스 권장사항에 대한 자세한 내용은 AlloyDB 성능 및 가용성 개선을 위한 권장사항을 참고하세요.
고가용성을 위해 읽기 풀 인스턴스당 노드를 두 개 이상 추가합니다.
읽기 쿼리 성능을 위해 특정 읽기 풀 인스턴스에서 열 형식 엔진을 선택적으로 사용 설정합니다. 기본 인스턴스에서 열 형식 엔진을 사용 설정하지 않아도 됩니다.
색인 자문과 같은 내장 기능을 사용하여 쿼리 성능을 개선할 수 있는 색인을 추가하는 것이 좋습니다.
OLAP 워크로드
OLAP 워크로드의 경우 기본 크기 조정 측정항목은 쿼리 성능, 특히 전체 테이블 스캔이나 집계를 요구하는 쿼리입니다. PostgreSQL용 AlloyDB에는 분석 쿼리를 가속화하는 데 도움이 되는 열 기반 엔진이 내장되어 있습니다. 기본적으로 열 형식 엔진을 사용하면 메모리의 30% 가 사용되고 초고속 캐시 데이터가 자동으로 사용됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-03(UTC)"],[[["\u003cp\u003eThis document offers guidelines for sizing AlloyDB for PostgreSQL instances, focusing on both OLTP and OLAP workloads.\u003c/p\u003e\n"],["\u003cp\u003eAlloyDB for PostgreSQL features include automatic memory management, adaptive autovacuum, optimized performance settings, low replication lag, and non-disruptive maintenance.\u003c/p\u003e\n"],["\u003cp\u003eSizing considerations include workload type, performance needs, expected data size, and workload scalability, with the primary metric for OLTP workloads being transactions per second (TPS).\u003c/p\u003e\n"],["\u003cp\u003eFor OLTP workloads, deployment can be primary-only or with a read pool, which is beneficial for latency-sensitive reads and can support multiple databases within the same instance, allowing for independent sizing of primary and read pool instances.\u003c/p\u003e\n"],["\u003cp\u003eFor OLAP workloads, the main sizing metric is query performance, with the columnar engine being crucial for accelerating analytical queries, and deployment options include primary-only for HTAP or primary with a read pool for heavy writes and analytical reads.\u003c/p\u003e\n"]]],[],null,["# Sizing and deployment recommendations\n\nThis document provides workload and deployment recommendations for sizing\nAlloyDB for PostgreSQL instances for both online transaction processing (OLTP)\nand online analytical processing (OLAP) workloads.\n\nOverview\n--------\n\nTo help you achieve better database performance, AlloyDB for PostgreSQL provides the following built-in features:\n\n- Automatic memory management\n- Adaptive autovacuum\n- Optimized built-in performance settings\n- Low replication lag\n- Non-disruptive maintenance with sub-second downtime for the primary and zero downtime for the read pool nodes during scale operations\n\nTuning your AlloyDB for PostgreSQL instance for performanceincludes managing the following::\n\n- Sizing your primary and read pool instances correctly\n- Updating flags that impact performance\n\nSizing considerations\n---------------------\n\nBefore you size your AlloyDB for PostgreSQL instance, determine the following:\n\n- **Workload type:** OLTP, OLAP, or HTAP\n- **Performance requirements:** latency and throughput requirements\n- **Expected data size:** the size of the data you plan to store in AlloyDB for PostgreSQL, and the active dataset size\n- **Scale of your workload:** an increase or growth in data size over time\n\nOLTP workloads\n--------------\n\nYou can deploy your AlloyDB for PostgreSQL database as a zonal instance (single node) or as a highly available instance (two nodes in each zone). Optionally, you can also add read pool instances and a secondary cluster in another region for geographically distributed workloads or for disaster recovery (DR).\n\nAlloyDB for PostgreSQL is deployed using cloud-scale, distributed architecture with\ndisaggregated compute and storage. Writes are acknowledged as soon as the write\nahead logs (WAL) files are persisted on the regional storage, while the\nblock materialization is offloaded to storage.\n\nSimilarly, with multi-tier cache architecture, data is automatically placed\nbetween buffer cache, ultra-fast cache, and the intelligent storage engine. Due\nto this multi-tier cache architecture used in AlloyDB for PostgreSQL, input and\noutput operations per second (IOPs) aren't relevant in the context of\nAlloyDB for PostgreSQL to compare with other database systems.\n\nHowever, using transactions per second\n(TPS)/transactions per minute (TPM) can provide a meaningful comparison to\nunderstand the amount of data that can be handled by AlloyDB for PostgreSQL.\n\nThe primary sizing metric is TPS. To estimate the required AlloyDB for PostgreSQL size,\nfollow these steps:\n\n1. **Identify your existing workload.** If you are migrating either from your self-managed PostgreSQL or from other commercial databases, then you may already have the TPS value for your existing workload.\n2. **Analyze your queries.** Identify the most critical queries in your workload and determine their performance requirements.\n3. **Use a tool such as `HammerDB` or `pgbench`.** These tools help to benchmark AlloyDB for PostgreSQL and determine if the machine size satisfies your TPS requirements.\n4. [**Use the AlloyDB for PostgreSQL OLTP Benchmarking Guide.**](https://services.google.com/fh/files/misc/alloydb_oltp_benchmarking_guide.pdf) This guide provides performance data forvarious AlloyDB for PostgreSQL configurations, to find a configuration that meets your TPS requirements.\n5. **Choose an appropriate AlloyDB for PostgreSQL size.** Consider your current data size and future growth expectations.\n\n### Machine size guidelines\n\nThe following example table shows recommendations for data with TPC-C benchmarking that has a\nread-write ratio of approximately 65% reads and 35% writes. When sizing an\nAlloyDB for PostgreSQL instance, you must aim to have a steady state CPU utilization of about\n60-70% to avoid operating system scheduling overhead. This allows some margin\nfor spikes in resource utilization by client applications.\n| **Note:** The sizing recommendations provided in the following table can be considered as general guidelines.\n\n### Deployment types\n\nBased on your workload, you can deploy AlloyDB for PostgreSQL as a primary instance only or\nprimary with read pool instance.\n\n#### Primary only\n\nChoose primary only deployment for the following workloads:\n\n- Write-heavy with low-medium reads\n- Read-heavy queries with light writes\n- Typical OLTP read-write.(60-70% reads, 30-40% writes).\n\nFor more information about machine types, see [General machine size\nguideline](#general-machine-size-guidelines).\n\n#### Primary with read pool instance\n\nIf you choose to deploy a primary with read pool instance, consider the\nfollowing:\n\n- If you have latency sensitive reads, then consider offloading your read queries to read pool instances. You can configure up to 20 nodes across all read pool instances. For more information, see [Create a read pool instance](/alloydb/docs/instance-read-pool-create).\n- Configure multiple read pool instances, if you have more than one database---for example, CRM or Finance in the same instance. Using this strategy helps with effective caching and query performance.\n- You can size your primary and read pool instances differently based on your requirements. For more information about best practices for read pool instances, see [Best practices for improving AlloyDB performance and availability](/alloydb/docs/best-practices-improve-performance-availability#add-read-pool-instances).\n- Add more than one node per read pool instance for high availability.\n- Enable columnar engine selectively in specific read pool instances for read query performance. This doesn't require enabling columnar engine on the primary instance.\n\nConsider using built-in features such as index advisor to help you add\nindexes that can improve query performance.\n\nOLAP workloads\n--------------\n\nFor OLAP workloads, the primary sizing metric is query performance, especially\nqueries that demand full table scans or aggregations. AlloyDB for PostgreSQL includes a\nbuilt-in [columnar engine](/alloydb/docs/columnar-engine/about) that helps in accelerating analytical queries. Enabling\nthe columnar engine by default consumes 30% of memory and automatically uses\nultra-fast cache data.\n\nFor more information about measuring OLAP performance with AlloyDB for PostgreSQL using TPC-H\nworkload, seethe [AlloyDB for PostgreSQL for PostgreSQL OLAP Benchmarking Guide](https://services.google.com/fh/files/misc/alloydb_olap_benchmarking_guide.pdf).\n\n### Deployment types\n\nBased on your workload, you can deploy AlloyDB for PostgreSQL as a primary instance only or\nprimary with read pool instance.\n\n#### Primary only\n\nIf you deploy a primary-only instance, consider the following:\n\n- Use this deployment for both transactions with analytical queries (HTAP).\n- Enable columnar engine to help with OLAP queries.\n- Consider deploying with 16 vCPU or larger machine that provides more memory to store columnar data.\n\n#### Primary with read pool\n\nIf you deploy a primary with read pool instance, consider the\nfollowing:\n\n- If you have heavy writes and also latency sensitive analytical reads with low lag requirements, then deploy the primary instance with HA enabled, and with read pool instances.\n- Enable columnar engine in read pool instances where you run your analytical queries.\n- Configure multiple read pool instances, if you have more than one database---for example, CRM or Finance in the same instance. Using this strategy helps with effective caching and query performance.\n- You can size your primary and read pool instances differently based on your requirements. For more information about best practices for read pool instances, see [Best practices for improving AlloyDB performance and availability](/alloydb/docs/best-practices-improve-performance-availability#add-read-pool-instances).\n- Add more than one node per read pool instance for high availability.\n- Enable columnar engine selectively in specific read pool instances for read query performance. This doesn't require enabling columnar engine on the primary instance.\n\nWhat's next\n-----------\n\n- [Learn about best practices for improving performance and availability](/alloydb/docs/best-practices-improve-performance-availability).\n- [AlloyDB for PostgreSQL for PostgreSQL OLTP Benchmarking Guide](https://services.google.com/fh/files/misc/alloydb_oltp_benchmarking_guide.pdf).\n- [AlloyDB for PostgreSQL for PostgreSQL OLAP Benchmarking Guide](https://services.google.com/fh/files/misc/alloydb_olap_benchmarking_guide.pdf)."]]
