김신건의 로그 - 위키 / database-internals

[DB] Transaction Isolation Levels: 완벽 가이드

koa (김신건) — Thu, 02 Jul 2026 00:00:00 GMT

정의

Transaction Isolation Level (트랜잭션 격리 수준) = 동시에 실행되는 여러 트랜잭션이 서로의 변경을 어디까지 볼 수 있는지 규정하는 수준. ACID 의 I.

격리를 완전히 없애면 최대 처리량, 완전히 직렬화하면 최상의 정합성. DB 는 이 사이 4단계 (ANSI SQL 표준) 를 제공한다. 더 강한 격리 = 더 많은 이상 현상 방지 = 더 낮은 동시성. 실무는 이 트레이드오프를 이해하고 상황에 맞게 고르는 문제다.

이 문서의 흐름

각 격리 수준을 낮은 것부터 하나씩 짚는다. 각 수준에서:

이 수준은 무엇을 보장하는가
하지만 여기서도 어떤 문제가 발생하는가 (애니메이션으로 시각화)
그 문제의 해결법과 대안 (다음 수준으로 올릴지, 다른 기법으로 우회할지)

격리 수준 매트릭스 (전체 지도)

먼저 어떤 이상 현상이 어느 수준에서 방지되는지 한눈에.

{}

이상 현상	READ UNCOMMITTED	READ COMMITTED	REPEATABLE READ	SERIALIZABLE
Dirty Read	발생	✓ 방지	✓ 방지	✓ 방지
Non-Repeatable Read	발생	발생	✓ 방지	✓ 방지
Phantom Read	발생	발생	△ 엔진별	✓ 방지
Lost Update	발생	발생	△ SI는 감지	✓ 방지
Write Skew	발생	발생	발생	✓ 방지

엔진별 차이가 매우 크다. 특히 REPEATABLE READ 는 같은 이름이라도 완전히 다른 것. 아래에서 자세히.

Level 1: READ UNCOMMITTED

이 수준의 정의

커밋되지 않은 값까지 다른 트랜잭션에 노출된다. 어떤 격리도 없다시피 하는 상태.

ANSI 4단계 중 가장 낮음
락을 거의 사용 안 함 → 최대 동시성
그러나 정합성은 최하

발생하는 문제: Dirty Read

트랜잭션 A 가 UPDATE 만 하고 아직 COMMIT 안 한 시점에 트랜잭션 B 가 그 값을 읽어 간다. A 가 ROLLBACK 하면 B 는 실존하지 않는 값 을 본 것.

{}

시나리오 (위 애니메이션):

-- 초기: balance = 500
-- T1
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
BEGIN;
UPDATE accounts SET balance = 1000 WHERE id = 1;
-- 아직 COMMIT 안 함

-- T2 (별도 세션)
BEGIN;
SELECT balance FROM accounts WHERE id = 1;
-- 결과: 1000  ← 미커밋 값 (dirty)!

-- T1
ROLLBACK;
-- balance 는 다시 500 이 됨. T2 가 봤던 1000 은 유령.

왜 문제인가:

T2 는 1000 을 보고 다음 판단 (송금 승인, 통계 계산 등) 을 내림
실제 커밋된 적 없는 값에 기반한 결정 → 데이터 일관성 파괴
ROLLBACK 이 잦다면 유령 데이터가 시스템 곳곳에 남음

해결법 / 대안

접근	방법	언제?
격리 올림	READ COMMITTED 이상 사용	대부분의 실무 (권장)
MVCC 엔진 채택	PostgreSQL, MySQL, Oracle 등	구조적으로 dirty read 가 불가능
read-only 명시	`SET TRANSACTION READ ONLY;`	대략적 통계, 리포트
replica 분리	Analytics 는 replica DB 로	최신성 덜 중요한 워크로드

[!IMPORTANT] PostgreSQL 은 READ UNCOMMITTED 를 지정해도 내부적으로 READ COMMITTED 로 승격. MVCC 특성상 dirty read 가 원천 불가능. 즉 PostgreSQL 에서 이 수준을 “쓰는” 것은 명목상만 의미 있음.

READ UNCOMMITTED 를 실제 쓰는 경우가 있나?

SQL Server 의 WITH (NOLOCK) hint 로 유사 효과. 대시보드 스냅샷 등에 종종 쓰이지만 공식적으로 지양.
Analytics/OLAP 워크로드는 대개 replica 로 분리하는 편이 낫다.
결국 거의 안 씀. 실무에서는 이 수준을 이해하되 실제 사용은 피한다.

Level 2: READ COMMITTED

이 수준의 정의

커밋된 값만 읽는다. Dirty Read 는 완전히 방지.

PostgreSQL, Oracle, SQL Server 의 기본값
MVCC 엔진에서는 문장 (statement) 마다 새 스냅샷을 잡음
락 사용 최소 → 높은 동시성

-- PostgreSQL 기본
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- 이 시점의 committed 값만 봄
COMMIT;

발생하는 문제: Non-Repeatable Read

같은 트랜잭션 안에서 같은 SELECT 를 두 번 실행했는데 결과가 다르다. 두 SELECT 사이에 다른 tx 가 UPDATE + COMMIT 하면 발생.

{}

시나리오 (위 애니메이션):

-- 초기: balance = 500
-- T1
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
SELECT balance FROM accounts WHERE id = 1;   -- 500

-- T2 (별도 세션): UPDATE + COMMIT 완료

-- T1 (계속)
SELECT balance FROM accounts WHERE id = 1;   -- 1000  ← 같은 tx인데 다름!
COMMIT;

왜 문제인가:

트랜잭션 안에서 계산에 쓴 값이 중간에 바뀜
예: 총액 = 첫 SELECT, 수수료 = 두번째 SELECT * 0.1 조합에서 총액과 수수료 비율이 불일치
리포트 생성 중 값이 흔들리면 통계가 왜곡됨

해결법 / 대안

접근	방법	트레이드오프
격리 올림	REPEATABLE READ 이상	같은 값 보장, 성능 약간 손해
명시적 락	`SELECT ... FOR UPDATE` (row lock)	정확, 대기 시간 발생
원자 연산	`UPDATE ... SET x = x - 100`	애초에 read-modify-write 안 함
애플리케이션 캐싱	첫 결과 저장, 재사용	코드 복잡, 지양

-- 옵션 1: REPEATABLE READ 로 올림
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- 옵션 2: FOR UPDATE 로 row 잠금
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
-- 이후 tx 끝까지 다른 tx의 UPDATE는 대기

-- 옵션 3: 원자 UPDATE 로 변경
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- read-modify-write 자체를 피함

[!TIP] 일반 CRUD 웹 서비스는 READ COMMITTED 로 충분. Non-Repeatable Read 가 실제 문제가 되는 상황은 리포트, 잔액 계산 등 같은 값을 여러 번 참조하는 로직. 그런 부분만 골라 REPEATABLE READ 나 FOR UPDATE 를 붙이는 편이 낫다.

Level 3: REPEATABLE READ

이 수준의 정의

같은 트랜잭션 안에서 같은 row 는 항상 같은 값. ANSI 정의로는 Non-Repeatable Read 만 방지하고 Phantom Read 는 허용. 하지만 실제 엔진마다 다르다.

MySQL InnoDB 의 기본값
PostgreSQL 은 명시적으로 지정 시 사용
MVCC 엔진에서는 트랜잭션 시작 시점의 스냅샷을 tx 끝까지 유지

엔진별 실제 구현:

엔진	구현 방식	Non-Rep	Phantom	Lost Update	Write Skew
MySQL InnoDB	2PL + next-key lock (범위 잠금)	✓	✓ 방지	✗	✗
PostgreSQL	Snapshot Isolation (MVCC)	✓	✓ 사실상 방지	△ 감지	✗
Oracle	미지원 (READ COMMITTED / SERIALIZABLE 만)	-	-	-	-
SQL Server	2PL	✓	✗	✗	✗

[!IMPORTANT] 같은 REPEATABLE READ 라도 엔진마다 완전히 다르다. MySQL RR 은 사실상 SERIALIZABLE 에 가까운 락 사용, PostgreSQL RR 은 Snapshot Isolation (락 없이 스냅샷). 이름 하나로 여러 개념을 뭉뚱그린 대표적 사례.

발생하는 문제: Phantom Read (ANSI 정의상)

같은 WHERE 조건을 두 번 실행했는데 row 개수가 다르다. UPDATE 가 아니라 INSERT/DELETE 가 원인.

{}

시나리오 (위 애니메이션):

-- 초기: orders 에 amount > 100 인 row 3개
-- T1
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT COUNT(*) FROM orders WHERE amount > 100;  -- 3

-- T2 (별도 세션)
BEGIN;
INSERT INTO orders (id, amount) VALUES (999, 200);
COMMIT;

-- T1 (계속)
SELECT COUNT(*) FROM orders WHERE amount > 100;
-- ANSI 정의상: 4 (phantom!)
-- MySQL InnoDB: 3 (next-key lock으로 방지)
-- PostgreSQL: 3 (snapshot으로 방지)
COMMIT;

왜 문제인가:

WHERE 범위에 해당하는 row 개수를 두 번 재는 로직에서 결과가 달라짐
예: 재고 검색 → 예약 처리 → 재확인 시 새 항목이 튀어나옴
리포트 통계, 배치 처리에서 count/sum 이 흔들림

해결법 / 대안

엔진	상황	조치
MySQL InnoDB	REPEATABLE READ (기본)	이미 방지됨 (next-key lock). 별도 조치 불필요
PostgreSQL	REPEATABLE READ (SI)	이미 방지됨 (snapshot). 스냅샷 시점 이후 insert 는 안 보임
Oracle / SQL Server (2PL)	REPEATABLE READ	SERIALIZABLE 로 올리거나 `SELECT ... FOR UPDATE` 로 범위 잠금
모든 엔진	안전 확실 필요	SERIALIZABLE 또는 predicate lock

MySQL 의 next-key lock 이란?

[gap lock][row lock][gap lock][row lock][gap lock]...

WHERE 조건에 매칭되는 인덱스 범위 전체에 lock. 새 row 가 그 범위에 INSERT 되지 못하게 막아 phantom 방지. 강력하지만 예상치 못한 deadlock 이 잦음.

PostgreSQL 의 SI 는?

트랜잭션 시작 시점의 스냅샷만 계속 봄. T2 가 나중에 INSERT + COMMIT 해도 T1 의 스냅샷에는 없으므로 count 가 그대로.

[!WARNING] PostgreSQL REPEATABLE READ 는 Snapshot Isolation 이지 진짜 Serializable 이 아니다. 아래 Write Skew 절에서 다룰 함정이 있다. 정합성이 극단적으로 중요하면 SERIALIZABLE 로 올려야 함.

Level 4: SERIALIZABLE

이 수준의 정의

개념적으로 트랜잭션이 하나씩 직렬 실행된 것과 같은 결과. 모든 이상 현상을 방지.

가장 강한 격리 수준
성능 대가 큼 (엔진마다 다름)
진짜 필요한 경우에만 (금융, 재고, 티켓팅 등)

엔진별 구현 방식:

엔진	구현	특징
PostgreSQL 9.1+	SSI (Serializable Snapshot Isolation)	성능 손해 적음, 충돌 시 abort → retry 필요
MySQL InnoDB	Strict 2PL (모든 SELECT 이 shared lock 획득)	대기 많음, deadlock 위험
SQL Server	2PL (SERIALIZABLE 힌트)	MySQL 유사
CockroachDB	SSI 변형	기본이 SERIALIZABLE

SERIALIZABLE 을 쓸 때 알아야 할 것

abort → retry 패턴 필수 (특히 PostgreSQL SSI):

import time
import psycopg2

for attempt in range(5):
    try:
        with conn.cursor() as cur:
            cur.execute("BEGIN ISOLATION LEVEL SERIALIZABLE")
            # ... 비즈니스 로직 ...
            cur.execute("COMMIT")
        break
    except psycopg2.errors.SerializationFailure:
        conn.rollback()
        time.sleep(0.01 * (2 ** attempt))  # 지수 backoff
        if attempt == 4:
            raise

왜 abort 가 필요한가: SSI 는 각 tx 가 자유롭게 진행하다가 커밋 직전에 충돌 감지. 감지되면 한쪽을 강제 abort (SQLSTATE 40001). 애플리케이션은 이를 잡아 재시도해야 함.

성능 트레이드오프

일반 워크로드에서 READ COMMITTED 대비:

PostgreSQL SSI: 약 10-20% 느림
2PL 기반 (MySQL, SQL Server): 최대 수 배 느림 (경합 심한 경우)

[!TIP] “무조건 SERIALIZABLE” 은 나쁜 선택. 대부분 상황은 READ COMMITTED + 필요한 로직에 SELECT FOR UPDATE 또는 원자 UPDATE 조합이 최적. SERIALIZABLE 은 진짜로 write skew 위험이 있는 로직 에만.

ANSI 표준을 벗어난 이상 현상들

ANSI SQL-92 표준의 4단계 매트릭스는 3가지 이상 현상만 정의했다. Berenson et al. (1995) 논문이 이 결함을 지적하며 2가지를 추가했다.

Lost Update (읽고 → 계산 → 쓰기 경쟁)

같은 데이터를 두 tx 가 read-modify-write 하는 사이, 한쪽의 UPDATE 가 사라진다.

{}

시나리오 (위 애니메이션):

-- 초기: count = 10
-- T1
BEGIN;
SELECT count FROM counters WHERE id = 1;   -- 10
-- 로컬 계산: 10 + 1 = 11
UPDATE counters SET count = 11 WHERE id = 1;
COMMIT;

-- T2 (T1과 병렬)
BEGIN;
SELECT count FROM counters WHERE id = 1;   -- 10 (T1 커밋 전에 SELECT)
-- 로컬 계산: 10 + 1 = 11
UPDATE counters SET count = 11 WHERE id = 1;   -- T1이 쓴 값 위에 덮어씀
COMMIT;

-- 결과: count = 11 (기대치는 12)

어느 수준에서 발생하는가: READ COMMITTED, REPEATABLE READ 모두 가능. PostgreSQL 의 SI (REPEATABLE READ) 는 first-writer-wins 로 감지해서 두번째 UPDATE 에서 에러를 냄. SERIALIZABLE 은 항상 방지.

해결법 (권장 순서):

-- ① 원자 UPDATE (가장 단순, 항상 우선)
UPDATE counters SET count = count + 1 WHERE id = 1;
-- 단일 UPDATE 문은 atomic. race condition 없음.

-- ② 낙관적 lock (version 컬럼)
UPDATE counters SET count = count + 1, version = version + 1
WHERE id = 1 AND version = <읽었을 때의 값>;
-- 0 row affected 면 race 발생 → 애플리케이션에서 재시도

-- ③ 비관적 lock (SELECT FOR UPDATE)
BEGIN;
SELECT count FROM counters WHERE id = 1 FOR UPDATE;  -- row 잠금
UPDATE counters SET count = count + 1 WHERE id = 1;
COMMIT;

-- ④ SERIALIZABLE 로 격리 올림
BEGIN ISOLATION LEVEL SERIALIZABLE;
-- 충돌 시 abort 재시도

-- ⑤ 별도 원자 저장소 (예: Redis INCR)

방법	언제?	단점
원자 UPDATE	단순 counter/누계, 사용 가능하면 항상	복잡 로직 못 표현
낙관적 lock	충돌 드물게	실패 시 재시도 로직
비관적 lock	충돌 잦음	대기 시간 ↑, deadlock 위험
SERIALIZABLE	정확성 우선	abort 재시도 필요
Redis 등 별도 저장소	극한 성능	이중 저장 복잡성

Write Skew (Snapshot Isolation 의 치명적 함정)

각자의 스냅샷 안에서는 조건이 참이지만, 두 tx 의 결과를 합치면 불변량이 깨진다.

Lost Update 와 다른 점: Lost Update 는 같은 row 를 두 tx 가 UPDATE 해서 하나가 사라짐. Write Skew 는 다른 row 를 각자 UPDATE 해서 first-writer-wins 감지가 안 됨.

{}

시나리오: 병원 온콜 스케줄 (위 애니메이션)

규칙: 최소 1명은 항상 on-call
현재 Alice, Bob 두 명이 on-call
둘 다 아파서 동시에 off-call 요청

-- 초기: on-call 2명 (alice, bob)
-- T1 (Alice의 세션)
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT COUNT(*) FROM doctors WHERE on_call = true;  -- 2, 조건 OK
UPDATE doctors SET on_call = false WHERE id = 'alice';
COMMIT;   -- 성공

-- T2 (Bob의 세션, T1과 동시)
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT COUNT(*) FROM doctors WHERE on_call = true;  -- 2 (자기 스냅샷), 조건 OK
UPDATE doctors SET on_call = false WHERE id = 'bob';
COMMIT;   -- 성공 (T1이 alice 를 건드렸을 뿐 bob 은 안 건드렸으므로)

SELECT COUNT(*) FROM doctors WHERE on_call = true;  -- 0 !! 규칙 위반

왜 SI 가 못 막나: 두 tx 가 다른 row 를 UPDATE 했으므로 write-write 충돌이 없음. SI 의 first-writer-wins 는 같은 row 에 대해서만 감지. 각자의 스냅샷 안에서는 count(on_call) >= 1 조건이 참이었지만, 실제로는 결합되어 위반됨.

해결법:

-- ① SERIALIZABLE (PostgreSQL SSI는 이를 자동 감지)
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT COUNT(*) FROM doctors WHERE on_call = true;
UPDATE doctors SET on_call = false WHERE id = 'alice';
COMMIT;
-- 동시 T2 시도 시 ERROR: could not serialize access due to read/write dependencies
-- → 애플리케이션은 재시도

-- ② SELECT ... FOR UPDATE 로 predicate 잠금
BEGIN;
SELECT COUNT(*) FROM doctors WHERE on_call = true FOR UPDATE;
-- 이제 다른 tx는 on_call=true 인 row 를 UPDATE 할 수 없음
UPDATE doctors SET on_call = false WHERE id = 'alice';
COMMIT;

-- ③ materializing the conflict (강제 write-write 충돌 만들기)
CREATE TABLE on_call_lock (locked BOOLEAN);
INSERT INTO on_call_lock VALUES (true);

BEGIN;
UPDATE on_call_lock SET locked = true;  -- 모든 tx가 이 row 를 UPDATE → 충돌 감지 가능
SELECT COUNT(*) FROM doctors WHERE on_call = true;
UPDATE doctors SET on_call = false WHERE id = 'alice';
COMMIT;

[!IMPORTANT] Write Skew 는 ANSI 표준에 없다. Berenson et al. 이 SI 의 함정을 지적하며 도입한 개념. PostgreSQL SSI (9.1+) 가 이를 자동 감지하는 유일한 격리 수준. MySQL SERIALIZABLE 은 strict 2PL 로 결과적으로 방지하지만 방법이 다름.

PostgreSQL SSI (Serializable Snapshot Isolation)

PostgreSQL 9.1 부터 도입된 SSI 는 Snapshot Isolation 위에 predicate lock 추적을 얹어 진정한 serializability 를 달성한다.

flowchart TD
    T1[T1 시작 스냅샷] --> Read1[T1 SELECT / UPDATE]
    T2[T2 시작 스냅샷] --> Read2[T2 SELECT / UPDATE]
    Read1 --> Track[predicate + row 접근 기록]
    Read2 --> Track
    Track --> Commit{둘 commit 시도}
    Commit --> Cycle{의존성 순환 감지?}
    Cycle -->|예| Abort[한쪽 abort<br/>SQLSTATE 40001]
    Cycle -->|아니오| OK[둘 다 commit]
    Abort --> Retry[애플리케이션 재시도]

핵심 아이디어:

각 tx 는 자기 스냅샷 위에서 자유롭게 실행 (락 최소)
백그라운드에서 predicate lock 추적 (T1 이 이 범위를 읽었다, T2 는 이 row 를 썼다)
커밋 시점에 rw-dependency 순환 있으면 한쪽 abort
애플리케이션은 40001 잡아서 재시도

장점: throughput 손해 적음 (2PL 대비 큰 차이), 정확성 완벽. 단점: 재시도 코드 필수. false positive 가능하지만 정확성에는 영향 없음.

MVCC 기반 스냅샷 격리의 원리

각 트랜잭션은 시작 시점의 스냅샷 을 잡고, 그 시점 이후의 변경은 자기에게 보이지 않는다.

PostgreSQL 은 각 row (tuple) 에 hidden column xmin, xmax 를 저장:

row 1: (id=1, name='Alice', xmin=100, xmax=0)
        → T200 이 UPDATE
row 1: (id=1, name='Alice', xmin=100, xmax=200)  ← 옛 버전
row 1: (id=1, name='Bob',   xmin=200, xmax=0)    ← 새 버전

트랜잭션 T150 은:

xmin ≤ 150 이고 (xmax = 0 or xmax > 150) 인 tuple 만 봄
즉, “내 스냅샷 시점에 살아 있던” 버전만 봄

자세한 구현은 [[mvcc]] 참조.

실무 가이드

언제 어느 수준을?

시나리오	권장 수준	이유
일반 CRUD, 짧은 tx	READ COMMITTED	성능 좋음, dirty read 만 방지
배치 리포트 (일관 스냅샷)	REPEATABLE READ	같은 값 여러 번 사용
잔액 계산, 재고 확인	REPEATABLE READ + FOR UPDATE	phantom 안전
금융 거래, 티켓 발권	SERIALIZABLE	write skew 방지
Analytics (최신성 덜 중요)	READ COMMITTED READ ONLY	최대 동시성

격리 수준 명시 방법

-- 세션 전체
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- 트랜잭션 하나만
BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- ...
COMMIT;

-- PostgreSQL: 시작과 동시에
BEGIN ISOLATION LEVEL SERIALIZABLE;

-- 프로그램 레벨 (JDBC 예시)
connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);

프레임워크 예시

# Django
from django.db import transaction
from django.db import connection

@transaction.atomic
def transfer(from_id, to_id, amount):
    with connection.cursor() as cursor:
        cursor.execute("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE")
    # ... 로직 ...

// Spring
@Transactional(isolation = Isolation.SERIALIZABLE)
public void transfer(Long from, Long to, BigDecimal amount) { ... }

자세한 프레임워크별 사용은 [[django-transactions]], [[spring-transaction]] 참조.

실제 DB 엔진 매핑

엔진	기본 격리	SERIALIZABLE 구현	특징
PostgreSQL	READ COMMITTED	SSI (Serializable Snapshot Isolation)	RR = Snapshot Isolation
MySQL InnoDB	REPEATABLE READ	Strict 2PL	RR 에서 next-key lock 으로 phantom 방지
Oracle	READ COMMITTED	SI 유사 (완전 SS 아님)	RR 미지원
SQL Server	READ COMMITTED	2PL	RCSI 옵션 (MVCC), Snapshot 옵션 별개
CockroachDB	SERIALIZABLE	SSI 변형	기본이 SS
MongoDB	(트랜잭션은 SS)	SI	단일 문서는 원자적
DynamoDB	(item 원자성)	TransactWriteItems (SSI 유사)	트랜잭션 API 사용 시
Cassandra	(트랜잭션 미지원)	LWT (Lightweight Transactions)	Paxos 기반 우회

흔한 함정

[!WARNING]

“REPEATABLE READ 라니 안전하겠지” = MySQL 과 PostgreSQL 의 RR 은 완전히 다른 것. Write Skew 는 어느 쪽에서도 발생.

SERIALIZABLE 만 박고 abort 처리 없음 = 부하 시 40001 폭증하여 요청 실패. 재시도 코드 필수.

READ COMMITTED 로 잔액 계산 = tx 안에서도 잔액이 바뀔 수 있음. 은행 앱에서 문제.

MySQL RR + gap lock deadlock = 의도치 않은 범위 잠금으로 데드락 폭증. SHOW ENGINE INNODB STATUS\G 로 진단.

낙관적 lock 없이 read-modify-write = 트래픽 증가 시 lost update 폭증.

SELECT FOR UPDATE 를 잔뜩 걸음 = 대기 시간 폭증 + deadlock. 필요한 최소 범위만.

긴 트랜잭션 (long-running tx) = VACUUM 방해, snapshot 유지 비용, lock 대기 폭증. 5분 넘으면 검토.

격리 수준을 애플리케이션 코드에서 매번 바꿈 = 세션 풀에서 오염 (다음 요청이 이전 설정 상속). 명시적 리셋 필요.

Anti-Pattern: Lock 으로 모든 것 해결 시도

-- ✗ 나쁜 예: 모든 SELECT 에 FOR UPDATE
SELECT * FROM users FOR UPDATE;
SELECT * FROM orders FOR UPDATE;
SELECT * FROM products FOR UPDATE;
-- → deadlock 폭증, 대기 시간 ↑

개선:

필요한 곳만 SELECT … FOR UPDATE (충돌 실제 발생하는 row 만)
순서 일관성 (항상 users → orders → products 순으로 lock)
SSI 로 전환 (retry 로 처리)
원자 UPDATE 가능하면 그것으로

N+1 쿼리 문제

koa (김신건) — Thu, 02 Jul 2026 00:00:00 GMT

정의

N+1 쿼리 문제 = ORM 이 부모 entity N 개를 조회한 뒤, 각 부모의 연관 entity 를 하나씩 로드하면서 추가 SQL 이 N 번 발생하는 성능 안티패턴.

이름의 의미:

1: 부모 목록 SELECT (1번)
N: 각 부모마다 연관 SELECT (N번)
총 N+1 쿼리

SQL 한 번에 끝낼 작업을 부모 개수만큼 반복 발생시키므로, 데이터가 커질수록 응답시간이 선형이 아니라 쿼리 왕복 (round-trip) 만큼 폭발한다.

ORM (Hibernate/JPA, Active Record, Django ORM, Sequelize, TypeORM 등) 공통 문제. 원인은 대부분 lazy loading + 반복문의 조합.

시각화

{}

lazy loading + 반복문이 만드는 N+1 → JOIN 으로 1쿼리에 해결.

왜 발생하나

전형적 시나리오:

// 1. Post 목록 조회 (SQL 1번)
List<Post> posts = postRepository.findAll();

// 2. 반복문에서 author 접근 (SQL N번)
for (Post p : posts) {
    System.out.println(p.getAuthor().getName());   // 매번 lazy proxy 초기화 → SELECT
}

발생 SQL:

posts 100 개면 SQL 101 번. p.getAuthor() 를 호출하는 순간 ORM 이 lazy proxy 를 초기화하려고 개별 SELECT 를 날리기 때문.

눈에 안 보이는 위치에서도 발생

템플릿 렌더링: Thymeleaf, JSP 에서 ${post.author.name} 순회
Jackson 직렬화: @JsonManagedReference 순회 시 lazy 컬렉션 접근
toString() / equals() / hashCode(): 연관 필드 사용하면 함정
로깅: log.info("posts: {}", posts) 도 컬렉션 전체 순회

성능 영향 (실제 수치 감각)

DB 왕복 지연 (round-trip time, RTT):

로컬 DB: 0.1 ~ 1 ms
같은 리전 클라우드: 1 ~ 5 ms
다른 리전: 20 ~ 100 ms

Post 100 건 조회 + 각 author lazy load 라면:

환경	JOIN 1쿼리	N+1 (101쿼리)	차이
로컬 DB (1ms RTT)	~10 ms	~110 ms	11 배
같은 리전 (3ms RTT)	~15 ms	~350 ms	23 배
다른 리전 (50ms RTT)	~80 ms	~5,100 ms	63 배

트래픽이 낮은 개발 환경에서는 문제가 안 보이지만 운영에서 QPS 가 오르면 즉시 스레드 풀 고갈 / DB connection 고갈로 연결된다.

응답시간뿐 아니라 DB 부하도 문제. 100 배 늘어난 쿼리 수는 커넥션 풀 대기, 락 경합, statement cache 압박을 동반한다.

감지 방법

1. SQL 로깅

가장 기본. 개발 / 스테이징에서 SQL 로그 켜고 순회 로직 실행:

# Spring / JPA
spring:
  jpa:
    show-sql: true
    properties:
      hibernate:
        format_sql: true
logging.level.org.hibernate.SQL: DEBUG

# Rails
ActiveRecord::Base.logger = Logger.new(STDOUT)

# Django
LOGGING = {
    "loggers": {"django.db.backends": {"level": "DEBUG", "handlers": ["console"]}}
}

같은 쿼리 패턴이 다른 파라미터로 반복되면 N+1 신호.

2. 자동 감지 도구

프레임워크	도구
JPA / Hibernate	Hypersistence Utils `assertSelectCount()`
Rails	`bullet` gem: 개발 환경 자동 알림 + CI 실패
Rails 6.1+	`strict_loading: true` 옵션
Django	`django-debug-toolbar` SQL 패널 + `django-silk`
Prisma	`prisma-query-count` 유틸
TypeORM	`logger: 'advanced-console'` + 수동 추적

3. 통합 테스트에서 쿼리 수 assert

가장 견고한 방법. 쿼리 수를 명시적으로 검증한다.

// Spring 예시 (Hypersistence Utils)
@Test
void findAllWithAuthor_uses_single_query() {
    var assertion = SQLStatementCountValidator.reset();
    postService.getAllPostsWithAuthor();
    SQLStatementCountValidator.assertSelectCount(1);
}

# Rails / RSpec (with rspec-sqlimit)
it "no N+1" do
  expect { get "/posts" }.to make_database_queries(count: 2)
end

# Django
def test_list_no_n_plus_one(self):
    with self.assertNumQueries(2):
        response = self.client.get("/posts/")

리팩터링 시 N+1 재발을 막는 안전망.

해결 전략 3가지

전략 1: JOIN (한 쿼리에 다 가져오기)

부모와 자식을 한 번의 SQL JOIN 으로 조회. 왕복이 1번.

SELECT p.*, a.*
FROM post p
INNER JOIN user a ON p.author_id = a.id;

JPA: [[spring-jpa-fetch-join|JOIN FETCH]] 또는 @EntityGraph
Rails: eager_load(:author) 또는 includes(:author).references(:author)
Django: select_related("author")

장점: 1쿼리 단점:

컬렉션 (ToMany) 이면 카르테시안 곱 → row 곱해짐
큰 결과에서 JOIN 자체가 무거움
Pageable 과 컬렉션 조합 시 문제 (JPA 는 in-memory paging 경고)

전략 2: IN 절 배치 조회 (부모 + 자식 2쿼리)

부모 먼저 조회, 자식은 WHERE parent_id IN (...) 로 한 번에.

-- 1
SELECT * FROM post;
-- 2
SELECT * FROM comment WHERE post_id IN (1, 2, 3, ..., 50);

JPA: @BatchSize, default_batch_fetch_size, @EntityGraph (fetch join 아닌 subselect)
Rails: preload(:comments) (항상 IN 방식) 또는 includes(:comments) (조건 없으면 자동 IN)
Django: prefetch_related("comments")

장점:

카르테시안 곱 없음
페이징과 잘 어울림
컬렉션 다수 처리 가능

단점: 2쿼리 (그래도 N+1 대비 극적 개선)

전략 3: 캐시 / counter 컬럼

자주 접근하는 count → 부모에 컬럼으로 저장 (Rails counter_cache, Hibernate @Formula)
자주 접근하는 값 → 캐시 계층 (Redis, application cache)
정말 자주 반복 조회 → CQRS / read model 분리

관계 로딩 자체를 제거하는 접근.

프레임워크별 해결

JPA / Hibernate

// 1. fetch join
@Query("SELECT p FROM Post p JOIN FETCH p.author")
List<Post> findAllWithAuthor();

// 2. @EntityGraph
@EntityGraph(attributePaths = {"author"})
List<Post> findAll();

// 3. @BatchSize (Hibernate 확장)
@Entity
class Post {
    @OneToMany(mappedBy = "post", fetch = LAZY)
    @BatchSize(size = 100)
    List<Comment> comments;
}

기본은 LAZY 로 매핑 + 쿼리마다 필요한 것만 명시. 자세히는 [[spring-jpa-fetch-type]] 과 [[spring-jpa-fetch-join]] 참고.

Rails / Active Record

# 1. includes (자동 선택: preload 또는 eager_load)
Post.includes(:author)

# 2. preload (항상 IN 절)
Post.preload(:author)

# 3. eager_load (항상 LEFT OUTER JOIN)
Post.eager_load(:author)

# 4. strict_loading (Rails 6.1+): 의도 안 한 lazy 차단
class Post < ApplicationRecord
  has_many :comments, strict_loading: true
end

자세히는 [[rails-query-optimization]] 참고. 개발 환경에는 bullet gem 필수.

Django

# 1. select_related (FK, OneToOne → JOIN)
Post.objects.select_related("author")

# 2. prefetch_related (ToMany → IN 절)
Post.objects.prefetch_related("comments")

# 3. Prefetch: 세밀 제어
from django.db.models import Prefetch
Post.objects.prefetch_related(
    Prefetch(
        "comments",
        queryset=Comment.objects.filter(approved=True).select_related("author"),
    )
)

자세히는 [[django-orm-advanced]] 참고.

Node.js ORM (참고)

// Sequelize
Post.findAll({ include: [{ model: User, as: 'author' }] });

// TypeORM
postRepository.find({ relations: ['author'] });

// Prisma
prisma.post.findMany({ include: { author: true } });

세 라이브러리 모두 include 지정이 필수. Prisma 는 아예 lazy 개념이 없어 명시 없으면 관계가 로드되지 않는다 (다른 종류의 안전 장치).

프레임워크 공통 함정

함정 1: `has_many :through` / 컬렉션 N+1

부모 → 중간 테이블 → 손자 조회 시 두 레벨 N+1 이 동시에 발생.

# Rails: post → tags 를 통해 → categories
posts.each { |p| p.tags.each { |t| t.category } }

해결: 깊은 nested includes(tags: :category) 또는 단계별 preload.

함정 2: 직렬화에서 노출

컨트롤러에서는 fetch 명시했지만 serializer / view 에서 다른 관계를 추가로 접근하는 경우.

// PostDto
public String getAuthorProfileImage() {
    return post.getAuthor().getProfile().getImageUrl();
    //                       ^^^^^^^^^ 여기서 lazy proxy 초기화!
}

해결: DTO 로 미리 projection 하거나 fetch 시점에 모든 필요한 필드 포함.

함정 3: 자체 관계 (self-referencing)

트리 구조에서 재귀적으로 부모/자식 접근하면 depth 만큼 N+1 배가.

def get_ancestry(comment):
    return [comment] + get_ancestry(comment.parent) if comment.parent else [comment]
    # 각 재귀마다 SELECT

해결: recursive CTE (Postgres WITH RECURSIVE), materialized path, closure table 같은 트리 저장 패턴.

함정 4: 조건부 접근

if (post.getFeatured() && post.getComments().size() > 5) { ... }
//                        ^^^^^^^^^^^^^^^^^^^^^^^^^ featured 아닌 것도 있으면 안 걸리지만 걸리면 lazy 초기화

해결: 조건 검사에 필요한 값도 미리 fetch 하거나 SIZE() 를 SQL 수준에서 계산.

함정 5: Kotlin data class / Java record 의 자동 참조

@JsonAutoDetect, Lombok @ToString(includeAllFields=true) 등이 lazy 필드를 자동으로 건드릴 수 있음.

해결: @ToString(exclude = {"comments"}), @JsonIgnore 로 명시적 제외.

예방 도구 (환경별)

시나리오	도구 / 설정
JPA 개발 환경	SQL 로깅 + `hibernate.session.events.log.LOG_QUERIES_SLOWER_THAN_MS`
JPA 테스트	Hypersistence Utils `assertSelectCount()`
JPA 운영	p6spy, datasource-proxy, APM (Datadog / New Relic)
Rails 개발	`bullet` gem, `strict_loading`
Rails 테스트	`rspec-sqlimit`, `make_database_queries` matcher
Django 개발	`django-debug-toolbar`, `django-silk`
Django 테스트	`assertNumQueries`
프레임워크 무관	pg_stat_statements (Postgres), slow query log (MySQL), APM 트레이스

왜 ORM 이 이런 함정을 만드나

ORM 의 핵심 가치는 객체 그래프처럼 데이터를 다루는 편의성. post.author.name 이 자연스럽게 SQL 로 바뀌면 좋겠지만, 그러려면 미리 어떤 관계가 필요할지 알아야 한다.

두 극단:

모든 관계를 eager 로 미리 로드: 매 쿼리마다 불필요한 대량 데이터 (JPA 의 FetchType.EAGER 함정)
lazy 로만 두고 접근 시점에 초기화: N+1

해답은 옵트인 eager. 기본 lazy, 필요한 곳에서 명시적으로 fetch 선언. 모든 성숙한 ORM 이 이 방향으로 수렴한다 (JPA 는 @ManyToOne 기본이 EAGER 라 예외, 잘못된 기본값).

함정과 베스트 프랙티스

연관 매핑은 기본 LAZY (JPA 는 @ManyToOne 도 명시적으로 LAZY 지정)
쿼리 시점에 필요한 관계만 명시적으로 fetch (JOIN FETCH, includes, select_related)
JOIN vs IN 배치 상황별 선택: ToOne 은 JOIN, ToMany 는 IN 배치 우선
컬렉션 여러 개 fetch 는 위험: 하나만 JOIN + 나머지는 IN 배치
직렬화 / view 에서 관계 접근하지 마세요: DTO 로 미리 projection
자동 감지 도구 항상 켜기: 개발에 bullet / debug-toolbar, 테스트에 assertNumQueries
자주 접근하는 count 는 counter 컬럼: 관계 로딩 자체를 회피
트랜잭션 밖에서 관계 접근 금지: LazyInitializationException 함정
APM 트레이스로 운영 관찰: SQL 로그로는 안 보이는 hot path 발견
QueryDSL / Criteria API 로 fetch 위치 명시: JPQL 이 익숙하지 않은 팀에서

[DB Internals] B-Tree 내부: split, merge, search 알고리즘

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

B-Tree (Bayer & McCreight, 1972) = 디스크 I/O 최적화된 balanced multi-way search tree. 모든 leaf 깊이 동일 + 노드당 큰 fan-out.

기존 개요는 [[btree-indexing]] 참고. 본 페이지는 내부 알고리즘 에 집중.

왜 B-Tree?

flowchart TB
    Q{"인덱스 자료구조"}
    Q -->|"BST"| BST["Binary Search Tree<br/>깊이 log N, disk I/O 큼"]
    Q -->|"Red-Black"| RB["균형이지만 여전히 log₂ N<br/>메모리 자료구조"]
    Q -->|"B-Tree"| BT["log_m N 깊이 (m=fan-out)<br/>disk I/O 최소"]
    BST --> BAD["N=10^9 → 30 depth = 30 disk read"]
    BT --> GOOD["N=10^9 + m=100 → 5 depth = 5 disk read"]

핵심: 한 노드 = 한 disk page (8-16KB). Fan-out 이 크면 깊이가 얕음 → I/O 최소.

정의 (Knuth)

Order m 인 B-Tree 는:

모든 leaf 는 같은 깊이.
각 노드 (root 제외) 는 ⌈m/2⌉-1 ~ m-1 keys.
Root 는 1 ~ m-1 keys.
각 internal node 는 k+1 children (k = keys).
노드 내 keys 정렬됨.

구조 (Order 4 예)

flowchart TB
    Root["[30 | 60]"]
    Root --> A["[10 | 20]"]
    Root --> B["[40 | 50]"]
    Root --> C["[70 | 80 | 90]"]
    A --> LA1["[5]"]
    A --> LA2["[15]"]
    A --> LA3["[25]"]
    B --> LB1["[35]"]
    B --> LB2["[45]"]
    B --> LB3["[55]"]
    C --> LC1["[65]"]
    C --> LC2["[75]"]
    C --> LC3["[85]"]
    C --> LC4["[95]"]

Search: O(log_m N)

search(root, key):
  node = root
  while node is not null:
    i = 0
    while i < node.n and key > node.keys[i]:
      i++
    if i < node.n and key == node.keys[i]:
      return node.values[i]   # HIT
    if node.is_leaf:
      return null              # MISS
    node = node.children[i]

각 노드에서 binary search (또는 linear if 노드 작음).

Insertion + Split

새 key 삽입 → leaf full 이면 split:

flowchart TB
    Before["[10 | 20 | 30 | 40] (full, m=4)"]
    Before --> Insert["Insert 25"]
    Insert --> Split
    subgraph Split["Split"]
        Mid["25 up to parent"]
        Left["[10 | 20]"]
        Right["[30 | 40]"]
    end

insert(node, key):
  if node.is_leaf:
    insert_in_order(node.keys, key)
    if node.n > m-1:
      split(node)
  else:
    child = find_child(node, key)
    insert(child, key)

Split (leaf full)

sequenceDiagram
    autonumber
    Note over Leaf: [10, 20, 30, 40, 50] (5 keys, m=4)
    Leaf->>Leaf: median = 30
    Leaf->>NewLeft: [10, 20]
    Leaf->>NewRight: [40, 50]
    Leaf->>Parent: push 30 up
    Parent->>Parent: 30 삽입
    alt parent full
        Parent->>Parent: recursive split
    end

중간값을 parent 로 push. Root split 시 tree 깊이 +1.

Deletion + Merge

Key 삭제 → leaf 가 minimum (⌈m/2⌉-1) 미만 → sibling 에서 빌리거나 merge:

flowchart TD
    Q{"Leaf underflow"}
    Q -->|"sibling 이 여유 있음"| Borrow["Rotate: sibling 에서 key 이동"]
    Q -->|"sibling 도 minimum"| Merge["Merge with sibling + parent key 내림"]
    Merge -->|"parent underflow"| Recurse["Recursive underflow up"]

delete(node, key):
  if node.is_leaf:
    node.keys.remove(key)
    if node.n < ⌈m/2⌉ - 1:
      rebalance(node)
  else:
    # Internal: 후속자 (in-order successor) 로 교체 후 삭제
    successor = min_of_right_subtree(node, key)
    node.replace(key, successor)
    delete(right_child, successor)

Rotation (borrow from sibling)

flowchart LR
    Before["parent[30]<br/>left[10,20] right[40,50,60]"]
    Before -->|"underflow left"| Rot
    Rot["parent[40]<br/>left[10,20,30] right[50,60]"]

Merge

flowchart LR
    Before["parent[30]<br/>left[10] right[40] (둘 다 min)"]
    Before -->|"merge"| After["parent[]<br/>merged[10,30,40]"]
    After -->|"parent underflow"| Cascade["Cascade up"]

Height 분석

N keys, fan-out m
Height h:
  minimum: m^h - 1 keys
  → h = log_m(N)

N = 10^9, m = 100 → h ≈ 4.5 = 최대 5 disk read

Cache-friendly 구현

flowchart LR
    Node["Node (8KB page)"] --> Header["Header (n, is_leaf)"]
    Node --> Keys["Keys array (정렬)"]
    Node --> Children["Children pointers 또는 values"]
    Note["Binary search on keys array<br/>모두 sequential memory access"]

페이지 내부 = 배열 + binary search. Cache miss 최소.

동시성 (Concurrency)

flowchart TB
    Q["Multi-writer"]
    Q --> Lock1["Latch coupling / Crabbing"]
    Q --> Lock2["Optimistic latch coupling (OLC)"]
    Q --> Lock3["Bw-Tree (lock-free)"]
    Q --> Lock4["Blink-tree"]

기법	의미
Latch coupling	Parent lock 잡고 child lock, parent 해제. Deadlock 없음
Optimistic (OLC)	Version 기반, 낙관적. 실패 시 재시도
Bw-Tree (Microsoft)	Lock-free, delta record + consolidation
Blink-tree	Right-link pointer, split 중 lookup 가능

PostgreSQL 특화

기법	의미
Nbtree	PG 의 B-Tree (nbtree.c)
HOT (Heap Only Tuple)	인덱스 update 안 하는 tuple 최적화
Duplicate deduplication (PG 13+)	중복 key 압축 저장
Bottom-up index deletion (PG 14+)	HOT 실패 시 인덱스 정리

흔한 함정

[!WARNING]

Random insert 순서 = split 폭증. Sequential insert (auto-increment) 가 최적.

UUID v4 primary key + B-Tree = random → 페이지 분할 극심. ULID / UUID v7 (정렬 가능) 권장.

Bloat = MVCC 로 dead tuple 누적. REINDEX CONCURRENTLY 정기.

Fan-out 계산 = column 폭 큰 index = 노드당 key 수 적음 = 트리 깊음. 포함할 컬럼 최소.

[DB Internals] B+ Tree 내부: leaf linked list, range scan

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

B+ Tree = B-Tree 의 변형. 모든 데이터가 leaf 에만, internal node 는 navigation key만. Leaf 들이 linked list 로 연결.

[!IMPORTANT] 현대 RDB 의 표준 인덱스. PostgreSQL, MySQL InnoDB, Oracle, SQL Server 모두 B+ Tree 기반.

B-Tree vs B+ Tree

flowchart TB
    subgraph BT["B-Tree (internal 도 데이터 저장)"]
        BT_R["Root: 30(data) | 60(data)"]
        BT_L1["Leaf: 10(d)|20(d)|25(d)"]
        BT_L2["Leaf: 40(d)|50(d)"]
        BT_R --> BT_L1
        BT_R --> BT_L2
    end
    subgraph BP["B+ Tree (internal 은 key 만)"]
        BP_R["Root: 30 | 60 (navigation)"]
        BP_L1["Leaf: 10,20,25 (data)"]
        BP_L2["Leaf: 40,50 (data)"]
        BP_L3["Leaf: 70,80,90 (data)"]
        BP_R --> BP_L1
        BP_R --> BP_L2
        BP_R --> BP_L3
        BP_L1 -.next.-> BP_L2
        BP_L2 -.next.-> BP_L3
    end

	B-Tree	B+ Tree
Internal 에 데이터	예	아니오 (key 만)
Leaf 연결 (linked list)	아니오	예
Range scan	각 노드 순회	linked list scan (빠름!)
Fan-out	작음 (data 도 저장)	큼 (navigation key 만)
트리 깊이	깊음	얕음
Point lookup	early exit 가능	항상 leaf 까지
공간 효율	나쁨 (중복)	좋음

Range Scan 의 우월성

SELECT * FROM orders WHERE created_at BETWEEN '2026-06-01' AND '2026-06-30';

sequenceDiagram
    autonumber
    Q->>Root: search '2026-06-01'
    Root->>Internal: navigate
    Internal->>Leaf1: found start
    loop leaf linked list traversal
        Leaf1-->>Q: return rows
        Leaf1->>Leaf2: next pointer
        Leaf2-->>Q: return rows
        Leaf2->>Leaf3: next pointer
        Leaf3-->>Q: return rows until > '2026-06-30'
    end

Leaf 만 순회 → disk sequential I/O. B-Tree 는 매번 root 부터 다시 시작해야 함.

Clustered Index (InnoDB)

MySQL InnoDB 는 Primary Key 의 B+ Tree leaf 가 실제 row 데이터:

flowchart TB
    Root["Root: navigation keys"]
    Root --> L1["Leaf 1: full row data (PK=1..100)"]
    Root --> L2["Leaf 2: full row data (PK=101..200)"]
    Root --> L3["Leaf 3: full row data (PK=201..300)"]
    L1 -.next.-> L2
    L2 -.next.-> L3
    Note["Secondary index → PK 값 저장 → 다시 클러스터 인덱스 조회"]

vs PostgreSQL 은 heap 별도, 인덱스는 heap tuple ID 만. 자세한 건 [[mysql-innodb]], [[postgresql]].

Leaf Linked List

Leaf 1: [10, 20, 25] → Leaf 2: [40, 50] → Leaf 3: [70, 80, 90] → null

각 leaf 페이지 header:

- prev_leaf pointer
- next_leaf pointer
- n_keys
- keys[] + values[] (or row data)

[!TIP] Reverse range scan 도 O(k). prev_leaf 로 역방향 순회.

Fan-out 계산 (실전)

InnoDB 페이지 = 16KB:

Internal node fan-out:
  key (bigint 8B) + pointer (6B) = 14B
  16KB / 14B ≈ 1170 children

Height 계산:
  N = 10^9, fan-out = 1170
  h = ceil(log_1170(10^9)) ≈ 3
  → 3 disk read 로 도달!

Split 알고리즘 (B+ Tree)

flowchart TB
    Before["Leaf: [10, 20, 30, 40, 50, 60] (full)"]
    Before --> Split
    subgraph Split["Split (median=30)"]
        L["New left: [10, 20, 30]"]
        R["New right: [40, 50, 60]"]
    end
    Split --> Parent["Parent 에 40 push (30이 아님!)"]
    Parent -->|"prev/next 갱신"| Linked["Linked list 유지"]

B+ Tree 는 중간 key 를 복사 해서 parent 에 push (B-Tree 는 이동). Leaf 에도 유지되어야 range scan 가능.

Sequential Insert 의 함정

PK = auto-increment (1, 2, 3, ...) 만 삽입
→ 항상 *마지막 leaf* 에만 삽입
→ 마지막 leaf 만 자꾸 split
→ tree 오른쪽으로 편향 성장

InnoDB 는 change buffer 로 완화. 다른 DB 는 bulk load 시 자동 balance.

Random Insert 의 함정

UUID v4 primary key:

UUID_v4 = random
→ 매 insert 마다 *다른 leaf 페이지*
→ Cache miss + 페이지 분할 폭증
→ 쓰기 성능 5-10배 저하

해결:

Auto-increment BIGINT (관계형 정통)
ULID / UUID v7 (시간 순 정렬 가능)
InnoDB: innodb_autoinc_lock_mode 조정

Reverse Scan + ORDER BY DESC

SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;

B+ Tree 의 leaf prev pointer 로 마지막에서 역행.
MySQL InnoDB 는 자동 지원.
PostgreSQL 은 reverse index 옵션 (CREATE INDEX ... DESC).

Concurrency: Latch Coupling

sequenceDiagram
    autonumber
    T->>Root: 잠금
    Root-->>T: children
    T->>Child: 잠금
    T->>Root: 잠금 해제
    T->>Grandchild: 잠금
    T->>Child: 잠금 해제
    Note over T,Grandchild: 항상 위→아래 순서 → deadlock free

InnoDB, PG 모두 latch coupling 기본. 자세한 건 [[b-tree-internals]].

Bulk Loading

COPY orders FROM '...' -- 대량 로드

B+ Tree 를 bottom-up 으로 구축 (sort + fill):

데이터 정렬 (외부 정렬).
Leaf 페이지 sequential fill (fillfactor 90%).
Internal 페이지 bottom-up 생성.

일반 insert 보다 수배 빠름.

Fillfactor

CREATE INDEX idx_orders ON orders(id) WITH (fillfactor = 90);

90% = 페이지의 10% 여유. Insert 시 분할 지연.
100% = 쓰기 성능 저하 + 잦은 분할.
Read-only 인덱스는 100% (공간 절약).

흔한 함정

[!WARNING]

UUID v4 PK = 성능 킬러. UUID v7 / ULID / BIGINT.

Fillfactor 100 = 쓰기 많은 테이블에서 분할 폭증.

Descending index 안 만듦 = 자주 ORDER BY x DESC 하면 성능 손해.

Multi-column index 순서 잘못 = 가장 선택도 높은 컬럼을 앞으로.

[DB Internals] CHAR / VARCHAR / TEXT / JSONB: 문자열 타입 비교

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

문자열 저장 타입 4가지 비교. 성능 + 저장 + 유연성 트레이드오프.

4가지 비교 (PostgreSQL)

타입	최대 길이	저장 방식	뒤 공백	사용
`CHAR(N)`	N (고정)	padding	붙임	옛 표준, 거의 안 씀
`VARCHAR(N)`	N	실제 크기	유지	옛 습관, 대부분 상황
`TEXT`	무제한	실제 크기	유지	PG 권장
`JSONB`	무제한 (내부 1GB)	binary + toast	-	구조화된 문서

PostgreSQL 의 특별한 진실

PostgreSQL: CHAR, VARCHAR, TEXT 는 *성능 동일*
→ 모두 내부적으로 *varlena* (variable-length array) 로 저장
→ length 검증 오버헤드만 다름

[!IMPORTANT] PostgreSQL 에서는 거의 항상 TEXT 사용. VARCHAR(N) 은 길이 제약 필요 할 때만. CHAR(N) 은 사실상 legacy.

저장 크기 비교

'hello' (5 chars)
  CHAR(20)   → 20 bytes (padding + length header)
  VARCHAR(20) → 5 + 1 header = 6 bytes
  VARCHAR    → 5 + 1 header = 6 bytes (제약 없음)
  TEXT       → 5 + 1 header = 6 bytes
  JSONB      → 파싱된 binary + headers ≈ 20+ bytes

MySQL 의 차이

MySQL 은 진짜 다르다:

	CHAR(N)	VARCHAR(N)
저장	N bytes 고정	실제 크기 + 1-2 byte header
뒤 공백	저장 X (`TRIM` 자동)	저장 O
성능	약간 빠름 (고정)	약간 느림
사용	고정 길이 (해시, 코드)	대부분

-- MySQL 만의 팁
country_code CHAR(2)      -- 항상 2자리
sha256_hex   CHAR(64)     -- 항상 64자
description  VARCHAR(1000) -- 가변
big_text     TEXT          -- BLOB 영역

InnoDB 의 TEXT 특별함

flowchart LR
    Row["InnoDB row (16KB page)"] --> Small["작은 VARCHAR/TEXT → row 안 저장"]
    Row --> Large["큰 TEXT/BLOB → 별도 page (overflow)"]
    Row --> Ptr["Row 에는 pointer 만"]

768 bytes 이내 → row 내 저장
초과 → 별도 페이지 + pointer
결과: TEXT 자주 안 쓰는 컬럼 은 성능 손실 없음

PostgreSQL TOAST

flowchart LR
    Row["PG row (8KB page)"] --> Check{"> 2KB?"}
    Check -->|아니오| Inline["Inline 저장"]
    Check -->|예| Comp["1. 압축 (LZ4/pglz)"]
    Comp -->|여전히 큼| Toast["2. TOAST table 별도 저장"]
    Toast --> Ptr["Row 에는 pointer"]

The Oversized-Attribute Storage Technique. PostgreSQL 자동 처리.

JSONB 의 특별함

CREATE TABLE events (
  id BIGSERIAL PRIMARY KEY,
  event_type TEXT,
  payload JSONB
);

vs TEXT 로 JSON 저장:

	TEXT (JSON)	JSONB
저장	원본 텍스트	binary parsed
인덱싱	어려움	GIN 가능
Query	`->` 매번 parse	빠름
Key 순서	보존	손실
Insert 속도	빠름	느림 (parse)
Read 속도	느림	빠름

자세한 JSONB 는 [[postgresql-jsonb]].

성능 벤치마크 (직관)

언제 무엇을?

flowchart TD
    Q{데이터 형태}
    Q -->|"고정 길이 코드 (ISO, hash)"| MC["MySQL: CHAR(N)<br/>PG: TEXT + CHECK 제약"]
    Q -->|"제한된 가변 (이메일, name)"| MV["MySQL: VARCHAR(N)<br/>PG: TEXT + CHECK"]
    Q -->|"긴 본문 (article, log)"| T["TEXT (PG/MySQL)"]
    Q -->|"schemaless 문서"| J["JSONB"]
    Q -->|"binary (image, encrypted)"| B["BYTEA (PG) / BLOB (MySQL)"]

PostgreSQL 권장 pattern

-- ✓ 권장
CREATE TABLE users (
  id         BIGSERIAL PRIMARY KEY,
  email      TEXT NOT NULL UNIQUE CHECK (length(email) <= 320),
  name       TEXT NOT NULL CHECK (length(name) BETWEEN 1 AND 100),
  country    TEXT NOT NULL CHECK (length(country) = 2 AND country ~ '^[A-Z]{2}$'),
  bio        TEXT,
  preferences JSONB NOT NULL DEFAULT '{}'
);

-- ✗ 옛 습관
CREATE TABLE users (
  email      VARCHAR(320),
  name       VARCHAR(100),
  country    CHAR(2),
  bio        VARCHAR(2000),
  preferences JSONB
);

MySQL 권장 pattern

CREATE TABLE users (
  id         BIGINT PRIMARY KEY AUTO_INCREMENT,
  email      VARCHAR(320) NOT NULL UNIQUE,
  name       VARCHAR(100) NOT NULL,
  country    CHAR(2) NOT NULL,
  bio        TEXT,
  preferences JSON  -- MySQL 8.0+
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

인덱싱 제약

-- PostgreSQL: 인덱스 key 최대 2704 bytes (BTree)
CREATE INDEX ON users(email);   -- ✓
CREATE INDEX ON users(bio);      -- 큰 bio 에러

-- 부분 인덱스 (prefix)
CREATE INDEX ON users((left(bio, 100)));

-- MySQL: 인덱스 prefix length 명시
CREATE INDEX idx_bio ON users(bio(255));   -- 앞 255 chars 만

Collation (정렬 규칙)

-- PostgreSQL
CREATE TABLE t (
  name TEXT COLLATE "ko-KR-x-icu"
);

-- MySQL
name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_ko_0900_as_cs

Collation	의미
`utf8mb4_bin`	binary (정확 매칭)
`utf8mb4_0900_ai_ci`	대소문자/악센트 무시
`ko_KR.UTF-8`	한국어 정렬

흔한 함정

[!WARNING]

PG 에서 VARCHAR(N) 성능 이유로 사용 = 같은 성능. TEXT + CHECK 로.

MySQL 에서 모든 곳에 TEXT = row 밖 저장 → 성능 손실. VARCHAR 우선.

CHAR 의 뒤 공백 사고 = WHERE name = 'koa' vs 'koa ' → 결과 다름.

UTF-8 3-byte vs 4-byte = MySQL 옛 utf8 은 3-byte (이모지 저장 안 됨). utf8mb4 필수.

[DB Internals] GIN Index 깊이: 구조, jsonb_path_ops, tsvector

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

GIN (Generalized Inverted Index) = 한 값이 여러 항목 을 가지는 데이터 (배열, JSON, tsvector) 의 역색인. PostgreSQL 의 강력한 확장점.

일반 인덱스 비교는 [[gin-gist-hash-indexes]] 참고. 본 페이지는 내부 구조 에 집중.

왜 GIN?

flowchart LR
    B["B-Tree: 한 row = 한 key"]
    B --> B1["ex: name = 'kim'"]
    G["GIN: 한 row = 여러 key"]
    G --> G1["ex: tags = ['ruby', 'rails', 'redis']"]
    G --> G2["ex: payload = { 'user_id': 42, 'tags': ['a', 'b'] }"]
    G --> G3["ex: to_tsvector('rabbit hat magic')"]

구조

flowchart TB
    Root["Entry B-Tree<br/>(term/element)"]
    Root --> E1["'ruby' → posting list"]
    Root --> E2["'rails' → posting list"]
    Root --> E3["'redis' → posting list"]
    E1 --> P1["Posting list: [doc1, doc3, doc7, ...]"]
    P1 -->|"크면"| PT["Posting Tree<br/>(B-Tree of doc IDs)"]

구성	의미
Entry Tree	모든 term 의 B-Tree
Posting List	Term → doc ID 목록 (작을 때 배열)
Posting Tree	Term 의 doc 이 많을 때 B-Tree

예시 (배열 컬럼)

CREATE TABLE posts (
  id BIGSERIAL PRIMARY KEY,
  tags TEXT[]
);

INSERT INTO posts (tags) VALUES
  ('{"ruby","rails","redis"}'),   -- id=1
  ('{"rails","postgres"}'),        -- id=2
  ('{"ruby","postgres","json"}');  -- id=3

CREATE INDEX idx_tags ON posts USING gin(tags);

내부:

Entry B-Tree:
  'json'     → [3]
  'postgres' → [2, 3]
  'rails'    → [1, 2]
  'redis'    → [1]
  'ruby'     → [1, 3]

Query: tags @> ARRAY['ruby', 'postgres']
  → 'ruby' posting: [1, 3]
  → 'postgres' posting: [2, 3]
  → 교집합: [3]

연산자

연산자	의미	예
`@>` (contains)	왼쪽이 오른쪽 포함	`tags @> ARRAY['ruby']`
`<@` (contained by)	왼쪽이 오른쪽에 포함	`tags <@ ARRAY['ruby','rails','redis']`
`&&` (overlap)	하나라도 공통	`tags && ARRAY['ruby','python']`
`?` (key exists)	JSON key 존재	`payload ? 'user_id'`
`?	` (any key)	여러 key 중 하나
`?&` (all keys)	모든 key 존재	`payload ?& array['a','b']`

jsonb_ops vs jsonb_path_ops

-- 1. jsonb_ops (기본): 모든 key 와 value 인덱싱
CREATE INDEX idx_payload_full ON events USING gin(payload);

-- 2. jsonb_path_ops: @> 만 인덱싱 (더 작음, 더 빠름)
CREATE INDEX idx_payload_path ON events USING gin(payload jsonb_path_ops);

	jsonb_ops	jsonb_path_ops
인덱스 크기	큼	~1/3
지원 연산자	`@>`, `?`, `?	`,` ?&`,` @?`,` @@`
Insert 속도	느림	빠름
Query 속도	보통	빠름 (@>)

[!IMPORTANT] 대부분 @> 만 쓴다 → jsonb_path_ops 권장. 크기 1/3, 속도 3x.

Full-Text Search (tsvector)

CREATE TABLE articles (
  id BIGSERIAL PRIMARY KEY,
  body TEXT,
  body_tsv TSVECTOR GENERATED ALWAYS AS (to_tsvector('english', body)) STORED
);

CREATE INDEX idx_body_tsv ON articles USING gin(body_tsv);

-- 검색
SELECT * FROM articles
WHERE body_tsv @@ to_tsquery('english', 'rabbit & hat');

-- 랭킹
SELECT *, ts_rank(body_tsv, query) AS rank
FROM articles, to_tsquery('english', 'rabbit') query
WHERE body_tsv @@ query
ORDER BY rank DESC;

pg_trgm (LIKE 최적화)

CREATE EXTENSION pg_trgm;

CREATE INDEX idx_name_trgm ON users
USING gin(name gin_trgm_ops);

-- Prefix / suffix / substring 모두 인덱스 활용!
SELECT * FROM users WHERE name LIKE '%kim%';
SELECT * FROM users WHERE name ILIKE 'kim%';
SELECT * FROM users WHERE name % 'kim';   -- 유사도

pg_trgm = 3-gram (trigram) 분해 → GIN. LIKE 성능 획기적 향상.

Fastupdate + Pending List

flowchart LR
    Insert["INSERT"] --> Pending["Pending list<br/>(빠른 accumulate)"]
    Pending -.gin_pending_list_limit.-> Merge["주기적 merge into GIN"]
    Merge --> GIN[(GIN 본체)]

기본 활성. INSERT/UPDATE 폭증 시 GIN 재계산이 비쌈 → 일단 임시 저장 + 배치 merge.

-- 비활성 (query 성능 우선)
CREATE INDEX ... USING gin(...) WITH (fastupdate = off);

-- 임계값 조정
gin_pending_list_limit = 4MB

[!CAUTION] Pending list 가 크면 query 시 pending list + GIN 둘 다 스캔 → 느림. VACUUM 이 merge 트리거.

GIN 크기 문제

-- 인덱스 크기 확인
SELECT pg_size_pretty(pg_relation_size('idx_payload_full'));

-- 재빌드 (bloat 정리)
REINDEX INDEX CONCURRENTLY idx_payload_full;

큰 GIN 인덱스 (수십 GB) 는 흔함. jsonb_path_ops 로 크기 대폭 감소.

GIN + partial index

-- 특정 조건만 인덱싱
CREATE INDEX idx_recent_tags ON posts USING gin(tags)
WHERE created_at > now() - interval '30 days';

Hot data 만 인덱싱 → 크기 감소 + 빌드 시간 단축.

Insert 성능

GIN insert cost:
  - term 하나마다 posting list update
  - N terms in row → N updates

배열 컬럼에 30개 tag 삽입:
  30 개의 posting list 업데이트 = 매우 비쌈

대안:
  - fastupdate ON (기본): 임시 저장
  - Bulk load: COPY + CREATE INDEX (기존 인덱스 drop)

GIN vs GiST vs Bloom

	GIN	GiST	Bloom
자료구조	Inverted	Balanced tree	Bit vector
Insert 속도	느림	빠름	매우 빠름
Query 속도	빠름	중간	매우 빠름 (fp)
다값 지원	예	예	아니오
사용	jsonb, array, tsvector	spatial, range	multi-column =

흔한 함정

[!WARNING]

jsonb_ops 항상 사용 = 크기 3배, 속도 저하. @> 만이면 jsonb_path_ops.

Pending list 무한 성장 = query 느림. VACUUM 정기.

작은 배열에도 GIN = 배열 항목 수 <10 면 별도 컬럼 + B-Tree 가 나을 수도.

HOT update 안 됨 in GIN = GIN 은 tuple ID 저장 → row 위치 바뀌면 update.

[DB Internals] R-Tree: 공간 인덱스, MBR, split

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

R-Tree (Guttman, 1984) = 공간 데이터 (2D, 3D) 를 인덱싱하는 balanced tree. 각 노드는 Minimum Bounding Rectangle (MBR) 을 저장.

[!IMPORTANT] 지도, GIS, 위치 기반 서비스, 3D 게임, CAD 의 표준. PostGIS, MySQL Spatial, SQL Server Spatial 모두 R-Tree 계열.

왜 B-Tree 로 안 되나?

공간 데이터: (x, y) 좌표
Query: "이 사각형 안의 점들"

B-Tree 는 1차원 정렬만 가능:

-- ✗ 각 축을 별도 인덱스 → 매우 비효율
CREATE INDEX ON points(x);
CREATE INDEX ON points(y);
SELECT * FROM points WHERE x BETWEEN 10 AND 20 AND y BETWEEN 30 AND 40;
-- 두 인덱스 AND, 대부분 안 씀

R-Tree = n차원 공간의 계층적 분할.

구조 (2D 예)

flowchart TB
    Root["Root MBR: (0,0)-(100,100)"]
    Root --> A["A MBR: (0,0)-(50,60)"]
    Root --> B["B MBR: (40,50)-(100,100)"]
    A --> A1["Leaf: 점들 in (0,0)-(30,40)"]
    A --> A2["Leaf: 점들 in (20,30)-(50,60)"]
    B --> B1["Leaf: 점들 in (40,50)-(70,80)"]
    B --> B2["Leaf: 점들 in (60,70)-(100,100)"]

각 노드가 자기 자식들을 감싸는 최소 사각형 (MBR) 저장. B-Tree 처럼 balanced.

MBR (Minimum Bounding Rectangle)

점: (10, 20)
선분: (5, 5) - (15, 25) → MBR = (5,5)-(15,25)
원: 중심 (10, 10), 반지름 5 → MBR = (5,5)-(15,15)
폴리곤: 모든 꼭짓점 감싸는 최소 사각형

R-Tree 는 실제 도형이 아닌 MBR 로 계산 → 빠름. Precision 은 별도 filter 로.

Search

sequenceDiagram
    autonumber
    Q->>Root: query rectangle (Q)
    Root->>Root: 자식 MBR 중 Q 와 *overlap* 하는 것만
    Root->>A: overlap? YES → 재귀
    Root->>B: overlap? NO → skip
    A->>A1: overlap? YES
    A->>A2: overlap? NO
    A1-->>Q: candidate 점 반환
    Q->>Q: 실제 도형 vs Q 확인 (refinement)

2 단계 필터링:

Filter: MBR 겹침 확인 (빠름, 근사)
Refinement: 실제 도형 vs 쿼리 (정확, 느림)

Insertion + Split

새 도형 → 가장 적게 확장되는 자식 선택 → leaf 도달:

insert(root, entry):
  if leaf:
    add entry to leaf
    if leaf overflow:
      split(leaf)
  else:
    best_child = choose_subtree(node, entry)
    insert(best_child, entry)
    update MBR of node

Split 알고리즘 (핵심)

flowchart LR
    Overflow["Leaf overflow (M+1 entries)"]
    Overflow --> Strategy{"Split 전략"}
    Strategy --> Linear["Linear split (Guttman)"]
    Strategy --> Quad["Quadratic split (더 좋은 quality)"]
    Strategy --> RStar["R* Tree (best quality)"]

알고리즘	시간	품질
Linear	O(N)	낮음
Quadratic	O(N²)	중간
R* Tree	O(N log N)	최고

R* Tree (2026 표준)

Beckmann et al. (1990) 의 개선:

Overflow 시 재삽입 (forced reinsertion).
Overlap 최소화 + coverage 최소화 + dead space 최소화.
PostGIS 의 GiST 가 R* 기반.

R-Tree vs Quad-tree vs KD-Tree

	R-Tree	Quad-tree	KD-Tree
Balanced	예	아니오	아니오
Disk I/O	최적	나쁨	나쁨
Dimension	낮음 (2-6)	2D	낮음 (2-10)
DB 사용	표준	드묾	드묾
삽입	복잡	간단	복잡
갱신	느림	빠름	매우 느림 (rebuild)

PostGIS 사용

CREATE EXTENSION postgis;

CREATE TABLE places (
  id BIGSERIAL PRIMARY KEY,
  name TEXT,
  location GEOMETRY(Point, 4326)   -- WGS 84
);

CREATE INDEX idx_places_geom ON places USING gist(location);

-- 반경 검색
SELECT * FROM places
WHERE ST_DWithin(location, ST_MakePoint(126.97, 37.55)::geography, 1000);

-- 사각형 검색
SELECT * FROM places
WHERE location && ST_MakeEnvelope(126.9, 37.5, 127.0, 37.6, 4326);

PostGIS 는 GiST + R-Tree. && (overlap), <@ (contains), ~= (equal).

PostGIS 의 성능 팁

-- 1. Geometry 대신 geography (구면 거리 정확)
location GEOGRAPHY(Point, 4326)

-- 2. SP-GiST 는 point 만 (더 빠름)
CREATE INDEX ON places USING spgist(location);

-- 3. Clustered index 로 physical order 개선
CLUSTER places USING idx_places_geom;

-- 4. Materialized bounding box column (자주 검색시)
ALTER TABLE places ADD COLUMN bbox BOX2D
  GENERATED ALWAYS AS (ST_Envelope(location)) STORED;
CREATE INDEX ON places USING gist(bbox);

GiST vs SP-GiST vs BRIN (공간)

인덱스	적합
GiST	일반 (Point, Polygon, Range) - R-Tree 기반
SP-GiST	Point only, Quadtree - 더 빠름
BRIN	시계열 좌표 (센서 데이터)

자세한 건 [[gin-index-deep]] / [[gin-gist-hash-indexes]].

R-Tree 알고리즘 (3D+)

flowchart TB
    Q["R-Tree 확장"]
    Q --> RD["R-Tree in R^d (d dimensions)"]
    Q --> Priority["Priority R-Tree (I/O 최적)"]
    Q --> M["M-Tree (metric space, arbitrary distance)"]
    Q --> HR["Hilbert R-Tree (space-filling curve)"]

M-Tree = 임의 거리 함수 (문자열 편집 거리 등) 가능. HNSW (벡터 검색) 은 완전히 다른 접근.

자세한 벡터 검색은 [[elasticsearch-vector-search]], [[Redis Vector Search]].

흔한 함정

[!WARNING]

&& (overlap) 만 쓰고 refinement 안 함 = MBR 겹치는 false positive. ST_Intersects 로 정밀.

Geography vs Geometry 혼용 = 거리 단위 다름. 명시.

SRID 불일치 = 검색 실패. ST_Transform 으로 통일.

큰 폴리곤의 R-Tree = MBR 이 너무 커서 false positive 폭증. 폴리곤 분할.

[DB Internals] Redis 8 / Valkey 9: 라이센스 분기, 신 데이터 구조, 실전 운영

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Redis 는 in-memory key-value 데이터 구조 서버. 2009년 Salvatore Sanfilippo (antirez) 가 Lua Manuscripts 의 한 줄에서 시작해 서비스 인프라의 표준 부품 이 되었다.

2026-06 시점의 풍경은 2년 전과 완전히 다르다:

라이센스 분기: 2024-03 의 BSD 종료 이후 Valkey 라는 Linux Foundation 산하 BSD fork 가 본격 자리잡았다.
antirez 복귀: 2024-11 에 antirez 가 Redis 사로 돌아오고, 2025-05 의 Redis 8 에서 AGPLv3 옵션 추가 + 새 데이터 구조 vector set 를 직접 만들어 발표.
Stack 통합: RediSearch, RedisJSON, RedisTimeSeries, Bloom, CMS, TopK 가 Redis 8 코어 로 들어왔다.
Vector DB 로서의 부상: LLM semantic cache, conversation memory, agent memory 의 de facto 저장소.

이 페이지는 2026-06 시점의 운영자/도입자 시점 에서 Redis / Valkey 양쪽의 동향과 실전 결정점 을 정리한다.

라이센스 분기 타임라인

시점	이벤트
2009	antirez 가 Redis 0.x 공개. BSD-3
2018-2019	Redis Labs (이후 Redis Inc.) 가 모듈 (RediSearch, RedisJSON 등) 에 RSAL/Commons Clause 적용
2024-03-20	Redis 7.4 부터 core 까지 RSALv2 + SSPLv1 dual. BSD 종료
2024-03-28	Linux Foundation 이 Valkey fork 발표. Redis 7.2.4 기반 BSD-3. AWS / Google / Oracle / Snap / Ericsson 등 참여
2024-04-16	Valkey 7.2.5 GA (BSD-3, 첫 안정 fork 릴리즈)
2024-09-16	Valkey 8.0 GA
2024-11	antirez 가 Redis 로 복귀 (developer evangelist). 커뮤니티 신호 큼
2025-04-02	Valkey 8.1 (new hash table, 50M ZSet 처리)
2025-05-01	Redis 8 + AGPLv3 옵션 추가. Redis Stack 코어 통합. vector set 첫 공개
2025-10-21	Valkey 9.0 (atomic slot migration, hash field expiration, numbered databases)
2026-05-19	Valkey 9.1 (보안 / 성능 / 관측성)

핵심 의미

Redis 는 AGPLv3 (OSI 승인) / RSALv2 / SSPLv1 의 triple license. 사용자는 AGPLv3 옵션 으로 진짜 OSS 로 쓸 수 있다.
Valkey 는 BSD-3. 라이센스 제약이 가장 가볍다. AWS / Google / Oracle 의 managed 서비스 가 대부분 Valkey 기반.
API 호환 은 대체로 유지된다. 2026-06 시점 두 줄기 모두 RESP3 호환. 다만 신 데이터 구조 (vector set, Array, RediSearch SVS-VAMANA) 는 각자 자기 동네에서 먼저 나온다.

도입 결정: managed 면 클라우드 벤더가 미는 Valkey 를 우선 검토. Stack 기능 (search, JSON, time-series) 을 통째로 쓰려면 Redis 8. 직접 호스팅하면 AGPL 의 obligation 을 평가.

Redis 8 시리즈 (2025-05 ~ )

Redis 8.0 (2025-05)

Vector set 데이터 구조 (preview): antirez 가 직접 작성. HNSW 인덱싱 + 도메인 임베딩 친화 API.
Stack 통합: RediSearch, RedisJSON, RedisTimeSeries, RedisBloom, Cuckoo, Count-Min Sketch, TopK 가 core 안 으로. 더 이상 modules 묶음 을 별도 배포할 필요가 없다.
새 hash 명령어: HGETEX, HSETEX, HGETDEL (세션 / 캐시 패턴에서 atomic + ttl).
성능: 일부 명령어 최대 87% latency 단축, replica 메모리 35% 절감, 2x throughput.
확장 ACL: 새 데이터 구조에 맞춘 권한 모델.

Redis 8.2

Streams: XDELEX / XACKDEL (라이프사이클 명령). consumer group 관리가 세분화.
BITOP 새 연산자 (복잡한 bitmap 워크플로).
RediSearch: SVS-VAMANA 벡터 인덱스 타입, SHARD_K_RATIO (KNN 샤드 후보 조절).
Keyspace notifications: 새 event type 으로 데이터 변경 추적 강화.

Redis 8.4

Strings: atomic compare-and-set.
Streams: idle entry claiming.
Search: hybrid search (벡터 + 텍스트 + 태그를 한 쿼리에서).
SIMD 최적화, JSON 처리 개선.

Redis 8.6 → 8.8

새 데이터 구조 Array (antirez 직접). append-mostly + index access 워크로드 타겟.
INCREX: INCR + 윈도우 카운터 + bounds + expiration 통합 rate limiter. 한 줄로 토큰 버킷 비슷한 패턴 구현 가능.
XNACK: streams 에서 consumer 가 명시적으로 메시지를 release.
ZUNION / ZINTER / ZUNIONSTORE / ZINTERSTORE: 새 COUNT aggregator.
JSON.SET: 새 FPHA argument (homogeneous FP array).
TS.RANGE / TS.MRANGE: 한 명령에서 multiple aggregators.
FT.HYBRID: 새 KNN 절 옵션 + FT.PROFILE 지원.

Valkey 시리즈 (2024-04 ~ )

Valkey 7.2.5 (2024-04)

Redis 7.2.4 기반 첫 GA. BSD-3. 드롭인 호환.

Valkey 8.0 (2024-09)

메모리 효율 개선 (압축 인코딩 튜닝).
1M RPS 벤치마크 달성 (싱글 노드 + 클라이언트 fleet).
새 async I/O 모델.

Valkey 8.1 (2025-04)

새 hash table 디자인 (blog). 50M 멤버 ZSet 시나리오에서 메모리 / 처리량 동시 개선.
성능 / 관측성 강화.

Valkey 9.0 (2025-10-21)

Atomic Slot Migration: 리샤딩이 원자적. 기존의 복잡한 PRE/MIGRATE/MIGRATING/STABLE 트랜잭션을 추상화 했다.
Hash Field Expiration: 키 전체가 아니라 해시 필드 하나마다 TTL. 세션 / 토큰 관리 패턴이 훨씬 간결.
Numbered Databases (재설계): cluster 모드에서도 namespacing 가능하도록 부활.
Vector Search 모듈 1.0 (별도 GA: 2025-07).
Bloom Filter / JSON / Search 가 valkey-bundle 단일 컨테이너로 묶임.

Valkey 9.1 (2026-05-19)

보안 강화 (TLS 운영 옵션, 기본값 정비).
관측성 (COMMANDLOG, SLOT-STATS, per-thread I/O metrics).
효율성, 클라이언트 라이브러리 호환성.

데이터 구조 카탈로그 (2026)

구조	핵심 명령	사용 케이스
String	`SET`, `GET`, `INCR`, `APPEND`	캐시, 카운터, flag
List	`LPUSH`, `RPOP`, `LRANGE`, `BLPOP`	큐, 큐 (FIFO), 최근 이벤트
Hash	`HSET`, `HGET`, `HGETEX`, `HEXPIRE` (필드 단위)	객체, 세션, 사용자 프로필
Set	`SADD`, `SISMEMBER`, `SINTER`	태그, 멤버십, 중복 제거
Sorted Set (ZSet)	`ZADD`, `ZRANGEBYSCORE`, `ZRANGEBYLEX`, `ZUNION ... COUNT`	리더보드, 시간순 인덱스, 우선순위 큐
Stream	`XADD`, `XREAD`, `XREADGROUP`, `XACK`, `XACKDEL`, `XNACK`	append-only log, 메시지 큐, event sourcing
HyperLogLog	`PFADD`, `PFCOUNT`	대규모 cardinality 추정 (UV 등)
Geo	`GEOADD`, `GEOSEARCH`	위치 인덱스, 반경 검색
Bitmap	`SETBIT`, `BITCOUNT`, `BITOP`	일자별 활성 사용자, 권한 비트
Bitfield	`BITFIELD`	작은 정수 패킹 (memory micro-opt)
Vector Set (Redis 8)	`VADD`, `VSIM`, `VLINKS`	임베딩 검색, semantic cache, agent memory
Array (Redis 8.8)	`ARRPUSH`, `ARRGET` 등	append-mostly index 패턴
Bloom / Cuckoo / CMS / TopK	`BF.ADD`, `BF.EXISTS` 등	확률적 자료구조
JSON (Redis 8 / Valkey JSON)	`JSON.SET`, `JSON.GET`, `JSON.ARRAPPEND`	문서 저장, partial update
Time Series	`TS.ADD`, `TS.RANGE`, `TS.MRANGE`	메트릭, IoT 텔레메트리

Stream vs Pub/Sub

항목	Pub/Sub	Stream
영속성	없음 (구독자가 없으면 사라짐)	영속 (TTL/MAXLEN 으로 관리)
Consumer group	없음	있음 (Kafka 와 유사)
ACK	없음	`XACK`, `XACKDEL`, `XNACK`
적합	알림, 신호 (lossy OK)	메시지 큐, event log

Pub/Sub 의 fan-out 신호 동작:

{}

Stream / List 큐의 FIFO 동작:

{}

자세한 비교는 [[Redis Pub Sub vs Streams]] 참고.

RediSearch / Valkey Search: 벡터 + 텍스트

LLM 시대의 Redis 의 두 번째 정체성. 벡터 인덱스 + 텍스트 + 태그 + 숫자를 한 쿼리 에서.

FT.CREATE idx ON HASH PREFIX 1 doc:
  SCHEMA
    title TEXT
    tag   TAG
    embedding VECTOR HNSW 6
      TYPE FLOAT32
      DIM 1536
      DISTANCE_METRIC COSINE

FT.SEARCH idx "@tag:{backend} =>[KNN 10 @embedding $vec AS score]"
  PARAMS 2 vec <bytes> DIALECT 2

알고리즘	특징
`FLAT`	정확한 brute-force, 작은 데이터셋
`HNSW`	Approximate Nearest Neighbor 표준. 빠름, 메모리 큼
`SVS-VAMANA` (Redis 8.2+)	대규모 + 메모리 효율. Intel/Microsoft 가 밀고 있는 알고리즘

Hybrid search (FT.HYBRID) 는 키워드 + 벡터 점수를 합쳐 RRF (Reciprocal Rank Fusion) 로 섞는다. RAG 시스템에서 키워드 매치 + 의미 검색 을 한 호출로.

실전 운영 패턴

1. 캐시 (가장 흔한 시작)

캐시 HIT (~6ms) 와 MISS (~72ms) 의 직관:

{}

{}

TTL 정책: 짧고 자주 가 안전. 데이터 모양 / 인기 분포에 따라 layered TTL (자주 쓰이는 키는 길게, 나머지 짧게).
Cache stampede: TTL 만료 시 동시에 많은 클라이언트 가 백엔드를 친다. probabilistic early refresh, single-flight lock, stale-while-revalidate 패턴으로 완화.
Cache aside vs Read-through vs Write-behind: Rails 의 Rails.cache.fetch 는 cache aside. write-through 는 트랜잭션 보장이 필요.

자세한 패턴 카탈로그는 [[Redis Cache Patterns]] 참고.

2. 분산 락

SET key value NX PX <ms> + Lua 로 compare-and-delete. Redis 의 Redlock 알고리즘.

Martin Kleppmann 의 비판 과 antirez 의 반박 이 유명. 정확한 mutual exclusion 을 보장해야 하는 영역 (예: 결제) 에는 Redlock 만으로 충분하지 않다. fencing token 이 추가로 필요.

idempotent + retry-safe 한 작업에는 Redlock 단순 패턴이 충분히 실용적.

3. 큐 (Sidekiq / BullMQ / RQ)

producer / consumer 의 blocking queue 동작:

{}

라이브러리	언어	큐 구현
Sidekiq	Ruby	List + Sorted Set (scheduled) + Hash (job hash)
BullMQ	Node	Stream + Sorted Set, 강력한 priority
RQ	Python	List 기반 단순
Resque	Ruby	List 기반 (Sidekiq 의 선조)
Celery (Redis broker)	Python	List + ZSet

Sidekiq Pro/Enterprise 는 reliable fetch (RPOPLPUSH 패턴) 으로 crash 시 작업 손실 을 막는다. Stream + consumer group 으로 다시 짤 수 있는 영역이지만 호환성 으로 List 가 유지.

4. Vector store / Semantic cache (LLM 시대)

패턴	구현
Semantic cache	질문 embedding 으로 KNN search → 임계값 이상이면 캐시 히트. LLM 호출 비용 절감
Conversation memory	`XADD` 로 turn 을 append + `VADD` 로 embedding 저장. 검색 시 최근 N turn + 의미 유사 M turn 혼합
Agent memory (Mem0 식)	세션 단위 short-term + 장기 long-term 분리. Valkey + Mem0 사례 (blog)
RAG retrieval	`FT.HYBRID` 로 키워드 + 벡터 결합

5. Rate Limiting

Token bucket: ZSet timestamp 또는 Lua script 로 atomic.
Sliding window: 마찬가지로 Lua 또는 INCREX (Redis 8.8) 단일 명령.
Fixed window: INCR + EXPIRE NX.

운영 결정점

Persistence: RDB vs AOF

옵션	동작	트레이드오프
RDB	주기적 snapshot	빠름, 분 단위 손실
AOF	모든 write 를 append-only file	손실 최소, 느림 + 큰 파일
RDB + AOF	둘 다	부팅 빠르고 손실 적음. 권장
`appendfsync everysec`	1초 1회 fsync	손실 ≤ 1초, 거의 표준
`appendfsync always`	매 write fsync	손실 0, throughput 큰 영향

캐시 전용이면 둘 다 끄고 도 OK. primary data store 면 AOF + RDB hybrid + replica.

Cluster vs Sentinel vs Standalone

모드	핵심
Standalone	단일 노드 + replica 옵션. 작은 워크로드
Sentinel	자동 failover, 키 분할 없음. 데이터셋이 한 노드 메모리 안
Cluster	16384 슬롯 분할. 수평 확장. 멀티 키 명령 제약 (`{hashtag}`)

Valkey 9.0 의 atomic slot migration 으로 Cluster 운영의 가장 무서운 부분 이 크게 완화. 2026 시점 Cluster 진입 장벽 이 낮아졌다.

메모리 / Eviction

LRU 의 동작 직관:

{}

maxmemory <bytes> + maxmemory-policy:

Policy	설명
`noeviction` (기본)	메모리 초과 시 write 에러
`allkeys-lru`	모든 키 중 LRU (캐시 전용)
`volatile-lru`	TTL 있는 키 중 LRU
`allkeys-lfu`	LFU (자주 쓰이는 키 우선 유지)
`allkeys-random`	랜덤

memory fragmentation 모니터링: INFO memory 의 mem_fragmentation_ratio (이상적 1.0 ~ 1.5). 1.5 초과면 jemalloc 의 fragmentation. MEMORY PURGE 또는 restart.

Pipeline vs Lua vs Function

도구	의미
Pipeline	여러 명령을 한 번에 보내고 응답을 모음. atomic 아님. RTT 절약
`MULTI / EXEC`	atomic batch. WATCH 로 optimistic
`EVAL` (Lua)	atomic 스크립트. SCRIPT LOAD 로 캐시
`FUNCTION` (Redis 7+)	Lua 함수를 서버에 등록. 명명 + 버전 관리 가능. Lua 보다 권장

대안

대안	라이센스	특징
Valkey	BSD-3	Redis 7.2 fork. Linux Foundation. AWS / Google managed
DragonflyDB	BSL 1.1	멀티스레드 재구현. Redis API 호환. 25x throughput claim
KeyDB	BSD-3 (Snap 인수)	Redis fork + 멀티스레드. 최근 활동 줄어듦
Memcached	BSD-3	순수 캐시. 데이터 구조 / 영속성 없음. 멀티스레드
Garnet	MIT (Microsoft)	RESP 호환 .NET 구현. cluster 미흡
Etcd	Apache 2.0	강한 일관성 (Raft). KV + watch. 캐시 아닌 coordination 용

선택 기준:

managed 가격 + 호환성 → Valkey (대형 클라우드 추천)
throughput + 멀티코어 풀활용 → DragonflyDB
Stack 기능 (vector / search / JSON) 전부 + AGPL 가능 → Redis 8
순수 캐시 + 단순함 → Memcached

김신건의 현장 메모 (hera-webapp 운영)

Sidekiq + Redis 4년 운영. 가장 자주 본 알람은 Sidekiq 큐 적체 와 Redis 메모리 사용량. INFO memory 와 INFO clients 를 대시보드 핵심 지표 로.
enqueue 폭발 은 보통 큐별 분리 와 concurrency 분리 로 해결. critical / default / mailers / low 등 우선순위 큐를 정의하고 워커 풀을 큐별로 분리.
대량 job + Redis 메모리 압박 시: job payload 를 Redis 에 넣지 말고 DB id 만 (또는 S3 reference). Sidekiq 의 default 가 전체 args 직렬화 라 의외로 함정.
Sentinel 운영 시 failover 동안 short-lived 클라이언트 timeout 이 가장 흔한 사고. application level retry 와 connection pool 의 failover 동작 명세 가 같이 가야 한다.
RediSearch / vector 는 hera-webapp 시기에는 별 필요 없었지만 역량 리포트 같은 세션/대화 기반 흐름에서는 Redis 8 vector set + semantic cache 가 프롬프트 비용 을 주 단위 그래프 로 끌어내릴 수 있는 가장 빠른 손.
AGPL 의무: SaaS 노출 면 AGPL 의 source 공개 의무 가 켜진다. 도입 전 법무 / 컴플라이언스 와 확인. Valkey 가 BSD 라는 점이 managed 환경 에서 거의 결정 요인.

참고

[DB] Cassandra: LSM-tree, quorum, eventually consistent

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Apache Cassandra = 마스터리스 (peer-to-peer) 분산 KV 스토어. write 우선, eventually consistent, 수평 무한 확장. 2008 Facebook 의 Dynamo + BigTable 결합.

ScyllaDB = Cassandra 호환 C++ 재구현. 10x throughput.

핵심 특성

	Cassandra
토폴로지	peer-to-peer (master 없음)
일관성	튜닝 가능 (per query)
스토리지	LSM-tree (write-optimized)
쿼리 언어	CQL (SQL-like)
인덱스	primary key + secondary (제한)
Join	없음
트랜잭션	제한적 (LWT, lightweight transaction)

LSM-Tree (Log-Structured Merge-Tree)

flowchart TB
    Write[Write] --> CommitLog["Commit Log<br/>(WAL)"]
    Write --> Memtable["Memtable<br/>(메모리)"]
    Memtable -.flush.-> SST1[SSTable L0]
    SST1 -.compact.-> SST2[SSTable L1]
    SST2 -.compact.-> SST3[SSTable L2]
    SST3 -.compact.-> SST4[SSTable L3]

컴포넌트	의미
Commit Log	WAL (crash recovery)
Memtable	메모리 정렬 자료
SSTable	불변 정렬 파일 (디스크)
Compaction	SSTable 들을 큰 SSTable 로 병합

{}

외부 정렬 머지의 일반 직관. LSM-tree 의 compaction 도 level 들을 순차 머지.

LSM vs B-tree

항목	B-tree	LSM
Write	in-place (random)	append (sequential)
Read	1 lookup	여러 SSTable 검색
Write amplification	작음	큼 (compaction)
Read amplification	작음	큼
적합	OLTP read-heavy	write-heavy, log-like

클러스터 토폴로지

flowchart LR
    subgraph Ring[Token Ring]
        N1[Node A<br/>token 0]
        N2[Node B<br/>token 1/3]
        N3[Node C<br/>token 2/3]
    end
    N1 --- N2 --- N3 --- N1
    Key1[hash key=42] -->|시계방향| N2

consistent hashing ring.
N 개 노드, Replication Factor (RF) 만큼 복제.
전체가 peer. master 없음.

Consistency Level (per query)

Level	의미
`ANY`	어떤 노드라도 응답 (write)
`ONE`	1 노드 응답
`TWO`, `THREE`	2 / 3 노드
`QUORUM`	과반 (RF/2 + 1)
`LOCAL_QUORUM`	같은 DC 안 과반
`EACH_QUORUM`	모든 DC 의 과반
`ALL`	모든 replica

Quorum 의 W + R > N 조건

flowchart LR
    Write[W = QUORUM] --> N[RF = 3]
    Read[R = QUORUM]
    Cond["W + R > N → 항상 최신 read"]
    Write --> Cond
    Read --> Cond

RF = 3, W = QUORUM (2), R = QUORUM (2). W + R = 4 > 3 → 최소 1 노드는 양쪽 모두 봄 → strong consistency.

Read Path

sequenceDiagram
    Client->>Coord: SELECT
    Coord->>R1: read
    Coord->>R2: read
    par 응답 대기
        R1-->>Coord: v1 (ts=100)
        R2-->>Coord: v2 (ts=110)
    end
    Coord->>Coord: 최신 (ts=110) 반환
    Coord->>R1: read repair (백그라운드)

Last-write-wins by timestamp. 시계 어긋남 이 데이터 정정 의 함정.

CQL (Cassandra Query Language)

CREATE KEYSPACE shop
  WITH replication = { 'class': 'NetworkTopologyStrategy', 'dc1': 3 };

CREATE TABLE orders (
  user_id UUID,
  order_id TIMEUUID,
  total INT,
  status TEXT,
  PRIMARY KEY (user_id, order_id)
) WITH CLUSTERING ORDER BY (order_id DESC);

-- partition key = user_id, clustering key = order_id
SELECT * FROM orders WHERE user_id = ? AND order_id > ?;
INSERT INTO orders (user_id, order_id, total, status)
  VALUES (?, now(), ?, ?);

키	의미
Partition Key	partition (노드) 결정
Clustering Key	partition 안의 정렬

LWT (Lightweight Transaction)

INSERT INTO users (id, email) VALUES (?, ?) IF NOT EXISTS;
UPDATE users SET email = ? WHERE id = ? IF email = ?;

Paxos 기반. 4 round-trip.
느림. 가끔만 사용.

적합 / 부적합

flowchart TD
    Q{사용 패턴}
    Q --> Good[적합]
    Q --> Bad[부적합]
    Good --> G1[Write-heavy log]
    Good --> G2[Time-series]
    Good --> G3[IoT telemetry]
    Good --> G4[수십 TB 데이터]
    Bad --> B1[복잡한 ad-hoc 쿼리]
    Bad --> B2[강한 트랜잭션]
    Bad --> B3[Join 많음]
    Bad --> B4[작은 데이터셋]

흔한 함정

[!WARNING]

Secondary index 남용 = 거의 항상 전체 노드 fan-out. 모든 access pattern 에 전용 테이블.

Tombstone (삭제 마커) 누적 = 압축 안 되면 read 폭증. gc_grace_seconds + 정기 repair.

Cross-partition query = 비싸다. partition key 디자인이 결정적.

Strong consistency 기대 = QUORUM 으로도 시계 어긋남 시 잘못된 결과. NTP + 보수적 timestamp.

[DB] DynamoDB: PK + SK, single-table design, GSI / LSI

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

DynamoDB 는 AWS 의 fully managed key-value + document NoSQL. low-latency, infinite scale, schemaless. single-table design 이 트레이드마크 패턴.

핵심 키

Primary Key = Partition Key (PK)
           또는 Partition Key + Sort Key (PK + SK) ← Composite

키	의미
PK (Partition Key)	hash → 물리 partition 결정
SK (Sort Key)	같은 PK 안의 정렬 키

[!IMPORTANT] DynamoDB 의 모든 query 는 PK 를 반드시 지정. SK 는 range query 가능. 이 제약이 single-table design 을 강제.

Item 예시

PK	SK	Type	Data
`USER#42`	`PROFILE`	user	name, email
`USER#42`	`ORDER#2026-06-25#o_1`	order	total, items
`USER#42`	`ORDER#2026-06-24#o_2`	order	total, items
`USER#42`	`ADDR#home`	address	city, street
`ORDER#o_1`	`META`	order	userId, status

한 테이블에 여러 entity type 동시 저장. 한 query 로 user 의 모든 데이터:

PK = USER#42  → 모든 row (PROFILE, ORDER, ADDR)
PK = USER#42 AND SK begins_with(ORDER#) → 주문만

Capacity Mode

모드	의미
Provisioned	RCU/WCU 미리 설정
On-Demand	자동 스케일, 사용량 청구

단위	1 RCU	1 WCU
Eventually consistent	2 read/sec (4KB)	-
Strongly consistent	1 read/sec	-
Write	-	1 write/sec (1KB)

Strongly vs Eventually Consistent Read

flowchart LR
    Write[Write] --> Leader[Leader replica]
    Leader -.async.-> R1[Replica 1]
    Leader -.async.-> R2[Replica 2]
    Read1[Strong read] --> Leader
    Read2[Eventual read] --> R1
    Read2 --> R2

	Strong	Eventual
Latency	약간 높음	낮음
Cost (RCU)	2배	기본
일관성	항상 최신	최근 쓰기 못 봄 가능

GSI vs LSI

	LSI (Local)	GSI (Global)
PK	같은 base table 의 PK	임의 키
동시 생성	create 시만	언제든
일관성	strong / eventual	eventual 만
크기 제한	10GB / PK	없음
개수	5	20

flowchart LR
    Base["Base table (PK, SK)"]
    Base --> LSI1["LSI (PK, new_SK)"]
    Base --> GSI1["GSI (different_PK, different_SK)"]

Single-Table Design

flowchart TB
    Q[모든 access pattern 정의]
    Q --> Choose[PK + SK 선택]
    Choose --> One[ONE table 에 모든 entity]
    One --> Why[*Join 없이* 한 query 로 끝]

[!IMPORTANT] RDB 사고 (테이블 = entity) 와 완전 다른 패러다임. access pattern 을 먼저 정의, 그에 맞춰 PK/SK 디자인. 잘못 설계하면 전체 마이그레이션.

Query vs Scan

# Query (효율적, PK 필수)
QUERY PK = "USER#42" AND SK begins_with "ORDER#"

# Scan (전체 테이블 순회, 비효율)
SCAN FilterExpression: "status = paid"

[!WARNING] Scan 은 거의 항상 안티패턴. 모든 partition 순회 → 비용 폭발. Scan 이 자주 필요하면 디자인 결함.

DAX (DynamoDB Accelerator)

flowchart LR
    App --> DAX["DAX Cluster<br/>(in-memory cache)"]
    DAX -->|miss| DDB[(DynamoDB)]
    DAX -.->|hit| App

마이크로초 단위 latency.
write-through 캐시.
읽기 중심 워크로드에서 효과.

Streams + Lambda

flowchart LR
    DDB[(DynamoDB Table)] -->|change stream| Streams[DDB Streams]
    Streams --> Lambda[Lambda]
    Lambda --> ES[ElasticSearch]
    Lambda --> SNS[SNS]
    Lambda --> SQS[SQS]

Change Data Capture. secondary index 가 부족할 때 Streams 로 외부 검색 인덱스 동기화.

PartiQL

-- SQL-like 쿼리
SELECT * FROM "MyTable" WHERE PK = 'USER#42' AND begins_with("SK", 'ORDER#');

익숙한 SQL 문법이지만 내부는 여전히 PK/SK 제약 적용. RDB 쿼리처럼 작성하면 Scan 폭발.

흔한 함정

[!WARNING]

Hot partition = 특정 PK 에 트래픽 집중. 분산 키 디자인 (해시 prefix).

너무 큰 item = 400KB 제한. 큰 데이터는 S3 + DDB 에 참조.

Scan 의존 쿼리 = 비용 폭발. GSI 추가.

eventual consistency 무시 = 방금 쓴 값이 없을 수 있음. strong read 명시 또는 재시도.

[DB] EXPLAIN 읽기: scan, join, sort, cost

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

EXPLAIN = 쿼리 실행 계획 표시. EXPLAIN ANALYZE = 실제로 실행 + 실제 시간 측정.

EXPLAIN (ANALYZE, BUFFERS, VERBOSE, FORMAT TEXT)
SELECT u.name, COUNT(o.id)
FROM users u LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > '2026-01-01'
GROUP BY u.id, u.name;

Scan 종류

flowchart TD
    Scan{Scan 종류}
    Scan --> Seq["Seq Scan<br/>전체 테이블 순회"]
    Scan --> Idx["Index Scan<br/>인덱스 → 테이블"]
    Scan --> IdxOnly["Index Only Scan<br/>인덱스에서만"]
    Scan --> Bitmap["Bitmap Scan<br/>bitmap 으로 페이지 모음"]

Scan	의미	적합
Seq Scan	전체 테이블	작은 테이블, 대부분 row 반환
Index Scan	인덱스 → row	선택적 (적은 row)
Index Only Scan	인덱스 only (heap 안 봄)	covering index
Bitmap Index Scan	여러 인덱스 결합 + bitmap	다 인덱스 조합
Bitmap Heap Scan	bitmap → 페이지 fetch	위와 짝
Tid Scan	직접 tid 접근	극히 드뭄

Join 종류

Join	동작	적합
Nested Loop	for outer { for inner }	작은 inner + 인덱스
Hash Join	hash 빌드 → 룩업	큰 양쪽, 등가 조건
Merge Join	정렬된 양쪽 머지	양쪽 정렬됨, 범위 조건

{}

위 애니메이션은 Grace Hash Join (메모리 부족 시 분할 hash). 대용량 join 의 일반 직관.

EXPLAIN ANALYZE 출력 읽기

Aggregate  (cost=1024.50..1024.51 rows=1 width=8) (actual time=15.234..15.236 rows=1 loops=1)
  ->  Hash Join  (cost=12.50..1020.50 rows=1600 width=4) (actual time=0.234..14.123 rows=1542 loops=1)
        Hash Cond: (o.user_id = u.id)
        ->  Seq Scan on orders o  (cost=0.00..900.00 rows=50000 width=8) (actual time=0.012..5.234 rows=49832 loops=1)
        ->  Hash  (cost=10.00..10.00 rows=200 width=8) (actual time=0.190..0.190 rows=215 loops=1)
              ->  Index Scan using idx_users_created on users u  (cost=0.42..10.00 rows=200 width=8) (actual time=0.012..0.123 rows=215 loops=1)
                    Index Cond: (created_at > '2026-01-01'::date)
Planning Time: 0.345 ms
Execution Time: 15.456 ms

필드	의미
`cost=A..B`	A = 시작 비용, B = 총 비용 (페이지 수 단위)
`rows=N`	예상 row 수
`width=N`	평균 row 바이트
`actual time=A..B`	실제 시작/종료 ms
`rows=actual`	실제 row 수
`loops=N`	이 노드가 N번 실행
`Planning Time`	optimizer 시간
`Execution Time`	실행 시간

[!IMPORTANT] 예상 vs 실제 row 수 차이가 수십배 면 통계 부정확 → ANALYZE table_name 으로 갱신.

자주 보는 안티 패턴

1. Seq Scan on 큰 테이블

Seq Scan on big_table  (rows=10000000)
  Filter: (status = 'pending')
  Rows Removed by Filter: 9990000

→ 인덱스 추가 또는 partial index (WHERE status = 'pending').

2. Nested Loop on 큰 양쪽

Nested Loop  (loops=100000)
  ->  Index Scan on table_a
  ->  Index Scan on table_b

→ 한쪽이 수만 row 면 Hash Join 으로 가야 함. set enable_nestloop = off 로 테스트.

3. Sort + Disk

Sort  (Sort Method: external merge  Disk: 1234kB)

→ work_mem 부족. session 또는 query 단위 증가.

{}

외부 정렬 (disk spill) 동작 직관. 임시 파일이 디스크에 쓰임.

4. Bitmap Heap Scan + 작은 rows

Bitmap Heap Scan  (rows=10)
  ->  Bitmap Index Scan

→ 좋은 패턴. 인덱스가 적절히 작동.

자주 쓰는 옵션

EXPLAIN (
  ANALYZE,      -- 실제 실행
  BUFFERS,      -- shared/local/temp buffer hits
  VERBOSE,      -- 컬럼 / 함수 상세
  COSTS OFF,    -- cost 숨김 (clean diff)
  FORMAT JSON   -- 도구 분석
) ...

시각화 도구

도구	비고
explain.depesz.com	색상 코딩
pev2 (Dalibo)	tree 시각화
pg_stat_statements	누적 통계
auto_explain	느린 쿼리 자동 로깅

흔한 함정

[!WARNING]

EXPLAIN (without ANALYZE) 만 신뢰 = optimizer 의 추정. 실제 행동은 다를 수 있다.

actual rows 와 rows= 차이 무시 = stale 통계. ANALYZE 필요.

Hash Join 의 큰 memory = work_mem 부족 시 disk spill. 그래도 Nested Loop 보다 빠를 수 있다.

planner hint 부재 = PostgreSQL 은 공식 hint 없음. SET 변수로 간접 제어. (MySQL 은 STRAIGHT_JOIN 등 hint 직접.)

[DB] GIN / GiST / Hash / BRIN: 비-B-tree 인덱스

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

B-tree 외 PostgreSQL 의 특수 인덱스 들. 자세한 B-tree 는 [[btree-indexing]] 참고.

인덱스	적합
B-tree	= < > BETWEEN ORDER BY (default)
Hash	= 만
GIN	다값 (배열, JSONB, full-text)
GiST	공간, 범위, 유사도
SP-GiST	공간 partitioning (Quadtree, kd-tree)
BRIN	큰 시계열, 잘 정렬된 데이터
Bloom	다컬럼 동등성 (확률)

GIN (Generalized Inverted Index)

하나의 컬럼이 여러 값 인 경우 (배열, JSONB, tsvector).

CREATE INDEX idx_tags ON posts USING gin(tags);
SELECT * FROM posts WHERE tags @> ARRAY['ruby', 'rails'];   -- 빠름

CREATE INDEX idx_jsonb ON events USING gin(payload jsonb_path_ops);
SELECT * FROM events WHERE payload @> '{"type": "click"}';

CREATE INDEX idx_fts ON articles USING gin(to_tsvector('english', body));
SELECT * FROM articles WHERE to_tsvector('english', body) @@ to_tsquery('postgres');

flowchart LR
    Doc1["doc 1: [a, b, c]"] --> Inv["a → [doc1, doc3]<br/>b → [doc1, doc2]<br/>c → [doc1]"]
    Doc2["doc 2: [b, d]"]
    Doc3["doc 3: [a, e]"]
    Inv --> Q["query: contains 'a' → [doc1, doc3]"]

[!TIP] JSONB 의 가장 흔한 인덱스. @>, ?, ?&, ?| 연산자 가속.

GiST (Generalized Search Tree)

tree 구조의 일반화. 공간 + 범위 + 유사도 검색.

-- PostGIS 공간
CREATE INDEX idx_geom ON places USING gist(geom);
SELECT * FROM places WHERE ST_DWithin(geom, ST_Point(-122, 37), 1000);

-- 범위 타입
CREATE INDEX idx_range ON bookings USING gist(during);
SELECT * FROM bookings WHERE during && '[2026-06-25, 2026-06-26)'::tsrange;

-- pg_trgm 유사도
CREATE EXTENSION pg_trgm;
CREATE INDEX idx_name_trgm ON users USING gist(name gist_trgm_ops);
SELECT * FROM users WHERE name % 'koa';   -- 유사 매치

BRIN (Block Range Index)

큰 테이블 + 물리 순서 ≈ 논리 순서 일 때. block 의 min/max 만 저장.

CREATE INDEX idx_created ON events USING brin(created_at);
SELECT * FROM events WHERE created_at >= '2026-06-25';

	B-tree	BRIN
크기	큼 (~ 10% of table)	작음 (~0.01%)
정밀도	정확	대략 (block range)
적합	일반	시계열, append-only

[!IMPORTANT] 수억 row 의 시계열 에서 BRIN 이 B-tree 의 1/100 메모리. 단 INSERT 순서와 정렬 컬럼이 일치 해야 효과.

Hash Index

CREATE INDEX idx_email_hash ON users USING hash(email);
SELECT * FROM users WHERE email = 'koa@x.com';   -- 빠름
SELECT * FROM users WHERE email LIKE 'koa%';     -- 사용 안 됨

= 검색만. range 불가.
PostgreSQL 10+ 부터 WAL 지원 (이전엔 replication 안 됨).
B-tree 가 거의 항상 더 좋음. 극히 큰 컬럼 의 = 만 검색 일 때 약간 우위.

SP-GiST

-- IP 주소 등 partitioning 자연
CREATE INDEX idx_ip ON logs USING spgist(client_ip);

Quadtree, kd-tree, radix tree 를 generic 으로 구현. 비균등 분포 데이터에 강함.

Bloom Index

CREATE EXTENSION bloom;
CREATE INDEX idx_multi ON events USING bloom(user_id, type, source)
  WITH (length = 80, col1 = 4, col2 = 4, col3 = 4);

SELECT * FROM events WHERE user_id = 42 AND type = 'click';

다컬럼 동등성.
확률적: false positive 가능 (PG 가 재검증).
모든 컬럼 동시 조회 에서 큰 B-tree 다수 대신.

인덱스 선택 매트릭스

flowchart TD
    Q1{쿼리 유형?}
    Q1 -->|"= < > BETWEEN ORDER BY"| Btree[B-tree]
    Q1 -->|"="| Hash[B-tree 또는 Hash]
    Q1 -->|배열 / JSONB / FTS| GIN[GIN]
    Q1 -->|공간 / 범위 / 유사도| GiST[GiST]
    Q1 -->|시계열 큼 + 정렬| BRIN[BRIN]
    Q1 -->|다컬럼 = AND| Bloom[Bloom 또는 B-tree composite]
    Q1 -->|IP / 비균등| SPGist[SP-GiST]

인덱스 크기 비교 (1억 row)

흔한 함정

[!WARNING]

JSONB 에 B-tree 인덱스 = 잘못. GIN 으로.

모든 컬럼에 인덱스 = INSERT 폭증. 사용 안 되는 인덱스 pg_stat_user_indexes.idx_scan = 0 으로 식별.

BRIN + 무작위 insert = 효과 0. clustered insert 가 전제.

hash index 의존 = 옛 버전은 WAL 안됨 → replica 에 없음. PG 10+ 만.

[DB] MongoDB: 문서 DB, WiredTiger, replica set, aggregation

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

MongoDB 는 BSON (binary JSON) 문서 기반 NoSQL DB. schema-less 라기보다 flexible schema. 2026 시점 Atlas (managed) 가 대다수.

핵심 개념

RDB	MongoDB
Database	Database
Table	Collection
Row	Document (BSON)
Column	Field
Index	Index (B-tree)
JOIN	`$lookup` (aggregation)
Foreign key	없음 (수동 관리)

문서 모델

{
  "_id": ObjectId("..."),
  "name": "koa",
  "email": "koa@x.com",
  "addresses": [
    { "type": "home", "city": "Seoul" },
    { "type": "work", "city": "SF" }
  ],
  "tags": ["admin", "pro"],
  "createdAt": ISODate("2026-06-25T00:00:00Z")
}

nested + 배열 자유로움. non-join read 가 빠름.

WiredTiger 스토리지 엔진

flowchart TB
    Op[op] --> WT[WiredTiger]
    WT --> Cache["메모리 cache (~50% RAM)"]
    WT --> Journal["Journal (WAL)"]
    WT --> Snappy[Snappy 압축]
    WT --> DataFiles[(BTree 데이터 파일)]

B-tree 인덱스.
Document-level locking (이전 글로벌 lock 에서 진화).
Snappy / Zstd 압축.

Replica Set

flowchart LR
    P[(Primary)] -->|oplog| S1[(Secondary 1)]
    P -->|oplog| S2[(Secondary 2)]
    Client -->|write| P
    Client -->|"read (옵션)"| S1
    Client -->|"read (옵션)"| S2

1 primary + N secondary.
자동 failover (election).
읽기 분산 옵션 (read preference).

Sharding

flowchart TB
    Client --> Mongos["mongos<br/>(라우터)"]
    Mongos --> Config[(Config Servers)]
    Mongos --> Shard1[(Shard 1)]
    Mongos --> Shard2[(Shard 2)]
    Mongos --> Shard3[(Shard 3)]

shard key 로 분산.
hashed, ranged, zone 정책.
chunk 단위 자동 balancing.

Aggregation Pipeline

db.orders.aggregate([
  { $match: { status: "paid" } },
  { $lookup: { from: "users", localField: "userId", foreignField: "_id", as: "user" } },
  { $unwind: "$user" },
  { $group: { _id: "$user.country", total: { $sum: "$amount" } } },
  { $sort: { total: -1 } },
  { $limit: 10 },
]);

Stage	의미
`$match`	WHERE
`$project`	SELECT
`$group`	GROUP BY
`$sort`	ORDER BY
`$limit` / `$skip`	LIMIT / OFFSET
`$lookup`	LEFT JOIN
`$unwind`	배열 분해
`$facet`	다중 sub-pipeline
`$bucket`	범위 그룹화

[!TIP] aggregation 순서 최적화: $match 와 $project 를 최대한 일찍. 인덱스 활용 + 처리량 감소.

Index

종류	의미
Single field	단일
Compound	다중
Multikey	배열 필드
Text	full-text
2dsphere	공간
Hashed	sharding 친화
Wildcard	임의 필드
TTL	자동 만료

db.orders.createIndex({ userId: 1, createdAt: -1 });
db.events.createIndex({ createdAt: 1 }, { expireAfterSeconds: 86400 });

Transactions (4.0+, 4.2+ sharded)

const session = db.startSession();
session.startTransaction();
try {
  await coll1.updateOne({ _id: 1 }, { $inc: { x: 1 } }, { session });
  await coll2.insertOne({ ... }, { session });
  await session.commitTransaction();
} catch (e) {
  await session.abortTransaction();
}

[!CAUTION] 과거 MongoDB = 트랜잭션 없음 이미지가 강했으나, 4.0+ 부터 multi-document ACID. Sharded 트랜잭션은 비용 큼, document 안에 묶을 수 있으면 그게 정통.

흔한 함정

[!WARNING]

_id 의 ObjectId 가 random 으로 clustered index 미친 분포 = MongoDB 는 _id index 의 random 분포 가 의도. 옛 PK 사고 패턴.

join 이 무거움 = $lookup 은 NoSQL 답지 않은 비용. 임베드 (embedding) 가 정통 패턴.

transaction 남용 = single document 안의 동작은 항상 atomic. transaction 은 진짜 필요할 때만.

shard key 잘못 선택 = 재선택 가능 했지만 옛 버전은 불가. write 분포가 균등하지 않은 키 가 가장 큰 함정.

[DB] MySQL / InnoDB: clustered index, redo log, MVCC

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

MySQL + InnoDB (기본 스토리지 엔진) 의 clustered index + redo log 기반 행 기반 RDBMS. 웹 / SaaS 의 가장 흔한 backbone.

아키텍처

flowchart TB
    Client --> Server["MySQL Server<br/>(parser, optimizer)"]
    Server --> InnoDB
    subgraph InnoDB
        BufferPool["Buffer Pool<br/>(메모리 캐시)"]
        RedoLog["Redo Log<br/>(WAL 류)"]
        UndoLog["Undo Log<br/>(MVCC)"]
        DataFiles[(ibd 데이터 파일)]
    end
    Server -->|writes| Binlog[(Binlog<br/>replication)]

Clustered Index (vs PostgreSQL)

	PostgreSQL	MySQL InnoDB
Primary 데이터 저장	heap + 별도 인덱스	primary key 의 B-tree leaf
Secondary index → 데이터	`tid` (heap 위치)	primary key 값
결과	secondary index lookup = 1 hop	secondary index lookup = 2 hop (인덱스 → PK → 데이터)
PK 영향	작음	큼 (변경 시 secondary index 도 갱신)

flowchart TB
    subgraph InnoDB
        PK[Primary Key B-tree<br/>= 실제 row 데이터]
        Sec[Secondary Index B-tree<br/>= PK 값을 leaf 에]
        Sec -->|PK lookup| PK
    end

[!IMPORTANT] InnoDB 의 PK 선택은 결정적. 큰 PK (UUID) = 모든 secondary index 가 큰 leaf. AUTO_INCREMENT BIGINT 가 보통 정답.

Redo Log + Undo Log

sequenceDiagram
    Client->>InnoDB: UPDATE ...
    InnoDB->>UndoLog: 옛 값 보관 (MVCC + rollback)
    InnoDB->>BufferPool: page dirty
    InnoDB->>RedoLog: 변경 기록 (WAL)
    InnoDB-->>Client: COMMIT (redo fsync 후)
    Note over InnoDB: Checkpoint 시점에 page → disk

로그	역할
Redo Log	crash recovery, WAL
Undo Log	MVCC + rollback
Binlog	replication, point-in-time recovery

Isolation Level (InnoDB 기본)

Level	InnoDB 기본	의미
READ UNCOMMITTED		dirty read
READ COMMITTED		다른 트랜잭션의 commit 된 것만
REPEATABLE READ	기본	같은 쿼리는 같은 결과 (snapshot)
SERIALIZABLE		완전 격리

InnoDB 의 REPEATABLE READ 는 next-key lock 으로 phantom read 방지. PostgreSQL 의 Read Committed 기본과 기본값이 다름.

자세한 건 [[transaction-isolation-levels]].

Buffer Pool

flowchart LR
    Disk[(ibd files)] --> BP[Buffer Pool]
    BP -->|hit| Client
    BP -.->|LRU eviction| Disk

메모리에 page 단위 (16KB) 캐시.
innodb_buffer_pool_size = 총 RAM 의 70-80% 가 운영 표준.
Hit ratio Innodb_buffer_pool_read_requests / Innodb_buffer_pool_reads.

Lock

Lock	의미
Shared (S)	다른 S 와 호환, X 와 충돌
Exclusive (X)	단독
Intention (IS, IX)	table-level 의도 표시
Record lock	row 단일
Gap lock	row 사이 간격
Next-key lock	record + gap (phantom 방지)
Auto-inc lock	AUTO_INCREMENT 동기

[!CAUTION] next-key lock 이 의도치 않게 넓은 범위 를 lock → deadlock 잦음. SHOW ENGINE INNODB STATUS\G 의 deadlock log 확인.

Replication

flowchart LR
    Primary --> Binlog[(binlog)]
    Binlog --> Replica1[Replica 1]
    Binlog --> Replica2[Replica 2]
    Binlog --> Replica3[Replica 3]

Async (기본): primary 가 즉시 OK
Semi-sync: 적어도 1개 replica 가 receive 후 OK
Group Replication: 다수 노드 합의

MySQL vs PostgreSQL

항목	MySQL	PostgreSQL
스토리지 엔진	InnoDB (+ MyISAM legacy)	단일
인덱스	clustered (PK = data)	heap + index
확장성 (extension)	적음	매우 많음
JSON 인덱싱	OK	JSONB + GIN 우수
복제	binlog 기반	streaming WAL
트랜잭션 DDL	옛 버전 X (8.0+ 부분)	대부분 트랜잭션
운영 도구	percona, mysql workbench	psql + 풍부한 ecosystem
라이센스	GPL (commercial 도)	PostgreSQL License

흔한 함정

[!WARNING]

PK = UUID v4 = clustered index random write → 페이지 분할 폭증. ULID / 정렬 가능 UUID 또는 BIGINT.

SELECT * 의 MVCC 비용 = old version chain 따라가기. unused 컬럼 안 가져오기.

deadlock 무시 = SHOW ENGINE INNODB STATUS 의 LATEST DEADLOCK 모니터링.

binlog format 이 STATEMENT = 비결정적 함수 (NOW(), UUID()) → replica 와 다른 결과. ROW 또는 MIXED 권장.

[DB] PostgreSQL: 프로세스 모델, MVCC, WAL, 확장성

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

PostgreSQL 은 오픈소스 ORDBMS. 1986 UC Berkeley POSTGRES 의 후예. MVCC, 확장 가능 타입, JSONB, full-text search, GIS (PostGIS), 벡터 (pgvector) 등 무거운 데이터 시스템 의 표준.

프로세스 모델

flowchart TB
    Postmaster[postmaster<br/>master process] --> BG[Background workers]
    BG --> WAL_W[WAL writer]
    BG --> BG_W[Background writer]
    BG --> Checkpointer[Checkpointer]
    BG --> Autovacuum[Autovacuum launcher]
    BG --> Stats[Stats collector]
    Postmaster -->|fork| C1["Backend 1<br/>(connection)"]
    Postmaster -->|fork| C2[Backend 2]
    Postmaster -->|fork| C3[Backend N]

[!IMPORTANT] 프로세스 per connection. 1000 연결 = 1000 OS 프로세스. connection pool (PgBouncer) 가 거의 필수.

MVCC + VACUUM

자세한 건 [[mvcc]] 참고. PostgreSQL 의 dead tuple 누적 → VACUUM 으로 회수.

flowchart LR
    Update[UPDATE 한 행] --> NewVer[새 버전 tuple]
    Update --> DeadVer["옛 버전 tuple<br/>(dead)"]
    Auto[autovacuum<br/>주기적 실행] --> DeadVer
    Auto -->|회수| Space[빈 공간]

VACUUM 종류	동작
`VACUUM`	dead tuple 표시, 공간 회수
`VACUUM ANALYZE`	+ 통계 갱신
`VACUUM FULL`	table rewrite. LOCK 필요. 운영 중 금지
autovacuum	자동

[!CAUTION] autovacuum 이 따라잡지 못하면 pg_stat_user_tables.n_dead_tup 증가 → 쿼리 느려짐 + transaction ID wrap-around 위험.

WAL (Write-Ahead Log)

sequenceDiagram
    Client->>Backend: UPDATE ...
    Backend->>WAL: write log record
    Backend->>SharedBuffer: page dirty
    Backend-->>Client: COMMIT OK
    Note over Backend: WAL fsync 후 commit
    Checkpointer->>Disk: dirty page → 데이터 파일

COMMIT = WAL fsync 면 OK. 데이터 파일은 나중에 checkpoint 시.
crash recovery = WAL replay.
replication 도 WAL streaming.

TOAST (큰 컬럼 압축)

The Oversized-Attribute Storage Technique

row size > 2KB 이면:
1. 압축 (LZ4 / pglz)
2. 그래도 크면 → toast 테이블에 *분할 저장*

대용량 텍스트 / JSONB / bytea 가 자동 처리. 사용자 코드 불필요.

핵심 도구

도구	의미
`psql`	CLI
`pg_dump` / `pg_restore`	백업
`pg_basebackup`	physical 백업
`pg_rewind`	replica → primary 빠른 동기화
`pgbench`	벤치마크
`EXPLAIN`	쿼리 plan
`pg_stat_*`	통계 view

EXPLAIN ANALYZE

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM users WHERE email = 'koa@x.com';

자세한 건 [[query-explain-plan]] 참고.

인덱스 종류

인덱스	용도
B-tree	일반 (default)
Hash	등가 검색만
GIN	다값 (배열, JSONB, full-text)
GiST	공간, 범위
SP-GiST	공간 partitioning
BRIN	큰 시계열 (작은 인덱스)
Bloom	다컬럼 (확률적)

자세한 건 [[gin-gist-hash-indexes]] 참고.

확장 (Extension)

CREATE EXTENSION postgis;      -- 공간
CREATE EXTENSION pgvector;     -- 벡터
CREATE EXTENSION pg_stat_statements;  -- 쿼리 통계
CREATE EXTENSION pg_trgm;      -- 트라이그램 (LIKE 최적화)
CREATE EXTENSION timescaledb;  -- 시계열

PostgreSQL 의 최대 강점. 코어를 확장 으로 거대화.

흔한 함정

[!WARNING]

SELECT * + 인덱스 only scan 기대 = TOAST 컬럼 있으면 table fetch 강제. 필요 컬럼만.

너무 많은 인덱스 = INSERT/UPDATE 느려짐. 사용 안 되는 인덱스 pg_stat_user_indexes.idx_scan = 0 으로 식별.

pg_dump 의 논리 백업 만 의존 = 대용량은 시간 폭증. pg_basebackup + WAL archive 가 정통.

autovacuum disable = transaction ID wrap-around → DB 정지. 절대 끄지 말 것.

[DB] Sharding vs Partitioning: 수평 확장의 두 얼굴

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

	Partitioning	Sharding
범위	한 DB 안	여러 DB 노드
목적	큰 테이블 관리	수평 확장 (write/storage)
투명성	DB 가 처리	보통 애플리케이션 인지
예	PostgreSQL `PARTITION BY`	Citus, Vitess, MongoDB

둘 다 “데이터를 여러 조각으로 나눈다”. 경계 가 DB 노드 안인지 밖인지 차이.

Partitioning (한 DB 안)

-- PostgreSQL: 시간 기준 range partition
CREATE TABLE events (
  id BIGSERIAL,
  created_at TIMESTAMPTZ,
  body JSONB
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2026_06 PARTITION OF events
  FOR VALUES FROM ('2026-06-01') TO ('2026-07-01');

CREATE TABLE events_2026_07 PARTITION OF events
  FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');

종류	의미
Range	시간, 숫자 범위
List	미리 정한 값 (region 등)
Hash	해시 (균등 분포)

장점:

큰 테이블 → 작은 partition (VACUUM, index 작음)
오래된 partition drop = 빠른 보관 정리
partition pruning = WHERE 조건이 partition 키면 그것만 스캔

Sharding (여러 DB 노드)

flowchart TB
    Client --> Router[Router / Coordinator]
    Router -->|shard_key % N| S1[(Shard 1)]
    Router -->|shard_key % N| S2[(Shard 2)]
    Router -->|shard_key % N| S3[(Shard 3)]

Shard Key 선택

키 선택	결과
`user_id` hash	고른 분포, 한 user 가 한 shard
`created_at` range	hot shard (최근만 트래픽)
`tenant_id`	멀티 테넌트. 큰 테넌트 = hot
`geographic`	data residency

[!IMPORTANT] Shard key 는 바꾸기 어렵다. 모든 query 가 shard key 포함 가능한지 먼저 검토.

Consistent Hashing

자세한 건 [[Load Balancer]] 의 consistent hashing 절.

flowchart LR
    Ring((Hash Ring)) --> N1[Node A]
    Ring --> N2[Node B]
    Ring --> N3[Node C]
    Key1["hash(user:42)"] -->|시계방향| N2

노드 추가/제거 시 N/M 만 재분배. Cassandra, DynamoDB, Redis Cluster 의 토대.

Cross-shard Query 의 비용

sequenceDiagram
    Client->>Router: SELECT count(*) FROM users
    par fan-out
        Router->>S1: SELECT count(*)
        Router->>S2: SELECT count(*)
        Router->>S3: SELECT count(*)
    end
    S1-->>Router: 1234
    S2-->>Router: 1567
    S3-->>Router: 1198
    Router->>Router: SUM
    Router-->>Client: 3999

쿼리	비용
`WHERE shard_key = X`	1 shard
`WHERE shard_key IN (X, Y)`	2 shard
`WHERE other_field = ...`	전 shard fan-out
`JOIN` cross-shard	매우 비쌈 (피하기)
`GROUP BY` cross-shard	router 가 merge

[!CAUTION] 대부분 쿼리가 shard key 포함 안 됨 = 디자인 실패. shard key 결정 전에 access pattern 정의.

Vitess (MySQL sharding) 아키텍처

flowchart TB
    App[App] --> VTGate["VTGate (router)"]
    VTGate --> VTTablet1[VTTablet 1]
    VTTablet1 --> MySQL1[(MySQL)]
    VTGate --> VTTablet2[VTTablet 2]
    VTTablet2 --> MySQL2[(MySQL)]
    VTGate --> Topo["Topology Service<br/>(etcd / Zookeeper)"]

YouTube 가 만들고 기여.
MySQL 호환 (Vitess client 가 MySQL 프로토콜).
re-sharding 자동화.

Citus (PostgreSQL extension)

SELECT create_distributed_table('events', 'user_id');
SELECT create_reference_table('countries');   -- 모든 노드 복제

PostgreSQL 의 extension 으로 동작.
PG 의 모든 기능 + sharding.
Microsoft Azure Cosmos DB for PostgreSQL 이 기반.

다른 sharding 전략

전략	의미
Hash-based	hash(key) % N. 균등하지만 N 변경 어려움
Range-based	키 범위. hot shard 위험
Directory-based	lookup table. 유연 + 단일 장애
Consistent hash	hash ring. N 변경 friendly

Re-sharding

shard 추가/제거 시 데이터 이동. 가장 어려운 운영.

flowchart LR
    Old[기존 3 shard] -->|N=4 추가| Migrate[데이터 이동]
    Migrate --> New[4 shard 분배]
    Note["traffic 처리 *지속* 가운데<br/>일관성 유지 어려움"] -.-> Migrate

온라인 re-sharding 은 몇 주 ~ 몇 달 운영.
Vitess, Citus, MongoDB 가 자동 도구 제공.
수동 sharding (애플리케이션 레벨) 은 매우 고통.

흔한 함정

[!WARNING]

Sharding 너무 일찍 = 운영 비용 폭증. 수직 확장 + replica 가 수십 TB 까지 가능.

Cross-shard transaction = 2PC 또는 saga 필요. 비용 큼.

Hot shard 무시 = 한 노드만 100% CPU. shard key 재선택 필요.

Partition pruning 작동 안 함 = partition key 가 WHERE 에 없으면 모든 partition 스캔.

[DB] SQLite: 단일 파일, WAL 모드, edge / mobile

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

SQLite 는 세계에서 가장 많이 배포된 DB (모든 스마트폰, 브라우저, OS). 서버 없이 라이브러리, 단일 파일, zero-config. embedded + edge 의 표준.

핵심 특성

항목	SQLite
구조	단일 파일 (`.db`)
프로세스	없음 (앱 안 라이브러리)
동시성	동시 reader 다수, writer 1개
트랜잭션	ACID
크기	라이브러리 ~600KB
SQL 표준	부분 (SQL-92 의 일부)
Type	dynamic typing (TYPE AFFINITY)

Journal Mode

flowchart LR
    Q{journal_mode}
    Q --> DELETE["DELETE (기본)<br/>rollback journal 사용"]
    Q --> WAL["WAL (권장)<br/>write-ahead log"]
    Q --> MEMORY["MEMORY<br/>rollback 메모리"]
    Q --> OFF["OFF<br/>crash 위험"]

WAL 모드 (운영 권장)

PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;

모드	reader vs writer	동시성
DELETE (기본)	writer 가 reader 막음	낮음
WAL	분리. reader 가 옛 snapshot 봄	높음

[!IMPORTANT] 프로덕션 SQLite 는 거의 항상 WAL. 동시 reader 폭증.

적합한 사용처

flowchart TD
    Q{환경}
    Q --> A[모바일 / 데스크톱 앱]
    Q --> B[Edge / Serverless]
    Q --> C[테스트 DB]
    Q --> D["작은 웹 사이트<br/>(write 적음)"]
    Q --> E[설정 / 캐시 파일]
    Q --> F[Local-first 앱]

부적합:

write throughput 큰 멀티 노드
cross-server 트랜잭션 필요

옛 평가와 현재 (2026)

“SQLite 는 장난감” 은 수년 전 평가.

옛 주장	현재 (2026)
writer 1개	1 writer * 분 단위 1만 commit. 대부분 충분
백업 어려움	Litestream, LiteFS, Turso 가 실시간 streaming
분산 안 됨	Turso (libSQL), Cloudflare D1 = edge 분산
큰 쿼리 느림	인덱스 잘 박으면 PostgreSQL 비교 가능

Litestream / LiteFS

flowchart LR
    App[App] --> SQLite[(local SQLite)]
    SQLite -->|WAL stream| Litestream[Litestream]
    Litestream --> S3[(S3 / R2)]
    Replica[다른 노드] -.replicate.-> S3

실시간 streaming 백업 (1초 지연).
S3, GCS, ABS, R2 어디든.
마치 Postgres WAL streaming 처럼.

libSQL / Turso

libSQL = SQLite fork. async/await, embedded replica, vector search.
Turso = libSQL 의 서버리스 클라우드.
2026 시점 edge DB 의 표준 으로 빠르게 성장.

동시성: BEGIN IMMEDIATE

-- 기본 (DEFERRED): 첫 write 명령 시 lock 시도 → SQLITE_BUSY 위험
BEGIN;
SELECT ...;  -- shared lock
UPDATE ...;  -- exclusive lock 시도 → 다른 writer 와 충돌 가능
COMMIT;

-- IMMEDIATE: 시작 시 이미 write lock
BEGIN IMMEDIATE;
SELECT ...;
UPDATE ...;
COMMIT;

[!TIP] write 가 섞인 트랜잭션 은 BEGIN IMMEDIATE 가 정통. SQLITE_BUSY 폭증을 막는다.

Type Affinity (NUMERIC, INTEGER, REAL, TEXT, BLOB)

-- SQLite 는 *dynamic typing*. 컬럼 타입은 *affinity hint*.
CREATE TABLE t (id INTEGER, name TEXT);
INSERT INTO t VALUES ('not number', 42);   -- 동작! (strict 모드 끄면)

-- 3.37+ STRICT 모드
CREATE TABLE t (id INTEGER, name TEXT) STRICT;
INSERT INTO t VALUES ('not number', 42);   -- 에러

[!CAUTION] Production 은 STRICT 모드 권장. 옛 SQLite 코드는 implicit conversion 으로 조용한 버그.

흔한 함정

[!WARNING]

WAL 모드 안 켬 = writer 가 reader 막음. 첫 운영 사고.

PRAGMA synchronous=OFF = crash 시 DB 손상 가능. NORMAL 이 권장 (성능 + 안전 균형).

여러 프로세스가 같은 파일 = NFS / 네트워크 파일시스템 위에서 lock 실패. 로컬 디스크 필수.

백업이 cp file.db = 진행 중 쿼리 때문에 손상. sqlite3 .backup 또는 Litestream.

[DB] WAL: Write-Ahead Log, crash recovery, replication 의 토대

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Write-Ahead Log (WAL) = 데이터 변경 전 로그를 먼저 디스크에 기록. 모든 모던 RDB / KV / 분산 시스템의 내구성 기반.

핵심 약속: 로그가 디스크에 있으면 → 데이터도 복구 가능.

왜 WAL?

flowchart LR
    Op[UPDATE row] --> Decide{쓰는 순서}
    Decide -->|"WAL first"| Safe[안전: crash 시 replay]
    Decide -->|"Data first"| Unsafe[위험: 부분 쓰기 후 crash → 불일치]

데이터 페이지를 디스크에 쓰는 건 비쌈. 로그는 sequential append 라 빠름. commit = 로그 fsync 만 보장하면 crash 후에도 복구 가능.

일반 흐름

sequenceDiagram
    autonumber
    participant C as Client
    participant App as DB Process
    participant WAL as WAL Buffer
    participant Disk as Disk
    participant Page as Page Buffer

    C->>App: UPDATE x SET v = 42
    App->>WAL: 로그 record append
    App->>Page: page in memory 변경 (dirty)
    Note over App: COMMIT 요청
    App->>WAL: fsync WAL
    Disk-->>App: ack
    App-->>C: COMMIT OK
    Note over App: 백그라운드에서<br/>checkpointer 가 dirty page → disk
    Page-.->Disk: 나중에 flush

Crash Recovery (ARIES 기반)

flowchart TB
    Crash[Crash 발생] --> Analyze[Analysis<br/>마지막 checkpoint 이후 로그 스캔]
    Analyze --> Redo[Redo<br/>committed 트랜잭션 적용]
    Redo --> Undo[Undo<br/>uncommitted 트랜잭션 롤백]
    Undo --> Ready[(서비스 가능)]

단계	의미
Analysis	마지막 checkpoint 이후의 로그 스캔. 트랜잭션 상태 복원
Redo	committed 트랜잭션의 변경 재적용
Undo	uncommitted 트랜잭션 롤백

[!IMPORTANT] 모든 modern DB 가 ARIES 또는 변형. 최초 commit 후 즉시 fsync 가 D (Durability) 의 정의.

Checkpoint

sequenceDiagram
    Checkpointer->>BufferPool: 모든 dirty page 식별
    loop dirty pages
        Checkpointer->>Disk: flush dirty page
    end
    Checkpointer->>WAL: checkpoint record 기록
    Note over WAL: checkpoint 이전 WAL 회수 가능

checkpoint = recovery 시작점. 자주 하면 recovery 빠름 + I/O 부담. 드물게 하면 I/O 적음 + recovery 길음.

fsync 의 비용과 group commit

sequenceDiagram
    T1->>DB: COMMIT
    T2->>DB: COMMIT
    T3->>DB: COMMIT
    DB->>DB: WAL buffer 모음
    DB->>Disk: 한 번의 fsync (3 트랜잭션 동시)
    DB-->>T1: OK
    DB-->>T2: OK
    DB-->>T3: OK

Group commit: 동시 commit 들을 한 fsync 로 묶음. throughput 큰 향상.

정책	의미	손실
`fsync = on`	매 commit fsync	0
`synchronous_commit = off`	WAL 버퍼만, fsync 지연	~수 ms
`fsync = off`	fsync 안함	crash 시 손실 가능

[!CAUTION] fsync = off 는 벤치마크 외 절대 금지. crash 시 DB 복구 불가 가능.

WAL → Replication

flowchart LR
    Primary --> WAL[(WAL)]
    WAL -->|streaming| R1[Replica 1]
    WAL -->|streaming| R2[Replica 2]
    WAL -->|archive| Archive[(S3 archive)]
    Archive -->|PITR| Restore[Point-in-Time Recovery]

Physical replication: WAL 그대로 전송
Logical replication: 행 단위 변경 (필터링 / 변환 가능)
Point-in-Time Recovery: archive + WAL = 임의 시점 복원

자세한 건 [[postgresql]] / [[mysql-innodb]] / [[Redis Replication]].

WAL 의 형태별 비교

DB	WAL 이름	비고
PostgreSQL	WAL	physical + logical
MySQL InnoDB	redo log + undo log + binlog	3 종 분리
SQLite	journal / WAL mode	journal_mode=WAL
Redis	AOF	옵션
LMDB	(copy-on-write, no WAL)	다른 모델
RocksDB	WAL	LSM-tree
etcd / CockroachDB	Raft log	consensus + WAL

fsync 만 = 안전?

flowchart LR
    App[App] -->|write| OS[OS Page Cache]
    OS -->|fsync| Disk[Disk Cache]
    Disk -->|Battery / FUA| Platter[Persistent]

Disk cache 까지가 전제. power loss 시 disk cache 손실 → battery-backed cache 또는 SSD 의 power-loss-protection (PLP) 필요.

흔한 함정

[!WARNING]

fsync 안 함 + 빠르다고 자랑 = 사실 D 가 사라진 상태. 벤치마크 무의미.

WAL archive 보관 부족 = PITR 시 복원 시점 없음. 최소 3-7일 보관.

Checkpoint 너무 자주 = I/O spike. PG checkpoint_timeout, max_wal_size 튜닝.

Group commit 안 켬 (MySQL) = throughput 1/N. innodb_flush_log_at_trx_commit + binlog group commit.

[PostgreSQL] JSONB: 장점과 단점, 인덱싱, 사용 패턴

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

JSONB (Binary JSON, PG 9.4+) = PostgreSQL 의 binary 직렬화된 JSON. 인덱싱 가능 + 빠른 query 가 json 과의 핵심 차이.

[!IMPORTANT] 2026 시점 PostgreSQL 에서 schema-less + 관계형 결합 의 표준. MongoDB 대안 + NoSQL/SQL 혼합 의 답.

json vs jsonb

	`json`	`jsonb`
저장	텍스트 그대로	binary parsed
입력 속도	빠름	느림 (parse 비용)
Query 속도	매번 parse	빠름
인덱싱	제한	GIN 가능
Key 순서	보존	손실
Whitespace	보존	손실
중복 key	모두 보존	마지막만

거의 항상 jsonb. json 은 원본 형식 보존 필요 (서명, 감사) 시만.

장점

flowchart TB
    Pro[JSONB 장점]
    Pro --> S[Schemaless flexibility]
    Pro --> I[GIN 인덱스로 빠른 검색]
    Pro --> O[관계형 + 문서형 혼합]
    Pro --> T[트랜잭션 + ACID]
    Pro --> F[다양한 연산자 / 함수]

1. Schemaless 유연성

CREATE TABLE events (
  id BIGSERIAL PRIMARY KEY,
  event_type TEXT,
  payload JSONB,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

INSERT INTO events (event_type, payload) VALUES
  ('click', '{"user_id": 42, "page": "/home", "duration": 1500}'),
  ('purchase', '{"user_id": 42, "product_id": 99, "amount": 50000, "items": [{"sku": "A"}, {"sku": "B"}]}'),
  ('error', '{"code": 500, "stack": "...", "context": {"db": "down"}}');

2. GIN 인덱스 + 풍부한 query

-- 인덱스 (전체 JSONB)
CREATE INDEX idx_payload_gin ON events USING gin(payload);

-- jsonb_path_ops: @> 만 빠르게 (더 작은 인덱스)
CREATE INDEX idx_payload_path ON events USING gin(payload jsonb_path_ops);

-- 특정 키만
CREATE INDEX idx_user_id ON events ((payload->>'user_id'));

자세한 인덱스 비교는 [[gin-gist-hash-indexes]].

3. 풍부한 연산자

-- containment (@>)
SELECT * FROM events WHERE payload @> '{"user_id": 42}';
SELECT * FROM events WHERE payload @> '{"items": [{"sku": "A"}]}';

-- key 존재 (?)
SELECT * FROM events WHERE payload ? 'error_code';

-- key 다수 (?| 또는 ?&)
SELECT * FROM events WHERE payload ?| array['error_code', 'warning_code'];

-- 경로 추출
SELECT payload->>'user_id' AS uid, payload->'items'->0->>'sku' FROM events;

-- JSONPath (PG 12+)
SELECT * FROM events WHERE payload @? '$.items[*].sku ? (@ == "A")';

-- 갱신
UPDATE events SET payload = payload || '{"processed": true}' WHERE id = 1;
UPDATE events SET payload = jsonb_set(payload, '{user_id}', '99') WHERE id = 1;
UPDATE events SET payload = payload - 'temp_field' WHERE id = 1;

4. 트랜잭션 + ACID

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET metadata = jsonb_set(metadata, '{last_transfer}', '"2026-06-25"') WHERE id = 1;
COMMIT;

MongoDB 에서는 문서 안 트랜잭션 OK, 컬렉션 간 은 느림. PostgreSQL = 어디든 ACID.

단점

flowchart TB
    Con[JSONB 단점]
    Con --> Size[저장 크기 큼]
    Con --> NoSchema[스키마 검증 부재]
    Con --> Slower[관계형 비교 느림]
    Con --> Update[부분 update 비효율]
    Con --> Type[타입 변환 비용]

1. 저장 크기

CREATE TABLE t1 (
  a INT, b INT, c TEXT
);
INSERT INTO t1 VALUES (1, 2, 'hello');
-- row size: ~40 bytes

CREATE TABLE t2 (
  data JSONB
);
INSERT INTO t2 VALUES ('{"a": 1, "b": 2, "c": "hello"}');
-- row size: ~80 bytes (key 이름이 반복 저장)

JSONB 는 key 이름이 매 row 마다 반복. 1억 row * 50 byte key 이름 = 5GB 낭비.

2. 스키마 검증 없음

INSERT INTO events VALUES (..., '{"user_id": "not-a-number"}');
-- 통과! (string 도 OK)

-- 컬럼 분리면
INSERT INTO events VALUES (..., 'not-a-number');
-- 에러

typo, 잘못된 타입 silent 통과. 운영 사고 단골.

3. 부분 update 의 비효율

-- 작은 변경도 *전체 row 재작성* (MVCC)
UPDATE events SET payload = jsonb_set(payload, '{processed}', 'true') WHERE id = 1;
-- → 옛 row 삭제 마크 + 새 row 작성. 큰 JSONB 일수록 비쌈.

자세한 MVCC 는 [[mvcc]].

4. JOIN 비효율

-- payload->>'user_id' 로 join 하면 *인덱스 활용 어려움*
SELECT u.name FROM events e JOIN users u ON u.id::text = e.payload->>'user_id';
-- → 매 row JSON path 추출 + 타입 cast

자주 JOIN 하는 필드는 별도 컬럼 으로 분리.

사용 패턴 (좋은 vs 나쁜)

✓ 좋은 사용

-- 이벤트 / 로그 / 감사
events (event_type TEXT, payload JSONB)

-- 동적 스키마 (사용자 정의 필드)
form_responses (form_id INT, answers JSONB)

-- 외부 API 응답 캐시
api_cache (endpoint TEXT, response JSONB, expires_at TIMESTAMPTZ)

-- 자주 안 변하는 metadata
products (id INT, sku TEXT, metadata JSONB)

✗ 나쁜 사용

-- 자주 조회 + 매번 같은 필드만
users (id INT, profile JSONB)
-- → name, email 등을 *컬럼으로* 분리해야 함

-- 자주 update
counters (id INT, data JSONB /* { "count": 100 } */)
-- → INT 컬럼이 *수십배 빠름*

-- JOIN 자주
orders (id INT, user_data JSONB /* { "user_id": ... } */)
-- → user_id 별도 컬럼 + FK

인덱스 전략

패턴	인덱스
`payload @> '{...}'`	`gin(payload jsonb_path_ops)` (작고 빠름)
`payload ? 'key'`	`gin(payload)`
`payload->>'user_id' = '42'`	`((payload->>'user_id'))`
`(payload->>'user_id')::int > 1000`	`(((payload->>'user_id')::int))`
자주 쓰는 필드	별도 컬럼 + 일반 인덱스

Hybrid 패턴 (권장)

CREATE TABLE events (
  id BIGSERIAL PRIMARY KEY,
  event_type TEXT NOT NULL,
  user_id BIGINT NOT NULL,        -- 자주 JOIN/검색 → 별도 컬럼
  created_at TIMESTAMPTZ NOT NULL,
  payload JSONB                    -- 나머지 schemaless
);

CREATE INDEX idx_user_created ON events (user_id, created_at);
CREATE INDEX idx_event_type ON events (event_type);
CREATE INDEX idx_payload ON events USING gin(payload jsonb_path_ops);

자주 쓰는 = 컬럼, 나머지 = JSONB. 양쪽 장점.

JSONB vs MongoDB

	PG JSONB	MongoDB
ACID	Yes	문서 단위
JOIN	Yes	$lookup (느림)
Schema	옵션	flexible
Indexing	GIN + B-tree	다양
Aggregation	SQL + JSONB	aggregation pipeline
Scale	큰 단일 + read replica	sharded native

관계형 + 문서 혼합 + <1TB = PG JSONB. 수십 TB 분산 = MongoDB.

흔한 함정

[!WARNING]

모든 데이터 JSONB = JOIN 폭증 + 인덱스 폭증. 자주 쓰는 건 컬럼.

GIN 인덱스 빌드 시간 = 큰 테이블 30분-수 시간. CONCURRENTLY 옵션 + 운영 시간.

jsonb_set 의 NULL = jsonb_set(payload, '{a}', null::jsonb) 가 key 자체 삭제 안 함. payload - 'a' 사용.

숫자 key 검색의 타입 = payload->>'id' = '42' (text). (payload->>'id')::int = 42 (cast).

[Redis] Bloom / Cuckoo / CMS / TopK: 확률 자료구조

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

확률 자료구조 (Probabilistic Data Structures) 는 작은 메모리 로 대규모 데이터의 통계적 답 을 제어된 오차 로 내는 자료구조군. Redis 는 Bloom 모듈 (Redis 8 부터 코어) 로 Bloom Filter / Cuckoo Filter / Count-Min Sketch / TopK / t-digest 를 제공한다.

자료구조	답하는 질문	대표 사용처
Bloom Filter	”이 멤버를 본 적 있나?” (yes/no, false positive 가능)	캐시 미스 차단, 중복 URL 필터
Cuckoo Filter	위와 같지만 삭제 가능	동적 멤버십
Count-Min Sketch	”이 멤버의 빈도?” (overcount 가능)	트래픽 통계, 광고 노출
TopK	”가장 자주 나오는 K 개”	핫 키, 인기 검색어
t-digest	”p99, p95, 분위수”	latency 분포

[!IMPORTANT] 이들의 공통점: *고정 또는 거의 고정 메모리 로 멤버 수가 무한히 늘어도 안정적인 답. Set / Hash 같은 정확한 자료구조 가 불가능한 크기 에서 빛난다.

Bloom Filter

동작 원리

flowchart LR
    Item["item: 'user:42'"] --> H["k개 hash 함수"]
    H -->|h1| B1["bit 7"]
    H -->|h2| B2["bit 31"]
    H -->|h3| B3["bit 64"]
    B1 & B2 & B3 -->|모두 set| BloomBits[("Bloom 비트 배열")]
    Query["query: 'user:99'"] --> H2["같은 k개 hash"]
    H2 -->|h1| Q1["bit 12"]
    H2 -->|h2| Q2["bit 64"]
    H2 -->|h3| Q3["bit 100"]
    Q1 & Q2 & Q3 -->|모두 1?| Check{"있다고 답<br/>(false positive 가능)"}

추가 (BF.ADD): k 개 hash 의 비트 를 1 로
존재 확인 (BF.EXISTS): k 개 hash 의 비트 모두 1 이면 있다 (단, false positive 있음)
삭제: 불가능 (다른 멤버의 비트와 겹치면 누구 비트인지 모름)

명령

# 자동 reserve (기본 capacity 100, error 0.01)
BF.ADD urls https://example.com
BF.EXISTS urls https://example.com         # 1
BF.EXISTS urls https://other.com           # 0 또는 1 (false positive)

# 명시 reserve (capacity 1M, error 0.001)
BF.RESERVE urls 0.001 1000000
BF.ADD urls https://example.com
BF.MADD urls url1 url2 url3                # 배치
BF.MEXISTS urls url1 url2 url3

# 정보
BF.INFO urls

메모리 vs 오차율

[!NOTE] 1M 멤버에 오차율 0.001 (0.1%) ≈ 1.8 MB. Set 으로 1M URL (각 50B) 저장하면 50 MB+. 25배 효율.

활용 패턴

1. 캐시 stampede 방지

# DB 에 없는 키를 자주 미스 → DB 부담
# Bloom 으로 *DB 에 있는 키 집합* 추적
if r.bfExists("known_users", user_id):
    # DB 조회 (있을 *확률* 높음)
    return db.query(user_id)
return None    # Bloom 이 false 면 *100% 없음* 보장

[!TIP] Bloom 의 false negative 는 절대 없다. false positive 만 있다. 따라서 “없다고 한 건 100% 없다” 는 강한 보장. 이것이 negative cache 와 다른 점.

2. 중복 URL / 중복 ID 차단

BF.RESERVE seen_urls 0.0001 100000000
# 크롤러: 새 URL 인지 확인
BF.ADD seen_urls $url           # 추가 + 추가 전 false 였는지 반환

3. 보안: 알려진 악성 IP / 토큰 차단

BF.RESERVE bad_ips 0.001 10000000
# 차단 목록 1000만개에서 *직접 메모리 1.8 MB*

Cuckoo Filter (Bloom 의 후계자)

Bloom 의 단점 (삭제 불가) 을 해결. 추가 / 삭제 / 존재 확인 모두 가능. false positive 는 더 낮은 경향.

CF.RESERVE seen 100000
CF.ADD seen item1
CF.EXISTS seen item1            # 1
CF.DEL seen item1               # 삭제 가능!
CF.EXISTS seen item1            # 0

Bloom vs Cuckoo 비교

항목	Bloom	Cuckoo
추가 / 조회	O(k)	O(1) (대부분)
삭제	불가	가능
채우기 임계	75% 부근부터 false positive 증가	90%+ 채워도 잘 동작
메모리 (같은 오차율)	보통 Cuckoo 가 약간 효율
멤버 수 추정	어려움	부정확하지만 가능

[!IMPORTANT] 동적 멤버십 (추가 + 삭제 모두) 이면 Cuckoo. 추가만 이면 Bloom (더 단순, 더 안정).

Count-Min Sketch (CMS): 빈도 추정

“이 키의 빈도가 몇 번?” 에 대한 overcount 가능한 추정. d × w 의 2D 카운터 배열 에 d 개 hash 함수 로 모든 hash 행 의 min 을 답으로.

동작

flowchart LR
    Item["item: 'url:a'"] --> H["d개 hash"]
    H -->|h1| C1["row 1 col 12 +1"]
    H -->|h2| C2["row 2 col 33 +1"]
    H -->|h3| C3["row 3 col 7 +1"]
    H -->|h4| C4["row 4 col 88 +1"]
    Query["count('url:a')"] --> H2["같은 4개 hash"]
    H2 --> Cells["같은 4 cell 값"]
    Cells -->|min| Estimate["frequency 추정"]

overcount 가능 (다른 멤버와 충돌하면 위로 셈), undercount 없음. min 이 진짜 빈도 ≤ 답.

명령

# 폭과 깊이로 초기화
CMS.INITBYDIM trafic 2000 5
# 또는 오차/확률로
CMS.INITBYPROB traffic 0.001 0.01

CMS.INCRBY traffic url:a 1 url:b 5
CMS.QUERY traffic url:a url:b              # [1, 5]
CMS.MERGE total 3 traffic1 traffic2 traffic3 WEIGHTS 1 1 1

활용

트래픽 빈도 통계: API endpoint 호출 빈도
광고 노출 카운터: ad → 노출 횟수
DDoS 탐지: IP → 요청 빈도
인기 상품 추정: product → 조회 빈도

[!NOTE] 정확한 빈도 가 필요하면 Hash + HINCRBY. 수십억 키의 빈도 통계 같이 Hash 가 메모리 부담 일 때 CMS.

TopK: 인기 K 개 추정

streaming 데이터에서 Top K 를 작은 메모리 로. Heavy Keepers 알고리즘 기반.

명령

TOPK.RESERVE hot_urls 10 1000 5 0.9        # k=10, width=1000, depth=5, decay=0.9
TOPK.ADD hot_urls url1 url2 url3
TOPK.INCRBY hot_urls url1 5

TOPK.LIST hot_urls                          # 현재 top-K
TOPK.LIST hot_urls WITHCOUNT                # 빈도 포함
TOPK.QUERY hot_urls url1 url2               # top-K 안에 있는지
TOPK.COUNT hot_urls url1                    # 추정 빈도

활용

인기 검색어 실시간: 검색 query 스트림 → TopK 100
핫 키 탐지: cache key 접근 빈도 → 가장 자주 쓰이는 100개
트렌딩 해시태그: 최근 N분 윈도우의 TopK
DDoS attacker top-K: 의심 IP 우선순위

[!TIP] 정확한 Top-K 가 필요하면 Sorted Set 의 ZRANGE. 수십억 unique 가 들어오는 streaming 에서 고정 메모리 안 에 끝내려면 TopK.

자료구조별 메모리 비교

같은 1억 unique 멤버 추적할 때:

결정 매트릭스

flowchart TD
    Q1{필요한 답?}
    Q1 -->|존재 여부| Q2{삭제도 필요?}
    Q2 -->|예| CF[Cuckoo Filter]
    Q2 -->|아니오| BF[Bloom Filter]
    Q1 -->|cardinality 만| HLL[HyperLogLog]
    Q1 -->|개별 빈도| CMS[Count-Min Sketch]
    Q1 -->|Top K 인기| TK[TopK]
    Q1 -->|분위수 p95/p99| TD[t-digest]

흔한 함정

[!WARNING]

Bloom 의 false negative 가 없다는 보장 을 false positive 가 없다고 오해 = 없다 라고 한 건 100% 없음. 있다 라고 한 건 확률적.

CMS 의 overcount 를 실제 빈도 로 사용 = 항상 추정 ≥ 진짜. 비교 / 상위 K 같은 순위 용도로만 신뢰.

고정 capacity Bloom 의 over-fill = capacity 를 넘기면 false positive rate 가 급격 악화. 주기적 reset + 새 키 또는 scaling Bloom 사용.

확률 자료구조의 합집합 = HLL PFMERGE 와 CMS CMS.MERGE 가능. Bloom 은 비트 OR 로 가능 (낯설지만 동작).

김신건의 현장 메모

역량 리포트 의 학생 활동 통계 같은 방대한 streaming 통계 에서 Hash + HINCRBY 가 너무 무거우면 CMS + 정확한 TopK 만 Sorted Set 의 하이브리드 가 메모리 / 정확도 균형.
Bloom 으로 cache miss 차단 은 Hot Path 의 가장 가벼운 가속. 없는 키를 매번 DB 조회 하는 비용이 Bloom 메모리보다 압도적으로 큼.
TopK 의 decay 파라미터 (0.9) 가 최근 트래픽 가중치. 너무 작으면 (0.5) 옛 데이터 무시, 너무 크면 (0.99) 변화 느림. 대시보드 갱신 주기에 맞춰 튜닝.
Redis 8 의 코어 통합 으로 별도 모듈 설치 없이 사용. 프로덕션 도입 진입 장벽 이 대폭 낮아짐.

참고

공식: Probabilistic Data Types
Bloom 원논문: Burton Bloom, 1970
Cuckoo Filter: Fan et al.
CMS: Cormode & Muthukrishnan

[Redis] Cache Patterns: Cache-Aside, Stampede, Eviction

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Cache Pattern 은 Redis (또는 다른 캐시) 를 어떤 경로로 읽고 쓰는지 의 디자인 결정. 같은 인프라로도 패턴 선택에 따라 일관성 / 지연 / 부하 가 완전히 달라진다.

가장 흔한 다섯 가지:

Cache-aside (look-aside): 애플리케이션이 캐시를 직접 본다. miss 면 DB 로 가서 직접 캐시에 채운다.
Read-through: 캐시 라이브러리 가 miss 시 자동 으로 backing store 를 조회.
Write-through: write 시 캐시 + DB 동시 갱신. 일관성 ↑.
Write-behind / Write-back: 캐시 먼저 쓰고 비동기 로 DB 반영. 쓰기 빠름, 손실 위험.
Refresh-ahead: TTL 만료 직전 에 백그라운드 refresh. miss 자체를 줄임.

Cache Hit / Miss 의 시각

행복 경로 (HIT):

{}

캐시 채우는 경로 (MISS → DB → set):

{}

[!NOTE] 위 두 애니메이션은 왼쪽 Client → Cache → DB 의 표준 cache-aside 패턴. HIT 는 ~6ms, MISS 는 DB 왕복까지 더해 ~72ms 의 직관 차이 를 보여준다.

5가지 패턴 비교

flowchart LR
    subgraph CA[Cache-Aside]
        A1[App] -->|GET| C1[Cache]
        C1 -->|miss| A1
        A1 -->|SELECT| D1[(DB)]
        D1 --> A1
        A1 -->|SET| C1
    end
    subgraph WT[Write-Through]
        A2[App] -->|UPDATE| L2[Cache lib]
        L2 -->|동시| C2[Cache]
        L2 -->|동시| D2[(DB)]
    end
    subgraph WB[Write-Behind]
        A3[App] -->|UPDATE| L3[Cache lib]
        L3 -->|즉시| C3[Cache]
        L3 -.비동기.-> D3[(DB)]
    end

매트릭스:

패턴	일관성	읽기 지연	쓰기 지연	복잡도	흔한 곳
Cache-aside	약 (TTL 의존)	miss 만 느림	DB 만 영향	낮음	기본값. Rails `Rails.cache.fetch`, Django
Read-through	약 (TTL 의존)	miss 만 느림	DB 만 영향	중간	캐시 라이브러리 / Hibernate L2
Write-through	강 (캐시 ↔ DB 같은 순간)	캐시에서 즉시	둘 다 기다림	중간	결제 / 잔액
Write-behind	약 (지연된 일관성)	캐시에서 즉시	캐시만 기다림	높음 (장애 시 손실)	메트릭 / 로그 집계
Refresh-ahead	약	항상 빠름	백그라운드	높음	인기 콘텐츠, 메인 페이지

Cache-aside 의 정석

GET → miss → SELECT → SET:

sequenceDiagram
    autonumber
    participant App
    participant Cache as Redis
    participant DB as PostgreSQL

    App->>Cache: GET user:42
    alt HIT
        Cache-->>App: 데이터 반환
    else MISS
        Cache-->>App: (nil)
        App->>DB: SELECT * FROM users WHERE id=42
        DB-->>App: row
        App->>Cache: SET user:42 ... EX 600
        Cache-->>App: OK
    end

여러 언어로 같은 패턴:

<CodeWithOutput outputLanguage=“text” outputLabel=“동일” title=“Cache-aside 의 본질” variants={[ { label: ‘ruby’, language: ‘ruby’, code: # Rails 의 표준 def find_user(id) Rails.cache.fetch("user:#{id}", expires_in: 10.minutes) do User.find(id) end end, }, { label: ‘python’, language: ‘python’, code: `import redis, json r = redis.Redis()

def find_user(id: int): key = f”user:{id}” cached = r.get(key) if cached: return json.loads(cached) user = db.query(“SELECT * FROM users WHERE id=%s”, id).fetchone() r.set(key, json.dumps(user), ex=600) return user, }, { label: 'typescript', language: 'typescript', code: import { Redis } from ‘ioredis’; const r = new Redis();

export async function findUser(id: number) { const key = `user:${id}`; const cached = await r.get(key); if (cached) return JSON.parse(cached);

const user = await db.queryOne(‘SELECT * FROM users WHERE id=$1’, [id]); await r.set(key, JSON.stringify(user), ‘EX’, 600); return user; }, }, { label: 'java', language: 'java', code: @Service class UserService { private final RedisTemplate<String, User> redis; private final UserRepo repo;

public User find(long id) { var key = “user:” + id; User cached = redis.opsForValue().get(key); if (cached != null) return cached;

User user = repo.findById(id).orElseThrow();
redis.opsForValue().set(key, user, Duration.ofMinutes(10));
return user;

} }, }, ]} output={동일 입력 → 동일 응답. miss 시 첫 호출만 DB 왕복.`} />

Cache Stampede (Thundering Herd / Dogpile)

TTL 이 동시에 만료 되면 수많은 클라이언트 가 동시에 DB 를 친다. 원래 막아주던 캐시 가 증폭기 가 되는 사고.

sequenceDiagram
    autonumber
    participant C1
    participant C2
    participant C3
    participant Cache
    participant DB

    Note over Cache: TTL 0, 만료된 순간
    par C1, C2, C3 모두 동시에
        C1->>Cache: GET
        Cache-->>C1: nil
        C2->>Cache: GET
        Cache-->>C2: nil
        C3->>Cache: GET
        Cache-->>C3: nil
    end
    par 모두 DB 로 (stampede!)
        C1->>DB: SELECT
        C2->>DB: SELECT
        C3->>DB: SELECT
    end
    par 같은 결과를 캐시에 N 번 SET
        C1->>Cache: SET
        C2->>Cache: SET
        C3->>Cache: SET
    end

완화 패턴 4가지

패턴	동작	단점
Single-flight (mutex)	`SET key:lock NX EX` 잡은 한 명 만 DB 조회, 나머지는 기다림 / 옛 값 사용	락 노드 장애 시 데드락 위험
Probabilistic Early Expiration (XFetch)	남은 TTL 의 함수 로 확률적 미리 갱신. 만료 전에 극소수 가 갱신	알고리즘 약간 복잡
Stale-while-revalidate	TTL 만료 후에도 N 초간 옛 값 응답 + 백그라운드 갱신	완전 stale 응답을 허용해야 함
Jitter on TTL	TTL = base + random(±N%)	동시 만료 자체 만 분산. 완전 해결 X

XFetch (Probabilistic Early Expiration)

논문 (Vattani et al.) 의 공식:

expiry = now + delta * beta * log(rand())

캐시에 기록 시점에 평균 fetch 시간 delta 를 함께 저장. 읽을 때 위 식이 TTL 만료 시점을 넘으면 자기가 갱신.

import math, random, time

def get_with_xfetch(r, key, fetch_fn, ttl_seconds, beta=1.0):
    payload = r.get(key)
    if payload is None:
        return refresh(r, key, fetch_fn, ttl_seconds)

    value, delta, expiry = decode(payload)
    now = time.time()
    if now - delta * beta * math.log(random.random()) >= expiry:
        # 만료 전이지만 *확률적으로 미리 갱신*
        return refresh(r, key, fetch_fn, ttl_seconds)
    return value

Single-flight: SET NX 락

def cache_aside_with_lock(r, key, fetch_fn, ttl=600):
    val = r.get(key)
    if val is not None:
        return val

    # 락 시도
    lock_key = f"lock:{key}"
    got = r.set(lock_key, "1", nx=True, ex=10)
    if got:
        try:
            fresh = fetch_fn()
            r.set(key, fresh, ex=ttl)
            return fresh
        finally:
            r.delete(lock_key)
    else:
        # 다른 클라이언트가 갱신 중. 잠시 기다렸다가 재시도
        time.sleep(0.05)
        return cache_aside_with_lock(r, key, fetch_fn, ttl)

Eviction Policy (`maxmemory-policy`)

메모리 한도 (maxmemory) 초과 시 어떤 키부터 버릴지. 패턴 선택만큼 중요.

Policy	동작	권장 시나리오
`noeviction` (기본)	메모리 초과 시 write 에러	데이터 손실 절대 안 됨 (primary store)
`allkeys-lru`	모든 키 중 최근 덜 쓰인 (LRU) 제거	순수 캐시
`allkeys-lfu`	덜 자주 쓰인 (LFU) 제거	인기 분포 편중 환경 (롱테일)
`allkeys-random`	무작위	LRU 비용도 아까울 때 (드물게)
`volatile-lru`	TTL 설정된 키 중 LRU	세션 + 영구 데이터 혼합
`volatile-lfu`	TTL 키 중 LFU	동일, 분포 편중
`volatile-ttl`	남은 TTL 짧은 키부터	TTL 의 의미가 우선순위 일 때
`volatile-random`	TTL 키 중 무작위	드물게

LRU 의 동작 직관

{}

[!NOTE] Redis 의 LRU 는 근사 LRU (maxmemory-samples 만큼 sampling). 정확한 LRU 가 아니다. maxmemory-samples 10 정도가 정확도 / 비용의 보통 타협점.

Eviction 성능 비교 (직관)

같은 워크로드, 다른 정책에서의 히트율 차이 의 직관:

Negative Caching (404 / null 도 캐시)

DB miss 자체가 비싸면 결과 없음 도 캐시.

def get_user(id):
    cached = r.get(f"user:{id}")
    if cached == NULL_SENTINEL:
        return None     # *없음* 도 캐시
    if cached is not None:
        return json.loads(cached)
    user = db_lookup(id)
    if user is None:
        r.set(f"user:{id}", NULL_SENTINEL, ex=60)   # 짧은 TTL
    else:
        r.set(f"user:{id}", json.dumps(user), ex=600)
    return user

[!CAUTION] Negative cache TTL 은 짧게 (예: 60초). 안 그러면 방금 가입한 사용자가 한참 동안 안 보이는 버그.

무효화 (Invalidation)

“There are only two hard things in Computer Science: cache invalidation and naming things.” (Phil Karlton)

Write 시 캐시 무효화 (가장 흔함)

def update_user(id, **fields):
    db.update("UPDATE users SET ... WHERE id=%s", id, **fields)
    r.delete(f"user:{id}")     # 다음 GET 이 miss → 새로 채움

SET 으로 갱신 보다 DEL 이 일반적으로 안전. 멀티 키 / 파생 캐시까지 정확히 갱신하기 어렵기 때문에 지우고 다시 빠뜨리는 패턴.

Tagged Invalidation (Russian Doll)

특정 그룹의 캐시 일괄 무효화 가 필요할 때. 키에 버전 / 타임스탬프 를 박는다.

def get_post(post_id):
    version = r.get(f"post:{post_id}:version") or "0"
    return cached_get(f"post:{post_id}:v{version}")

def invalidate_post(post_id):
    r.incr(f"post:{post_id}:version")   # 옛 키들은 *자연 만료* 만 기다림

김신건의 현장 메모

Rails.cache.fetch 의 race_condition_ttl 이 single-flight + stale-while-revalidate 의 내장 버전. 인기 페이지에 반드시.
Sidekiq job 결과 를 캐시할 때 영구 캐시 + 명시적 invalidation 이 짧은 TTL 보다 DB / Redis 모두 가벼웠다.
Memcached 에서 Redis 로 갈아탄 가장 큰 이유: negative cache 와 데이터 구조 였다. Memcached 는 단순 캐시 의 끝까지 단단 하지만, 해시 / 정렬셋 / 집합 이 필요해지면 결국 Redis.
LFU 가 LRU 보다 좋은 경우 의 직관: “대부분의 트래픽은 인기 콘텐츠 20%” 이면 LFU 가 강함. 균일 분포 에서는 LRU 와 LFU 가 비슷.

참고

공식: Eviction policies
AWS: Caching Best Practices
Wikipedia: Cache stampede
Cloudflare: SWR 적용

[Redis] Cluster: 16384 슬롯, MOVED/ASK, Atomic Slot Migration

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Redis Cluster 는 수평 확장 을 위한 내장된 sharding + 자동 failover. 16384 개의 hash slot 으로 키 공간 을 잘라 여러 노드 에 분배. 각 슬롯은 replica 를 가질 수 있어 고가용성 도 함께.

[!NOTE] Sentinel 은 분할 없음 + 전체 데이터셋이 한 노드. Cluster 는 분할 + 자동 failover. 데이터셋 > 한 노드 메모리 면 Cluster 가 답.

키 → 슬롯 매핑

slot = CRC16(key) mod 16384

키마다 결정적 으로 0 ~ 16383 사이 슬롯 번호. 노드는 연속된 슬롯 범위 들을 담당.

flowchart LR
    K1["key: user:42"] -->|CRC16 mod 16384| S1[slot 5793]
    K2["key: order:1"] -->|CRC16 mod 16384| S2[slot 11923]
    K3["key: cart:99"] -->|CRC16 mod 16384| S3[slot 2010]
    S1 -->|"0..5460"| N1[(Node A)]
    S2 -->|"10923..16383"| N3[(Node C)]
    S3 -->|"5461..10922"| N2[(Node B)]

Hash Tag: 같은 슬롯에 묶고 싶을 때

기본은 키 전체 가 hash 입력. 중괄호로 일부만 감싸면 그 부분만 hash 됨.

{user:42}:cart        → CRC16("user:42") % 16384
{user:42}:profile     → CRC16("user:42") % 16384   ← 같은 슬롯
{user:42}:history     → CRC16("user:42") % 16384   ← 같은 슬롯

[!TIP] 멀티 키 명령 (MGET, MSET, SUNION, transaction MULTI/EXEC, Lua KEYS) 은 모든 키가 같은 슬롯 에 있어야 동작. 항상 같이 묶어 다닐 키들에 hash tag 를 미리 박아두는 게 유일한 처방.

토폴로지

flowchart TB
    subgraph Cluster
      subgraph ShardA["Shard A (slots 0..5460)"]
        PA[(Primary A)]
        RA1[(Replica A1)]
        RA2[(Replica A2)]
      end
      subgraph ShardB["Shard B (slots 5461..10922)"]
        PB[(Primary B)]
        RB1[(Replica B1)]
      end
      subgraph ShardC["Shard C (slots 10923..16383)"]
        PC[(Primary C)]
        RC1[(Replica C1)]
      end
      PA -.gossip.-> PB
      PB -.gossip.-> PC
      PA -.gossip.-> PC
    end
    Client -->|MOVED redirect| ShardA & ShardB & ShardC

모든 primary 끼리 gossip (Cluster Bus port = client_port + 10000).
클라이언트는 cluster-aware. 처음 한 번 토폴로지 조회 후 MOVED 받으면 캐시 갱신.

MOVED / ASK 리디렉션

클라이언트가 잘못된 노드 에 명령을 보내면:

sequenceDiagram
    autonumber
    participant C as Client
    participant A as Node A (slot 5793 주인)
    participant B as Node B (slot 5793 주인 아님)

    C->>B: GET user:42 (slot 5793)
    B-->>C: -MOVED 5793 10.0.0.1:6379
    Note over C: 클라이언트가 토폴로지 캐시 갱신
    C->>A: GET user:42 (slot 5793)
    A-->>C: "kim"

마이그레이션 중인 슬롯은 다르다. ASK 패턴:

sequenceDiagram
    autonumber
    participant C as Client
    participant Src as 출발 노드
    participant Dst as 도착 노드

    Note over Src,Dst: slot 5793 가 Src → Dst 마이그레이션 중
    C->>Src: GET user:42
    alt 키가 아직 Src 에 있음
        Src-->>C: 값 반환
    else 이미 옮겨짐
        Src-->>C: -ASK 5793 dst-ip:port
        C->>Dst: ASKING + GET user:42
        Dst-->>C: 값 반환
    end

차이:

Redirect	의미	클라이언트 동작
`MOVED`	영구적 으로 슬롯의 주인이 바뀜	토폴로지 캐시 갱신
`ASK`	마이그레이션 일시적 으로 이번 요청만 도착 노드	`ASKING` prefix 후 한 번 만 보냄. 캐시 안 바꿈

슬롯 마이그레이션 (Resharding)

전통적 흐름 (Redis 7 이전 + 현재 Redis 호환):

stateDiagram-v2
    [*] --> STABLE
    STABLE --> IMPORTING: CLUSTER SETSLOT N IMPORTING <src>
    STABLE --> MIGRATING: CLUSTER SETSLOT N MIGRATING <dst>
    MIGRATING --> KeysMoving: MIGRATE 명령 반복
    KeysMoving --> KeysMoving: ASK 응답으로 클라이언트 안내
    KeysMoving --> STABLE: 모든 키 이전 + CLUSTER SETSLOT N NODE <dst>
    IMPORTING --> STABLE: 같이 STABLE 로

흐름의 비원자성 이 가장 큰 함정. 중간 에 재시작 / 네트워크 사고 가 발생하면 손으로 복구 가 필요.

Valkey 9.0: Atomic Slot Migration

Valkey 9.0 (2025-10) 의 가장 큰 셀링 포인트. 슬롯 단위로 원자적 마이그레이션. 클라이언트는 MOVED 한 번 만 받고 끝. MIGRATING/IMPORTING/ASK 의 복잡한 중간 상태 가 단축된다 (blog).

항목	전통 (Redis Cluster)	Atomic (Valkey 9.0+)
슬롯 한 개 마이그레이션	다단계 (MIGRATING / IMPORTING / per-key MIGRATE / ASK 응답 / SETSLOT)	원자적 단일 단계
클라이언트 redirect	ASK 다수 + MOVED 1개	MOVED 1개
중간 실패 복구	수동 SETSLOT 복구 필요	자동 롤백

처리량 / 노드 수 스케일링

scale out 이 얼마나 잘 통하는지 의 직관 (Valkey 9.0 의 1B RPS 벤치마크):

[!NOTE] 멀티 키 명령 / transaction 이 많을수록 선형성 이 깨진다. cross-shard 요청은 클라이언트가 N 번 분할 해서 보내야 하기 때문.

쓰기 / 읽기 라우팅

flowchart TB
    Client[Client] -->|GET user:42| Pool[Cluster 클라이언트]
    Pool -->|CRC16 + slot map| Decide{primary or replica?}
    Decide -->|쓰기| Primary[(Primary)]
    Decide -->|READONLY 켰을 때| Replica[(Replica)]
    Decide -->|"기본 (READONLY 안 켜면)"| Primary
    Primary -->|복제 비동기| Replica

READONLY 명령으로 해당 연결에서만 replica 읽기 허용. replica 가 stale 한 경우가 있어 eventual consistent OK 한 쿼리에만.

셋업: redis-cli 의 cluster 도구

<CodeWithOutput language=“bash” label=”$ bash” outputLanguage=“text” outputLabel=“redis-cli” title=“6 노드 클러스터 생성 + 슬롯 분배” code={# 3 primary + 3 replica redis-cli --cluster create \\ 10.0.0.1:6379 10.0.0.2:6379 10.0.0.3:6379 \\ 10.0.0.4:6379 10.0.0.5:6379 10.0.0.6:6379 \\ --cluster-replicas 1} output={`>>> Performing hash slots allocation on 6 nodes… Master[0] -> Slots 0 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 Adding replica 10.0.0.5:6379 to 10.0.0.1:6379 Adding replica 10.0.0.6:6379 to 10.0.0.2:6379 Adding replica 10.0.0.4:6379 to 10.0.0.3:6379 Can I set the above configuration? (type ‘yes’ to accept): yes

Nodes configuration updated Assign a different config epoch to each node Sending CLUSTER MEET messages to join the cluster Performing Cluster Check (using node 10.0.0.1:6379) [OK] All 16384 slots covered.`} />

상태 점검:

[!IMPORTANT] cluster_state:ok 이 유일하게 신뢰할 수 있는 상태 비트. 다른 노드는 gossip 으로 곧 알게 된다 라는 희망 메시지 는 무시하고 모든 노드에서 ok 가 떠야 한다.

데이터 분포의 함정

[!WARNING] Hot slot: 키 분포가 균등하지 않으면 특정 슬롯이 전체 처리량의 대부분 을 가져간다. 해시태그 남발 의 가장 흔한 부작용. ({tenant:1} 으로 전체 테넌트 1 의 데이터를 한 슬롯 으로 묶으면, 테넌트 1 이 가장 큰 고객 일 때 노드 1개가 다 받는다.)

증상:

CLUSTER COUNTKEYSINSLOT <slot> 으로 슬롯별 키 수 확인 → 편중 발견.
redis-cli -h <node> --hotkeys (Redis 4+) 로 특정 노드의 hot key 추출.
운영 시: hot slot 만 수동으로 같은 노드 안의 다른 슬롯으로 옮기는 게 의미 없다. 키 디자인 재검토 가 진짜 답.

Cluster vs Sentinel: 결정 트리

flowchart TD
    A{전체 데이터셋이<br/>한 노드 메모리 안?}
    A -->|예| Sentinel[Sentinel 충분]
    A -->|아니오| B{멀티 키 명령<br/>많이 쓰는가?}
    B -->|많음| Refactor[키 디자인<br/>해시태그 재설계]
    B -->|적음| Cluster[Cluster 가 답]
    Refactor --> Cluster

참고

[Redis] Distributed Lock: SET NX, Redlock, Fencing Token

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

분산 락 (Distributed Lock) 은 여러 프로세스 / 머신 에서 한 시점에 하나만 임계 영역에 진입하도록 보장하는 동기화 도구. Redis 는 간단한 SETNX + EX 부터 Redlock (5-node 합의) 까지 spectrum 을 제공한다.

[!IMPORTANT] 분산 락은 일반적인 mutex 의 직접 대체가 아니다. GC pause, 네트워크 분할, 시계 어긋남 같은 분산 환경의 현실 이 어떤 락도 100% 안전하지 않게 한다. idempotent + fencing token 의 두 겹 안전망 이 거의 항상 추가로 필요.

단일 인스턴스: SET NX EX + Lua

잘못된 패턴 (절대 금지)

SETNX lock:order:42 "owner-1"      # 락 잡음
EXPIRE lock:order:42 30             # ❌ 두 명령 사이에 죽으면 *영구 락*

SETNX 와 EXPIRE 가 원자적이지 않다. 사이에 프로세스 다운 시 TTL 없는 락 이 남음.

정석: 한 명령으로

SET lock:order:42 "uuid-abc" NX PX 30000
# OK   → 락 획득
# nil  → 누가 이미 잡고 있음

옵션	의미
`NX`	존재하지 않을 때만 set
`PX 30000`	30000 ms 후 만료
value = 고유 ID	release 시 내가 잡은 락만 풀기 위함

Release: GET + DEL 의 함정

GET lock:order:42        # "uuid-abc"
DEL lock:order:42        # ❌ 사이에 *TTL 만료 + 다른 owner* 가 잡으면 *남의 락을 푼다*

정석: Lua 로 compare-and-delete

-- KEYS[1] = lock 키, ARGV[1] = 내 토큰
if redis.call('GET', KEYS[1]) == ARGV[1] then
    return redis.call('DEL', KEYS[1])
else
    return 0
end

EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end" 1 lock:order:42 uuid-abc

전체 흐름

sequenceDiagram
    autonumber
    participant Client
    participant Redis

    Client->>Client: token = uuid()
    Client->>Redis: SET lock:order:42 token NX PX 30000
    alt OK 응답
        Note over Client: 임계 영역 진입
        Client->>Client: 작업 수행
        Client->>Redis: EVAL CAS-delete (token)
        Redis-->>Client: 1 (내 락 풀림)
    else nil 응답
        Note over Client: 누가 잡음 → 대기 / 재시도 / 실패 처리
    end

TTL 의 함정과 watchdog

sequenceDiagram
    autonumber
    participant C as Client (락 보유)
    participant R as Redis
    Note over C: 30s 락 획득
    C->>C: 작업 시작
    Note over C: GC pause / 큰 IO 25s
    Note over C: 작업 아직 안 끝남
    Note over R: 30s 후 TTL 만료
    R->>R: 락 자동 해제
    participant D as 다른 Client
    D->>R: SET ... NX PX 30000
    R-->>D: OK (락 획득)
    Note over C: GC pause 끝남, 작업 끝, "내 락" 푼다고 EVAL
    C->>R: EVAL CAS-delete (token)
    Note over R: token 안 맞음 → 0 반환 (남의 락 보호됨)
    Note over C,D: 그런데 *둘 다 동시에 critical section* 에 있었다!

핵심: TTL < 실제 작업 시간 이면 두 클라이언트가 동시에 critical section 진입 가능. Redlock 도 이 문제를 완전히 해결하지 못한다.

Watchdog (자동 갱신)

작업이 돌고 있는 동안 락 TTL 을 주기적으로 갱신. Java 의 Redisson 이 내장 으로 제공.

sequenceDiagram
    autonumber
    participant C as Client
    participant W as Watchdog Thread
    participant R as Redis

    C->>R: SET lock NX PX 30000
    Note over W: 10초마다 PEXPIRE 갱신
    loop work in progress
        W->>R: PEXPIRE lock 30000
    end
    Note over C: 작업 완료
    C->>W: 중지
    C->>R: EVAL CAS-delete

[!CAUTION] Watchdog 도 프로세스가 응답 안 하면 작동 안 함. GC pause / OS 스왑 / VM 정지 같은 프로세스가 멈춘 시간 은 watchdog 도 멈춰 있다.

Redlock: 5-node 합의 알고리즘

antirez 가 제안한 다수 노드 알고리즘. N 개의 독립 Redis 인스턴스 (보통 5개) 에 과반수 (3개 이상) 가 락을 동의 하면 획득 성공.

sequenceDiagram
    autonumber
    participant C as Client
    participant R1 as Redis A
    participant R2 as Redis B
    participant R3 as Redis C
    participant R4 as Redis D
    participant R5 as Redis E

    C->>C: token = uuid(), t0 = now()
    par 모든 인스턴스에 동시에
        C->>R1: SET lock token NX PX 10000
        C->>R2: SET lock token NX PX 10000
        C->>R3: SET lock token NX PX 10000
        C->>R4: SET lock token NX PX 10000
        C->>R5: SET lock token NX PX 10000
    end
    R1-->>C: OK
    R2-->>C: OK
    R3-->>C: OK
    R4-->>C: nil
    R5-->>C: nil
    C->>C: count = 3, elapsed = now() - t0
    alt count >= 3 AND elapsed < TTL/2
        Note over C: 락 획득. 유효 TTL = TTL - elapsed
    else
        C->>R1: EVAL release (token)
        C->>R2: EVAL release
        C->>R3: EVAL release
        Note over C: 실패. 모든 노드에 release.
    end

알고리즘 요약

token = unique-id, t0 = now().
모든 N 개 인스턴스 에 동시에 SET lock token NX PX <TTL>.
OK 응답 수 = count. elapsed = now() - t0.
모두 만족 해야 락 획득:
- count >= (N/2)+1 (다수)
- elapsed < TTL (의미 있는 시간 안에)
유효 락 TTL = TTL - elapsed.
실패하면 모든 노드에 release (받았던 곳이 일부라도).

5-node 노드 수의 정당성

Kleppmann의 비판과 fencing token

Martin Kleppmann 의 글 은 Redlock 이 strong mutual exclusion 을 보장하지 못한다 고 지적. 핵심 시나리오:

sequenceDiagram
    autonumber
    participant C1 as Client 1
    participant Lock as Redlock
    participant Storage as 보호 대상 (DB / S3 / ...)

    C1->>Lock: acquire (TTL 10s)
    Lock-->>C1: OK (token A)
    Note over C1: GC pause 12s
    Note over Lock: 10s 만료, 락 풀림
    participant C2 as Client 2
    C2->>Lock: acquire
    Lock-->>C2: OK (token B)
    C2->>Storage: 데이터 쓰기 (token B 의 책임)
    Note over C1: GC pause 끝
    C1->>Storage: 데이터 쓰기 (이미 만료된 token A 의 책임)
    Note over Storage: 두 client 의 write 가 *동시에* 발생

→ clock drift, GC pause, 네트워크 지연 이 분산 락의 본질적 한계. 이 모든 것은 전체 시스템에서 발생할 수 밖에 없다.

Fencing token: 가장 강력한 보강

락을 잡을 때 monotonic increasing token 을 함께 받는다. 보호 대상 이 작은 토큰의 요청을 거절 한다.

sequenceDiagram
    autonumber
    participant C1 as Client 1
    participant Lock
    participant Storage

    C1->>Lock: acquire
    Lock-->>C1: OK, token=33
    Note over C1: GC pause
    Note over Lock: 만료
    participant C2 as Client 2
    C2->>Lock: acquire
    Lock-->>C2: OK, token=34
    C2->>Storage: write(token=34)
    Storage->>Storage: last_token = 34
    Storage-->>C2: OK
    Note over C1: GC pause 끝
    C1->>Storage: write(token=33)
    Storage->>Storage: 33 < last_token (34) → 거절
    Storage-->>C1: REJECTED

[!IMPORTANT] Redis 자체 는 fencing token monotonicity 를 보장하지 않는다. 별도 monotonic 카운터 (INCR) 또는 Zookeeper / etcd 같은 합의 시스템 이 필요. Kleppmann 의 입장: fencing 이 가능하면 분산 락 자체가 필요 없는 경우가 많다.

antirez 의 반박 요약

Redlock 은 모든 mutual exclusion 사고를 막는다 라고 주장한 적 없다. 실용적 안전 마진 + idempotent 작업 위에 충분한 도구.
clock drift 는 현대 OS / NTP 에서 수 ms 수준 이고, Redlock TTL > 클럭 drift 의 최악 케이스 면 문제 없다.

→ 결론: **Redlock 만으로 결제 / 잔액 / 인벤토리 의 불변량 보호는 위험. 그런 워크로드는 DB transaction / row lock 으로 묶거나, fencing token + idempotent operation 두 겹 안전망 필요.

안전 가이드 (실전 체크리스트)

항목	기준
TTL > 최악 작업 시간 + 안전 마진 (예: 5x)	짧으면 동시 진입 위험
token = 고유 UUID	release 시 남의 락 풀기 방지
release 는 Lua CAS	절대 `GET → DEL` 분리하지 말 것
락은 idempotent 작업 보호용으로 사용	인벤토리 같은 불변량 은 DB transaction 으로
실패 시 retry 정책 정의	무한 retry → starvation
fencing token 필요시 별도 카운터	또는 etcd / Zookeeper
분산 락 = 만능 이라고 생각하지 말 것	항상 race condition 가정

라이브러리

언어	라이브러리	특징
Java	Redisson	watchdog 자동, fairness lock, semaphore, multi-lock 모두
Python	redis-py	`Lock` 클래스 (단일 인스턴스), `redlock-py` (Redlock)
Ruby	redlock-rb	Redlock 알고리즘 직접
Node	redlock	abort signal, extension 자동 갱신
Go	redsync	Redlock 표준 구현

Redisson 예시

RLock lock = redisson.getLock("order:42");

if (lock.tryLock(10, 30, TimeUnit.SECONDS)) {   // wait 10s, lease 30s
    try {
        // 임계 영역
    } finally {
        lock.unlock();
    }
}

watchdog 으로 작업 진행 중 자동 갱신. 프로세스 다운 시 락 회수.

김신건의 현장 메모

hera-webapp 의 이메일 일괄 발송 batch 는 분산 락 + idempotent insert 두 겹. 같은 batch_id 가 DB unique constraint 에 막혀서 분산 락 이 풀려도 중복 발송이 없다.
Redisson watchdog 은 Spring + Redis 환경 에서 최고의 ROI. 단일 인스턴스 + 자동 갱신 + Spring 친화.
Sidekiq unique jobs (분산 락 기반) 은 short window 에서만 안전. 결제 / 잔액 같은 불변량 보호 는 DB row lock 만 안전.
Lock 으로 throughput 을 짠다 는 발상이 가장 위험. 분산 락을 매번 잡는 워크플로 는 재설계 가 답.

참고

공식: Distributed Locks with Redis
Kleppmann: How to do distributed locking
antirez 반박: Is Redlock safe?

[Redis] Hash: 객체 저장, Field TTL (7.4+), Listpack vs Hashtable

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Redis Hash 는 키 안의 작은 dict. 하나의 키 (user:42) 가 여러 field → value 쌍을 가진다. 부분 갱신 / 부분 조회 가 atomic + 효율적.

= “Redis 의 객체”. 객체 저장이 String + JSON 보다 효율적일 때의 표준 선택.

[!IMPORTANT] 2024-04 부터 Redis 7.4 가, 2025-10 부터 Valkey 9.0 이 Hash Field 단위 TTL 을 지원 (HEXPIRE). 더 이상 키 전체 TTL 만의 시대가 아니다. 세션 / 토큰 / 캐시 entry 패턴이 크게 단순해진다.

내부 인코딩

인코딩	조건 (기본)
`listpack`	필드 수 ≤ `hash-max-listpack-entries` (128) AND 각 값 크기 ≤ `hash-max-listpack-value` (64)
`hashtable`	그 외

hash-max-listpack-entries 128
hash-max-listpack-value 64

작은 hash 는 연속 메모리 배열. cache locality 가 압도적. 큰 hash 는 dict + chaining 의 진짜 hashtable 로 자동 전환.

Listpack: flat 배열

flowchart LR
    Hdr["[헤더]"] --> F1[field1] --> V1[value1]
    V1 --> F2[field2] --> V2[value2]
    V2 --> F3[field3] --> V3[value3]
    V3 --> End["[end]"]

총 길이가 작을 때 의 최적. 메모리 ~ String 한 줄 수준.

Hashtable: chaining

{}

{}

큰 hash 에서는 bucket 배열 + 동일 hash 에 충돌하는 노드의 연결 리스트. 위 두 애니메이션이 그 내부 동작을 시각화한다.

[!NOTE] Redis 의 dict 는 progressive rehashing (두 개의 hashtable 을 점진적으로 옮긴다). 큰 hash 의 resize 가 짧게 끊어 분산 되어 single-thread 차단 을 피한다. 자세한 건 [[Redis]] 의 내부 절.

핵심 명령

HSET user:42 name "koa" email "koa@x.com" tier "pro"
HGET user:42 name                  # "koa"
HMGET user:42 name email           # 여러 필드
HGETALL user:42                    # 전체 (작을 때만!)
HKEYS user:42                      # field 이름들
HVALS user:42                      # 값들

HDEL user:42 email                  # 필드 삭제
HEXISTS user:42 name                # 존재 여부

HLEN user:42                        # 필드 수
HINCRBY user:42 visits 1            # atomic 정수 증가
HINCRBYFLOAT user:42 balance 0.5    # float 증가

HRANDFIELD user:42 3 WITHVALUES     # 랜덤 (Redis 6.2+)
HSCAN user:42 0 MATCH 'name*' COUNT 100   # 페이지 스캔

Redis 8 의 새 명령

명령	의미
`HGETEX key field [EX seconds]`	가져오면서 키 전체 TTL 갱신 (String 의 `GETEX` 와 동일)
`HSETEX key seconds field value`	한 번에 set + 키 TTL
`HGETDEL key FIELDS N f1 f2 ...`	가져오면서 해당 필드 즉시 삭제

[!TIP] Redis 7.4+ 의 필드 단위 TTL 과 함께 세션 store / one-time token 같은 패턴의 atomic 동작이 매우 간결.

Hash Field TTL (Redis 7.4 / Valkey 9.0)

기존: 키 전체 TTL 만. 한 hash 안에 서로 다른 만료 시점이 섞이면 여러 키로 분리 해야 했다.

7.4 부터:

HEXPIRE key seconds FIELDS N f1 [f2 ...]
HPEXPIRE key milliseconds FIELDS N f1 [f2 ...]
HEXPIREAT key unixtime FIELDS N f1 [f2 ...]
HPEXPIREAT key unixtime-ms FIELDS N f1 [f2 ...]
HEXPIRETIME key FIELDS N f1 [f2 ...]    # 만료 시각
HPEXPIRETIME key FIELDS N f1 [f2 ...]   # ms 단위
HTTL key FIELDS N f1 [f2 ...]            # 남은 초
HPTTL key FIELDS N f1 [f2 ...]           # 남은 ms
HPERSIST key FIELDS N f1 [f2 ...]        # TTL 제거 (영구)

활용: 세션 store

기존:

SET session:abc123:user_id 42 EX 1800
SET session:abc123:csrf_token xyz EX 1800
SET session:abc123:ip 10.0.0.1 EX 1800
# 같은 세션의 3개 키, 모두 EX 1800

7.4+:

HSET session:abc123 user_id 42 csrf_token xyz ip 10.0.0.1
HEXPIRE session:abc123 1800 FIELDS 3 user_id csrf_token ip
# 또는 키 단위 TTL 만 잡고 필드 단위는 *더 짧게*:
EXPIRE session:abc123 3600                    # 세션 자체 1시간
HEXPIRE session:abc123 300 FIELDS 1 csrf_token  # CSRF 토큰만 5분

키 단위 TTL 과 필드 단위 TTL 은 공존. 둘 다 적용되면 더 짧은 쪽이 이긴다.

활용: JWT blacklist

# token 마다 다른 만료 시점
HSET jwt:blacklist sig_aaa "revoked" sig_bbb "revoked" sig_ccc "revoked"
HEXPIRE jwt:blacklist 3600 FIELDS 1 sig_aaa   # aaa 는 1시간 후 자동 삭제
HEXPIRE jwt:blacklist 600  FIELDS 1 sig_bbb   # bbb 는 10분

→ 한 hash 가 수만 개의 작은 entry 와 각자 다른 TTL 을 원자적으로 관리.

활용: 캐시 entry per-field

flowchart LR
    Cache[(cache:user:42)] -->|HEXPIRE 60| F1[profile field]
    Cache -->|HEXPIRE 600| F2[preferences field]
    Cache -->|HEXPIRE 3600| F3[settings field]
    Cache -->|HPERSIST| F4[immutable_id field]

서로 다른 갱신 주기 의 데이터를 한 객체로 묶으면서 각자 TTL 줄 수 있다. 세분화된 캐시 무효화 의 깔끔한 표현.

객체 저장: Hash vs String+JSON

flowchart LR
    Use{사용 패턴}
    Use -->|전체 갱신 위주<br/>작은 객체| Str[String + JSON]
    Use -->|부분 갱신 위주<br/>큰 객체| Hash[Hash]
    Use -->|필드별 TTL 필요| Hash
    Use -->|언어 간 호환성<br/>중요| Str
    Use -->|atomic 카운터<br/>필드 중 일부에| Hash

비교 매트릭스:

항목	String + JSON	Hash
단일 필드 갱신	전체 직렬화 다시	`HSET field value` (O(1))
단일 필드 조회	전체 파싱	`HGET field` (O(1))
전체 조회	`GET` 1번	`HGETALL` (작으면 OK, 크면 위험)
atomic 카운터	Lua 필요	`HINCRBY field` (O(1) atomic)
직렬화 비용	매번	없음
필드별 TTL	불가능	7.4+ 가능
메모리 (작은 객체)	비슷 / 약간 손해	listpack 으로 작은 hash 는 매우 효율

성능 표

명령	복잡도
`HSET`, `HGET`, `HEXISTS`, `HDEL`, `HINCRBY`	O(1)
`HMGET (k)`, `HSET (k fields)`	O(k)
`HKEYS`, `HVALS`, `HGETALL`, `HLEN`	O(N)
`HSCAN`	amortized O(N) (cursor 분할)
`HEXPIRE FIELDS k`	O(k)
`HRANDFIELD`	O(1) (count=1) / O(N) (큰 count + unique)

[!CAUTION] HGETALL / HKEYS / HVALS 는 큰 hash 에서 single thread 차단. 큰 hash 의 부분 순회 는 HSCAN 으로.

메모리 효율 비교

같은 데이터 (1만 개 사용자 객체, 각 5 필드) 의 저장 방식별 메모리:

[!IMPORTANT] 왼쪽 두 번째 (Hash listpack) 가 가장 효율. 자동으로 hashtable 로 넘어가는 임계점 을 알고 운영. 큰 객체 (필드 100+) 면 listpack 의 이점은 사라진다.

흔한 함정

[!WARNING]

HGETALL 의 큰 hash = 모든 명령 차단. 운영 사고 단골 1위.

HMSET 는 deprecated (Redis 4+). HSET 가 여러 인자 받음. 새 코드는 HSET 로.

필드 단위 TTL 의 만료 알림 = notify-keyspace-events Hg 또는 Hh 필요. 기본은 조용히 사라짐.

listpack 임계 조정 = hash-max-listpack-entries 를 너무 크게 잡으면 listpack 의 O(N) 검색 이 느려진다. 기본 128 이 조용한 sweet spot.

김신건의 현장 메모

세션 store 를 Hash + Field TTL 로 옮긴 뒤 Redis 키 수 가 대폭 감소. 세션 마다 4-5 키 → 1 키. KEYS / SCAN 도 훨씬 가벼움.
작은 객체 1만개 시나리오에서 listpack 임계 안에 들도록 필드 수를 의도적으로 제한했더니 메모리 거의 2배 효율.
Redis 8 의 HSETEX + HGETDEL 은 Rails session_id one-time token 같은 흐름에 완벽한 atomic 한 줄.
HGETALL 사고 회피 패턴: 클라이언트 라이브러리에 HGETALL 호출 시 size 임계 초과면 자동으로 HSCAN 으로 전환 하도록 공통 helper.

참고

공식: Hashes
Hash Field Expiration: redis/redis #13172, Valkey blog

[Redis] HyperLogLog & Geo: 확률 카운팅 + 공간 인덱스

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

이 페이지는 작지만 강력한 두 자료구조 를 묶는다.

HyperLogLog (HLL): 대규모 unique count 를 0.81% 오차로 12 KB 안에 추정.
Geo: 위경도 + 멤버 의 공간 인덱스. 내부는 Sorted Set + geohash 인코딩.

[!IMPORTANT] 둘 다 Sorted Set / Set / Hash 같은 일반 자료구조 위 에 얹은 것이지만, 고유한 명령 + 알고리즘 으로 별도 자료구조 처럼 다뤄진다.

HyperLogLog: 0.81% 오차로 unique 추정

왜 필요한가?

일별 UV (unique visitor) 같은 대규모 cardinality. Set 으로 정확히 세려면 모든 ID 가 메모리에. 1억 명이면 GB 단위.

HLL 은 고정 12 KB 로 1억 unique 도 0.81% 오차 안에 추정한다.

알고리즘 직관

각 입력의 hash 의 첫 N 비트 로 bucket 결정, 나머지 비트의 leading zeros 의 max 를 bucket 에 저장. 전체 unique 수가 많을수록 leading zeros 가 클 확률 증가. 모든 bucket 의 조화 평균 으로 cardinality 역산.

flowchart LR
    Input["item: 'user:42'"] -->|hash| H["64-bit hash: 0b01000...10..."]
    H -->|"top 14 bits"| Bucket["bucket index (0..16383)"]
    H -->|"나머지 50 bits"| LZ["leading zeros count"]
    LZ -->|max| Reg["register at bucket"]
    Reg --> Estimate["전체 estimate ≈ α × m² / Σ 2^-Reg[i]"]

파라미터	Redis 값
Buckets (m)	16384 (2^14)
메모리	12 KB (sparse 인코딩이면 더 작음)
표준 오차	0.81%

명령

PFADD pageviews:home user:42 user:99 user:200
PFADD pageviews:home user:42 user:777        # 이미 있는 user:42 는 무시 (확률적으로)

PFCOUNT pageviews:home                        # 추정 unique 수
PFCOUNT pageviews:home pageviews:about        # 합집합의 unique (별도 키 동시 계산)

# 누적: 일 별 → 주 별 → 월 별
PFMERGE pageviews:weekly pageviews:2026-06-25 pageviews:2026-06-24 ...
PFCOUNT pageviews:weekly                       # 7일 unique 합집합

Set vs HLL 메모리 비교

1억 unique 에 12 KB 라는 게 직관에 반함. 처음 본 사람이 항상 “진짜?” 라고 묻는다.

정확도 vs 오차

# 1만 개 unique 시뮬레이션 (10번 반복)
import redis
r = redis.Redis()
r.delete("test:hll")
for i in range(10000):
    r.pfadd("test:hll", f"user:{i}")
print(r.pfcount("test:hll"))
# → 보통 9920 ~ 10080 범위 (0.8% 오차)

[!TIP] 정확한 cardinality 가 필요한 경우 (예: 결제 unique 사용자) 면 Set + 별도 보관. 대시보드 / 분석 이면 HLL 가 압도적.

활용 패턴

일/주/월 UV: 하루마다 새 HLL, PFMERGE 로 누적
광고 reach: 광고에 노출된 unique 사용자 추정
검색 query 의 unique users: 검색어별 HLL
API endpoint 의 unique 호출자: rate limiting 의 cardinality 통계

[!NOTE] HLL 의 sparse → dense 자동 전환. 처음 채워질 때는 sparse 인코딩 (수십 B 만 사용), 차오를수록 dense 12 KB 가 된다.

Set 과의 조합

# 정확 cardinality 가 필요할 때는 Set, 추정으로 충분할 때는 HLL
SADD users:premium user:42 user:99           # 정확
PFADD users:active user:42 user:99 user:200  # 추정

Geo: 공간 인덱스

내부 구조

Sorted Set + 52-bit geohash. 즉 Geo 자료형 은 별도 자료구조가 아니라 Sorted Set 의 score 가 geohash 인 것.

flowchart LR
    A["GEOADD stores 126.97 37.55 'seoul'"] -->|"geohash → score"| B["ZADD stores 4067218530100 'seoul'"]
    C["GEOSEARCH stores FROMLONLAT ..."] -->|"score 범위 + 후처리"| D["가까운 멤버 목록"]

내부	의미
Score	52-bit geohash (인터리브 비트로 공간 locality 유지)
Member	사용자 정의 ID
거리 계산	Haversine 공식 (구면 거리)

Geohash 의 grid 분할

지도를 재귀적 격자 로 나누어 각 격자에 base32 문자 부여:

1차: 지구를 8개 영역
2차: 각 영역을 다시 8개
...
12자 까지 가면 ≈ 3.7 cm 정밀

같은 prefix 의 geohash 는 공간적으로 가깝다. ZSet 의 score 범위 검색 이 대략적 인접 검색 이 된다.

[!CAUTION] Geohash 의 경계 함정. 두 점이 공간적으로 가까워도 다른 cell 에 떨어질 수 있다 (예: 위/아래 cell 의 경계). Redis 는 주변 cell 도 함께 검색 해서 자동 보정.

명령

GEOADD stores 126.97 37.55 "seoul-gangnam"
GEOADD stores 126.92 37.56 "seoul-myeongdong"
GEOADD stores 139.69 35.69 "tokyo"

# 좌표 + 멤버 동시 (Redis 6.2+)
GEOADD stores NX 121.47 31.23 "shanghai"

# 위치
GEOPOS stores seoul-gangnam tokyo
# → [[126.97, 37.55], [139.69, 35.69]]

# 거리 (단위 옵션: m/km/mi/ft)
GEODIST stores seoul-gangnam tokyo km
# → 1158.42

# Geohash 인코딩 문자열
GEOHASH stores seoul-gangnam
# → wydn... (base32)

검색

# 좌표 기준 반경 검색 (Redis 6.2+ 표준)
GEOSEARCH stores
  FROMLONLAT 126.97 37.55
  BYRADIUS 10 km
  ASC
  COUNT 10
  WITHCOORD WITHDIST

# 멤버 기준 검색
GEOSEARCH stores FROMMEMBER seoul-gangnam BYRADIUS 5 km ASC

# Bounding box (사각)
GEOSEARCH stores
  FROMLONLAT 126.97 37.55
  BYBOX 20 20 km
  ASC

# 결과를 다른 키로 (BYSCORE / BYHASH)
GEOSEARCHSTORE result_key stores FROMLONLAT 126.97 37.55 BYRADIUS 10 km

[!NOTE] 옛 명령 GEORADIUS / GEORADIUSBYMEMBER 은 deprecated. 새 코드는 GEOSEARCH + 옵션 (FROMLONLAT/FROMMEMBER, BYRADIUS/BYBOX) 으로.

검색 시각화 (격자 인접)

flowchart TB
    subgraph Grid["geohash grid"]
        A[A] --- B[B] --- C[C]
        D[D] --- E["E (검색 중심)"] --- F[F]
        G[G] --- H[H] --- I[I]
    end
    Query[Query: 중심 E + 반경 R] -->|9 cell 합집합| Cells["E 와 8 인접 cell 의 멤버"]
    Cells --> Filter["Haversine 거리 ≤ R 인 것만"]
    Filter --> Result[최종 결과]

Redis 가 9 개 cell (자기 + 8 주변) 의 멤버를 후보군 으로 모은 뒤, Haversine 거리 로 정확히 filter. 거리 정확성과 검색 효율의 균형.

활용 패턴

근처 매장 / 식당 검색: GEOSEARCH FROMLONLAT BYRADIUS
배달 라이더 매칭: 주문 위치 → 가까운 라이더 N명
친구 근처 알림: GEOSEARCH FROMMEMBER BYRADIUS
지오펜싱: bounding box 안에 들어왔는지 주기적 체크
POI 클러스터링: geohash prefix 별 grouping

성능 표

명령	복잡도
`GEOADD`	O(log N)
`GEOPOS`, `GEOHASH`	O(log N)
`GEODIST`	O(log N)
`GEOSEARCH BYRADIUS`	O(N + log M) (cell 안 멤버 수 N)
`GEOSEARCH BYBOX`	동일
`GEOSEARCHSTORE`	O(N) + ZADD 비용

[!CAUTION] 전 지구를 한 키 로 만들면 반경 검색의 후보군 이 크다. 국가별 / 지역별 분할 이 후보 수 감소 + 검색 속도 의 표준 패턴.

메모리 비교 (1만 매장 + 위치)

메모리는 비슷하지만 Hash 나 List 는 공간 인덱스 검색 이 클라이언트 코드 + O(N). Geo 는 서버에서 log time.

두 자료구조 결합 시나리오

광고 reach + 지역 분포

# 광고 ad:1234 가 노출된 *unique 사용자* (HLL)
PFADD ad:1234:reach user:42 user:99 user:200
PFCOUNT ad:1234:reach

# 각 사용자의 *현재 위치* (Geo)
GEOADD users:loc 126.97 37.55 user:42
GEOADD users:loc 139.69 35.69 user:99

# *서울 반경 30km 의 *unique 노출 사용자* 추정
GEOSEARCHSTORE seoul_users users:loc FROMLONLAT 126.97 37.55 BYRADIUS 30 km
# → seoul_users 의 멤버를 ad:1234:reach 와 *비교* 하려면 별도 Set 도 필요

[!NOTE] HLL 은 부분집합 cardinality 추정이 어려움. HLL 만으로 “서울에서 광고 노출된 unique 수” 를 정확히 계산 불가. 정확한 교집합 cardinality 가 필요하면 Set + Geo.

흔한 함정

[!WARNING]

HLL 의 작은 cardinality 에서 큰 오차 = 100 명 unique 일 때 ±20% 까지 흔들림. PFCOUNT 가 작은 수 일 때는 신뢰성 낮음.

PFMERGE 의 지속적 누적 = 12 KB 가 고정이지만 합집합 후 정확도 떨어지지 않음. 그러나 Set 처럼 멤버를 다시 빼내지 못함.

Geo 의 위경도 순서 = GEOADD lng lat member 순서. lat / lng 헷갈리는 사고 빈번.

Geohash 셀 경계 = 직접 binary geohash prefix 매칭 으로 검색하면 경계에서 가까운 점 누락. 항상 GEOSEARCH 사용 (자동 보정).

고밀도 영역의 GEOSEARCH = 도심지처럼 한 cell 에 수십만 개 면 후보군 자체가 큼. 국가/도시별 분할 필요.

김신건의 현장 메모

광고 reach 같은 비즈니스 대시보드 는 HLL 의 0.81% 오차 가 완전히 무시 가능. 정확한 cardinality 가 비즈니스 가치를 더 가져다 주지 않음.
Geo 의 BYBOX 가 BYRADIUS 보다 대시보드 UI 친화. 지도 viewport 그대로 BYBOX.
HLL + Set 의 hybrid: 일반 사용자 는 HLL, 프리미엄 / 결제 사용자 는 Set 으로 정확히. 비용 / 정확도 의 분할.
Geo 의 세로 의미 (고도) 가 없다. 단일 평면 (위경도 만). 3D 가 필요하면 별도 인덱싱 (R-tree 같은).

참고

공식: HyperLogLog, Geo
HLL 원논문: Flajolet et al.
Geohash: Wikipedia

[Redis] List: Quicklist / Listpack, BLPOP, Sidekiq 큐

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Redis List 는 양끝 push / pop 이 O(1) 인 순서 보존 시퀀스. 큐 (FIFO), 스택 (LIFO), 최근 N개 목록, Sidekiq 같은 큐 시스템 의 토대.

겉으로는 연결 리스트 같지만 내부적으로는 quicklist + listpack 의 공간 효율 + cache locality 친화 구조.

내부 구조 직관

순수 연결 리스트 의 동작:

{}

위 애니메이션은 연결 리스트 의 insert / delete / traverse 직관. Redis List 의 논리적 동작 은 정확히 이렇다.

큐로 쓰는 경우:

{}

스택으로 쓰는 경우:

{}

[!NOTE] Redis List 는 push / pop 의 양끝 방향 만 정해주면 큐 (push 한쪽, pop 반대쪽) 도 되고 스택 (push 와 pop 이 같은 쪽) 도 된다. 일반적인 큐 구현은 RPUSH ... + BLPOP 또는 LPUSH ... + BRPOP.

Quicklist + Listpack: 실제 내부

Redis 3.2 이전: 순수 linked list 또는 작은 리스트는 ziplist.

Redis 3.2 ~ 7: quicklist = linked list of ziplists. 노드마다 작은 packed 배열.

Redis 7+: ziplist → listpack 으로 교체. 더 단순한 encoding overflow 검출.

flowchart LR
    Head[(head)] --> N1
    subgraph N1[Node 1<br/>listpack]
        N1a["[a, b, c, d]"]
    end
    N1 --> N2
    subgraph N2[Node 2<br/>listpack]
        N2a["[e, f, g, h, i]"]
    end
    N2 --> N3
    subgraph N3[Node 3<br/>listpack]
        N3a["[j, k]"]
    end
    N3 --> Tail[(tail)]

인코딩	조건
`listpack` (Redis 7+)	전체 리스트가 작거나 (`list-max-listpack-size`), 각 노드의 listpack
`quicklist`	큰 리스트 (linked list of listpacks)
`linkedlist` (deprecated)	옛 인코딩
`ziplist` (deprecated)	옛 작은 인코딩

설정:

# 노드당 max 항목 수 (음수면 바이트 단위 한계)
list-max-listpack-size -2     # -2 = 8KB per node (기본)
list-compress-depth 0          # 0 = 압축 안함, 1+ = 양끝부터 N 개 노드 빼고 LZF 압축

[!TIP] 큰 리스트가 메모리 압박 이면 list-compress-depth 1 또는 2 로 중간 노드들 LZF 압축. 양끝 (자주 접근) 은 그대로.

핵심 명령

기본

LPUSH queue:default job1 job2 job3       # 왼쪽 (head) 추가
RPUSH queue:default job4                  # 오른쪽 (tail) 추가
LLEN queue:default                        # 길이

LRANGE queue:default 0 -1                 # 전체
LRANGE queue:default 0 9                  # 처음 10개

LINDEX queue:default 0                    # 첫 번째
LSET queue:default 0 newjob               # 인덱스로 수정
LINSERT queue:default BEFORE job2 new     # 특정 값 *앞* 에 삽입
LREM queue:default 1 job2                 # 첫 번째 만나는 job2 제거
LTRIM queue:default 0 9                   # 처음 10개만 남기고 자름

Pop

LPOP queue:default                        # 왼쪽 1개
RPOP queue:default                        # 오른쪽 1개
LPOP queue:default 5                      # 왼쪽 5개 (Redis 6.2+)

Blocking Pop (Workers 의 핵심)

워커가 큐가 빌 때까지 대기. Sidekiq / Resque / Celery 의 fetch loop 토대.

BLPOP queue:critical queue:default 5      # 두 큐 중 하나 + 최대 5초 대기
# → 큐가 비면 5초 후 nil, 메시지 오면 즉시 반환

sequenceDiagram
    autonumber
    participant W as Worker
    participant Q as queue:default
    participant P as Producer

    W->>Q: BLPOP queue:critical queue:default 0
    Note over W,Q: 큐가 비어있음. 워커가 대기 (blocked)
    P->>Q: RPUSH queue:default job-1
    Q-->>W: ("queue:default", "job-1")
    Note over W: 작업 처리
    W->>Q: BLPOP queue:critical queue:default 0
    Note over W,Q: 다시 대기

[!IMPORTANT] BLPOP 는 redis-cli 가 timeout 0 으로 영원히 대기 가능. 워커 프로세스 는 idle 상태에서 CPU 0%. polling 보다 압도적.

신뢰성 fetch: LMOVE

BRPOPLPUSH (deprecated) → BLMOVE / LMOVE 로. fetch + 별도 처리 목록 의 원자성 보장.

LMOVE queue:default processing:host:pid LEFT RIGHT
# = LPOP queue:default + RPUSH processing:host:pid (한 명령으로 atomic)

sequenceDiagram
    autonumber
    participant W as Worker
    participant Q as queue
    participant P as processing:host:pid

    W->>Q: LMOVE queue processing LEFT RIGHT
    Q->>P: (job-1 이동)
    Q-->>W: job-1
    Note over W: 처리 시작
    alt 성공
        W->>P: LREM processing 1 job-1
    else 크래시
        Note over P: job-1 이 processing 에 남음
        Note over P: 다른 워커 / 운영자가 회수
    end

→ Sidekiq 의 reliable fetch. 자세한 건 [[Redis Pub Sub vs Streams]] 의 Sidekiq 절.

활용 패턴

1. 최근 N개 알림 (LTRIM)

LPUSH notifications:user:42 'json...'
LTRIM notifications:user:42 0 99       # 최근 100개만
LRANGE notifications:user:42 0 19      # 처음 20개 가져오기

고정 크기 윈도우 는 LTRIM 으로 append 직후 자르기. O(N) 이지만 N 이 작아 무시 가능.

2. 큐 (Sidekiq 패턴)

flowchart LR
    P[Producer<br/>Rails App] -->|RPUSH queue:default| Q[(queue:default<br/>List)]
    Q -->|BLPOP| W1[Worker 1]
    Q -->|BLPOP| W2[Worker 2]
    Q -->|BLPOP| W3[Worker 3]
    W1 -->|LMOVE| P1[(processing<br/>:host:pid)]
    W2 -->|LMOVE| P2[(processing<br/>:host:pid)]
    W3 -->|LMOVE| P3[(processing<br/>:host:pid)]

Sidekiq 큐 종류	List 키
기본 큐	`queue:default`
우선순위 큐	`queue:critical`, `queue:low`
진행 중	`processing:host:pid`
예약	`schedule` (Sorted Set, List 아님)
재시도	`retry` (Sorted Set)
죽은 잡	`dead` (Sorted Set)

3. Circular Buffer (LPOP + RPUSH)

def push_recent(r, key, item, max_size=100):
    pipe = r.pipeline()
    pipe.rpush(key, item)
    pipe.ltrim(key, -max_size, -1)    # 끝에서부터 max_size 만 남김
    pipe.execute()

성능 특성

명령	복잡도
`LPUSH` / `RPUSH` / `LPOP` / `RPOP`	O(1)
`LLEN`	O(1)
`LRANGE` (k 개)	O(k)
`LINDEX`	O(N) worst (quicklist node 검색)
`LSET`	O(N) worst
`LINSERT`	O(N) (피벗 검색)
`LREM`	O(N)
`LTRIM`	O(N)

[!CAUTION] 중간 접근 (LINDEX, LINSERT, LSET) 은 O(N). List 의 가치 는 양끝 에서 나온다. 임의 접근 이 많으면 Sorted Set 이나 Hash + Sorted Set 인덱스 가 답.

메모리 비교 (인코딩별)

큐 시스템 비교 (Java/Ruby/Node 의 List 위 큐)

각 언어의 blocking queue 동작을 비교:

{}

producer / consumer 가 큐 한 점 에서 만나는 일반 패턴. Redis List + BLPOP/BRPOP 도 같은 직관.

흔한 함정

[!WARNING]

LRANGE 0 -1 대용량 = O(N), single thread 차단. 큰 리스트는 페이지 단위.

LINSERT BEFORE pivot 의 pivot 검색 = O(N). 자주 쓰면 Sorted Set 으로 인덱싱.

블록 명령은 connection 점유 = Sentinel failover 시 재연결 후 BLPOP 다시 시작 해야 함. 클라이언트 라이브러리가 자동 으로 처리하는지 확인.

List 가 영구 큐 라는 인상 = Redis 가 재시작 + AOF 없으면 그대로 손실. Persistence 가 큐의 신뢰성을 결정. [[Redis Persistence]] 참고.

김신건의 현장 메모

hera-webapp 의 Sidekiq 운영에서 큐 별 우선순위 + 워커 풀 별 분리 가 핵심. queue:critical 에만 전담 워커 5개, queue:default 에 공유 워커 10개 처럼.
최근 알림 N개 같은 읽기 중심 리스트 는 LTRIM 으로 고정 크기 유지. 그 외 오래된 알림 은 별도 archive.
LMOVE 가 도입되기 전 (Redis 6.2 이전) 의 BRPOPLPUSH 가 여전히 많이 보인다. Sidekiq 호환 을 위해 옛 명령도 살아있음. 새 코드는 LMOVE 로.
block 명령은 connection 풀 한 자리 를 차지. 워커 수 * 큐 수 가 Redis connection 한도 와 만난다. max-clients 와 워커 fleet 크기 의 곱셈 으로 미리 검산.

참고

공식: Lists
listpack RFC: redis/redis listpack.md

[Redis] Persistence: RDB / AOF / Hybrid

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Redis Persistence 는 in-memory 데이터를 디스크 로 지속화하는 메커니즘. 세 가지 옵션:

RDB (Redis Database file): 주기적 snapshot. 작고 빠른 부팅, 분 단위 손실 가능.
AOF (Append-Only File): 모든 write 명령을 로그처럼 append. 손실 거의 없음, 큰 파일 + 부팅 느림.
Hybrid (RDB + AOF, 권장): AOF rewrite 가 내부에 RDB preamble 을 포함. 둘의 장점을 모두.

선택은 세 축의 트레이드오프 위에 놓인다: 데이터 손실 허용 시간, 부팅 시간, fsync 비용 (I/O / latency).

트레이드오프 매트릭스

옵션	마지막 손실	파일 크기	부팅 속도	I/O 부하	운영 복잡도
`save ""` (영속화 끔)	재시작 = 전부 손실	0	즉시	0	0
RDB 만	수 분	작음	빠름	낮음 (fork 시 spike)	낮음
AOF `everysec` (기본)	최대 1초	큼	느림	중간	중간
AOF `always`	0	큼	느림	높음	중간
Hybrid (RDB + AOF)	최대 1초	중간	중간	중간	중간

quadrantChart
    title Persistence 옵션의 위치
    x-axis "디스크 I-O 비용 낮음" --> "높음"
    y-axis "데이터 손실 큼" --> "작음"
    quadrant-1 "안전하지만 비쌈"
    quadrant-2 "안전 저렴 이상"
    quadrant-3 "위험 저렴"
    quadrant-4 "위험 비쌈"
    "save 비활성": [0.05, 0.05]
    "RDB only": [0.2, 0.35]
    "AOF everysec": [0.55, 0.85]
    "AOF always": [0.95, 0.98]
    "Hybrid": [0.55, 0.90]

fsync 정책별 처리량 / 손실 시각화

appendfsync 정책이 latency 와 데이터 손실의 가장 큰 결정 변수. 동일 워크로드에서의 상대적 처리량 (베이스라인 = always):

손실 가능 시간:

[!TIP] 프로덕션 표준 은 거의 항상 everysec. 결제 / 주문 같이 어떤 손실도 안 됨 인 경우에만 always 와 함께 DB primary 로 안 쓰는 게 최선.

RDB: BGSAVE 와 fork(2)

RDB 의 핵심은 프로세스 fork 후 자식이 메모리 dump. fork(2) 의 Copy-on-Write 가 핵심.

sequenceDiagram
    autonumber
    participant Client
    participant Redis (parent)
    participant Forked (child)
    participant Disk

    Client->>Redis (parent): BGSAVE
    Note over Redis (parent): SAVE 트리거 (저장점) 또는 명령
    Redis (parent)->>Forked (child): fork()
    Note over Forked (child): 부모 메모리의 CoW 스냅샷
    par 부모는 명령 계속 처리
        Client->>Redis (parent): SET / GET (계속)
        Note over Redis (parent): write 가 발생한 페이지만 *복제*
    and 자식은 dump 작성
        Forked (child)->>Disk: dump.rdb (임시 파일)
        Forked (child)->>Disk: rename (atomic)
    end
    Forked (child)->>Redis (parent): exit(0)
    Note over Redis (parent): SAVE 완료, 다음 저장점 대기

저장점 (redis.conf):

# "M 초 안에 K 개 이상의 키 변경" 이면 자동 BGSAVE
save 3600 1
save 300 100
save 60 10000

# 자동 비활성:
# save ""

[!CAUTION] fork 는 부모 메모리만큼의 가상 메모리 commit 이 필요해 보일 수 있다. Linux 의 vm.overcommit_memory=1 필요. 안 그러면 fork 실패 = BGSAVE 실패. Redis 가 부팅 시 경고를 띄운다.

AOF: append 그리고 rewrite

모든 write 를 RESP 프로토콜 그대로 파일에 append. 시간이 지나면 redundant 명령 이 누적 → 주기적 rewrite 로 압축.

flowchart LR
    A[SET / DEL / EXPIRE / ...] --> B[in-memory state]
    A --> C{appendfsync}
    C -->|always| D[write + fsync<br/>매 명령]
    C -->|everysec| E[write 즉시<br/>fsync 별도 스레드 1초]
    C -->|no| F[write 즉시<br/>fsync OS 위임]
    D --> G[(appendonly.aof)]
    E --> G
    F --> G
    G -->|크기 임계값| H{BGREWRITEAOF}
    H --> I[(새 AOF<br/>RDB preamble +<br/>증분 명령)]

Hybrid (aof-use-rdb-preamble yes, 기본):

AOF rewrite 시작 → fork → child 가 현재 메모리를 RDB 형태로 dump → 그 뒤에 이후 들어온 명령 을 RESP 로 append.
부팅 시: RDB 부분 빠르게 load → 나머지 RESP 명령 replay. AOF 의 안정성 + RDB 의 빠른 부팅.

# 현재 AOF 상태 확인
redis-cli INFO persistence

[!NOTE] aof_delayed_fsync 는 fsync 가 지연된 횟수. 0 이 아니면 디스크 I/O 가 따라오지 못함. EBS, 느린 NFS 등에서 특히 자주 본다.

부팅: 무엇이 먼저 읽히는가?

flowchart TB
    Start[redis-server 시작] --> Check{AOF enabled?}
    Check -->|yes| AofPath
    Check -->|no| RdbPath
    AofPath{aof-use-rdb-preamble yes?} -->|yes| HybridLoad
    AofPath -->|no| AofLoad
    HybridLoad[appendonly.aof 의 RDB preamble 빠르게 load] --> ReplayResp[이후 RESP 명령 replay]
    AofLoad[모든 명령 RESP 로 replay] --> Ready
    RdbPath[dump.rdb 만 load] --> Ready
    ReplayResp --> Ready
    Ready[(READY)]

[!IMPORTANT] AOF 가 활성 이면 RDB 는 부팅에 사용되지 않는다. 둘 다 켜놓아도 최종 진실은 AOF. RDB 는 백업 / 복제 의 빠른 경로로 남는다.

운영 결정 가이드 (의사결정 트리)

flowchart TD
    Q1{"데이터가 캐시 전용?<br/>(다시 데울 수 있음)"}
    Q1 -->|예| OFF[영속화 비활성<br/>save '' + aof off]
    Q1 -->|아니오| Q2{최대 허용 손실?}
    Q2 -->|수 분 OK| RDB[RDB only]
    Q2 -->|1초 이하| Q3{쓰기 처리량 critical?}
    Q3 -->|아니오| HYB[Hybrid<br/>aof everysec +<br/>rdb-preamble]
    Q3 -->|예| TUNE[Hybrid + 빠른 디스크<br/>NVMe / io_uring]
    Q2 -->|0초| WARN[AOF always<br/>+ 다른 primary DB 권장]

시나리오	권장
순수 캐시 (auth token, page cache)	`save ""` + `appendonly no`
세션 store (1시간 미만 손실 OK)	RDB 만, `save 60 10000`
큐 / 분산락 (1초 손실 OK)	Hybrid, `appendfsync everysec`
운영 critical KV (트랜잭션)	Redis 단독 비추천. PostgreSQL 등을 primary 로

디스크와 메모리: 함정

[!WARNING] RDB BGSAVE 의 fork 가 비싸지는 환경 (큰 데이터셋, 잦은 write):

Transparent Huge Pages (THP) 켜져 있으면 CoW latency spike. transparent_hugepage=never 권장.

vm.overcommit_memory=1 안 되어 있으면 fork 실패.

메모리의 fork 시점 free 가 적으면 CoW 가 빠르게 물리 메모리 2배 차지.

EBS GP3 처럼 throughput 한계가 명확한 디스크에서는 BGSAVE 와 AOF rewrite 동시 실행 시 지연 spike.

THP 끄기

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

김신건의 현장 메모

Sidekiq + Redis 운영에서 가장 자주 본 알람은 AOF rewrite 중 latency spike. 새벽 트래픽 적은 시간 에 rewrite 가 일어나도록 auto-aof-rewrite-percentage 100 + auto-aof-rewrite-min-size 1gb 조정.
replica 에서만 BGSAVE 하는 패턴: primary 는 save "" + AOF, replica 는 RDB. snapshot 부담 을 분리.
재해 복구 연습 을 분기 1회 정도는 한다. dump.rdb 만 들고 깨끗한 인스턴스 에서 부팅이 몇 분 인지 측정 → 부팅 시간이 RTO 에 맞는지 확인.
AOF only 환경에서 오랫동안 rewrite 실패 가 누적되면 appendonly.aof 가 수십 GB 까지 가는 사고를 본 적이 있다. 디스크 모니터링 이 redis 메트릭 만큼 중요.

참고

[Redis] Pub/Sub vs Streams: 휘발 신호 vs 영속 로그

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Pub/Sub (PUBLISH / SUBSCRIBE): 지금 듣고 있는 구독자 에게만 메시지가 전달되는 휘발성 신호. 영속 없음, ACK 없음. fan-out.
Streams (XADD / XREAD / XREADGROUP / XACK): 영속적인 append-only 로그. consumer group 으로 작업 분배. Kafka 에 가장 가까운 Redis 자료구조.

[!IMPORTANT] Pub/Sub 는 메시지 큐가 아니다. 다운된 구독자가 나중에 돌아와도 지난 메시지는 못 받는다. 처리 보장 이 필요하면 Streams 또는 List 큐 로.

Pub/Sub 의 동작

{}

sequenceDiagram
    autonumber
    participant P as Publisher
    participant R as Redis
    participant S1 as Subscriber 1
    participant S2 as Subscriber 2

    S1->>R: SUBSCRIBE chat:42
    S2->>R: SUBSCRIBE chat:42
    P->>R: PUBLISH chat:42 "hello"
    par 같은 메시지 fan-out
        R-->>S1: message chat:42 "hello"
        R-->>S2: message chat:42 "hello"
    end
    Note over S2: 네트워크 끊김
    P->>R: PUBLISH chat:42 "world"
    R-->>S1: message chat:42 "world"
    Note over R,S2: S2 는 못 받는다 (휘발). 다시 SUBSCRIBE 해도 "world" 는 영원히 사라짐

명령 셋

# 구독
SUBSCRIBE chat:42 chat:99           # 정확한 채널
PSUBSCRIBE chat:*                   # 패턴
SSUBSCRIBE shardchannel             # Redis 7+ Sharded Pub/Sub (Cluster 친화)

# 발행
PUBLISH chat:42 "hello"             # 받은 구독자 수 반환
SPUBLISH shardchannel "msg"         # Sharded

# 상태
PUBSUB CHANNELS chat:*              # 활성 채널
PUBSUB NUMSUB chat:42               # 채널별 구독자 수
PUBSUB NUMPAT                       # 패턴 구독 수

Sharded Pub/Sub (Redis 7+)

전통 Pub/Sub 는 Cluster 에서 모든 노드로 fan-out → 노드 수 늘수록 낭비. Sharded Pub/Sub 는 채널을 슬롯에 매핑 해 해당 슬롯의 노드만 받게 한다.

flowchart LR
    P[Publisher] -->|PUBLISH| All[모든 노드로 fan-out<br/>~ N nodes 비용]
    P2[Publisher] -->|SPUBLISH| Slot[CRC16 slot → 1 노드만]
    Slot --> Sub[해당 슬롯 구독자만]

Streams: 영속 로그 + Consumer Group

{}

위 애니메이션은 FIFO 큐 동작 의 일반 직관. Streams 는 큐 + 영속 + 다중 consumer group 으로 확장된 형태.

flowchart LR
    P[Producer] -->|XADD chat:42 *<br/>field=value| Log[(Stream chat:42)]
    Log -->|XREADGROUP| G1[Group A]
    Log -->|XREADGROUP| G2[Group B]
    subgraph G1
        C11[Consumer 1]
        C12[Consumer 2]
    end
    subgraph G2
        C21[Consumer 1]
    end
    G1 -->|XACK| Log
    G2 -->|XACK| Log

각 group 은 자기 진행 위치 (last-delivered-id) 를 Stream 안에 저장. consumer 하나가 죽어도 다른 consumer 가 XPENDING 으로 못 ACK 된 메시지 를 XCLAIM 으로 이어받음.

명령 셋

# 추가
XADD chat:42 * user "alice" body "hi"           # ID = millis-seq
XLEN chat:42                                     # 길이

# 단일 consumer 읽기
XREAD COUNT 10 STREAMS chat:42 0                 # 처음부터
XREAD BLOCK 5000 STREAMS chat:42 $               # 새 것만 5초 블록

# Consumer group
XGROUP CREATE chat:42 workers $ MKSTREAM         # 그룹 생성 (가장 최신부터)
XREADGROUP GROUP workers c1 COUNT 10 STREAMS chat:42 >
XACK chat:42 workers 1709305822-0                # 처리 완료 표시
XPENDING chat:42 workers                         # 미완료 목록
XCLAIM chat:42 workers c2 60000 1709305822-0     # 60초 이상 응답 없는 메시지 빼앗아 옴
XAUTOCLAIM chat:42 workers c2 60000 0            # 일괄 (Redis 6.2+)

# 정리
XTRIM chat:42 MAXLEN ~ 100000                    # approximate, ~ 가 효율적
XADD chat:42 MAXLEN ~ 100000 * field value       # add 와 함께

XADD ↔ XACK 의 전형적 흐름

sequenceDiagram
    autonumber
    participant Producer
    participant Stream
    participant W1 as Worker 1
    participant W2 as Worker 2

    Producer->>Stream: XADD orders * id 1
    Producer->>Stream: XADD orders * id 2
    W1->>Stream: XREADGROUP workers w1 COUNT 1 >
    Stream-->>W1: (orders, "1-0", {id:1})
    W2->>Stream: XREADGROUP workers w2 COUNT 1 >
    Stream-->>W2: (orders, "2-0", {id:2})
    Note over W1: 처리 성공
    W1->>Stream: XACK orders workers 1-0
    Note over W2: 처리 중 크래시
    W2-xStream: (응답 없음)
    Note over Stream: 1분 후 운영자가 또는 다른 worker 가
    W1->>Stream: XAUTOCLAIM orders workers w1 60000 0
    Stream-->>W1: ("2-0", ...) 가져옴
    W1->>Stream: XACK orders workers 2-0

8.x 의 신규 명령

명령	의미
`XDELEX` (Redis 8.2)	지정 ID 를 delete + 즉시 reclaim. consumer group ack 와 동시에 처리
`XACKDEL` (Redis 8.2)	ack + delete 한 번에
`XNACK` (Redis 8.8)	consumer 가 명시적으로 메시지를 release. 재시도 가능

Pub/Sub vs Streams: 결정 매트릭스

특성	Pub/Sub	Streams
영속성	없음	있음 (MAXLEN 으로 조절)
다운된 구독자의 메시지	영구 손실	복귀 후 수신 가능
Consumer group	없음 (broadcast 만)	있음 (작업 분배)
ACK / 재시도	없음	있음 (XACK / XCLAIM)
Fan-out	N 구독자 에게 모두	그룹 단위 1개
Cluster	전체 fan-out (Sharded 로 완화)	키 (Stream) 별 슬롯
메모리 비용	0 (즉시 버림)	길이 비례
적합	알림, 무효화 신호, 라이브 채팅	메시지 큐, 이벤트 소싱

처리량 / 지연 (직관)

Redis 위의 큐 시스템들

flowchart TB
    subgraph Sidekiq[Sidekiq, Ruby]
        SK_LIST[List<br/>queue:default]
        SK_ZSET[ZSet<br/>schedule]
        SK_HASH[Hash<br/>job hash]
    end
    subgraph BullMQ[BullMQ, Node]
        BMQ_STREAM[Stream<br/>jobs]
        BMQ_ZSET[ZSet<br/>delayed]
    end
    subgraph Celery[Celery, Python]
        CL_LIST[List<br/>queue]
    end
    subgraph RQ[RQ, Python]
        RQ_LIST[List<br/>rq:queue:default]
    end

라이브러리	기본 구현	신뢰성
Sidekiq (OSS)	`BRPOPLPUSH` (현 `LMOVE`) 로 fetch + 처리 중 표시, ACK 시 제거	crash 시 처리 중 목록 에서 회수
Sidekiq Pro	”reliable fetch” 강화	동일, 보강
BullMQ	Streams 기반	XACK + retry 로 견고
Celery (Redis broker)	List 기반 단순 fetch	crash 시 일부 손실 가능
RQ	List 기반 단순	동일

Sidekiq 의 reliable fetch 원리

sequenceDiagram
    autonumber
    participant W as Worker
    participant Q as queue:default (List)
    participant P as processing:host:pid (List)

    W->>Q: LMOVE queue:default processing:host:pid LEFT RIGHT
    Q-->>W: job-1
    Note over W: 처리 시작 (job 은 processing 목록에 남아있음)
    alt 성공
        W->>P: LREM processing:host:pid 1 job-1
    else crash
        Note over P: 워커 다운 감지 (heartbeat)
        Note over P: 운영자 / 다른 워커가 processing 의 job 을 queue 로 복귀
    end

[!TIP] 영원히 List 기반인 이유 는 호환성. 이론적으로는 Streams 로 다시 짤 수 있지만 모든 user 의 큐 키 / 미들웨어 / 콘솔 이 List 인 것을 가정.

Keyspace Notifications

키 변경을 Pub/Sub 채널 로 받는 기능. invalidation broadcast 에 흔히 사용.

notify-keyspace-events "KEA"

플래그 (조합):

플래그	의미
`K`	keyspace 채널 (`__keyspace@0__:key` 로 이벤트 이름 발행)
`E`	keyevent 채널 (`__keyevent@0__:event` 로 키 이름 발행)
`g`	일반 (DEL, EXPIRE, RENAME)
`$`	String
`l`	List
`s`	Set
`h`	Hash
`z`	ZSet
`x`	expired
`e`	evicted
`A`	`g$lshzxe` 의 alias (all)

PSUBSCRIBE '__keyevent@0__:expired'
# expired 가 발생할 때마다 키 이름이 메시지로 옴

[!CAUTION] expired 이벤트 는 실제 키 만료 시점 이 아니라 Redis 가 발견한 시점. lazy expiration 때문에 수 초 지연 가능. 정확한 시각이 필요하면 Streams + 스케줄러 가 답.

실전 패턴

캐시 무효화 fan-out (Pub/Sub)

sequenceDiagram
    autonumber
    participant W as Writer (DB 갱신)
    participant R as Redis
    participant A1 as App 인스턴스 1
    participant A2 as App 인스턴스 2

    A1->>R: SUBSCRIBE cache:invalidate
    A2->>R: SUBSCRIBE cache:invalidate
    W->>R: PUBLISH cache:invalidate user:42
    par
        R-->>A1: cache:invalidate user:42
        R-->>A2: cache:invalidate user:42
    end
    A1->>A1: in-memory LRU 의 user:42 제거
    A2->>A2: in-memory LRU 의 user:42 제거

로컬 L1 캐시 + Redis L2 캐시 인 환경의 L1 무효화.

이벤트 소싱 + projection (Streams)

flowchart LR
    Cmd[Commands] -->|XADD events| Stream[(events stream)]
    Stream -->|XREADGROUP proj1| P1[Read Model A]
    Stream -->|XREADGROUP proj2| P2[Read Model B]
    Stream -->|XREADGROUP audit| P3[Audit Log]
    P1 --> View1[(Materialized View 1)]
    P2 --> View2[(Materialized View 2)]
    P3 --> Store[(Append-only audit)]

각 projection 이 독립 group. 한 projection 이 과거 이벤트 다시 처리 가 필요하면 XGROUP CREATE … 0 으로 처음부터.

김신건의 현장 메모

hera-webapp 의 알림 fan-out 은 Pub/Sub. 놓쳐도 되는 라이브 신호 만. 영속이 필요한 재발송 가능 이메일 은 Sidekiq 의 List 큐.
Streams 로 큐를 직접 운영 한 경험: XACK 누락 시 무한 retry 와 DLQ (XCLAIM 한도 초과 시 별도 stream) 의 수동 운영 부담이 크다. Sidekiq 가 훨씬 더 운영자 친화.
Sharded Pub/Sub 는 Cluster + Pub/Sub fan-out 환경에서 네트워크 대역폭 을 수 배 절감. 신규 시스템은 처음부터 SPUBLISH/SSUBSCRIBE.
Keyspace notifications 의 expired 는 재미있지만 위험. 의존하면 안 된다. 항상 별도 스케줄러 가 재확인.

참고

공식: Pub/Sub, Streams
Sidekiq Wiki: github.com/sidekiq/sidekiq/wiki
BullMQ: docs.bullmq.io

[Redis] Replication & Sentinel: 비동기 복제와 자동 Failover

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Redis Replication 은 primary (master) → replica (slave) 방향의 비동기 단방향 복제. 읽기 부하 분산 과 고가용성 의 토대.

Redis Sentinel 은 그 위에 얹는 watchdog 시스템. 일정 quorum 이상이 primary 가 죽었다 라고 동의하면, replica 하나를 새 primary 로 승격 + 다른 replica 들을 재구성 + 클라이언트에 알림.

[!IMPORTANT] Sentinel ≠ Cluster. Sentinel 은 키 분할이 없다. 전체 데이터셋이 한 노드 메모리 안에 들어가야 한다. 분할이 필요하면 Cluster 로. [[Redis Cluster]] 참고.

Replication 의 시각

{}

토폴로지:

flowchart LR
    subgraph DC1[데이터센터 / VPC]
        P[(Primary<br/>읽기+쓰기)]
        R1[(Replica 1<br/>읽기 only)]
        R2[(Replica 2<br/>읽기 only)]
    end
    P -->|RESP 명령 스트림| R1
    P -->|RESP 명령 스트림| R2
    Client[App] -->|Write| P
    Client -->|Read| R1
    Client -->|Read| R2

특징:

비동기: write 가 primary 에서 성공하면 바로 응답. replica 에 반영되었는지 모름.
단방향: replica 에 직접 write 하면 조용히 거부 (또는 replica 가 read-only 가 아니면 분기. 절대 금지).
PSYNC: 처음 한 번은 RDB 풀 동기화, 이후엔 backlog 의 offset 부터 증분 동기화.

PSYNC: 풀 / 부분 동기화

sequenceDiagram
    autonumber
    participant R as Replica
    participant P as Primary

    R->>P: PSYNC ? -1 (replicationid 모름)
    P-->>R: +FULLRESYNC <replid> <offset>
    Note over P: BGSAVE 시작
    P->>P: dump.rdb 생성 (fork)
    P-->>R: $<bytes>\r\n<RDB binary>
    Note over R: RDB load → state 동기
    P-->>R: 이후의 명령 스트림 (replication backlog 부터)
    Note over R: 이후 정상 streaming
    Note over R,P: 네트워크 끊김 시 ↓
    R->>P: PSYNC <replid> <offset>
    alt offset 이 backlog 안에 있음
        P-->>R: +CONTINUE (증분만 보냄)
    else 너무 오래 끊겼음
        P-->>R: +FULLRESYNC ... (다시 RDB 풀 동기화)
    end

replication backlog 가 크기 (메모리) 만큼만 부분 재동기화 가 가능. 끊김 시간이 backlog 보다 길면 RDB 풀 동기화로 회귀.

# redis.conf
repl-backlog-size 64mb       # 끊김에 견딜 최대 시간 = backlog / 처리량
repl-backlog-ttl 3600        # replica 없을 때 backlog 유지 시간
repl-diskless-sync yes       # primary 가 RDB 를 socket 으로 직접 전송 (디스크 우회)
repl-diskless-sync-delay 5   # 더 많은 replica 가 모일 때까지 기다림

[!TIP] replica 다수가 동시에 재접속 하면 (예: 배포 후) repl-diskless-sync-delay 가 동일 BGSAVE 를 여러 replica 가 공유 하게 해준다. fork 비용 절감.

Replication Lag 의 시각화

primary 에 지속적인 쓰기 가 있을 때 replica 가 얼마나 늦었는지. 일반적인 행복한 경우 vs 네트워크 혼잡 비교:

핵심 지표 (INFO replication):

master_repl_offset / slave_repl_offset 의 차이 = 명령 단위 lag.
master_link_status = up / down.
master_last_io_seconds_ago = primary 로부터 마지막 명령 수신 후 경과.

안전 가드: WAIT 와 min-replicas

비동기라도 일부 동기 보장 을 흉내내는 두 장치:

`WAIT numreplicas timeout`

마지막 쓰기가 numreplicas 개 이상 의 replica 에 도달할 때까지 최대 timeout ms 대기. 도달하지 못하면 실제로 도달한 수 를 반환.

# 1개 replica 이상 ACK 받을 때까지 100ms 대기
SET payment:42 paid
WAIT 1 100
# → (integer) 1   # 1개에 도달
# → (integer) 0   # 어디에도 못 갔음 (네트워크 끊김 등)

[!CAUTION] WAIT 는 완벽한 동기 복제 가 아니다. primary 가 죽어도 replica 가 못 받은 케이스 는 여전히 존재. 결제 / 주문 의 primary store 로 Redis 를 쓰면 안 되는 이유.

`min-replicas-to-write` / `min-replicas-max-lag`

min-replicas-to-write 1
min-replicas-max-lag 10

→ “최소 1개 이상 의 replica 가 지난 10초 안에 응답했어야 primary 가 write 를 받아준다”. split-brain 의 write 손실 을 줄인다.

Sentinel: 자동 Failover

Sentinel 은 별도 프로세스 (3 ~ 5개 짝수 피하기). 각 Sentinel 이 모든 노드를 주기적으로 ping + INFO. quorum 명이 동의 하면 Subjective Down → Objective Down → Election → Promotion.

sequenceDiagram
    autonumber
    participant S1 as Sentinel 1
    participant S2 as Sentinel 2
    participant S3 as Sentinel 3
    participant P as Primary
    participant R as Replica
    participant C as Client

    Note over P: 정상 동작
    P-xS1: PING 응답 없음
    P-xS2: PING 응답 없음
    Note over S1: S_DOWN 표시
    Note over S2: S_DOWN 표시
    S1->>S2: SENTINEL is-master-down-by-addr ?
    S2-->>S1: 예
    S1->>S3: SENTINEL is-master-down-by-addr ?
    S3-->>S1: 예
    Note over S1: 정족수 도달 → O_DOWN
    S1->>S2: 리더 선출 (Raft 비슷)
    S1->>S3: 리더 선출
    Note over S1: 리더 = S1
    S1->>R: 후보 평가 (lag / priority)
    S1->>R: REPLICAOF NO ONE (승격)
    R-->>S1: OK (이제 새 Primary)
    S1->>R: 다른 replica 들을 새 primary 로 REPLICAOF
    S1->>C: Pub/Sub +switch-master 알림
    C->>R: 이후 트래픽

핵심 단계:

단계	의미
`S_DOWN` (Subjective)	나 (이 Sentinel) 보기엔 primary 가 죽었다. 단독 판단
`O_DOWN` (Objective)	quorum 명 이상 의 Sentinel 이 동의. 진짜 죽었다고 합의
`Election`	Sentinel 들이 리더 1개를 선출
`Promote`	리더가 replica 중 하나를 새 primary 로 승격
`Reconfigure`	나머지 replica 들을 새 primary 의 replica 로 REPLICAOF
`Notify`	Sentinel 의 Pub/Sub 채널 (`+switch-master`) 로 알림

설정 (sentinel.conf):

port 26379
sentinel monitor mymaster 10.0.0.10 6379 2     # quorum = 2
sentinel down-after-milliseconds mymaster 5000  # 5초 응답 없으면 S_DOWN
sentinel failover-timeout mymaster 60000        # failover 한 사이클 한도
sentinel parallel-syncs mymaster 1              # 동시에 새 primary 와 sync 할 replica 수

RTO / RPO 의 직관

gantt
    title Failover 타임라인 (예시, 단위 = 초)
    dateFormat ss
    axisFormat %Ss

    section Primary 다운
    실제 다운             :done, p1, 00, 1s

    section Sentinel
    down-after (5s)       :crit, s1, 01, 5s
    Election             :active, s2, after s1, 2s
    Promote              :active, s3, after s2, 1s
    Replicas 재구성      :active, s4, after s3, 3s

    section Client
    Sentinel Pub/Sub 수신 :milestone, m1, after s3, 0s
    재연결               :active, c1, after m1, 2s

지표	의미	Sentinel 의 보통 범위
RTO (Recovery Time Objective)	서비스 복구까지	5초 (down-after) + 5 ~ 15초 (election + promote + reconnect)
RPO (Recovery Point Objective)	데이터 손실 허용 시점	비동기 복제 이므로 마지막 ACK 안 된 write 만큼 (수십 ms ~ 수 초)

[!TIP] RTO 를 수 초 로 줄이려면 down-after-milliseconds 를 작게. 너무 작으면 네트워크 jitter 만으로도 false failover. 보통 1 ~ 5초 사이에서 false positive 와 RTO 의 균형.

흔한 함정

[!WARNING] 클라이언트 라이브러리 가 Sentinel 의 알림 을 제대로 처리 해야 한다. connection pool 이 옛 primary 의 IP 를 가지고 있으면 failover 후에도 옛 노드 로 계속 시도. Lettuce, redis-py-cluster, redis-rb 등 Sentinel discovery 가 켜져 있는지 확인.

흔한 사고:

Split-brain: 네트워크 분할로 옛 primary 와 새 primary 가 동시 에 write 받음. min-replicas-to-write 가 핵심 방어.
Replica 가 너무 lag 한 상태에서 승격 → 최근 write 손실 큼. Sentinel 의 replica 우선순위 와 replica-priority (낮은 값 우선) 로 lag 적은 replica 가 선정되도록.
Quorum = 노드 수와 동일 → 어떤 Sentinel 한 명이 죽어도 failover 못함. quorum = (N/2)+1.
Sentinel 이 같은 호스트 / VM 에서 동작 → 호스트 장애가 모든 Sentinel 을 한꺼번에 죽임. 반드시 분산.

Redis 자체 HA: Standalone vs Sentinel vs Cluster

모드	데이터 분할	자동 failover	클라이언트 복잡도
Standalone	없음	수동	가장 단순
Sentinel	없음 (전체 데이터 한 노드 메모리에)	자동	Sentinel 발견 필요
Cluster	16384 슬롯 분할	자동	cluster-aware 클라이언트

김신건의 현장 메모

hera-webapp 에서는 AWS ElastiCache Redis Cluster Mode Off + Multi-AZ 사용. managed Sentinel 이라고 봐도 된다. 직접 Sentinel 운영은 3 노드 분산 + Sentinel 모니터링 알람 이 필수.
*failover 동안 짧은 timeout 으로 connection pool 이 즉시 새 primary 를 잡도록 셋업했더니, 간헐적 5xx 가 안 보이기 시작.
Sidekiq 은 Sentinel 친화적. :sentinels 옵션 + :role => :master 로 항상 primary 로 라우팅.
failover 연습 을 카오스 엔지니어링 한 일과 로. primary 에 일부러 DEBUG SLEEP 30 을 날려 Sentinel 이 실전처럼 동작 하는지 검증.

참고

[Redis] Set: 중복 없는 멤버십, SINTER / SUNION / SDIFF

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Redis Set 은 중복 없는 unordered 멤버 집합. SADD / SREM / SISMEMBER 가 O(1), SINTER / SUNION / SDIFF 의 집합 연산 이 자료구조 자체에 박혀 있다.

활용:

멤버십 (“이 사용자가 그룹에 속하나?”)
태그 (게시물 → 태그들, 태그 → 게시물들)
친구 / 팔로워 (양방향, 공통 친구 SINTER)
고유 카운트 (정확한, 작은 집합)
권한 / 역할

[!NOTE] 순서가 필요 하면 [[Redis Sorted Sets]] 로. 대규모 cardinality (정확도 약간 희생 가능) 면 [[Redis HyperLogLog Geo]] 의 HLL 로.

내부 인코딩

인코딩	조건 (기본)
`intset`	모든 멤버가 정수 이고 길이 ≤ `set-max-intset-entries` (512)
`listpack`	작은 set (Redis 7.2+) ≤ `set-max-listpack-entries` (128) AND 멤버 크기 작음
`hashtable`	그 외

set-max-intset-entries 512
set-max-listpack-entries 128
set-max-listpack-value 64

intset 의 마법

{}

위 애니메이션은 Hash Set 의 bucket + 충돌 해결 직관. Redis 의 hashtable 인코딩 은 정확히 이 구조.

flowchart LR
    Hdr["[encoding: int16/int32/int64]<br/>length: 5"] --> M["sorted: [-3, 1, 7, 42, 99]"]

정렬된 정수 배열. binary search 로 SISMEMBER 가 O(log N). 최소 정수 비트 폭 으로 극도로 압축. 1 만개 정수도 수십 KB 면 충분.

[!TIP] 순수 정수 ID 의 큰 멤버십 은 intset 이 비현실적으로 효율. 사용자 ID 같은 정수만 다룬다면 Redis 가 자동 으로 가장 좋은 인코딩을 고른다.

hashtable 인코딩

{}

큰 set 또는 문자열 멤버 면 해시 테이블 로 전환. 같은 dict 구현체이지만 value 가 없는 dict.

핵심 명령

기본

SADD friends:42 100 200 300
SREM friends:42 200
SISMEMBER friends:42 100             # 1
SMISMEMBER friends:42 100 200 300    # [1, 0, 1]  (Redis 6.2+)
SMEMBERS friends:42                  # 전체 (작을 때만!)
SCARD friends:42                     # 길이
SRANDMEMBER friends:42 3             # 랜덤 3개
SPOP friends:42 1                    # pop (제거하면서 반환)
SMOVE friends:42 blocked:42 200      # 멤버 이동 (atomic)
SSCAN friends:42 0 MATCH '*' COUNT 100   # 페이지 스캔

집합 연산

SINTER friends:42 friends:99           # 공통 친구
SUNION friends:42 friends:99           # 전체 합집합
SDIFF friends:42 friends:99            # 42 의 친구 중 99 의 친구가 아닌 사람

# STORE 변형: 결과를 키에 저장
SINTERSTORE result friends:42 friends:99
SUNIONSTORE result friends:42 friends:99
SDIFFSTORE result friends:42 friends:99

# SINTERCARD: 결과 크기만 (Redis 7+)
SINTERCARD 2 friends:42 friends:99 LIMIT 100

flowchart LR
    A["friends:42<br/>{100, 200, 300, 400}"] --> Op
    B["friends:99<br/>{200, 300, 500, 600}"] --> Op
    Op{집합 연산} --> SI["SINTER<br/>{200, 300}"]
    Op --> SU["SUNION<br/>{100, 200, 300, 400, 500, 600}"]
    Op --> SD["SDIFF (42 - 99)<br/>{100, 400}"]

[!IMPORTANT] 집합 연산은 Cluster 에서 같은 슬롯 의 키여야 동작. 친구 / 팔로워 같이 함께 다닐 키 는 {user:42}:friends 처럼 hash tag 로 같은 슬롯 보장.

활용 패턴

1. 태그 시스템 (양방향 인덱스)

# 게시물 1 의 태그
SADD post:1:tags ruby rails redis

# 태그 → 게시물 역인덱스
SADD tag:ruby:posts 1
SADD tag:rails:posts 1
SADD tag:redis:posts 1

# "ruby 와 redis 가 둘 다 달린 게시물"
SINTER tag:ruby:posts tag:redis:posts

역인덱스 만들기 + atomic 검색 이 한 줄. 검색엔진 없이 Redis 만으로 작은 검색 가능.

2. 친구 관계 (양방향)

# 양방향 친구 = a 와 b 모두에 추가
MULTI
SADD friends:42 99
SADD friends:99 42
EXEC

# 공통 친구
SINTER friends:42 friends:99

# 친구의 친구 (확장)
SUNION friends:99 friends:100 friends:101   # 친구 99/100/101 의 모든 친구
SDIFF temp friends:42                       # 내 친구 제외

3. 권한 / 역할

SADD user:42:roles admin editor reviewer
SISMEMBER user:42:roles admin              # 1
SMEMBERS user:42:roles

# 모든 admin
SADD role:admin:users 42 99 100
SMEMBERS role:admin:users

4. 중복 방지 (deduplication)

# 같은 ID 가 *처음* 들어왔는지 atomic 체크
def first_time(r, event_id: str) -> bool:
    return r.sadd("seen:events", event_id) == 1

1 == 처음 (추가됨), 0 == 이미 있음. 멱등성 보장의 한 줄 패턴.

5. 분리 집합 (Disjoint Set)

집합 연산 직관:

{}

Union-Find 의 find / union 패턴. Redis Set 으로 느슨한 disjoint 표현 가능 (정밀하게는 알고리즘 자료구조가 더 적합).

성능 표

명령	복잡도
`SADD`, `SREM`, `SISMEMBER`, `SCARD`, `SPOP`	O(1)
`SMISMEMBER (k)`	O(k)
`SMEMBERS`	O(N)
`SINTER (N1, N2, ..., Nk)`	O(N * k) (최소 집합 기준)
`SUNION (N1, N2, ..., Nk)`	O(N)
`SDIFF (N1, N2, ..., Nk)`	O(N)
`SRANDMEMBER (count)`	O(N) (큰 count 일 때)
`SSCAN`	amortized O(N)

[!CAUTION] SINTER 의 최적화 = Redis 는 가장 작은 집합 부터 처리. 큰 집합 ∩ 작은 집합 을 자주 쓰면 작은 집합을 첫 인자로 주는 것이 명시적으로 빠르다.

메모리 효율 비교

같은 1만 정수 멤버를 각 자료형에 저장:

intset 은 수십 배 효율. 멤버가 정수 + 작은 set 이면 자동 으로 intset 이 잡힌다.

Set vs HyperLogLog 결정

flowchart TD
    Q1{정확한 cardinality<br/>필요?}
    Q1 -->|예| Q2
    Q1 -->|아니오 0.81% 오차 OK| HLL[HyperLogLog<br/>12KB 고정]
    Q2{개별 멤버에<br/>접근 필요?}
    Q2 -->|"예 (SISMEMBER 등)"| Set[Set]
    Q2 -->|아니오 cardinality 만| Q3
    Q3{메모리 한계?}
    Q3 -->|충분| Set
    Q3 -->|타이트| HLL

흔한 함정

[!WARNING]

SMEMBERS 대용량 = O(N) single-thread 차단. 작은 set 에서만.

SUNION/SINTER cross-slot = Cluster 에서 키들이 다른 슬롯 이면 에러. hash tag 필수.

SADD 의 매우 큰 batch = 한 명령에 수만 개 인자 면 명령 자체 가 single-thread 차단. 나눠서.

intset → hashtable 전환 = 한 번 hashtable 가 되면 되돌리지 않는다. 메모리 사용량이 영구히 늘어남. 전환 임계 를 알고 운영.

김신건의 현장 메모

태그 시스템 을 Set + 역인덱스로 만들면 검색엔진 없이도 AND/OR/NOT 가 즉각 가능. 작은 / 중간 규모에서는 ElasticSearch 도입 직전까지 충분.
팔로워 / 팔로잉 같은 대칭 관계 는 MULTI/EXEC 로 묶어 둘 다 정합 보장. 비대칭 (블록 같은) 은 한 쪽만.
intset 의 자동 효율 이 너무 좋아서 종종 intset 이 잡혔는지 OBJECT ENCODING 으로 확인하는 습관이 들었다. 멤버가 비정수로 섞이면 자동 hashtable 로 영구 전환.
Sidekiq unique jobs 같은 멱등성 토큰 은 Set 으로 simple 한 자기 멱등 보장 이 자연스럽다. SADD 의 0/1 반환 을 조건 으로 직접 사용.

참고

공식: Sets
intset 소스: redis/redis/src/intset.c

김신건의 로그 - 위키 / database-internals

[DB] Transaction Isolation Levels: 완벽 가이드

정의

이 문서의 흐름

격리 수준 매트릭스 (전체 지도)

Level 1: READ UNCOMMITTED

이 수준의 정의

발생하는 문제: Dirty Read

해결법 / 대안

Level 2: READ COMMITTED

이 수준의 정의

발생하는 문제: Non-Repeatable Read

해결법 / 대안

Level 3: REPEATABLE READ

이 수준의 정의

발생하는 문제: Phantom Read (ANSI 정의상)

해결법 / 대안

Level 4: SERIALIZABLE

이 수준의 정의

SERIALIZABLE 을 쓸 때 알아야 할 것

성능 트레이드오프

ANSI 표준을 벗어난 이상 현상들

Lost Update (읽고 → 계산 → 쓰기 경쟁)

Write Skew (Snapshot Isolation 의 치명적 함정)

PostgreSQL SSI (Serializable Snapshot Isolation)

MVCC 기반 스냅샷 격리의 원리

실무 가이드

언제 어느 수준을?

격리 수준 명시 방법

프레임워크 예시

실제 DB 엔진 매핑

흔한 함정

Anti-Pattern: Lock 으로 모든 것 해결 시도

관련 위키

N+1 쿼리 문제

정의

시각화

왜 발생하나

눈에 안 보이는 위치에서도 발생

성능 영향 (실제 수치 감각)

감지 방법

1. SQL 로깅

2. 자동 감지 도구

3. 통합 테스트에서 쿼리 수 assert

해결 전략 3가지

전략 1: JOIN (한 쿼리에 다 가져오기)

전략 2: IN 절 배치 조회 (부모 + 자식 2쿼리)

전략 3: 캐시 / counter 컬럼

프레임워크별 해결

JPA / Hibernate

Rails / Active Record

Django

Node.js ORM (참고)

프레임워크 공통 함정

함정 1: has_many :through / 컬렉션 N+1

함정 2: 직렬화에서 노출

함정 3: 자체 관계 (self-referencing)

함정 4: 조건부 접근

함정 5: Kotlin data class / Java record 의 자동 참조

예방 도구 (환경별)

왜 ORM 이 이런 함정을 만드나

함정과 베스트 프랙티스

관련 위키

[DB Internals] B-Tree 내부: split, merge, search 알고리즘

정의

왜 B-Tree?

정의 (Knuth)

구조 (Order 4 예)

Search: O(log_m N)

Insertion + Split

Split (leaf full)

Deletion + Merge

Rotation (borrow from sibling)

Merge

Height 분석

Cache-friendly 구현

동시성 (Concurrency)

PostgreSQL 특화

흔한 함정

관련 위키

함정 1: `has_many :through` / 컬렉션 N+1