💡 핵심 인사이트
데이터베이스 성능 최적화의 핵심은 **"얼마나 디스크(SSD/HDD)를 읽지 않고 버틸 수 있는가?"**입니다.
이를 위해 DBMS는 메인 메모리(RAM)에 거대한 캐시 공간인 **버퍼 풀(Buffer Pool)**을 두고, 디스크에서 읽어온 데이터 블록을 이곳에 쟁여두어 속도를 극대화합니다.

Ⅰ. 버퍼 풀(Buffer Pool)의 개념과 존재 이유

디스크에서 데이터를 읽고 쓰는 I/O 작업은 메모리(RAM)에서 작업하는 것보다 수만 배 이상 느립니다. 매번 SQL 쿼리가 들어올 때마다 디스크를 긁는다면 DB는 버티지 못합니다.

  • 버퍼 풀(캐시): DBMS가 서버를 시작할 때 운영체제로부터 할당받는 거대한 메모리 영역입니다. (보통 전체 서버 RAM의 50~80%를 버퍼 풀로 할당합니다. 예: InnoDB Buffer Pool)
  • 버퍼 관리자(Buffer Manager): 이 한정된 메모리 공간을 효율적으로 관리하여, 자주 찾는 데이터는 메모리에 남겨두고 안 찾는 데이터는 쫓아내는 소프트웨어 모듈입니다.

Ⅱ. 버퍼 풀의 동작 원리 (데이터 읽기와 쓰기)

1. 데이터를 읽을 때 (Read)

  1. 사용자가 SELECT 쿼리를 요청하면, DBMS는 먼저 디스크로 가지 않고 버퍼 풀을 뒤집니다.
  2. 캐시 히트(Cache Hit): 원하는 데이터 블록(페이지)이 버퍼 풀에 있다면 즉시 메모리에서 읽어 반환합니다. (응답속도 0.1ms 이하)
  3. 캐시 미스(Cache Miss): 데이터가 없다면, 그제야 디스크에서 해당 블록을 퍼올려 버퍼 풀의 빈자리에 올려놓고(Load) 사용자에게 반환합니다. 다음번 요청 시에는 캐시 히트가 나도록 대비하는 것입니다.

2. 데이터를 쓸 때 (Write) - 더티 페이지(Dirty Page)

  1. UPDATE나 INSERT 쿼리가 들어오면, DBMS는 디스크에 있는 원본 데이터를 직접 수정하지 않습니다.
  2. 일단 버퍼 풀에 올라와 있는 메모리 상의 데이터만 잽싸게 수정하고 사용자에게 "수정 완료!"라고 응답합니다.
  3. 이때 메모리의 데이터와 디스크의 원본 데이터 내용이 달라지게 되는데, 이를 **더티 페이지(Dirty Page)**라고 부릅니다.
  4. 버퍼 관리자는 이 더티 페이지들을 모아두었다가 시스템이 한가할 때나 버퍼가 꽉 찼을 때, 백그라운드 스레드를 통해 한꺼번에 디스크로 내려보내어(Flush) 동기화시킵니다. 이를 통해 디스크 쓰기 부하를 극단적으로 줄입니다.

Ⅲ. 페이지 교체 알고리즘 (Page Replacement)

버퍼 풀은 크기가 한정되어 있으므로, 새로운 데이터를 디스크에서 퍼올려야 하는데 빈자리가 없다면 기존에 있던 데이터 중 하나를 쫓아내야 합니다.

  • LRU (Least Recently Used): 가장 널리 쓰이는 알고리즘입니다. 가장 오랫동안 사용되지 않은(참조되지 않은) 페이지를 1순위로 버퍼 풀에서 쫓아냅니다. 자주 조회되는 '핫(Hot) 데이터'는 메모리에 영구히 남게 됩니다.

📢 섹션 요약 비유: 버퍼 풀은 요리사의 **'도마(도구대)'**와 같습니다. 매번 냉장고(디스크) 문을 열고 닫는 것이 귀찮으니, 오늘 자주 쓸 것 같은 양파와 파를 도마(버퍼 풀) 위에 미리 다 꺼내놓고 칼질하는 것입니다. 도마가 꽉 차면 제일 안 쓸 것 같은 재료(LRU)를 다시 냉장고에 집어넣습니다.