226. 블로킹 (Blocking) 현상 완화 - MVCC 최대 장점 트랜잭션 대기 병목 해소 동시성 극대화 읽기와 쓰기 충돌 배제

핵심 인사이트: (224, 225번 MVCC의 최종 목적) 1차선 좁은 톨게이트(데이터베이스)에 자동차 10만 대가 섰다. 맨 앞에 벤츠 1대(쓰기 트랜잭션)가 요금소 창구 직원과 싸우느라 5분째(무한 자물쇠 Lock) 차를 안 빼고 있다. 뒤에 줄 선 99,999대의 경차들(단순 조회 Read 트랜잭션)은 아무 짓도 안 했는데, 앞차가 길을 쳐막고 있다는 이유 하나만으로 5분 동안 시동 끄고 도로에서 개거품을 무는 생지옥(Blocking 대기 상태)에 빠졌다. "야 ㅆㅂ!! 언제까지 벤츠 1대 때문에 경차 10만 대를 도로에 세워둘래?! 당장 톨게이트 창구를 위아래 2층(MVCC)으로 복사해서 쪼개버려!! 벤츠(쓰기)는 1층 창구에서 평생 직원하고 싸우게 자물쇠 걸어두고! 나머지 경차 10만 대(읽기)는 벤츠 똥구멍 쳐다보면서 멈춰 서(블로킹) 있지 말고, 허공의 2층 하이패스 창구(Undo 세그먼트 과거 사진)로 0.1초 딜레이도 없이 빛의 속도로 다 뚫고 지나가게 만들어 버리라고!!" 트랜잭션의 발목을 잡는 '정지(Stop)' 현상을 우주 끝으로 지워버린 궁극의 고속도로, 블로킹 현상 완화다.

Ⅰ. 단순 락킹(Locking) 시대의 끔찍한 정체

  • 215번에서 배운 무식한 자물쇠(기본 2PL) 세상에서는 **"읽기(S-Lock)와 쓰기(X-Lock)는 하늘이 두 쪽 나도 절대 한방에 같이 못 있는다"**는 룰이 있었습니다.
  • 블로킹(Blocking): 한 트랜잭션(T1)이 엑셀 칸을 쥐고(Lock) 작업을 끝내고 풀어줄(Unlock) 때까지, 그 엑셀 칸을 만지고 싶어 뒤늦게 도착한 불쌍한 수만 명의 트랜잭션(T2, T3...)들이 꼼짝없이 CPU 연산을 멈추고 대기열(Queue)에 갇혀 무한 정지해버리는 현상입니다. (서버의 속도(Throughput)가 박살 나는 근본 원인)

Ⅱ. 블로킹을 박살 내는 MVCC의 기적 🌟

오라클과 MySQL이 우주 최강의 동시성(성능)을 자랑하는 이유, 224번 **MVCC(다중 버전 동시성 제어)**의 존재 목적 그 자체입니다.

  • 225번 **Undo 세그먼트(과거 엑셀 사진관)**를 도입하면서 기적이 일어났습니다.
  • 앞차(쓰기 트랜잭션)가 엑셀 원본 방에서 10시간 동안 뚝딱대며 피 튀기게 수술을 하고 있어도 상관없습니다.
  • 뒤따라온 수만 명의 단순 조회자(읽기 트랜잭션)들은 그 10시간짜리 피 튀기는 엑셀 원본 방의 문을 두드릴 필요조차 없습니다. 지하 창고(Undo)에 미리 빼둔 '10시간 전 멀쩡했던 과거 사진(스냅샷)'만 쓱 보고 그냥 제 갈 길을 지나쳐 가버립니다!

Ⅲ. 무결성 파괴 없는 블로킹 완전 해소 🌟 핵심 기출 🌟

  • 놀랍게도, 수만 명의 구경꾼이 락(Lock)을 전혀 기다리지 않고(블로킹 0%) 미친 속도로 프리패스하여 지나가는데도, 오손 읽기(Dirty Read)나 갱신 손실 같은 데이터 오염 에러가 단 1개도 터지지 않습니다.
  • 왜? 애초에 덜 익은 피투성이 원본 데이터 근처에는 얼씬도 안 하고, 100% 안전이 보증된 '과거의 확정된 스냅샷 사진'만을 읽고 나갔기 때문에, 속도(동시성)와 안전(격리성) 두 마리 토끼의 정점을 찍은 것입니다.

Ⅳ. 블로킹의 완전 소멸? (단 하나의 예외) 🌟

그렇다면 MVCC를 쓰면 블로킹(대기)이 우주에서 100% 사라졌을까요? 아닙니다! 딱 한 가지 경우에는 여전히 블로킹 지옥이 열립니다.

  • 읽기와 읽기(Read-Read) ➜ 통과 (원래 충돌 안 함)
  • 읽기와 쓰기(Read-Write) ➜ 통과! (MVCC의 기적! 투명 인간 패스)
  • 쓰기와 쓰기(Write-Write) ➜ 블로킹 발생! (예외 불가)
    • 앞놈(T1)이 에어팟 가격을 '25만 원'으로 뜯어고치고(Write) 있는데, 뒷놈(T2)이 쏜살같이 튀어 와서 그 에어팟 가격을 '30만 원'으로 덮어쓰려(Write) 덤빕니다.
    • 이건 203번 **갱신 손실(덮어쓰기)**의 정면충돌입니다. 과거 사진(Undo) 쪼가리를 보여주는 꼼수로는 이 살육전을 절대 해결할 수 없습니다.
    • 결론: 둘 다 뜯어고치려는(Write-Write) 악당들이 만났을 때는, 아무리 뛰어난 MVCC라도 무조건 앞놈(T1)이 엑셀에 건 쇳덩어리 배타 락(X-Lock)을 못 뚫고 뒷놈(T2)을 문 밖에서 영원히 멈춰 세워 무한 대기(블로킹 Blocking) 시켜야만 시스템이 살아남습니다.

📢 섹션 요약 비유: 블로킹(Blocking) 현상은 1차선 산길 터널(데이터베이스)에서 덤프트럭(쓰기 트랜잭션, X-Lock) 한 대가 퍼져서 시동이 꺼졌을 때, 뒤따라오던 오토바이, 승용차, 자전거 10만 대(읽기 트랜잭션, Read)가 아무 죄도 없이 오도 가도 못하고 산길에서 10시간 동안 갇혀서 썩어 들어가는 끔찍한 정체 현상입니다. 트럭이 고쳐져서(COMMIT) 터널을 빠져나갈 때까지 뒷차들은 숨을 쉴 수가 없습니다. 이 정체를 부숴버린 MVCC의 '블로킹 완화' 마법은 터널 입구에 **'마법의 포탈(Undo 세그먼트 스냅샷)'**을 뚫어버린 것입니다. 터널 중앙에선 여전히 덤프트럭이 퍼져서 공사(수정) 중입니다. 하지만 뒤따라온 승용차 10만 대는 덤프트럭 똥구멍 뒤에 서서 기다리지(블로킹) 않습니다. 입구에 뚫린 마법의 포탈(과거 사진관)로 쏙 들어가면, 덤프트럭이 퍼지기 1시간 전의 '뻥 뚫린 맑은 산길 풍경(과거 데이터)' 홀로그램을 보면서 0.001초 만에 빛의 속도로 산을 우회해서(Lock-Free) 톨게이트를 쏙 빠져나가 버립니다. 트럭 놈 혼자 터널에서 피 똥을 싸게 냅두고(Write), 나머지 10만 명의 선량한 독자(Read)들은 터널 바깥의 4차원 시공간으로 대기 시간 없이 논스톱 주행을 하게 만들어, 미친 듯한 고성능 다중 프로그래밍(동시성)의 한계를 깨부순 궁극의 교통정리 예술입니다.