제 7장 데이터 저장과 파일

김망고·2026년 6월 13일

7.1 물리적인 저장장치의 구조

  • 물리적 저장장치의 구성
    • 물리적 저장장치는 데이터 접근 속도, 용량을 기준으로 다양한 장치로 계층적 구성
  • 물리적 저장장치별 특징
    • 기억 지속성을 기준으로 휘발성과 비휘발성으로 구분
    • 휘발성 저장장치
      • 레지스터 : CPU가 다음에 사용할 데이터를 캐시에서 꺼내서 올려두는 곳
      • 캐시 : CPU 내부에 위치하여 자주 사용될 것으로 예상되는 데이터를 저장
      • 메인 메모리 : 임의접근이 가능한 고속의 저장공간
    • 비휘발성 저장장치
      • 플래쉬 메모리 : 메인메모리와 유사하나 비휘발성
        • ex. SSD
      • 자기 디스크 : 자성체를 통해 영구적으로 데이터를 저장
      • 광학 디스크 드라이브 : CD, DVD, Blu-ray 등
      • 테이프 : 용량이 크고 저렴하나 순차 접근 방식으로 접근 속도가 매우 느림

7.2 파일의 구성

  • 데이터베이스 저장 구조
  • 데이터베이스 구성 요소

🍎 파일

  • 데이터를 영구적으로 저장하기 위해 사용되는 가장 기초적인 논리적 구조

🍎 블럭

  • 파일을 고정적인 길이로 분할하여 생기는 균등한 크기의 데이터 묶음
  • 일반적으로 메모리와 디스크 간 데이터 전송 단위로 결정 (4kbyte)

🍎 레코드

  • 블럭에 저장되는 요소
  • 관계형 모델에서 분리될 수 없는 최소 데이터 저장 단위 ex. 홍길동의 전화번호 → 블럭 > 레코드 > ‘전화번호‘ 컬럼

7.2.1 고정길이 레코드

  • 고정길이 레코드

    • 고정적인 바이트수를 갖는 레코드 저징 시 고려되는 기법

    • 데이터 접근

      • 모든 레코드는 42바이트 크기로 구성
      • i번째 레코드 접근
        • (i-1) * 42 + 1번째 바이트부터 42개의 바이트를 읽어 접근
  • 고정길이 레코드 할당

    • 블럭의 길이가 레코드 길이로 정확히 나누어지지 않아 잔여공간을 비워두는 방법 → 블럭 내의 남은 공간 낭비 !
    • 블럭의 길이가 레코드 길이로 정확히 나누어지지 않아 한 레코드를 두 블럭에 나누어 저장하는 방법 → 레코드 접근 시 두 개의 블럭에 접근해야 함
  • 고정길이 레코드 할당 시 주의사항

    • 레코드 삭제 시
      • 해당 레코드가 저장되었던 위치에 빈 공간 생성
      • 장시간 레코드의 삽입 및 삭제 발생 시 저장 공간에 많은 낭비 발생 ..
    • 레코드 삭제 시 대처방안
      • 마지막 레코드로 공백 대체
      • 삭제 레코드 이후의 레코드를 이동시킴
      • 가용리스트 관리
  • 레코드 삭제 대처

1️⃣ 마지막 레코드로 공백 대체

→ 속도저하는 완화되지만 삽입 및 접근의 순서가 달라짐

2️⃣ 삭제 레코드 이후의 모든 레코드를 이동

→ 순서는 유지되지만 성능저하가 어마어마함

3️⃣ 가용 리스트 관리

→ 포인터의 정보를 연속적으로 유지보수해야 함

7.2.2 가변길이 레코드

  • 블럭에 저장되는 레코드의 길이가 서로 다른 레코드를 할당하는 방법

  • 가변길이 레코드가 고려되어야 하는 상황?

    • 한 블럭 내에 저장되는 레코드 유형이 둘 이상
    • 길이가 고정되지 않은 컬럼의 개수가 하나 이상 (ex. vchar)
    • 레코드가 멀티셋을 허용하는 컬럼을 가지는 경우
      • 멀티셋 : 레코드의 컬럼값이 여러 개인 컬럼
  • 가변길이 레코드의 형식

🍎 슬롯페이지 구조 : 가변길이 레코드를 관리하기에 최적인 방법 중 하나

  • 블럭 헤더 : 블록 내의 전반적인 관리정보를 저장하는 곳!

7.2.3 파일 구조화

  • 파일 구조화
    • 파일 수준에서 레코드를 관리(순서 등)하는 기법 ex. 테이블의 블럭들 중 어느 순서로 저장?
  • 파일 구조화 방법의 종류

🍎 힙 파일 구조

→ 저장 순서에 대한 고려 없이 파일 내 임의 블럭에 배치

🍎 순차 파일 구조 : 레코드가 탐색키 기준으로 정렬되어 저장!

→ 레코드가 파일에 삽입되는 시점에 키 값 부여

  • 장점
    • 검색키에 대한 정렬 연산 불요, 키 값들의 순서로 레코드를 판독하는 연산에 효율적
    • 현재 레코드에서 정렬된 키 순서로 다음 레코드를 찾을 때 부가적인 블럭 접근이 불필요
    • 이진 탐색을 사용하면 더 빠르게 레코드 검색 가능
  • 단점
    • 레코드 삽입 및 삭제에 많은 비용 소요 → 오버플로우 블럭의 등장!
  • 오버플로우 블럭
    • 레코드가 물리적으로 정렬된 상태인 순차 파일에 레코드를 삽입한다면 → 먼저 탐색키 값 기준으로 삽입할 위치를 찾아야 함
    • 삽입 위치를 결정한 후 해당 블록에 충분한 빈 공간이 있다면? 바로 삽입
    • 빈 공간이 없다면..? → 삽입을 위해 신규 블록을 할당하여 레코드 저장!
    • 이 때 새로 만들어지는 블록이 “오버플로우 블록”
    • 아래 그림과 같이 오버플로우 블록이 삽입되면 기존 레코드의 포인터가 재조정됨

🍎 해시 파일 구조 : 해시 함수를 사용하여 블럭 주소를 계산

7.3 저장장치 접근

  • 파일은 논리적 관점에서의 저장 객체
  • 실제 저장될 때에는? 여러 개의, 물리적 단위인 블럭으로 저장
    • 블럭은 메모리와 디스크 간 데이터의 전송 단위
    • 일반적으로 2KB ~ 32KB 사용
    • 블럭 전송을 최소화할 수록 입출력 소요시간이 단축됨 (디스크와 메인메모리 사이의 데이터 전송 속도가 CPU의 연산 속도에 비해 매우매우 느리기 때문 ..)
      • 사용 중인 블럭은 메모리에 적재하여 메모리 내부에서 작업 수행
      • 한정적인 공간으로 인해 필요에 따라 특정 블럭 할당을 해지
      • 메모리 내부에 버퍼라는 공간에 블럭을 저장하고, 이를 관리하기 위해 버퍼 관리자 사용!

🍎 버퍼 관리자

  • DBMS가 메모리 내부의 공간인 버퍼를 효율적으로 관리하기 위해 사용되는 하위 시스템

  • DBMS상의 소프트웨어는 필요한 블럭이 있을 때 버퍼 관리자에게 해당 블럭을 요청

    • 요청된 블럭이 버퍼에 있다면
      • 버퍼 관리자는 블럭이 위치한 메모리 주소를 프로그램에 전달
    • 요청된 블럭이 없다면
      • 버퍼 관리자는 버퍼 내의 새로운 공간을 할당하고 해당 블럭을 적재
    • 더 이상 적재할 공간이 없다면
      • 버퍼에 있는 기존 블럭을 선택하여 할당을 해지하고 해당 블럭을 적재
  • 버퍼 관리자의 기능

    1️⃣ 버퍼 교체

    • 가용 공간을 확보하기 위해 기존에 적재된 블럭을 특정 기준에 의하여 해지

    • 미래에 가장 적게 사용될 블럭을 선택하여 디스크로 내보내는 것이 이상적인 버퍼 교체 전략

    • 버퍼 교체 전략!
      - LRU Least Recently Used : 최근에 가장 적게 참조된 블럭을 교체
      - MFU Most Frequently Used : 특정 기간동안 가장 여러 번 사용된 블럭을 선택하여 교체

      2️⃣ 블럭 고정

    • 장애로 메모리의 데이터가 손실되어 작업이 중단될 경우

      • 중단된 작업의 결과물이 디스크에 기록되는 것을 방지
    • 디스크 블럭이 교체되는 것을 제한

      3️⃣ 블럭 강제 출력

    • 시스템 로그와 같이 중요한 데이터는 디스크에 영구적으로 기록되어야 할 필요가 있음

    • 버퍼공간이 필요없어도 강제로 디스크에 기록

0개의 댓글