데이터베이스의 물리적 구조
데이터베이스는 물리적으로 위와 같이 저장된다.
MySQL Workbench나 Datagrip, SQL Command Line과 같이 사용자가 편하게 DBMS를 이용할 수 있게 하는 GUI TOOL이 있고 이를 바탕으로 DBMS가 작동하는 것이다.
- 실제 데이터가 저장되는 곳은 보조기억장치(HDD, SSD, USB 메모리 등..)
- 가장 많이 사용되는 장치는 하드디스크
[InnoDB]
InnoDB에는 DBA(Database Administrator)에게 중요한 정보들이 나온다. Deadlock 정보, 버퍼 풀 정보, 트랜잭션 정보 등.. 지금은 실제 운영 중인 서버가 아니고 그냥 명령어를 테스트해본 것이라 중요한 정보는 딱히 없다.
InnoDB는 서버 상태에 따라 1초에 한 번씩 백그라운드 작업을 수행하는 소스 Thread가 있다.
ex. SHOW ENGINE INNODB STATUS 하는 경우 InnoDB 모니터에서 저장한 스토리지 엔진 상태에 대한 정보를 표시해준다. 분석 시점에 대한 결과를 출력할 수 있다.
MySQL
[MySQL의 DBMS 구조]
MySQL은 크게 서버 엔진과 스토리지 엔진으로 구성되어 있다.
- 서버 엔진 : 클라이언트가 Query를 요청했을 때, 쿼리 파싱과 스토리지 엔진에 데이터를 요청하는 작업 수행
- 스토리지 엔진 : 물리적 저장장치에서 데이터를 읽어 오는 역할을 담당
[스토리지 엔진]
- 직접적으로 데이터를 다루는 역할이므로 엔진 종류마다 동작 원리가 다르고, 따라서 트랜잭션이나 성능과 같은 주요 이슈에 밀접하게 연관되어 있다.
- 기본적으로 8가지의 스토리지 엔진이 탑재되어 있음(
SHOW ENGINES로 확인 가능) - MySQL은 Plug-in 방식이므로 스토리지 엔진 교체 작업이 비교적 간단함
- InnoDB는 가장 많이 쓰이는 스토리지 엔진 중 하나로 따로 스토리지 엔진을 명시하지 않았을 때 default로 설정되는 스토리지 엔진
(default storage engine. CREATE TABLE t1 (i INT) ENGINE = INNODB;)
<대표적인 스토리지 엔진>
-
InnoDB : transaction-safe, 커밋과 롤백, 데이터 복구 기능 제공. 기본적으로 row-level locking을 제공하고, 데이터를 clustered index에 저장해 PK 기반의 query I/O 비용을 줄임. FK 제약(cascade와 같은..)을 제공해 데이터 무결성을 보장.
-
MyISAM : 트랜잭션 지원 X, table-level locking 제공. 파티셔닝 지원.
=> multi-thread 환경에서 성능 저하 가능성 있음. 특정 세션이 테이블을 변경하는 동안 테이블 단위로 lock -
Archive : 로그 수집에 적합한 엔진. 데이터가 메모리 상에서 압축되고 압축된 상태로 디스크에 저장이 되기 때문에 row-level lokcing 가능. BUT!! 한번 INSERT된 데이터는 UPDATE, DELETE 사용 불가하며 인덱스 지원하지 않음. 테이블 파티셔닝 지원, 트랜잭션 지원
=> 가공하지 않을 원시 로그 데이터 관리에 효율적
[MySQL 주요 스레드 종류]
- Master Thread :백그라운드 스레드 관리 및 다양한 작업들의 스케줄링을 담당. 비동기 새로고침 및 데이터 일관성 처리 담당
- IO Thread : 비동기 I/O 모델을 사용해 다양한 유형의 I/O 요청 콜백처리 담당. Insert Buffer(Change Buffer)의 머지, 트랜잭선 로그 작성, 다양한 유형의 Read/Write 요청 처리
- Purge Thread : DELETE 쿼리 등에 의해 삭제 표시된 레코드를 물리적으로 제거하는 작업을 하는 스레드(like 가비지 컬렉션)
- Page Cleaner Thread : Buffer Pool의 Dirty Page를 디스크로 flush
인덱스
도서의 색인이나 사전처럼 데이터를 쉽고 빠르게 찾을 수 있도록 만든 데이터 구조
인덱스의 특징
1. 테이블에서 한 개 이상의 속성을 이용해 생성
2. 빠른 검색과 함께 효율적인 레코드 접근 가능
3. 순서대로 정렬된 속성과 데이터의 위치만 보유하므로 테이블보다 작은 공간 차지
4. 저장된 값들은 테이블의 부분집합이 됨
5. 일반적으로 B-tree 구조
6. 데이터의 수정/삭제 등 변경 발생 시 인덱스 재구성 필요
그냥 느낀 점..
테이블별로 이렇게 다른 스토리지 엔진을 개발자가 직접 설정해줄 수 있는지 몰랐다. 웬만하면 다른 스토리지 엔진을 설정해야 하는 상황이 발생하지 않겠지만 이런 걸 알고 있다는 자체가 추후에 도움이 될 것 같다는 생각이 든다.
그리고 이번 블로그 내용에 담진 않았지만 스토리지 엔진별 차이점 보면서 row-level locking과 tabel-level locking, optimistic lock에 대해서 추가로 공부해봤는데 이제는 티켓팅할 때 왜 이미 선택된 좌석입니다.가 뜨는 건지 친구들한테 잘 설명해줄 수 있을 것 같다.. 이 글 참고
티켓팅 앱 같은 경우에는 속도를 위해서 낙관적 로킹 기법을 사용하기 때문인듯. ㅜ.ㅜ
생각해보면 나같아도 선택부터 안돼서 답답하게 하는 것보단 일단 선택되지만 이선좌 뜨게 개발할 것 같다.
동시성 제어에 대해서 한발자국 가까워진듯.. GOOD
참고자료
[MySQL] 주요 스토리지 엔진(Storage Engine) 간단 비교
MySQL Documentation - Chapter 15 Alternative Storage Engines
[MySQL] InnoDB 스토리지 엔진 상태 모니터링
MySQL Architecture - 3. Thread
