Find XO: PostgreSQL이 느린 원인이 저장장치일 수 있다는 벤치마크 발표 정리 (clickhouse.com)

- 이 글은 PostgreSQL 데이터가 수백 GB에서 TB 규모로 커졌을 때 느려지는 원인이 저장장치에 있을 수 있다는 발표 내용을 정리한다. 발표자는 Sai Srirampur이며 ClickHouse 블로그에 실린 POSETTE 2026 발표 요약이다. - 원문 벤치마크는 33억 행 pgbench 워크로드를 gp3 EBS(3,000 IOPS 설정)와 로컬 NVMe 인스턴스 저장장치에서 각각 5분간 실행한 결과다. 중앙값 TPS는 NVMe 16,030, EBS 1,734로 보고됐다. - 원문에 따르면 EBS 쪽 트랜잭션 지연 37ms 중 페이지 읽기가 약 19ms, 커밋 시 WAL 동기화가 약 11ms였다. 이는 발표자의 벤치마크 측정값이며 해당 조건에서의 수치다. - 고가용성은 동기 복제 대기 서버 후보 두 대(ANY 1 구성)로, 백업은 WAL-G 같은 도구로 객체 스토리지에 따로 보관하는 구조가 발표에서 제안됐다.

발견한 곳

Hacker News ↗ / 추천 55 / 댓글 27 (2026년 10월 12일 17:54 확인)

비슷한 일을 겪어 본 적이 있나요? 그때 어떻게 했는지 한두 줄로 들려주세요. 제품을 잘 몰라도 괜찮습니다.

로그인하고 댓글 쓰기

댓글 1개

편집 의견startupxo 1시간 전

EBS 세션 64개 중 29개가 DataFileRead 대기에 걸려 있었다는 장면이 숫자보다 먼저 눈에 들어옵니다. 다만 원문이 이건 한 시점의 스냅샷이라고 직접 적어 두었으니, 평균처럼 읽기보다는 그 순간의 모습으로 받아들이는 편이 맞겠네요. 인스턴스 저장장치가 노드와 함께 사라지는 문제는 결국 복제와 백업을 어떻게 설계하느냐로 넘어가는데, 그 비용이 얼마나 늘어나는지는 원문에 나오지 않아서 직접 따져 보셔야 할 것 같아요. 비슷한 구성을 운영해 보신 분이라면 복제 쪽에서 어디가 가장 번거로웠는지 궁금합니다.

작성 언어: 한국어