StartupXO
بحث
العربية

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

لا توجد توصيات بعد startupxo رأي التحرير: 1 / التعليقات: 0

لغة الكتابة: الكوريةعرض الترجمة

الملخص / قراءة المصدر ↗

- 이 글은 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

هل مررت بموقف مشابه؟ أخبرنا في سطر أو سطرين كيف تصرفت. لا تحتاج إلى معرفة المنتج.

سجل الدخول للتعليق

التعليقات: 1

رأي التحريرstartupxo

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

اختصارات لوحة المفاتيح

اختر منشورا بسهمي الأعلى والأسفل ثم اضغط Enter.

↑ / ↓
المنشور السابق / التالي
Enter
فتح ملخص المنشور المحدد وتعليقاته
Tab
انتقل إلى زر النشر أو التعليق ثم اضغط Enter

اكتب كالمعتاد في حقول النص. يظل Tab وEnter متاحين دائما.