Postgres 느린 원인은 쿼리가 아니라 스토리지: 로컬 NVMe가 EBS보다 TPS 9배 이상
- 로컬 NVMe 클러스터가 중앙값 16,030 TPS를 기록해 EBS gp3의 1,734 TPS보다 9.24배 높음
- 중앙값 트랜잭션 지연 시간은 36.9ms에서 4.0ms로 줄고, 10GB 블로트 VACUUM은 964초 대신 366초에 끝남
- ingestion 지연, P95 읽기 지연, autovacuum 밀림, 체크포인트 경합, 논리 복제 지연이 공유 스토리지의 대역폭과 IOPS 경쟁에서 함께 생긴다고 설명함
- 로컬 NVMe는 I/O를 없애는 게 아니라 비용을 크게 줄여서 수십 마이크로초 단위 작업이 가능함
Hacker News opinions
제목 보니 LLM 냄새부터 나서 본문 읽기가 싫어짐. 관심 있는 주제여도 그냥 닫게 됨.
이런 제목 형식은 LLM 나오기 한참 전부터 발표나 블로그 제목에 흔했음.
솔직히 네트워크 스토리지는 HDD 시절에나 말이 됐음. IOPS랑 지연에서 10배 페널티 내면서 운영 유연성만 얻는 건 과함. 로컬 NVMe에 복제 잘 해두면 구조가 훨씬 단순해짐.
복제, 페일오버, 백업을 직접 챙겨야 하는 게 문제임. 복제된 블록 스토리지를 쓰면 그 부분을 밖으로 넘길 수 있음.
여러 DB가 스토리지를 같이 쓰는 비용 절감 목적이면 NAS/SAN이 여전히 말이 됨. 대부분 앱 DB는 SSD 한 장보다 훨씬 작음.
쿠버네티스에 붙이면 DB 인스턴스를 노드 사이로 옮기기 쉬움. 대신 성능 값을 치르는 거라 상황 따라 다름.
RDS를 r8g에서 r8gd로 옮겼는데 평균 I/O 지연이 1.0ms에서 0.1ms로 줄었음. 큰 쿼리에서 체감 차이가 큼.
스키마랑 쿼리가 문제인 경우가 훨씬 많음. 인덱스 설계 안 하고 DB를 블랙박스 덤프처럼 쓰는 사람들이 너무 많음.
프로덕션 통계가 바뀌면 로컬에서 예쁘던 실행 계획이 중첩 루프로 무너짐. 플랜 힌트가 없는 게 진짜 아픔임.
SQLite에 로컬 NVMe 조합이면 지연 시간 쪽은 사기 수준임. 게임 서버에서 월드마다 SQLite 파일 하나 쓰고 Litestream으로 WAL 스트리밍 중인데 ack 중앙값이 4-6ms임.