01. MySQL을 학습하는 이유
- DB랭킹 2위
- MySQL 뿐 아니라 현재 1 ~ 4위가 모두 관계형 DB
- 관계형DB는 아직까지도 가장 범용적으로 사용됨
- 백엔드 개발자는 높은 확률로 관계형 DB를 실무에서 다루게 될 것
물론 다른 데이터베이스를 몰라도 되는것은 아니다. 서로 단점을 보완하고 상호보완적이기 때문이다.
따라서 하나의 DB를 깊게 학습하고 다른종류의 데이터베이스도 반드시 학습해야 한다.
일단은 부담없고 인기많은 MySQL을 사용하려고 한다.
02. MySQL
Note:
데이터베이스는 데이터를 관리하는 서버이다. ( = MySQL server)
서버(Web)는 SQL을 통해서 MySQL에게 요청한다
2-1. MySQL 서버 아키텍처
- 2-1-1. 판단과 명령을 하는 두뇌의 역할 MySQL 엔진과
2-1-2. 수행을 담당하는 팔다리 역할의 스토리지 엔진이 있다.
2-1-1. MySQL 엔진
MySQL아키텍처 그림에서 MySQL엔진을 들여다보면
쿼리파서 -> 전처리기 -> 옵티마이저 -> 쿼리 실행기 로 나뉘어져 있음
-
쿼리파서
- SQL을 파싱하여 Syntax Tree를 만듬
- 문법 오류 검사가 이루어짐
- Syntax Tree가 만들어지는 과정
-
전처리기
- 쿼리파서에서 만든 Tree를 바탕으로 전처리 시작
- 테이블이나 컬럼 존재 여부, 접근권한 등 Semantic 오류 검사
Note:
위 두가지 과정은 컴파일 과정과 매우 비슷하다.
그러나, SQL은 프로그래밍 언어처럼 컴파일 과정에서 모든 것을 검증할 수 없음
따라서 매번 구문평가를 진행하게 된다.
- 옵티마이저
- 쿼리를 처리하기 위한 여러 방법들을 만들고, 각 방법들의 비용정보와 테이블의 통계정보를 이용해 비용을 산정
- 테이블 순서, 불필요한 조건 제거, 통계정보를 바탕으로 전략을 결정(실행 계획 수립)
- 옵티마이저가 어떤 전략을 결정하느냐에 따라 성능이 많이 달라진다.
- 항상 최적의 결정만 하지는 않기 때문에 개발자가 힌트를 사용해 도움을 줄 수 있다.
- 어떠한 결정을 했는지 보기 위한 explain 쿼리
- 쿼리실행기
- 옵티마이저가 결정한 방법대로 스토리지 엔진에게 요청을 보내는 작업을 함 (Handler API)
2-1-2. 스토리지 엔진
Note :
MySQL 스토리지 엔진은 플러그인 형태이다.
MySQL 엔진의 쿼리 실행기가 스토리지 엔진에 읽기/쓰기 요청하는 것을 Handler API라고 하며 Handler API를 만족하는 스토리지 엔진만 구현할 수 있다면 누구든지 MySQL에 스토리지 엔진을 추가할 수 있음
- 디스크에서 데이터를 가져오거나 저장하는 역할
- InnoDB, Mylsam 등 여러개의 스토리지 엔진이 존재
- MySQL 서버에서 MySQL 엔진은 한개만 존재하지만 스토리지 엔진은 여러개를 같이 쓸 수 있음
(8버전 이후부터는 InnoDB 엔진을 디폴트로 사용한다.)
- MySQL 서버에서 MySQL 엔진은 한개만 존재하지만 스토리지 엔진은 여러개를 같이 쓸 수 있음
2-2. InnoDB *참고
Note :
Transaction-safe 한 Storage Engine으로 MySQL에서 기본적으로 사용되고 있다. MyISAM 보다 많은 기능을 제공한다.
사용 이유
- 대용량의 데이터를 컨트롤하는 경우
- 트랜잭션 관리가 필요한 경우
- 복구가 필요할 경우
- 정렬등의 구문이 들어가는 경우
- IUD 등이 빈번하게 발생하는 경우
- 높은 퍼포먼스가 필요한 대용량 사이트에 적합
장점
- 데이터 무결성이 보장
- 동시성 제어가 가능
- 제약조건, 외래 키 생성이 가능
- Row-level Lock (행 단위 Lock)을 사용하기 때문에 속도가 빠름
단점
- 복구가 어려움
- Dead lock 발생 가능성 있음
- 시스템 자원을 많이 차지함
3. 인사이트
3-1. 쿼리캐시(MySQL), 소프트 파싱(Oracle)
3-1-1. MySQL 5.0ver 아키텍처
MySQL 5버전에는 쿼리캐시가 있었다.
그러나 8.0 대에 들어와서 폐기 됐다.
데이터를 직접 캐싱하기 때문에 테이블의 데이터가 변경 되면 캐시된 데이터도 함께 변경되어야 하지만, lock이슈 같은 문제 들로 인해 쿼리캐시가 주는 이점보다 문제점이 더 크다고 판단돼 사라졌다고 한다.
3-1-2. Oracle
-
소프트 파싱 : SQL, 실행 계획을 캐시에서 찾아 옵티마이저 과정을 생략하고 실행 단계로 넘어감.
-
하드 파싱 : SQL, 실행계획을 캐시에서 찾지 못해 옵티마이저 과정을 거치고나서 실행단계로 넘어감.
MySQL에는 소프트 파싱이 없다.
(5버전 까지는 쿼리캐시가 존재)
- 쿼리캐시 :
SQL에 해당하는 데이터를 저장하는 것
테이블의 데이터가 변경 되면 캐시된 데이터도 함께 변경되어야 한다.
Oracle에는 소프트 파싱이 존재
- 소프트파싱 : 실행 계획 까지만 캐싱
모든 SQL과 매핑하여 데이터까지 캐싱하지 않는다.
3-1-3. 비교
공통점 :
두 가지 기술의 배경은 모두 성능 최적화
차이점 :
- 캐싱의 범위가 다르다.
- 조회성능
쿼리캐시 > 소프트 파싱 - 캐시 데이터 관리 비용
쿼리캐시 < 소프트 파싱
결론
모든 기술은 트레이드 오프 이다.
사용하려는 기술의 장단점을 파악하고 어느 부분에 초점을 맞추느냐에 따라 기술을 선택하면 된다. 개발에 정답이 없는 이유이다.
A, B 기술을 그냥 사용하기 보다 적재적소에 사용할 수 있는 개발자가 되는것을 목표로 한다.
