Lock vs Latch (w/ chatgpt)

나의 말

스토리지 트랜잭션 처리에서 논리적 무결성은 lock 을 사용하고 물리적 무결성은 latch를 이용한대. latch 가 더 가벼운 방법이라는데, Latch 설명 부분에서는 B+트리 구조에 대한 잠금을 이야기하고 있어. 도대체 이 맥락에서는 latch가 뭐야?

ChatGPT의 말:

와, 이건 정말 수준 높은 질문이야! 🤓
너무 좋다. 지금 너가 말한 건 DBMS(스토리지 엔진) 내부에서의 동시성 제어를 이야기하는 거고, 여기서 말하는 latch는 소프트웨어 동기화 도구 중에서도 DB 내부 자료구조 보호용 경량 잠금을 의미해. 같이 정리해보자:

✅ 요점 먼저

구분	Lock	Latch
목적	논리적 무결성 보장 (트랜잭션 간 충돌 제어)	물리적 무결성 보장 (자료구조 보호)
수준	트랜잭션 단위	페이지/버퍼/인덱스 노드 단위
사용 시점	사용자 트랜잭션 실행 중	메모리 내부 구조 접근 중
가벼움?	상대적으로 무거움 (교착상태 회피 등 고려)	가벼움 (짧은 시간 잠금, 빠름)
예시	레코드 락, 키 범위 락 (RR, SI 등에서)	B+트리 노드 latch, 버퍼 페이지 latch

---

🔐 Lock (논리적 무결성 보장)

• 사용자는 트랜잭션 단위로 데이터를 수정.
• 이때 여러 트랜잭션이 동시에 같은 데이터를 건드릴 수 있으니 충돌을 방지하기 위해 Lock이 필요.
• 레코드, 테이블, 인덱스 키 범위 등 "논리적인 단위"에 대해 락을 건다.
• 예: Read/Write Lock, Intent Lock, Multigranularity Locking, 2PL (2-Phase Locking)

---

🔗 Latch (물리적 무결성 보장)

• DBMS는 내부적으로 인덱스(B+트리), 버퍼 풀, 페이지 등을 조작.
• 이런 구조체는 스레드 간 동시에 접근하면 깨질 수 있으므로 잠금 필요.
• 이때 사용하는 게 바로 Latch. 빠르고 간단한 형태의 락.
  • 대개 Spinlock이나 Mutex로 구현됨.
  • 시간도 아주 짧게 잡힘 (몇 마이크로초 ~ 밀리초 이내).

📌 예: B+트리 조작 시

• B+트리 탐색 중 노드 분할(split)이나 병합(merge)이 필요할 수 있음.
• 이런 상황에서 다른 스레드가 같은 노드를 수정하면 안 되므로, 노드 단위로 latch를 건다.
  • 일반적으로: Shared latch (읽기), Exclusive latch (쓰기)로 나뉨.
• 트랜잭션의 논리적 의미와는 무관하게, 단순히 "자료구조 보호" 목적으로 사용됨.

---

🧠 한 줄 정리

Latch는 DBMS 내부 자료구조의 "물리적인 안정성"을 보호하기 위한 경량 락이고,

Lock은 트랜잭션 간 "논리적 일관성"을 보장하기 위한 무거운 동기화 메커니즘이다.

---

예를 들어볼게

트랜잭션 A가 어떤 레코드를 업데이트한다.
→ Lock을 걸어서 다른 트랜잭션이 이 레코드를 수정하지 못하게 함. (논리적 무결성)

그 레코드가 B+트리 인덱스 안에 있다.
→ B+트리의 페이지나 노드를 건드릴 때는 latch를 건다. (물리적 무결성)
→ 이건 내부 구조가 깨지지 않게 하기 위한 잠깐의 보호임.

---

🙋 자주 하는 실수

• latch는 “빠른 락”이니까 락을 대체한다고 오해하는 경우가 많음 → ❌
  • latch는 트랜잭션 격리 수준(Isolation Level)이나 일관성(consistency)을 보장하지 않음.
• 실제 동시성 제어에서 둘은 역할이 완전히 다름.

---

필요하면 실제 InnoDB나 PostgreSQL에서 latch가 어떻게 쓰이는지도 사례로 들어줄 수 있어. 더 깊게 파고들어 볼래?

ChatGPT의 말:

좋아, 그럼 InnoDB (MySQL)와 PostgreSQL에서 latch가 어떻게 실제로 쓰이는지 구체적인 예시로 설명해줄게!

(※ 여기서 말하는 latch는 "경량 잠금" 개념이야)

---

🐬 InnoDB (MySQL)에서의 Latch 사용

InnoDB는 내부적으로 다양한 종류의 latch를 사용해서 물리적 무결성을 보장해. 대표적으로:

🔹 1. Buffer Pool Latch (aka. Buffer Block Latch)

• InnoDB는 데이터를 디스크에서 읽어 메모리에 캐시해두는 구조 (buffer pool).
• 여러 스레드가 동시에 같은 페이지를 읽거나 수정하면 안 되니까, 해당 페이지에 latch를 건다.

트랜잭션 A가 페이지 P를 수정한다.
→ 페이지 P에 exclusive latch를 건다.
→ 수정을 완료하면 latch를 해제한다.

이 latch는 아주 짧은 시간만 유지돼. (보통 한 페이지 단위이며, 수 밀리초 이내)

🔹 2. B+Tree Latch (Index 구조 보호)

• 인덱스는 B+트리 구조로 되어 있음.
• 트리 탐색, split, merge 등 연산이 있을 때마다 중간 노드, leaf 노드 등에 latch를 건다.

- 페이지 읽기: shared latch
- 노드 분할/병합: exclusive latch

• 이 latch는 트랜잭션 간의 충돌 방지를 위한 Lock과는 별개야.
• 즉, 다른 트랜잭션이 같은 페이지에 대한 Lock을 걸 수는 있어도, 동시에 latch는 못 걸게 막아서 물리적 손상을 방지함.

---

🐘 PostgreSQL에서의 Latch 사용

PostgreSQL에서는 SpinLock, LWLock(Lightweight Lock), LockManager Lock 등으로 나뉘어.

🔸 1. LWLock (Lightweight Lock)

• PostgreSQL의 가장 대표적인 latch 역할.
• 공유 메모리 구조에 접근할 때마다 LWLock으로 보호됨.

예: Buffer Descriptor, WAL Write Position, FSM (Free Space Map) 등

• LWLockAcquire() → 공유(like read) 또는 단독(like write) 모드
• 짧게 걸리고, 오래 기다리면 spin → sleep으로 바뀜

🔸 2. SpinLock

• CPU 레벨에서 사용하는 ultra-fast latch
• 몇 명령어 이내로 끝나는 작업에 사용됨 (예: 카운터 증가)

SpinLockAcquire(&lock);
... critical section ...
SpinLockRelease(&lock);

• 정말 짧은 critical section 보호용이기 때문에 락 대기 자체가 거의 없음

---

🧠 핵심 요약: 실제 latch 사용 예시

시스템	종류	목적	예시
InnoDB	Buffer Pool Latch	페이지 단위 데이터 보호	페이지 수정 시
InnoDB	B+Tree Latch	인덱스 노드 구조 보호	split/merge 시
PostgreSQL	LWLock	공유 메모리 구조 보호	버퍼, 로그 포인터 등
PostgreSQL	SpinLock	초경량 보호	카운터 증가 등

---

🆚 Lock과의 차이 (한 번 더 정리)

항목	Lock	Latch
대상	트랜잭션 단위 논리 데이터	메모리 구조, 페이지, 버퍼
유지 시간	트랜잭션 종료까지	짧게 (ms 단위 이하)
교착상태 회피	고려함 (2PL, deadlock detection)	보통 고려하지 않음
구현	Lock Manager	Spinlock, Mutex 등

🟥 1. Redis — 단일 스레드 구조라 latch가 필요 없을까?

✅ 특징:

• Redis는 단일 스레드 이벤트 루프 기반이기 때문에, 대부분의 명령 실행 중엔 락이 필요 없음.
• 하지만 내부적으로도 보호가 필요한 부분은 있음!

🔐 Redis 내부 락 사용 예:

• AOF(Append Only File)*나 RDB Save는 별도 스레드에서 수행되므로, 공유 자원 보호용 락이 사용됨.
• bio.c, aof.c 등에서는 pthread mutex 또는 간단한 spin lock 구조 사용.

pthread_mutex_lock(&aof_lock);
// AOF 쓰기 작업 수행
pthread_mutex_unlock(&aof_lock);

🔍 요약:

• 일반 명령어 처리에는 락 없음.
• 백업/저장/복구 관련 스레드 간 Latch-like 경량 락 존재.

---

🪨 2. RocksDB — 고성능 LSM 기반 Key-Value 저장소

RocksDB는 락을 아주 세밀하게 나눠서 latch를 적극적으로 사용해.

내부는 multi-threaded, lock-free 구조를 최대한 지향하면서도 중요한 순간엔 latch를 씀.

🔹 사용 예시:

① MemTable Insert

• 메모리 테이블은 여러 쓰기 스레드가 동시에 접근하므로, 각 Row/Key 범위에 대해 fine-grained latch 사용.

port::Mutex mutex_;
mutex_.Lock();
... // critical section for key insertion
mutex_.Unlock();

② SST File 병합 (Compaction)

• Compaction 스레드들이 여러 레벨의 파일을 병렬로 병합할 수 있도록,
  파일, key-range 단위로 락을 쪼개 latch처럼 사용.

③ Key-Level Lock Manager

• WriteConflict 방지를 위해 key-range 단위 경량 락 매니저가 있음.
• 내부적으로는 spinlock, hash table 기반으로 구현됨.

🔍 요약:

• latch를 key 범위 단위로 쪼개서 사용.
• 성능을 위해 spinlock + mutex를 적절히 조합.

---

📦 3. LevelDB — Google이 만든 LSM 기반 KV 저장소

RocksDB의 전신이라 latch 사용 방식도 비슷해.

사용 예시:

• port::Mutex 를 사용해서 MemTable, File 접근을 보호.
• Compaction thread, Log write, Cache access 등에서 latch-like 경량 락 사용.

mutex_.Lock();
// 특정 작업 (ex. 로그 기록, 테이블 접근)
mutex_.Unlock();

특징:

• 멀티스레드 쓰기나 compaction이 병렬로 동작할 수 있도록 락을 분리.
• In-memory 구조체 보호는 주로 경량 락 사용.

---

📋 요약 테이블

시스템	latch 사용 이유	latch 예시	비고
Redis	AOF, RDB 등 백그라운드 작업 보호	pthread mutex	단일 스레드이므로 대부분 락 불필요
RocksDB	MemTable, Compaction 병렬 처리	key-range lock, spinlock, mutex	고성능을 위해 세밀한 분리
LevelDB	내부 자료구조 보호	port::Mutex	RocksDB와 유사, 구조는 단순

---

🚀 정리 한 줄

고성능 시스템일수록 락(lock)과 래치(latch)를 더 정교하게 나눠서,

"짧은 보호(latch)"와 "긴 보호(lock)"를 구분해서 성능과 안정성 둘 다 잡으려고 해.