[DB] INSERT했던 데이터는 어디에 저장될까?(데이터 저장 구조와 엑세스)

 

들어가며

로컬에 데이터베이스를 설치해보신 분들이라면 어느정도 아시겠지만, 데이터는 파일로 저장이 됩니다. 물리적인 계층에서는 파일과 블록, 메타데이터로 구성이 되며 데이터베이스는 파일에 쓰여진 데이터들을 효율적으로 관리할 수 있도록 도와주는 역할을 하죠. 우리는 데이터베이스 서버 프로그램에 SQL을 보내서 필요한 데이터를 찾거나, 수정, 삭제를 진행합니다. 연관관계가 있는 상황에서 우리는 때론 복잡한 SQL도 작성합니다. 하지만, 단순히 SQL만 잘 사용한다고 해서 데이터베이스를 잘 아는 것이 아닐 겁니다. 오늘은 데이터베이스의 내부 작동 원리에 대해 자세히 알아보고 데이터베이스의 성능을 올리기 위해 어떤 것을 신경써야하는지 살펴보겠습니다.

 

데이터베이스의 내부 데이터 관리 구조는 데이터를 효율적으로 저장하고 관리하며, 빠르게 검색하기 위해 설계된 복잡한 시스템입니다. 여기에서는 데이터가 데이터베이스에 저장되고 관리되는 전체 구조를 단계별로 설명하겠습니다.

---

1. 데이터 파일과 블록

데이터는 디스크의 파일 시스템 위에 저장되며, 데이터 파일은 데이터베이스가 관리하는 가장 기본적인 단위입니다.

1-1. 데이터 파일 구성

• 데이터 파일(Data File): 데이터베이스의 모든 데이터는 디스크에 데이터 파일로 저장됩니다.
• 데이터 파일은 내부적으로 블록(Block)으로 나뉘며, 블록은 데이터 파일의 저장 및 읽기/쓰기 단위입니다.
• 일반적인 데이터베이스에서 블록 크기는 4KB, 8KB, 16KB 등으로 설정됩니다.

1-2. 블록의 내부 구조

• 헤더(Header): 블록의 메타데이터(블록 번호, 데이터 사용량 등)가 저장됩니다.
• 데이터(Data): 실제 데이터가 저장되는 영역입니다.
• 프리 리스트(Free Space): 사용 가능한 빈 공간입니다. 업데이트 시 기존 블록에 데이터를 추가할 공간을 제공합니다.

 

출처: https://dotnettutorials.net/lesson/availability-and-optimization-of-free-space-in-oracle/

 

 

---

 

2. 테이블 관리

테이블은 데이터를 행(Row) 단위로 저장하며, 내부적으로는 다음과 같은 구조로 관리됩니다.

2-1. 테이블 스토리지 구조

• 테이블은 행(Row) 단위로 저장됩니다.
• 각 행은 레코드(Record)로 불리며, 레코드는 다음과 같은 구조를 가집니다:
  • 레코드 헤더: 메타데이터(레코드 크기, 트랜잭션 ID 등).
  • 데이터 필드: 실제 데이터 값.
  • ROWID: 행의 고유 식별자. 블록 번호와 위치를 나타냅니다.

 

출처: https://velog.io/@impala/DB-Data-Storage-Structure

2-2. 테이블 스페이스

테이블 스페이스는 논리적 계층에서 동작하며, 아래와 같은 구성 요소를 포함합니다:

테이블 스페이스

• 데이터베이스에서 관리하는 논리적 스토리지 단위입니다.
• 하나의 테이블 스페이스는 하나 이상의 데이터 파일(Data File)을 포함합니다.

데이터 파일(Data File)

• 테이블 스페이스의 물리적 저장소입니다.
• 파일 시스템에 실제로 저장되는 파일이며, 블록(Block) 단위로 데이터를 저장합니다.

세그먼트(Segment)

• 테이블, 인덱스 등 데이터베이스 객체를 저장하기 위한 공간입니다.
• 하나의 세그먼트는 여러 블록으로 구성됩니다.

익스텐트(Extent)

• 데이터 저장 공간이 필요할 때 할당되는 연속적인 블록 그룹입니다.
• 세그먼트는 하나 이상의 익스텐트로 구성됩니다.

블록(Block)

• 데이터 파일의 최소 저장 단위로, 데이터를 저장하거나 읽을 때 사용됩니다.

출처: https://velog.io/@hoonki/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%A0%80%EC%9E%A5-%EA%B5%AC%EC%A1%B0-%EB%B0%8F-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%95%A1%EC%84%B8%EC%8A%A4-%EB%B0%A9%EB%B2%95

 

2-3 주요 DBMS에서의 테이블 스페이스

Oracle

• SYSTEM 테이블 스페이스: 데이터베이스의 시스템 데이터(메타데이터 등)를 저장.
• SYSAUX 테이블 스페이스: 추가 시스템 데이터를 저장.
• USERS 테이블 스페이스: 사용자 데이터 저장.
• TEMP 테이블 스페이스: 임시 데이터 저장(정렬 작업 등).
• UNDO 테이블 스페이스: 트랜잭션 롤백을 위한 UNDO 데이터를 저장.

MySQL (InnoDB)

• MySQL에서 InnoDB는 기본적으로 데이터를 공유 테이블 스페이스(ibdata1 파일) 또는 개별 테이블 스페이스(각 테이블마다 별도 파일)로 저장합니다.
• 공유 테이블 스페이스를 사용하면 모든 테이블과 인덱스가 하나의 파일에 저장됩니다.
• 개별 테이블 스페이스를 사용하면 테이블별로 별도의 .ibd 파일이 생성됩니다.

PostgreSQL

• PostgreSQL은 직접적으로 "테이블 스페이스"라는 개념을 지원하며, 데이터 파일을 저장할 디렉터리를 정의할 수 있습니다.
• 기본 테이블 스페이스는 pg_default이며, 특정 테이블 또는 인덱스를 별도의 테이블 스페이스에 저장하도록 설정할 수 있습니다.

 

---

 

3. 인덱스 관리

인덱스는 테이블 데이터에 대한 검색 속도를 향상시키기 위한 별도의 데이터 구조입니다.

3-1. B-Tree 인덱스

• 가장 널리 사용되는 인덱스 유형으로, 데이터는 정렬된 상태로 저장됩니다.
• 구조:
  • 루트 노드(Root Node): 최상위 노드로 데이터를 검색하는 시작점.
  • 내부 노드(Intermediate Node): 데이터 범위를 정의하는 중간 노드.
  • 리프 노드(Leaf Node): 실제 데이터(또는 데이터 위치)가 저장된 최하위 노드.
• 장점: 범위 검색과 순차 검색에 효율적.

3-2. Hash 인덱스

• 키와 값을 기반으로 데이터 위치를 빠르게 찾습니다.
• 구조:
  • 해시 함수(Hash Function): 입력 값(키)을 고유의 해시 값으로 변환.
  • 해시 테이블(Hash Table): 해시 값과 데이터를 매핑.
• 장점: 정확한 값 검색에 효율적.

3-3. 인덱스 스캔방식

• Table Full Scan: 말 그대로 테이블 전체를 읽는 방식입니다. 시퀀셜 엑세스를 통해 읽으며 Multi Block I/O 방식으로 디스크 블록을 읽습니다. 인덱스가 없는 테이블에 해당합니다.
• Index Range Scan: 인덱스를 스캔하면서 얻은 RowID로 범위를 부여하면서 테이블 레코드를 찾는 방식입니다. index 값이 unique가 아니라 중복을 허용할 때, 2번 이상 범위를 탐색하는 방법입니다.
• Index Skip Scan: 결합 칼럼 인덱스의 첫 칼럼이 WHERE에 있지 않아도, 인덱스를 이용할 수 있는 방식입니다.
• Index Full Scan: 인덱스 테이블 전체를 스캔합니다. 

---

 

4. 버퍼 관리

데이터베이스는 데이터를 빠르게 처리하기 위해 메모리와 디스크를 함께 사용합니다.

4-1. 버퍼 풀(Buffer Pool)

• 데이터베이스는 디스크 I/O를 최소화하기 위해 자주 사용하는 데이터를 메모리의 버퍼 풀에 캐싱합니다.
• 버퍼 풀은 페이지(Page) 단위로 데이터를 관리합니다.

4-2. LRU 알고리즘

• 버퍼 풀의 공간이 부족하면 LRU(Least Recently Used) 알고리즘을 사용하여 가장 오랫동안 사용되지 않은 데이터를 제거합니다.

---

 

5. 트랜잭션과 로그 관리

데이터의 일관성과 신뢰성을 유지하기 위해 트랜잭션과 로그가 관리됩니다.

5-1. Write-Ahead Logging (WAL)

• 데이터 변경이 발생하면 먼저 로그에 기록하고, 이후에 데이터 파일을 수정합니다.
• 장애가 발생해도 로그를 사용해 데이터를 복구할 수 있습니다.

5-2. UNDO와 REDO 로그

• UNDO 로그: 트랜잭션을 롤백할 때 사용됩니다.
• REDO 로그: 트랜잭션 커밋 이후 데이터를 복구할 때 사용됩니다.

---

 

6. 쿼리 실행과 최적화

데이터베이스는 SQL 쿼리를 효율적으로 실행하기 위해 최적화 과정을 거칩니다.

6-1. 쿼리 최적화 과정

1. 파싱(Parsing): SQL 문법 확인 및 내부 표현으로 변환.
2. 최적화(Optimization): 실행 계획을 생성하고 비용(Cost)을 계산.
3. 실행(Execution): 최적의 실행 계획에 따라 데이터를 검색.

6-2. 실행 계획

• 실행 계획은 테이블 스캔, 인덱스 스캔, 조인 전략 등을 포함합니다.
• 테이블 스캔: 모든 데이터를 순차적으로 검색.
• 인덱스 스캔: 인덱스를 사용하여 필요한 데이터만 검색.

---

 

7. 동시성 제어와 잠금(Locking)

여러 사용자가 동시에 데이터를 읽고 쓸 수 있도록 동시성 제어가 필요합니다.

7-1. 락(Lock)

• 데이터 수정 시 충돌을 방지하기 위해 잠금을 사용합니다.
• 행 수준 잠금(Row-Level Lock): 특정 행에만 잠금을 설정.
• 테이블 수준 잠금(Table-Level Lock): 테이블 전체에 잠금을 설정.

7-2. MVCC(Multi-Version Concurrency Control)

• 트랜잭션 별로 데이터의 스냅샷을 제공합니다.
• 데이터를 읽을 때 다른 트랜잭션의 쓰기 작업에 영향을 받지 않습니다.

---

 

8. 백그라운드 작업

데이터베이스는 성능을 유지하기 위해 여러 백그라운드 작업을 수행합니다.

• Checkpointing: 변경된 데이터를 디스크에 주기적으로 기록.
• Vacuuming: 삭제된 데이터 정리(PostgreSQL 등에서 사용).
• Auto-Tuning: 데이터베이스 설정을 자동으로 조정.

---