PostgreSQL
The World's Most Advanced Open Source Relational Database
중년개발자
@loxo
#11 - EXPLAIN ANALYZE(큰 테이블이 작은 테이블을 만났을 때, DB는 어떻게 행동할까?)
실행 계획을 이해하는 감각 만들기 이제부터는 EXPLAIN ANALYZE를 왜 이렇게 나왔는지 납득하는 단계로 들어간다. 숫자와 용어를 외우는 게 아니라, 데이터 크기와 접근 방식의 이야기로 이해하면 훨씬 편하다. Seq Scan이 선택되는 진짜 이유 Seq Scan은 말 그대로 테이블을 처음부터 끝까지 읽는 방식이다. 많이들 이렇게 생각한다. Seq Scan = 인덱스를 못 써서 생긴 문제 하지만 PostgreSQL 입장에서는 전혀 다르다. PostgreSQL이 Seq Scan을 고르는 논리 DB는 항상 이렇게 계산한다. 인덱스를 타면 인덱스 페이지 읽고 테이블 페이지 다시 읽고 랜덤 I/O가 많이 발생 Seq Scan을 하면 테이블 페이지를 순서대로 쭉 읽음 디스크, 캐시 입장에서 매우 효율적 그래서: 전체 row 중 많은 비율을 읽어야 한다면 인덱스가 있어도 Seq Scan이 더 빠를 수 있다 실생활 비유 책에서 단어 하나 찾기: 단어가 2~3개만 필요 → 목차(인덱스) 사용
0
0
14
중년개발자
@loxo
#10 - EXPLAIN ANALYZE 제대로 읽기
PostgreSQL 성능 문제의 90%는 여기서 시작해서 여기서 끝난다 EXPLAIN ANALYZE는 처음 보면 외계어처럼 느껴지기 쉽다. 하지만 관점을 조금만 바꾸면, 이건 DB가 직접 써주는 성적표에 가깝다. 이 글에서는 "모든 숫자를 이해하려 하지 말고, 무엇을 먼저 봐야 하는지"에 집중한다. sql QUERY PLAN | -----------------------------------------------------------------------------------------------------------------------------------------------------------------+ Nested Loop (cost=0.42..14.33 rows=69 width=563) (actual time=0.087..0.198 rows=52 loops=1) | -> Index Only Scan using boards_pkey on boards b
0
0
15
중년개발자
@loxo
#9 - WSL PostgreSQL 17 Master-Replica 구축 가이드
WSL PostgreSQL 17 Master-Replica 구축 가이드 이 문서는 WSL 2 환경에서 Debian 배포판을 복제하여 PostgreSQL 17 Streaming Replication을 구축하는 전체 절차를 다룹니다. 📋 환경 및 전제 조건 Infrastructure: WSL 2 (Windows Subsystem for Linux) Base Image: Debian (기존에 설치된 배포판) Network: WSL은 모든 인스턴스가 127.0.0.1을 공유함. 따라서 포트로 구분. Master: Port 5432 / Tablespace: /var/lib/postgresql/ts_data Replica: Port 5433 / Tablespace: /var/lib/postgresql/ts_data 1단계: WSL 인스턴스 준비 (Export & Import) Windows PowerShell(관리자 권한)에서 실행합니다. 1.1 기존 배포판 내보내기 기존 Debian
0
0
22
중년개발자
@loxo
#8 - PgBouncer 실전 운영 챕터 - Spring Boot 읽기·쓰기 분리 전략
PgBouncer 실전 운영 챕터 Master / Replica 분리, DNS 설계, Spring Boot 읽기·쓰기 분리 전략 이 챕터의 전제 (중요) 이 문서는 PgBouncer 공식 문서의 동작 원리를 기반으로, PostgreSQL Master / Replica 구조 DNS 또는 엔드포인트 분리 PgBouncer databases 섹션 설계 Spring Boot 입장에서의 쓰기 / 읽기 분리 전략 을 실제 운영에서 가장 많이 쓰이는 방식으로 정리한 실전 가이드다. 목표는 "개념 설명"이 아니라 운영자가 그대로 가져다 쓸 수 있는 설정이다. PostgreSQL Master / Replica 구조 복습 PostgreSQL 자체는 Read / Write 분리를 자동으로 해주지 않는다. Write → 반드시 Master Read → Replica 여러 대로 분산 가능 따라서 분리는 반드시 애플리케이션 또는 미들웨어 계층에서 수행해야 한다. PgBouncer의 핵심 한계 (중요한 오해
0
0
22
중년개발자
@loxo
#7 - PgBouncer로 이해하는 대규모 PostgreSQL 커넥션 풀링
PgBouncer로 이해하는 대규모 PostgreSQL 커넥션 풀링 대규모 PostgreSQL 운영 사례 OpenAI는 PostgreSQL을 단일 Master + 약 50대 Replica(Read Only) 구조로 확장 운영하고 있는 것으로 공개적으로 알려져 있습니다. 이 구조의 핵심은 쓰기와 읽기의 분리, 그리고 연결(Connection) 관리의 효율화입니다. PostgreSQL은 구조적으로 클라이언트 연결 1개당 서버 백엔드 프로세스 1개를 생성합니다. 이는 안정성과 단순성 측면에서는 훌륭하지만, 대규모 트래픽 환경에서는 매우 비싼 비용 구조가 됩니다. 이 문제를 해결하기 위해 OpenAI를 포함한 대규모 서비스들은 PgBouncer 같은 외부 커넥션 풀러(Connection Pooler) 를 필수 인프라로 사용합니다. PostgreSQL 커넥션은 왜 비싼가? PostgreSQL은 Thread 기반이 아니라 Process 기반 구조 커넥션 1개 = OS 프로세스 1개 각
0
0
23
중년개발자
@loxo
#6 - PostgreSQL VACUUM (배큠) - ‘청소’이자 ‘건강검진’이다.
PostgreSQL VACUUM 가이드 🔊 발음: VACUUM = [배큠] / [배큐엄] (실무에서는 보통 배큠) VACUUM은 PostgreSQL에서 ‘청소’이자 ‘건강검진’이다. 언제 실행되는지, 안 하면 뭐가 문제인지, 운영자는 무엇만 챙기면 되는지 완전 초보 관점에서 설명한다. 1️⃣ VACUUM은 왜 필요한가? 지난 강의에서 CTID는 row의 물리적 주소이며, UPDATE 시 새로운 CTID로 이동한다는 것을 배웠다. 이 흐름의 연장선에서 이해해야 할 핵심이 바로 다음 문장이다. PostgreSQL은 UPDATE / DELETE 시 바로 지우지 않는다. UPDATE → 기존 row는 Dead Tuple DELETE → 바로 제거 ❌, 죽음 표시만 mermaid flowchart LR A[INSERT] --> B[Tuple] B -->|UPDATE/DELETE| C[Dead Tuple] C -->|VACUUM| D[Space Reused] 📌 핵심 VACUUM이 없으면
0
0
23
중년개발자
@loxo
#5 - PostgreSQL Heap Page(8KB)와 CTID - 이해가 쉬운 설명
PostgreSQL Heap Page(8KB)와 CTID PostgreSQL를 처음 배우면 CTID가 뭐지? 왜 페이지가 8KB야?에서 많이 막힙니다. 이 문서는 DB 내부 동작을 모른다는 전제에서, 눈으로 그려지듯 이해하도록 설명합니다. 1️⃣ PostgreSQL Heap이란? PostgreSQL에서 테이블은 곧 Heap입니다. Heap = 정렬되지 않은 데이터 덩어리 INSERT 순서대로 막 쌓임 인덱스가 없으면 전부 Heap Scan 📌 즉, PostgreSQL은 기본적으로 "책장 없이 바닥에 쌓아둔 종이더미" 같은 구조입니다. 2️⃣ 왜 Page 크기는 8KB일까? PostgreSQL의 기본 Page(Block) 크기: 8 KB (8192 bytes) 이유 요약 디스크 I/O 최소 단위 OS 메모리 페이지와 궁합이 좋음 너무 크면 낭비, 너무 작으면 I/O 폭증 👉 "가성비 최적" 사이즈 3️⃣ Heap Page 내부 구조 (핵심) 하나의 Heap Page(8KB)는
0
0
25
mstest404
@mstest404
test123
풀스택 개발자를 위한 DB-백엔드-프론트엔드 통합 기술 지식 제공, PostgreSQL, Spring Boot, Next.js 기반의 실전 연동 아키텍처 가이드, 백엔드 개발자의 성능 고민을 해결해 주는 SQL 및 서버 튜닝 노하우, 프론트엔드 엔지니어를 위한 데이터 효율적 호출 및 시각화 기술, "Deep Insight" 슬로건 기반의 심도 있는 풀스택 기술 아티클 제공, 입문자부터 전문가까지 단계별로
0
1
25
중년개발자
@loxo
#4 - PostgreSQL WAL · INSERT · SELECT · 디스크 관계 정리
PostgreSQL WAL · INSERT · SELECT · 디스크 관계 정리 이 문서는 PostgreSQL 내부에서 INSERT, SELECT, WAL, 디스크가 어떻게 상호작용하는지를 흐름 중심으로 정리한 자료다. PostgreSQL의 핵심 구성 요소 PostgreSQL에서 데이터 흐름을 이해하려면 아래 3가지를 반드시 구분해야 한다. 1️⃣ Shared Buffer (메모리) 실제 쿼리가 읽고 쓰는 대상 INSERT / UPDATE / DELETE / SELECT 모두 여기서 수행됨 디스크 데이터 파일의 캐시 역할 2️⃣ Data File (디스크) 테이블의 실제 물리 파일 즉시 쓰이지 않음 (비동기) Checkpoint 시점에 반영 3️⃣ WAL (Write-Ahead Log) "무슨 변경을 할지" 기록하는 로그 데이터 자체가 아닌 변경 내역 기록 복구, 복제, 안정성의 핵심 조회용으로 사용되지 않음 INSERT 한 번의 정확한 내부 흐름 아래 순서는 PostgreSQL의
0
0
31
중년개발자
@loxo
#3 - WSL에서 시작하는 실전 PostgreSQL 17 + Redis 개발환경 구축, 강의용 데이터 구축
Next.js, Spring Boot 강의에 필요한 데이터베이스 구축 및 샘플 데이터입니다. 중간중간 설치 시 에러가 있을 수 있습니다. 각자의 환경이 제각각이라서 그럴 땐 AI에게 질문하셔서 끝까지 설치 부탁드립니다. WSL 개발환경 구축 가이드 (Debian + PostgreSQL 17 + Redis) WSL 설치부터 PostgreSQL/Redis 구성, 소유자 계정과 애플리케이션 계정 분리, 파티션 설계, 대량 샘플 데이터까지 포함합니다. ⚠️ 이 문서는 그대로 따라 쳐도 오류 없이 완주*하도록 설계되었습니다. 전체 구조 요약 (먼저 읽기) 역할 분리 원칙 (중요) | 계정 | 역할 | | :--- | :--- | | postgres | DBMS 슈퍼유저 (설치/관리 전용) | | lecture\_own | DB/Schema/Table 소유자 | | lecture\_app | Spring Boot 등 애플리케이션 전용 계정 | Tablespace 분리 | 용도 |
0
0
30
중년개발자
@loxo
PostgreSQL 15 → 18 pg_dump 기반 마이그레이션 무사고 절차서
오늘 미루어 놓았던 PostgreSQL 15에서 18로 업그레이드를 했다. 그러면서 좌충우돌이 많았다. 늘 하는 작업이 아니라 문서로 정리하였다. PostgreSQL 15 → 18 pg_dump 기반 마이그레이션 무사고 절차서 (가상 DB 기준) 목표 pgdump / pgrestore 방식으로 PostgreSQL 15 → 18 업그레이드 tablespace 분리 구조 유지 role / 권한 / extension / 검색(pg_trgm·pgroonga)까지 완전 복구 실제 발생한 실수와 오류를 사전에 차단 전체 전략 요약 (중요) OS: Debian 12 (bookworm) 방식: pgupgrade ❌ / pgdump + pg_restore ✅ 이유: major version + extension(pgroonga) 구조 변경 tablespace 다수 사용 롤/권한/검색 구조를 명시적으로 재구성 필요 사전 점검 (절대 생략 금지) 1-1. 기존 PostgreSQL 15 상태 확인
0
0
32
중년개발자
@loxo
#2 - 실무적인 입장에서 대용량 처리 테이블 생성
이 문서는 postgresql.co.kr 프로젝트의 데이터베이스 스키마 설계 철학, 주요 개념, 그리고 성능 최적화 전략을 설명하는 교육 자료입니다. 이 스키마는 대규모 트래픽과 데이터를 효율적으로 처리하기 위해 설계되었습니다. 비록 시작은 작은 사이트이지만, 실제 처리는 대형 사이트보다 실무적인 테이블 설계를 하였습니다. 그렇다고 딱히 대단한 것도 아닌 것이, 어떻게 보면 다 똑같은 게시판입니다. 그러나 게시판도 어떻게 설계 방향을 가져가느냐에 따라, 대형 사이트 블로그처럼 큰 데이터를 다룰 수 있다고 생각합니다. 작은 설계는 결국 개인에게 도움되지 않습니다. 테이블 설계에 조금이나마 도움이 되었으면 합니다. 여기에서 나오는 용어를 알기만 해도 요즘은 AI가 해주는 시대이니 용어 개념이라도 얻어 가셨으면 합니다. 핵심 설계 개념 (Key Concepts) 1.1 UUIDv7 (Primary Key 전략) 전통적인 정수형 ID(Auto Increment) 대신 UUIDv7을 기본
0
0
37