[데이터베이스] DBMS와 옵티마이저

MySQL 기준

사용할 땐 하더라도 내부 엔진을 알고 사용하자클라이언트-서버 아키텍처

 

 

 

클라이언트 층

서버에 명령, GUI

• Connection Handling : 클라이언트가 서버에 접속하면 연결을 클라이언트는 위한 스레드를 얻음
• Authentication : Mysql에 연결할 때 서버쪽에서 수행, username과 password로 인증
• Security : 서버와 연결된 후 특정 사용자에게 쿼리 권한이 있는지 확인

서버 층 (a.k.a “Brain of MySQL Architecture”)

RDB의 논리적인 기능을 책임짐

• Thread Handling : 연결된 클라이언트가 스레드를 할당받을 때 그 스레드를 제공, 스레드로 실행되는 클라이언트 쿼리들을 핸들링
• Parser : SQL을 분석해 문법 검사, 구성요소 파악 후 자료구조(parse tree)를 만듦.
• Optimizer : 파싱이 끝나면 다양한 최적화 기술이 적용됨. 쿼리, 테이블 스캔 순서 재작성이라든지 인덱스를 사용한다든지…
• Query Cache : 쿼리 결과를 캐싱해놓음. 파싱 전 쿼리 캐시를 확인하여 사용. (야호~! 파싱, 최적화, 실행을 건너 뜀!)
• Buffer and Cache : 캐시와 will buffer(??)는 쿼리나 발생했던 문제를 저장함 (Cache and will buffer store the previous query or problem asked by user.)
• Table Metadata Cache : 데베, 인덱스 같은 메타정보가 저장되어 있음
• Key Cache : 유일한 index entry가 저장되는 곳. 기본적으로 엣지 서버가 전체 리소스 경로나 쿼리에 기반한 내용을 캐싱함

저장소 층

MySQL 저장소 엔진 덕분에 개발자들이 DB엔진으로 가장 선호함!

• MySQL의 특징 : easy, security, client-server architecture, free, scalable multithreading, fast, flexible, various OS, allow transactions to be rolled back/commit/recovery, low memory leak, dual password(버전 8), partitioning ⇒ 싸다! 빠르다! 유연하다! 멀티스레딩! 적은 메모리!

https://www.geeksforgeeks.org/architecture-of-mysql/

---

옵티마이저에 대하여

(그냥 찾아보고 싶어서, 참고 : https://coding-factory.tistory.com/743)

규칙 기반 옵티마이저 (RBO)

실행 속도가 빠른 순으로 규칙을 먼저 세워두고 우선순위가 앞서는 방법을 채택, 과거에는 옵티마이저의 비용을 예측하는 능력이 그다지 좋지 않아 이러한 방식을 사용

 

비용 기반 옵티마이저

최근 많이 사용하는 방식, 오라클10 이후부터는 비용 기반 옵티마이저만 사용

옵티마이저에서 실행 계획을 세운 뒤(최대 2천개까지) 비용이 최소한으로 나온 실행 계획을 수행 (비용을 예측하기 위해서 규칙 기반 옵티마이저가 사용하지 않는 테이블, 인덱스, 칼럼 등의 다양한 객체 통계정보와 시스템 통계정보를 이용)

• 주요 통계 정보들

 

 

 

 

옵티마이저는 결코 만능은 아니다!

통계 정보만 가지고는 비용 결과가 정확하지 않음.

비용 산정이 쿼리 단독으로 실행된다고 가정하기 때문에 실제 비용과 달라질 수 있음.

→ DB/쿼리 튜닝할 땐 실행계획을 확인하고 비효율적인 작동을 인지해야 함

⇒ 그냥 개발자가 잘해야 함

사용할 땐 하더라도 내부 엔진을 알고 사용하자

클라이언트-서버 아키텍처