RDBMS 아키텍처(MySQL)

DB와 연결한 서버에서(spring) DB api를 이용해 쿼리를 보낸 경우를 생각해보자. 객체 간 역할 분담이 잘 되어 있다면 프로그래머는 DBMS에서 어떤 일이 벌어지는지 신경 쓸 필요가 없다. 그래도 가끔은 상상해본다.  내가 요청한 쿼리가 어떻게 처리될까? 또, 내가 요청한 쿼리가 DBMS와 협업하기에 최적의 쿼리일지 의심이 될 때도 있다.

 

 

 

아키텍처

큰 그림은 항상 머릿속에 담자두자.

 

- 파서 : 요청받은 쿼리를 토큰 단위로 잘라 문법 체크를 해준다.

- 전처리기 : 토큰 단위로 객체를 테이블 또는 내장 메서드로 매핑한다.

- 옵티마이저 : 요청받은 쿼리의 최적화를 담당

- 쿼리 실행기 : 핸들러를 이용해 스토리지 엔진에게 결과 요청 및 결과 사용자에게 반환

- 스토리지 엔진 : 쿼리 실행기에게 전달받은 요청을 내부적으로 처리(IO여부 판단 등등)

 

 

InnoDB 스토리지

- 자동 데드락 감지 : 데드락 발생 시 롤백이 가장 적은 트랜젝션 롤백

- Non-locking consistencd read : undo 로그를 이용해 A트랜젝션에서 레코드a에 update작업을 하고 있다면 B트랜젝션도 update완료 전의 레코드a에 접근할 수 있다.

- InnoDB 버퍼 풀 지원 : 데이터와 인덱스를 모두 캐싱하여 쓰기 지연을 통한 배치 작업으로 성능 개선

undo로그를 지원하여 편리한 롤백 및 유연한 트렌젝션 격리 수준 적용 가능