📚 파티셔닝이 뭐길래?

파티셔닝은 쉽게 말해서 하나의 거대한 테이블을 여러 개의 작은 조각으로 나누는 기술이야. 마치 거대한 창고를 여러 개의 작은 창고로 나누는 것과 비슷해. 🏢

예를 들어볼게. 너가 온라인 쇼핑몰을 운영하는데, 주문 테이블에 5년치 데이터가 쌓여서 5억 건이 넘는다고 가정해보자. 이 상태에서 "지난달 주문 내역을 보여줘"라는 쿼리를 실행하면 어떻게 될까? 😱

PostgreSQL은 5억 건의 데이터를 모두 뒤져야 해. 인덱스가 있어도 인덱스 자체가 너무 커서 메모리에 올리기도 버거워. 결과적으로 쿼리 실행 시간이 길어지고, 디스크 I/O가 폭발하고, CPU는 과부하에 걸리지.

파티셀닝의 주요 장점들:

🔧 PostgreSQL 파티셔닝 종류

PostgreSQL은 크게 세 가지 파티셔닝 방식을 지원해. 각각의 특징과 사용 시나리오를 알아보자! 📖

1. Range Partitioning (범위 파티셔닝) 📅

가장 많이 사용되는 방식이야. 특정 컬럼의 값 범위에 따라 데이터를 나누는 거지. 날짜, 숫자 등 순서가 있는 데이터에 적합해.

실전 예제: 주문 테이블을 월별로 파티셔닝

-- 부모 테이블 생성
CREATE TABLE orders (
    order_id BIGSERIAL,
    customer_id INTEGER,
    order_date DATE NOT NULL,
    total_amount DECIMAL(10,2),
    status VARCHAR(20)
) PARTITION BY RANGE (order_date);

-- 2024년 1월 파티션
CREATE TABLE orders_2024_01 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

-- 2024년 2월 파티션
CREATE TABLE orders_2024_02 PARTITION OF orders
    FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

-- 2024년 3월 파티션
CREATE TABLE orders_2024_03 PARTITION OF orders
    FOR VALUES FROM ('2024-03-01') TO ('2024-04-01');

-- 기본 파티션 (범위에 속하지 않는 데이터용)
CREATE TABLE orders_default PARTITION OF orders DEFAULT;

2. List Partitioning (리스트 파티셔닝) 🗂️

특정 값의 목록에 따라 데이터를 나누는 방식이야. 카테고리, 지역, 상태 코드처럼 명확하게 구분되는 값들에 사용해.

-- 지역별 고객 테이블 파티셔닝
CREATE TABLE customers (
    customer_id BIGSERIAL,
    name VARCHAR(100),
    region VARCHAR(20) NOT NULL,
    email VARCHAR(100)
) PARTITION BY LIST (region);

-- 서울/경기 파티션
CREATE TABLE customers_seoul PARTITION OF customers
    FOR VALUES IN ('서울', '경기');

-- 부산/경남 파티션
CREATE TABLE customers_busan PARTITION OF customers
    FOR VALUES IN ('부산', '경남', '울산');

-- 기타 지역 파티션
CREATE TABLE customers_others PARTITION OF customers
    FOR VALUES IN ('강원', '충청', '전라', '제주');

3. Hash Partitioning (해시 파티셔닝) #️⃣

특정 컬럼의 해시 값을 기준으로 데이터를 균등하게 분산시키는 방식이야. 데이터를 고르게 나누고 싶을 때 사용해.

-- 사용자 테이블을 4개 파티션으로 해시 분산
CREATE TABLE users (
    user_id BIGSERIAL,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100),
    created_at TIMESTAMP
) PARTITION BY HASH (user_id);

-- 4개의 해시 파티션 생성
CREATE TABLE users_p0 PARTITION OF users
    FOR VALUES WITH (MODULUS 4, REMAINDER 0);

CREATE TABLE users_p1 PARTITION OF users
    FOR VALUES WITH (MODULUS 4, REMAINDER 1);

CREATE TABLE users_p2 PARTITION OF users
    FOR VALUES WITH (MODULUS 4, REMAINDER 2);

CREATE TABLE users_p3 PARTITION OF users
    FOR VALUES WITH (MODULUS 4, REMAINDER 3);

⚡ 파티셔닝 실전 구현 가이드

이론은 충분히 배웠으니, 이제 실제로 파티셔닝을 구현하는 방법을 단계별로 알아보자! 실무에서 바로 적용할 수 있는 내용들이야. 💼

Step 1: 기존 테이블 분석 🔍

파티셔닝을 적용하기 전에 먼저 테이블을 분석해야 해. 모든 테이블에 파티셔닝이 필요한 건 아니거든!

-- 테이블 크기 확인
SELECT 
    schemaname,
    tablename,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) AS size,
    pg_total_relation_size(schemaname||'.'||tablename) AS size_bytes
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY size_bytes DESC;

-- 테이블 행 수 확인
SELECT 
    schemaname,
    tablename,
    n_live_tup AS row_count
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;

-- 쿼리 패턴 분석 (자주 사용되는 WHERE 조건 확인)
SELECT 
    query,
    calls,
    total_exec_time,
    mean_exec_time
FROM pg_stat_statements
WHERE query LIKE '%your_table%'
ORDER BY calls DESC
LIMIT 20;

Step 2: 파티션 키 선택 🔑

파티션 키는 파티셔닝의 성패를 좌우하는 가장 중요한 요소야. 신중하게 선택해야 해!

Step 3: 기존 테이블을 파티션 테이블로 전환 🔄

이미 운영 중인 테이블을 파티셔닝하는 건 조심스러운 작업이야. 다운타임을 최소화하는 방법을 알아보자!

-- 방법 1: 새 파티션 테이블 생성 후 데이터 이관
-- 1단계: 파티션 테이블 생성
CREATE TABLE orders_new (
    order_id BIGSERIAL,
    customer_id INTEGER,
    order_date DATE NOT NULL,
    total_amount DECIMAL(10,2),
    status VARCHAR(20)
) PARTITION BY RANGE (order_date);

-- 2단계: 필요한 파티션들 생성
CREATE TABLE orders_new_2023_q1 PARTITION OF orders_new
    FOR VALUES FROM ('2023-01-01') TO ('2023-04-01');
    
CREATE TABLE orders_new_2023_q2 PARTITION OF orders_new
    FOR VALUES FROM ('2023-04-01') TO ('2023-07-01');
-- ... 나머지 파티션들

-- 3단계: 인덱스 생성
CREATE INDEX idx_orders_new_customer ON orders_new(customer_id);
CREATE INDEX idx_orders_new_date ON orders_new(order_date);

-- 4단계: 데이터 복사 (배치로 나눠서 실행)
INSERT INTO orders_new 
SELECT * FROM orders 
WHERE order_date >= '2023-01-01' AND order_date < '2023-04-01';

-- 5단계: 테이블 교체 (트랜잭션 내에서)
BEGIN;
ALTER TABLE orders RENAME TO orders_old;
ALTER TABLE orders_new RENAME TO orders;
COMMIT;

-- 6단계: 검증 후 기존 테이블 삭제
DROP TABLE orders_old;

Step 4: 파티션 자동 관리 설정 🤖

매번 수동으로 파티션을 만들 순 없잖아? 자동화가 답이야!

-- pg_partman 확장 설치 (파티션 자동 관리 도구)
CREATE EXTENSION pg_partman;

-- 파티션 자동 생성 함수
CREATE OR REPLACE FUNCTION create_monthly_partitions()
RETURNS void AS $$
DECLARE
    start_date DATE;
    end_date DATE;
    partition_name TEXT;
BEGIN
    -- 다음 달 파티션 생성
    start_date := date_trunc('month', CURRENT_DATE + interval '1 month');
    end_date := start_date + interval '1 month';
    partition_name := 'orders_' || to_char(start_date, 'YYYY_MM');
    
    -- 파티션이 없으면 생성
    IF NOT EXISTS (
        SELECT 1 FROM pg_tables 
        WHERE tablename = partition_name
    ) THEN
        EXECUTE format(
            'CREATE TABLE %I PARTITION OF orders FOR VALUES FROM (%L) TO (%L)',
            partition_name, start_date, end_date
        );
        
        RAISE NOTICE '파티션 생성됨: %', partition_name;
    END IF;
END;
$$ LANGUAGE plpgsql;

-- 크론잡으로 매월 1일에 자동 실행 (pg_cron 사용)
CREATE EXTENSION pg_cron;

SELECT cron.schedule(
    'create-monthly-partition',
    '0 0 1 * *',  -- 매월 1일 자정
    'SELECT create_monthly_partitions()'
);

🚀 파티셔닝과 함께 사용하는 성능 최적화 기법

파티셔닝만으로는 부족해! 다른 최적화 기법들과 함께 사용하면 시너지 효과가 엄청나거든. 실전에서 검증된 기법들을 소개할게! 🎯

1. 인덱스 전략 최적화 📊

파티션 테이블에서 인덱스는 더욱 중요해. 각 파티션마다 독립적인 인덱스가 생성되기 때문에 전략적으로 접근해야 해.

-- 파티션 테이블에 인덱스 생성 (모든 파티션에 자동 적용)
CREATE INDEX idx_orders_customer ON orders(customer_id);
CREATE INDEX idx_orders_status ON orders(status);

-- 복합 인덱스 (쿼리 패턴에 맞춰서)
CREATE INDEX idx_orders_date_status ON orders(order_date, status);

-- 부분 인덱스 (특정 조건의 데이터만)
CREATE INDEX idx_orders_pending ON orders(order_date) 
WHERE status = 'pending';

-- BRIN 인덱스 (시계열 데이터에 효과적)
CREATE INDEX idx_orders_date_brin ON orders USING BRIN(order_date);

-- 인덱스 사용 현황 확인
SELECT 
    schemaname,
    tablename,
    indexname,
    idx_scan,
    idx_tup_read,
    idx_tup_fetch
FROM pg_stat_user_indexes
WHERE tablename LIKE 'orders%'
ORDER BY idx_scan DESC;

2. VACUUM과 ANALYZE 최적화 🧹

PostgreSQL의 성능을 유지하려면 정기적인 유지보수가 필수야. 파티션 테이블은 각 파티션별로 관리할 수 있어서 더 효율적이지!

-- 자동 VACUUM 설정 조정
ALTER TABLE orders SET (
    autovacuum_vacuum_scale_factor = 0.05,  -- 5% 변경 시 VACUUM
    autovacuum_analyze_scale_factor = 0.02, -- 2% 변경 시 ANALYZE
    autovacuum_vacuum_cost_delay = 10       -- VACUUM 속도 조절
);

-- 특정 파티션만 수동 VACUUM
VACUUM ANALYZE orders_2024_01;

-- 전체 파티션 VACUUM (병렬 처리)
DO $$
DECLARE
    partition_name TEXT;
BEGIN
    FOR partition_name IN 
        SELECT tablename FROM pg_tables 
        WHERE tablename LIKE 'orders_2024%'
    LOOP
        EXECUTE 'VACUUM ANALYZE ' || partition_name;
        RAISE NOTICE 'VACUUM 완료: %', partition_name;
    END LOOP;
END $$;

-- VACUUM 진행 상황 모니터링
SELECT 
    pid,
    datname,
    query,
    state,
    wait_event_type,
    wait_event
FROM pg_stat_activity
WHERE query LIKE '%VACUUM%';

3. 쿼리 최적화 기법 ⚡

파티션 테이블에서 최고의 성능을 뽑아내려면 쿼리를 어떻게 작성하느냐가 중요해!

-- ❌ 나쁜 예: 파티션 키를 사용하지 않음
SELECT * FROM orders WHERE customer_id = 12345;
-- 모든 파티션을 스캔해야 함

-- ✅ 좋은 예: 파티션 키 포함
SELECT * FROM orders 
WHERE order_date >= '2024-01-01' 
  AND order_date < '2024-02-01'
  AND customer_id = 12345;
-- 2024년 1월 파티션만 스캔

-- 파티션 프루닝 확인
EXPLAIN (ANALYZE, BUFFERS) 
SELECT * FROM orders 
WHERE order_date = '2024-01-15';

-- 결과에서 "Partitions pruned: X" 확인

-- 집계 쿼리 최적화 (병렬 처리 활용)
SET max_parallel_workers_per_gather = 4;

SELECT 
    date_trunc('month', order_date) AS month,
    COUNT(*) AS order_count,
    SUM(total_amount) AS total_sales
FROM orders
WHERE order_date >= '2023-01-01'
GROUP BY 1
ORDER BY 1;

-- CTE를 활용한 복잡한 쿼리 최적화
WITH recent_orders AS (
    SELECT * FROM orders
    WHERE order_date >= CURRENT_DATE - INTERVAL '30 days'
      AND status = 'completed'
)
SELECT 
    customer_id,
    COUNT(*) AS order_count,
    AVG(total_amount) AS avg_amount
FROM recent_orders
GROUP BY customer_id
HAVING COUNT(*) >= 3;

4. 연결 풀링과 커넥션 관리 🔌

데이터베이스 성능은 쿼리만의 문제가 아니야. 연결 관리도 엄청 중요해!

-- PostgreSQL 연결 설정 최적화
-- postgresql.conf 파일 수정

max_connections = 200              # 동시 연결 수
shared_buffers = 4GB               # 공유 메모리 버퍼
effective_cache_size = 12GB        # OS 캐시 크기
work_mem = 50MB                    # 정렬/해시 작업 메모리
maintenance_work_mem = 1GB         # VACUUM, 인덱스 생성 메모리
random_page_cost = 1.1             # SSD 사용 시 낮춤
effective_io_concurrency = 200     # SSD 동시 I/O

-- 연결 풀링 (PgBouncer 설정 예시)
[databases]
mydb = host=localhost port=5432 dbname=mydb

[pgbouncer]
pool_mode = transaction            # 트랜잭션 단위 풀링
max_client_conn = 1000             # 클라이언트 최대 연결
default_pool_size = 25             # DB당 풀 크기
reserve_pool_size = 5              # 예비 연결
reserve_pool_timeout = 3           # 예비 연결 대기 시간

-- 연결 상태 모니터링
SELECT 
    datname,
    count(*) AS connections,
    count(*) FILTER (WHERE state = 'active') AS active,
    count(*) FILTER (WHERE state = 'idle') AS idle
FROM pg_stat_activity
GROUP BY datname;

5. 테이블스페이스 활용 💾

파티션별로 다른 디스크에 저장하면 I/O 성능을 극대화할 수 있어!

-- 빠른 SSD용 테이블스페이스
CREATE TABLESPACE fast_ssd 
LOCATION '/mnt/fast_ssd/postgresql';

-- 느린 HDD용 테이블스페이스 (아카이브용)
CREATE TABLESPACE slow_hdd 
LOCATION '/mnt/slow_hdd/postgresql';

-- 최근 파티션은 빠른 디스크에
CREATE TABLE orders_2024_01 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01')
    TABLESPACE fast_ssd;

-- 오래된 파티션은 느린 디스크로 이동
ALTER TABLE orders_2023_01 SET TABLESPACE slow_hdd;

-- 테이블스페이스 사용 현황
SELECT 
    spcname,
    pg_size_pretty(pg_tablespace_size(spcname)) AS size
FROM pg_tablespace;

📈 실전 성능 모니터링과 튜닝

파티셔닝을 적용했다고 끝이 아니야! 지속적인 모니터링과 튜닝이 필요해. 실전에서 사용하는 모니터링 기법들을 알아보자! 👀

1. 파티션 성능 모니터링 📊

-- 파티션별 크기 확인
SELECT 
    schemaname,
    tablename,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) AS total_size,
    pg_size_pretty(pg_relation_size(schemaname||'.'||tablename)) AS table_size,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename) - 
                   pg_relation_size(schemaname||'.'||tablename)) AS index_size
FROM pg_tables
WHERE tablename LIKE 'orders_%'
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC;

-- 파티션별 통계 정보
SELECT 
    schemaname,
    tablename,
    n_live_tup AS live_rows,
    n_dead_tup AS dead_rows,
    last_vacuum,
    last_autovacuum,
    last_analyze,
    last_autoanalyze
FROM pg_stat_user_tables
WHERE tablename LIKE 'orders_%'
ORDER BY tablename;

-- 파티션 프루닝 효과 측정
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT * FROM orders
WHERE order_date = '2024-01-15'
  AND status = 'completed';

-- 결과 분석:
-- Partitions pruned: X  <- 스캔하지 않은 파티션 수
-- Buffers: shared hit=Y  <- 캐시 히트율

2. 느린 쿼리 추적 🐌

-- postgresql.conf 설정
log_min_duration_statement = 1000  # 1초 이상 쿼리 로깅
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '
log_statement = 'all'              # 모든 SQL 로깅 (개발환경)

-- pg_stat_statements 확장 활성화
CREATE EXTENSION pg_stat_statements;

-- 가장 느린 쿼리 TOP 10
SELECT 
    query,
    calls,
    total_exec_time,
    mean_exec_time,
    max_exec_time,
    stddev_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

-- 특정 테이블 관련 쿼리 분석
SELECT 
    query,
    calls,
    total_exec_time / 1000 AS total_seconds,
    mean_exec_time AS avg_ms,
    100.0 * shared_blks_hit / NULLIF(shared_blks_hit + shared_blks_read, 0) AS cache_hit_ratio
FROM pg_stat_statements
WHERE query LIKE '%orders%'
ORDER BY total_exec_time DESC
LIMIT 20;

-- 통계 초기화 (필요시)
SELECT pg_stat_statements_reset();

3. 캐시 히트율 최적화 💾

-- 전체 캐시 히트율 확인
SELECT 
    sum(heap_blks_read) AS heap_read,
    sum(heap_blks_hit) AS heap_hit,
    sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS ratio
FROM pg_statio_user_tables;

-- 테이블별 캐시 히트율
SELECT 
    schemaname,
    tablename,
    heap_blks_read,
    heap_blks_hit,
    round(100.0 * heap_blks_hit / NULLIF(heap_blks_hit + heap_blks_read, 0), 2) AS cache_hit_ratio
FROM pg_statio_user_tables
WHERE tablename LIKE 'orders_%'
ORDER BY heap_blks_read DESC;

-- 인덱스 캐시 히트율
SELECT 
    schemaname,
    tablename,
    indexname,
    idx_blks_read,
    idx_blks_hit,
    round(100.0 * idx_blks_hit / NULLIF(idx_blks_hit + idx_blks_read, 0), 2) AS cache_hit_ratio
FROM pg_statio_user_indexes
WHERE tablename LIKE 'orders_%'
ORDER BY idx_blks_read DESC;

-- shared_buffers 사용 현황
SELECT 
    count(*) AS buffers,
    usagecount,
    isdirty
FROM pg_buffercache
GROUP BY usagecount, isdirty
ORDER BY usagecount, isdirty;

4. 실시간 성능 대시보드 구축 📊

모니터링 도구를 활용하면 훨씬 편하게 관리할 수 있어. 추천 도구들을 소개할게!

-- Prometheus용 PostgreSQL Exporter 메트릭 예시
-- 파티션별 크기 추적
SELECT 
    tablename,
    pg_total_relation_size(schemaname||'.'||tablename) AS size_bytes
FROM pg_tables
WHERE tablename LIKE 'orders_%';

-- 활성 연결 수
SELECT count(*) FROM pg_stat_activity WHERE state = 'active';

-- 트랜잭션 처리량
SELECT 
    xact_commit + xact_rollback AS total_transactions,
    xact_commit,
    xact_rollback
FROM pg_stat_database
WHERE datname = current_database();

🎓 실전 케이스 스터디

이론만으로는 부족하지! 실제 프로젝트에서 파티셔닝을 적용한 사례들을 살펴보자. 😊

케이스 1: 대용량 로그 시스템 📝

케이스 2: 글로벌 전자상거래 플랫폼 🛒

케이스 3: IoT 센서 데이터 플랫폼 🌡️

⚠️ 파티셔닝 시 주의사항과 함정

파티셔닝이 만능은 아니야. 잘못 사용하면 오히려 성능이 나빠질 수 있어. 주의해야 할 점들을 알아보자! 🚨

파티셔닝이 적합하지 않은 경우 🤔

🔮 PostgreSQL 파티셔닝의 미래

PostgreSQL의 파티셔닝 기능은 계속 발전하고 있어. 최신 버전들의 개선사항과 앞으로의 방향을 살펴보자! 🚀

PostgreSQL 버전별 파티셔닝 발전사 📚

앞으로 기대되는 기능들 🌟

💼 재능넷에서 DB 전문가 찾기

PostgreSQL 파티셔닝과 성능 최적화는 복잡한 작업이야. 혼자서 해결하기 어렵다면 전문가의 도움을 받는 것도 좋은 방법이지! 🤝

재능넷(https://www.jaenung.net)에서는 데이터베이스 전문가들이 다양한 서비스를 제공하고 있어:

• PostgreSQL 파티셔닝 설계 및 구현
• 데이터베이스 성능 진단 및 튜닝
• 쿼리 최적화 컨설팅
• 대용량 데이터 마이그레이션
• 모니터링 시스템 구축

실무 경험이 풍부한 전문가들이 당신의 프로젝트를 성공으로 이끌어줄 거야. 특히 처음 파티셔닝을 도입하는 경우, 전문가의 리뷰를 받으면 많은 시행착오를 줄일 수 있어! 😊

🎯 마무리하며

여기까지 PostgreSQL 파티셔닝과 성능 최적화에 대해 깊이 있게 알아봤어! 긴 글 읽느라 수고했어. 👏

핵심 내용을 다시 한번 정리해볼게:

파티셔닝은 강력한 도구지만, 은탄환(Silver Bullet)은 아니야. 당신의 시스템 특성과 요구사항을 정확히 파악하고, 적절한 시점에 적용하는 게 중요해. 🎯

처음에는 작은 규모로 시작해서 경험을 쌓고, 점진적으로 확대해나가는 걸 추천해. 그리고 항상 테스트 환경에서 충분히 검증한 후에 프로덕션에 적용하자!

데이터베이스 성능 최적화는 끝이 없는 여정이야. 하지만 이 글에서 배운 내용들을 잘 활용한다면, 당신의 PostgreSQL 데이터베이스는 훨씬 더 빠르고 안정적으로 운영될 거야! 💪

궁금한 점이 있거나 더 깊이 있는 도움이 필요하다면, 재능넷의 DB 전문가들을 찾아보는 것도 잊지 마! 함께 성장하는 개발자 커뮤니티에서 서로 도우며 발전해나가자! 🚀

행복한 코딩 되길 바라! Happy Querying! 😊✨