목차
개요
본 포스팅은 Oracle, MySQL의 공식문서를 참고 하였다.
https://dev.mysql.com/doc/refman/8.4/en/glossary.html#glos_segment
MySQL :: MySQL 8.4 Reference Manual :: MySQL Glossary
MySQL 8.4 Reference Manual / MySQL Glossary These terms are commonly used in information about the MySQL database server. A .ARM file Metadata for ARCHIVE tables. Contrast with .ARZ file. Files with this extension are always included in backups produce
dev.mysql.com
https://docs.oracle.com/cd/B13789_01/server.101/b10743/logical.htm
2 Data Blocks, Extents, and Segments
Oracle maintains information to nullify changes made to the database. Such information consists of records of the actions of transactions, collectively known as 'undo.' Oracle uses the undo to do the following: Automatic undo management is undo-tablespace
docs.oracle.com
용어 및 개념 설명
데이터베이스의 물리적 구조는 일반적으로 다음과 같은 구성 요소로 이루어져 있다. 범위가 넓은 순서대로 작성해보았다.
1. 테이블스페이스 (Tablespace)
2. 데이터 파일 (Data File)
3. 세그먼트 (Segment)
4. 익스텐트 (Extent)
5. 데이터 블록 (Data Block) 또는 페이지 (Page)
1. 테이블스페이스 (Tablespace)
테이블스페이스는 데이터베이스의 논리적 저장 단위로, 하나 이상의 데이터 파일로 구성된다.
데이터베이스 객체(테이블, 인덱스 등)를 저장하는 공간을 제공한다.
예시: 사용자가 생성한 테이블스페이스, 시스템 테이블스페이스, 임시 테이블스페이스 등이 있다.
2. 데이터 파일 (Data File)
데이터 파일은 테이블스페이스를 구성하는 물리적 파일로, 실제 데이터를 저장하는 단위.
예시: userspace01.dbf, system01.dbf 등.
3. 세그먼트 (Segment)
세그먼트는 테이블, 인덱스, LOB 등 데이터베이스 객체의 데이터를 저장하는 논리적 저장 단위.
테이블 세그먼트: 테이블 데이터 저장
인덱스 세그먼트: 인덱스 데이터 저장
LOB 세그먼트: 대용량 객체(BLOB, CLOB) 저장
임시 세그먼트: 임시 데이터 저장
언두 세그먼트: 트랜잭션 복구를 위한 undo 데이터 저장
MySQL에서는 Oracle과 달리 별도의 LOB(Large Object) 세그먼트가 존재하지 않다.
MySQL InnoDB 스토리지 엔진은 LOB 데이터(BLOB, TEXT 등)를 테이블의 기본 세그먼트에 저장하고 필요에 따라 기본 행 데이터와 연결한다.
4. 익스텐트 (Extent)
익스텐트는 연속된 데이터 블록의 집합으로, 세그먼트를 구성한다. 세그먼트가 필요한 저장 공간을 모두 사용하면 새로운 익스텐트를 할당받는다.
예시: 각 익스텐트는 특정 세그먼트에 속하며, 크기는 고정되거나 가변적일 수 있다.
5. 데이터 블록 (Data Block for Oracle) 또는 페이지 (Page for MySQL)
데이터 블록 또는 페이지는 데이터베이스의 가장 작은 저장 단위로, 데이터를 실제로 저장하는 공간이다.
각 데이터 블록은 운영 체제 블록의 배수로 설정된다.
Oracle은 DB_BLOCK_SIZE 파라미터를 이용해 사이즈를 지정하고 2KB~32KB까지 이용이 가능하다.
MySQL은 innodb_page_size 파라미터를 이용하고 5.5 버전이하 에서는 16KB 페이지 크기가 고정 되어있었지만 이후에는 다양한 크기를 지원한다.
두 DB 모두 서로 다른 블록 크기를 가지는 테이블 스페이스를 생성하는 다중 블록(페이지) 관리 기법 사용이 가능하다.
인덱스의 유무, 파티션의 유무에 따른 세그먼트 개수 예상해보기
예시 1: 파티션이 없는 테이블과 인덱스
상황: employees 테이블이 있으며, 인덱스가 3개(employee_id, last_name, department_id) 존재
세그먼트 개수:
• 테이블 세그먼트: 1개
• 인덱스 세그먼트: 3개
총 세그먼트 개수: 4개
예시 2: 파티션이 있는 테이블과 인덱스 (범위 파티션 2개, 인덱스 2개)
상황: sales 테이블이 범위 파티션 2개로 나누어져 있으며, 인덱스가 2개(sale_id, sale_date) 존재
세그먼트 개수:
• 테이블 세그먼트: 2개 (각 파티션당 1개)
• 인덱스 세그먼트: 4개 (각 파티션당 2개 인덱스)
총 세그먼트 개수: 6개
예시 3: 파티션이 있는 테이블과 인덱스 (범위 파티션 4개, 인덱스 2개)
상황: orders 테이블이 범위 파티션 4개로 나누어져 있으며, 인덱스가 2개(order_id, order_date) 존재
세그먼트 개수:
• 테이블 세그먼트: 4개 (각 파티션당 1개)
• 인덱스 세그먼트: 8개 (각 파티션당 2개 인덱스)
총 세그먼트 개수: 12개
파티션이 존재하는 경우, 테이블 세그먼트는 파티션으로 나누어져 개별 파티션이 각각 독립적인 세그먼트를 갖기 때문에 따라서 파티션된 테이블은 독립적인 “단일” 테이블 세그먼트를 가지지 않고, 각 파티션이 독립적으로 세그먼트를 갖게 된다.
마무리
구조 개념은 암기하고 넘어가면 되었지만 세그먼트들이 어떻게 작동하는지 쉽게 이해하기 위해 상황을 가정해서 세그먼트의 개수를 예상해보는 과정을 통해 확실히 알게 되었다.
'SQLP' 카테고리의 다른 글
| 데이터베이스 성능 최적화를 위한 하드 파싱과 소프트 파싱 : Spring 에서의 활용방법 (1) | 2024.06.05 |
|---|
