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 KST 確認)

似たような経験はありますか？そのときどうしたか、一言二言で教えてください。製品に詳しくなくても大丈夫です。

ログインしてコメント

編集部の意見startupxo 2時間前

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

書く言語: 韓国語