MySQL의 논리적 아키텍처

크게 3개의 층으로 나뉘어 있는 형태. 클라이언트 -> 핵심 엔진들 -> 스토리지 엔진으로 이어진다. 

  • 클라이언트는 -> DB서버 그 자체가 아닌, 더 앞단에 위치하고 있는, 웹서버나 사용자 접속 툴등 DB로 접속해 들어오는 부분을 뜻한다. 즉, 클라이언트는  MySQL 서버 그 자체의 동작 방식과는 아무런 상관이 없다. 다만 MySQL에서 제공되는 접속 방식을 통해 접속해야 하므로 MySQL 아키텍처의 일부라 할 수도 있겠다.
  • 핵심 엔진들은 -> 연결된 사용자로부터, 쿼리를 전달받고, 분석하여, 어떻게 동작할 것인지 결정 짓고, 실제로 작동하여 결과를 얻어내는 등의 일련의 과정들을 의미한다. 
  • 스토리지 엔진은 -> MySQL에 데이터가 저장되고 검색되는 방식을 결정 짓는다. 이는 MySQL 핵식 엔진들과는 별개로 동작하며 Pluggable하다. 즉, 사용자가 직접 스토리지 엔진을 작성하여 추가한다거나, 3rd 파티 스토리지 엔진등을 구비하여 사용할 수도 있다는 것이다. 다시 말하자면, 스토리지 엔진은 단 한가지만 존재하는 것이 아니며, 또 MySQL 인스턴스에 꼭 하나의 스토리지 엔진만을 사용하지 않아도 된다. 테이블 마다 다 다른 스토리지 엔진을 사용해도 무방하다. 어떠한 스토리지 엔진을 상용하는지에 따라 제공되는 기능이 크게 달라지게 된다.

이 책에서 MySQL의 아키텍처를 크게 3가지로 나눈 것은, MySQL 소스의 입장에서 생각해보면 쉽게 이해가 될 것이다. DB에 실제 접속하여 쿼리를 하는 등, MySQL을 사용하게 될 툴을 작성해야 할 것이고(이를테면 웹사이트) / MySQL 전체적으로 동일하게 적용될 내용들에 대해 작성해야 할 것이다. (이를테면, 테이블에 컬럼을 추가하기 위해서 어떤식으로 동작할 것인지, 두개의 테이블로부터 데이터를 select하려 할 때에, 두 테이블을 어떤 방식으로 조인하여 데이터를 추출해내야 할는지와 같은 부분) / 그리고 마지막으로 MySQL만의 큰 특징이라 할 수 있는 Pluggable한 스토리지 엔진을 작성해야 된다. 

위에도 언급했다싶이 클라이언트는 MySQL 그 자체의 특징과는 상관 없는 부분이므로 MySQL에 대해 처음 공부하는 사람이라 할지언정 클라이언트가 뭔지는 이해했을 것이라 생각한다.

그렇다면 스토리지 엔진과, 그 외의 엔진들만 제대로 구분해서 생각해낼 수 있다면 MySQL의 논리적 아키텍처 부분은 이해하고 넘어가는 것이 아닐까한다. 

위 그림에서 쿼리 캐시를 빼고, (쿼리 캐시는 나중에 쿼리캐시 기능을 살펴볼때 언급하도록 하겠다.)  연결/스레드 핸들링 , 파서 , 옵티마이저 부분만 놓고 보도록하자. 이 기능들은 MySQL이라는 RDBMS에만 있는 기능이 아니라, 데이터베이스론이라는 학문에서 언급되고 있는 기능으로, 다른 대부분의 RDBMS들도 가지고 있는 기능이다. 

연결 관리와 보안

그 중에서 연결/스레드 핸들링의 경우, DB를 사용하려는 사용자로부터 어떻게 요청을 받고, 보안을 유지하며, 요청에 응대할 것인지에 대한 내용을 담당하고 있다. 

  • 사용자 접속 하나당 하나의 스레드를 사용하게 된다. 
  • 사용자가 실행하는 쿼리 역시 하나의 스레드 만을 사용하여 동작한다. 이 이야기는 즉, CPU를 하나밖에 사용할 수 없다는 이야기가 되며, MySQL 확장성에 발목을 붙잡는 이유 중 하나가 된다.
  • 연결 스레드들은 MySQL서버에 의해 캐싱되게 되므로, 접속을 해지하고, 또 접속을 맺을 때 마다, 스레드를 죽이고, 다시 생성하는 동작을 하지 않는다. 
  • MySQL 계정은 '계정명'@'IP주소'로 이루어 진다. 어떤 사용자가 MySQL에 접속하려 할 때에, 계정에 입력되어 있는 IP주소 이외의 호스트로부터 연결을 시도한다면 접근이 차단된다. 즉, 지정된 호스트로부터만 접속을 허용하며, 접속시 암호도 맞게 입력해야한다. 이렇게 계정명 / 호스트IP주소 / 암호에 의해 접속 보안이 이루어진다.
  • 접속이 이루어진 이후에는, 해당 사용자가 입력한 쿼리를 사용할 권한이 있는지를 다시 체크하게 된다. 즉, ABC 테이블에 대한 select 권한이 없는 사용자는 select * from ABC;라는 쿼리를 수행할 수 없다. 접속 계정에 대한 권한 체크가 이루어 진다는 것이다. (이부분은 연결/스레드 핸들링과 관련 있는 것이 아니라, 파서에 의한 구문 분석 과정중에 이루어지는 동작이다. 책이랑 조금 다르게 서술 하려다보니 어느쪽에 적어야할지....아무튼 책에선 이부분에 언급되어있어서 같이 적었다. ^^;;;) 

보안에 관한 더 상세한 내용은 12장에 다시 언급된다.
만약 MySQL 소스를 열어볼 생각이 있다면 커넥션에 관한 내용은 /sql/sql_connect.cc라는 파일에 포함되어있다. 위에 5개 항목 중 위로부터 4개의 항목은 이 파일에서 관련 사항을 확인해볼 수 있다. 마지막 항목은 구문 분석 단계에서 체크되므로, /sql/sql_parse.cc 파일에서 확인할 수 있다.

최적화와 실행

정상적으로 접속이 이루어지고, 쿼리가 입력되면 파서에 의해 해당 쿼리를 분석하게 된다. 파서(Parser)가 하는 일, 즉, 파스(Parse)란 원래 언어학에서 사용되는 용어로, 하나의 문장이 문법적으로 맞는 문장인지를 분석하는 일을 말한다. 즉 파서가 하는 일은, 사용자가 입력한 쿼리문이 문법에 맞는 문장인지를 체크하는 것이다. 

 

동시성 제어

 

읽기 / 쓰기 잠금

 

잠금 세분성

 

테이블 잠금

 

레코드 락

 

트랜잭션

원자성

일관성

독립성/격리

영속성

 

 

격리수준

커밋되지 않은 읽기(READ UNCOMMITTED)

커밋된 읽기(READ COMMITTED)

반복 읽기(REPEATABLE READ)

직렬화된 읽기(SERIALIZABLE)

 

데드락

 

트랜잭션 로깅

 

MySQL의 트랜잭션

자동 커밋(AUTOCOMMIT)

트랜잭션 내에서 여러 스토리지 엔진 사용하기

암시적 잠금과 명시적 잠금

 

MVCC(다중 버전 동시성 제어)

 

MySQL의 스토리지 엔진

 

MyISAM 엔진
MyISAM 머지 엔진
InnoDB 엔진
Memory 엔진
Archive 엔진
CSV 엔진
Federated 엔진
Blackhole 엔진
NDB 클러스터 엔진
Falcon 엔진
SolidDB 엔진
PBXT(Primebase XT) 엔진
Maria 엔진
그 밖의 스토리지 엔진
적합한 엔진 선택하기
고려사항

 

 

실용 예제

 

스토리지 엔진 요약

레이블 (0)

  • 레이블 없음
댓글 쓰기...

첨부 파일  (1)

첨부 파일 추가하기
  파일 변경됨
PNG 파일 MySQL01.png 1월 23, 2013 by 민항