jossiya

  데이터베이스 서버에서 테이블의 구조 정보와 스토어드 프로그램 등의 정보를 데이터 딕셔너리 또는 메타데이터라고 하는 는데, 5.7버전까지 테이블의 구조를 FRM 파일에 저장하고 일부 스토어드 프로그램 또한 파일(*.TRN ,*TRG ,*PAR, ...)기반으로 관리 했습니다. 하지만 이러한 파일 기반의 메타데이터는 생성 및 변경 작업이 트랜잭션을 지원하지 않기 때문에 테이블의 생성 또는 변경 도중에 MySQL 서버가 비정상적으로 종료되면 일관되지 않은 상태로 남는 문제가 있었습니다. 많은 사용자들이 이 같은 현상을 가리켜 '데이터베이스나 테이블이 깨졌다'라고 표현합니다.

  MySQL 8.0 버전부터는 이러한 문제점을 해결하기 위해 테이블의 구조 정보나 스토어드 프로그램의 코드 관련 정보르르 모두 InnoDB의 테이블에 저장하도록 개선됐습니다. MySQL서버가 작동하는 데 기본적으로 필요한 테이블들을 묶어서 시스템 테이블이라고 하는데, 대표적으로 사용자의 인증과 권한에 관현된 테이블들이 있습니다. MySQL 서버 8.0 버전부터는 이런 시스템 테이블을 모두 InnoDB 스토리지 엔진을 사용하도록 개선했으며, 시스템 테이블과 데이터 딕셔너리 정보를 모두 모아서 mysql DB에 저장하고 있습니다. mysql DB는 통째로 mysql.ibd라는 이름의 테이블스페이스에 저장됩니다. 그래서 MySQL 서버의 데이터 디렉터리에 존재하는 mysql.ibd라는 파일은 다른 *.ibd 파일과 함꼐 특별히 주의해야 합니다.

MySQL 8.0 버전부터 데이터 딕셔너리와 시스템 테이블이 모두 트랜잭션 기반의 InnoDB 스토리지엔진에 저장되도록 개선되면서 이제 스키마 변경 작업 중간에 MySQL 서버가 비정상적으로 종료되고 하더라도 스키마 변경이 완전한 성공 또는 완전한 실패로 정리가 됩니다. 기존의 파일 기반 메다테이터를 사용할 때와 같이 작업 진행 중인 상태로 남으면서 문제를 유발하지 않게 개선됬습니다.

MySQL 서버에서 InnoDB 스토리지 엔진을 사용하는 테이블은 메타 정보가 InnoDB 이외의 테이블들에 대해서는 SDI 포맷의 *.sdi 파일이 존재하며, 이파일은 기존의 *.FRM 파일과 동일한 역할을 합니다. 그리고 SDI는 이름 그대로 직렬화(Serailized)를 위한 포맷이므로 InnoDB 테이블들의 구조도 SDI 파일로 변환 할 수 있습니다. ibd2sdi 유틸리티를 이용하면 InnoDB 테이블 스페이스에서 스키마 정보를 추출할 수 있습니다.

linux> idb2sdi mysql_data_dir/mysql.idb > mysql_schema.json

linux > cat mysql_schema.json

mysql DB에 포함된 테이블의 스키마를 JSON 파일로 덤프하고, ibd2sdi 유틸리티로 추출한 데이블의 정보 중에는 Mysql 서버에서 SHOW TABLE 명령으로 학인 할 수 없던 mysql.tables 딕셔너리 데이터를 위한 테이블 구조도 볼 수 있습니다.

문제 설명

답 :

SELECT ROUND(AVG(DAILY_FEE),0)  AS  AVERAGE_FEE 

FROM CAR_RENTAL_COMPANY_CAR 

WHERE CAR_TYPE='SUV';

풀이 :

1. 평균 구하는 AVG 를 사용해 조건 컬럼 지정 후 AS(별칭) 사용해 원하는 컬럼명 적용

2. ROUND("값","자리수") -> 소수점 반올림 ->정수로 나타내야 하기 때문

3. WHERE절을 사용해 조건을 부여하여 원하는 ROW의 평균값을 구함

   ->WHERE 절 말고 GROUP BY 사용 가능

   -> SELECT round(avg(daily_fee) , 0) AS AVERAGE_FEE
       FROM car_rental_company_car
       GROUP BY car_type
       HAVING car_type = 'suv'

*WHERE 절은 각 데이터들에게 적요오디는 조건을 설정, 조건식에 그룹함수 사용 못함

*HAVING절은 각 그룹에 적용되는 조건을 설정 조건식에 그룹함수 사용 가능

쿼리파서

쿼리파서는 사용자 요청으로 들어온 쿼리 문장을 토큰(MySQL이 인식할 수 있는 최소 단위의 어휘나 기호)으로 분리해 트리 형태의 구조로 만들어 내는 작업을 의미합니다. 쿼리 문장의 기본 문법 오류는 이 과정에서 발견되고 사용자에게 오류 메시지를 전달하게 됩니다.

전처리기

파서 과정에서 만들어진 파서 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인합니다. 각 토큰을 테이블 이름이나 칼럼 이름, 또는 내장 함수와 같은 개체를 매핑해 해당 객체의 존재 여부와 객체의 접근 권한 등을 확인하는 과정을 이 단계에서 수행합니다. 신제 존재하지 않거나 권한상 사용할 수 없는 개체의 토큰은 이 단계에서 걸러집니다.

옵티마이저

옵티마이저란 사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지를 결정하는 역할을 담당하며, DBMS의 두뇌에 해당한다고 볼 수 있습니다. 

실행 엔진

옵티마이저가 두뇌라면 실행엔진과 핸들러는 손과 발에 비유할 수 있습니다(회사로 비유하자면 옵티마이저는 회사의 경영진, 실행 엔진은 중간 관리자, 핸들러는 각 업무의 실무자로 비유할 수 있습니다).

옵티마이저가 GROUP BY를 처리하기 위해 임시 테이블을 사용하기로 결정했다고 가정해보면,

1. 실행 엔진이 햔들러에게 임시테이블을 만들라고 요청

2. 다시 실행 엔진은 WHERE 절에 일치하는 레코드를 읽어오라고 핸들러에게 요청

3. 읽어온 레코드들을 1번에서 준비한 임시테이블로 저장하라고 다시 핸들러에게 요청

4. 데이터가 준비된 임시 테이블에서 필요한 방식으로 데이터를 읽어 오라고 핸들러에게 다시 요청

5. 최종적으로 살향 엔진은 결과를 사용자나 다른 모듈로 넘김

핸들러(스토리 엔진)

MySQL 서버의 가장 밑단에서 MySQL 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어 오는 역할을 담당합니다. 핸들러는 결국 스토리지 엔진을 의미하며, MyISAM 테이블을 조작하는 경우에는 핸들러가 MyISAM 스토리지 엔진이 되고 InnoD 테이블을 조작하는 경우에는 핸들러가 InnoDb 스토리지 엔진이 됩니다.

  MySQL의 독특한 구조 중 대표적인 것이 플로그인 모델입니다. 플러그인해서 사용할 수 있는 것이 스토리지 엔진만 있는 것이 아닙니다. 전문 검색 엔진을 위한 검색어 파서(인덱싱할 키워드를 분리해대는 작업)도 플러그인 형태로 개발해서 사용할 수 있으며, 사용자의 인증을 위핸 Native Authentication과 Caching SHA-2 Authentication 든도 모두 클러그인으로 구현되어 제공된다. MySQL은 이미 기본적으로 많은 스토리지 엔진을 가지고 잇습니다. 하지만 이 세상의 수많은 사용자의 요구 조건을 만족시키기 위해 기본적으로 제공되는 스토리지 엔진 이외에 부가적인 기능을 더 제공하는 스토리지 엔진이 피룡할 수 잇으며, 이러한 요건을 기초로 다른 전문 개발 회사 또는 사용자가 직접 스토리지 엔진을 개발하는 것도 가능합니다. 

  MySQL에서 쿼리가 실행되는 과정을 크게 나눈다면 거의 대부분의 작업이 MySQL엔진에서 처리되고 마지막 '데이터 읽기/쓰기' 작업만 스토리지 엔진에 의해 처리됩니다.(만약 사용자가 새로운 용도의 스토리지 엔진을 만든다 하더라도 DBMS의 전체 기능이 아닌 일부분의 기능만 수행하는 엔진을 작성하게된다는 의미입니다.)

위 그림의 각 처리 영역에서 '데이터 읽기/쓰기' 작업은 대부분 1건의 레코드 단위(예를 들어, 특정 인덱스의 레코드 1건 읽기 또는 마지막으로 읽은 레코드의 다음 또는 이전 레코드 읽기와 같이)로 처리됩니다. 그리고 MySQL을 사용하다 보면 '핸들러(Handler)'라는 단어를 자주 접하게 됩니다. 핸들러라는 단어는 MySQL 서버의 소스코드로부터 넘어온 표현인데, 이는 우리가 매일 타고다니는 자동차로 비유해 보면 쉽게 이해할 수 있습니다.   사람이 핸들(운전대)을 이용해 자동차를 운전하듯이, 프로그래밍 언어에서는 어떤 기능을 호출하기 위해 사용하는 운전대와 같은 역할을 하는 객체를 핸들러(또는 핸들러 객체)라고 표현합니다. MySQL 서버에서 MySQL 엔진은 사람 역할을 하고 각 스토리지 엔진은 자동차 역할을 하는데, MySQL 엔진이 스토리지 엔진을 조정하기 위해 핸들러라는 것을 사용하게 됩니다.

  MySQL에서 핸들러라는 것은 개념적인 내용이라서 완전히 이해하지 못하더라도 크게 문제가 되지는 않지만 최소한 MySQL 엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 반드시 핸들러를 통해야 한다는 점만 기억 해야 합니다. MySQL 상태 변수라는 것이 있는데, 상태 변수 가운데 'Handler_'로 시작하는 것이 많습니다. 'Handler_'로 시작하는 상태 변수는 'MySQL 엔진이 각 스토리지 엔진에게 보낸 명령의 횟수를 의미하는 변수'라고 이해하면 됩니다. MySQL에서 MyISAM이나 InnoDB와 같이 다흔 스토리지 엔진을 사용하는 테이블에 대해 쿼리를 실행하더라도 MySQL의 처리 내용은 대부분 동일하며, 단순히( 위 그림의 마지막 단계인) ' 데이터 읽기/쓰기' 영역의 처리만 차이가 있을 뿐입니다. 실직적인 GROUP BY나 ODER BY등 복잡한 처리는 스토리 엔진 영역이 아니라 MySQL 엔진의 처리 영역인 '쿼리 실행기'에서 처리됩니다.

그렇다면 MyISAM이나 InnoDB 스토리지 엔진 가운데 뭘 사용하든 별 차이가 없는 것 아닌가, 라고 생각 할수 있지만 그렇지 않습니다. 여기서 설명한 내용은 아주 간략하게 언급한 것일 뿐이고, 단순히 보이는 '데이터 읽기/쓰기'작업처리 방식이 얼마나 달라질 수 있는 지는 더 공부해보면 알 수 있습니다. 여기서 중요한 내용은 '하나의 쿼리 작업은 여러 하위 작업으로 나뉘는데, 각 하위 작업이 MySQL 엔진 영역에서 처리되는지 아니면 스토리지 엔진 영역에서 처리되는지 구분할 줄 알아야 합니다'는 점입니다. 사실 여기서는 스토리지 엔진의 개념을 알기 위한 것도 있지만 각 단위 작업을 누가 처리하고 'MySQL엔진 영역'과 '스토리지 엔진 영역'의 차이를 아는데 목적이 있습니다.

MySQL 서버에서 지원되는 스토리지 엔진 볼수 있습니다. ' mysql>SHOW ENGINES '

Support 컬럼에 표시 될 수 있는 값은 다음 4가지입니다.

-YES : MySQL 서버에 해당 스토리지 엔진이 포함돼 있고, 사용가능으로 활성화된 상태임

-DEFAULT : 'YES'와 동일한 상태이지만 필수 스토리지 엔진임을 의미함(즉, 이 스토리지 엔진이 없으면 MySQL이 시작되지 않을 수 있다는 걸 의미 합니다.)

-NO : 현재 MySQL 서버애 포함되지 않았음을 의미

-DISABLE : 현재 MySQL 서버에는 포함됐지만 파라미터에 의해 비활성화된 상태임

  MySQL 서버에 포함되지 않은 스토리지 엔진을 사용하려면 MySQL 서버를 다시 빌드해야 합니다. 하지만 MySQL 서버가 적절히 준비만 돼 있다면 플러그인 형태로 빌드된 스토리지 엔진 하이브러리를 다운로드해서 끼워 넣기만 하면 사용할 수 있습니다. 또한 플로그인 혀애의 스토리지 엔진은 손쉽게 업그레이드 할 수 있습니다. 스토리지 엔진뿐만 아니라 인증 및 전문 검색용 파서와 같은 플러그인도(설치돼 있다면) 확인 할 수 있습니다.

  MySQL 서버에서는 스토리지 엔진뿐만 아니라 다양한 기능을 플러그인 형태로 지원합니다. 인증이나 전문 검색 파서 또는 쿼리 재작성과 같은 플러그인이 있으며, 비밀번호 검증과 커넥션 제어 등에 관현된 다양한 플러그인이 제공됩니다. 그뿐만 아니라 MySQL 서버의 기능을 커스텀하게 확장할 수 있게 플러그인 API가 메뉴얼에 공개돼 있으므로 기존 MySQL 서버에서 제공하던 기능들을 확장하거나 완전히 새로운 기능들을 플러그인을 이용해 구현할 수도 있습니다.

컴포넌트

MySQL 8.0부터는 기존의 플러그인 아키텍처를 대체하기 위해 컴포넌트 아키텍처가 지원됩니다.

MySQL 서버의 플러그인은 다음과 같은 몇 가지 단점이 있는데, 컴포넌트는 이러한 단점들을 보완해서 구현됐습니다.

-플러그인은 오직 MySQL 서버와 인터페이스할 수 있고, 플러그인끼리는 통신할 수 없음

-플러그인은 MySQL 서버의 변수나 함수를 직접 호출하기 때문에 안전하지 않음(캡슐화 안 됨)

-플러그인은 상호 의전 관계를 설정할 수 없어서 초기화가 어려움

MySQL 5.7 버전까지는 비밀번호 검증 기능이 플러그인 형태로 제공됐지만 MySQL8.0의 비밀번호 검증 기능은 컴포넌트로 개선됐습니다.

컴포넌트의 간단한 사용법을 비밀번호 검증 기능 컴포넌트를 통해 살펴보면

--// validate_password 컴포넌트 설치

mysql> INSTALL COMPONENT 'file://componet_validtae_password';

--// 설치된 컴포넌트 확인

mysql>SELECT *FROM mysql.component;

플러그인과 마찬가지로 컴포넌트도 설치하면서 새로운 시스템 변수를 설정해야 할 수 도 있으니 컴포넌트를 사용하기 전에 관련 매뉴얼을 살펴보고 MySQL 서버에서 기본적으로 제공되는 컴포넌트에 대한 자세한 설명과 컴포넌트 개발과 관련된 메뉴얼을 참고해보면 좋습니다.

글로벌 메모리 영역

일반적으로 클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당됩니다. 단, 필요에 따라 2개 이상의 메모리 공간을 할당 받을 수도 있지만 클라이언트의 스레드 수와는 무관하며, 생성된 글로벌 영역이 n개라 하더라도 모든 스레드에 의해 공유됩니다. 대표적인 글로벌 메모리 영역은 다음과 같습니다.

 -테이블 캐시

 -InnoDB 버퍼 풀

 -InnoDB 어탭티브 해시 인덱스

 -InnoDB 리두 로그 버퍼

로컬 메모리 영역 

  세션 메모리 영역이라고도 표현하며, MySQL 서버상 존재하는 클라이언트 스레드가 쿼리를 처리하는 데 사용하는 메모리 영역입니다. 대표적으로 커넥션 버퍼와 정령(소트) 버퍼 등이 있습니다. 클라이언트가 MySQL 서버에 접속하면 MySQL서버에서는 클라이언트 커넥션으로부터의 요청을 처리하기 위해 스레드를 하나씩 할당하게 되는데, 클라이언트 스레드가 사용하는 메모리 공간이라고 해서 클라이언트 메모리영역이라고도 합니다. 클라이언트와 MySQL 서버와의 커넥션을 세션이라고 하기 때문에 로컬 메모리 영역을 세션 메모리 영역이라고도 표현합니다.

로컬 메모리는 각 클라이언트 스레드별로 독립적으로 할당되며 절대 공유되어 사용되지 않는다는 특징이 있습니다. 일반적으로 글로벌 메모리 여역의 크기는 주의해서 설정하지만 소트 버퍼와 같은 로컬 메모리 영역은 크게 신경 쓰지 않고 설정하는데, 최악의 경우(가능성은 희박하지만)에는 MySQL 서버가 메모리 부족으로 멈춰 버릴 수도 있으므로 적절한 메모리 공간을 설정하는 것이 중요합니다.로컬 메모리 공간의 또 한 가지 중요한 특징은 각 쿼리의 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우 MySQL이 메모리 공간을 할당조차도 하지 않을 수도 있다는 점입니다. 대표적으로 소트 버퍼나 조인 버퍼와 같은 공간이 그러합니다. 그리고 로컬 메모리 공간은 커넥션이 열려 있는 동안 계속 할당된 상태로 남아 있는 공간도 있고(커넥션 버퍼나 결과 버퍼) 그렇지 않고 쿼리를 실행하는 순간에만 할당했다가 다시 해제하는 공간(소트 버퍼나 조인 버퍼)도 있습니다.

  -정렬 버퍼(Sort buffer)

  -조인 버퍼

  -바이너리 로그 캐시

  -네트워크 버퍼

filter란?

필터는 DispatcherServlet 이전에 실행 되는데 필터가 동작하도록 지정된 자원 앞단에서 요청내용을 변경하거나, 여러가지 체크를 수행할 수 있습니다.

스프링 어플리케이션에서 빈으로 등록되지만 톰캣과 같은 웹 어플리케이션 서버에서 관리되며 자원의 터리가 끝난 후 응답내용을 변경하는 처리도 가능합니다.

일반적으로 인코딩 변환 처리, XSS방어 등의 처리로 사용됩니다.

필터 객체를 초기화해 서비스에 등록하는 init 메서드, url pattern에 맞는 모든 http 요청이 DispatcherServlet으로 전달 되기 전 Web Application Server에서 실행되는 doFilter 메서드, 필터 객체를 서비스에서 제거하고 사용하던 자원을 반환하는 destroy 메서드를 사용해서 구현합니다.

Interceptor란?

인터셉터는 스프링의 DispatcherServlet이 컨트롤러를 호출하기 전,후로 끼어들어 동작하며 스프링 컨텍스트 내부에서 컨트롤러에 관한 요청과 응답에 대해 처리합니다.

스프링의 모든 빈 객체에 접근할 수 있으며, 여러게의 인터셉터를 사용할 수 있고 로그인 체크, 권한 체크, 프로그램 실행시간 계산작업 로그확인 등의 업무에 인터셉터가 사용됩니다.

컨트롤러 메서드가 실행되기 전 처리하는 preHandler(), 메서드와 컨트롤러 메서드 실행 직 후 view 페이지가 렌더링 되기 전에 처리하는 postHandler(), view페이지가 렌더링 되고 난 후에 처리하는 afterCompletion()등의 메서드를 사용해 구현합니다.

AOP란?

OOP를 보완하기 위해 나온 개념(관점 지향 프로그래밍)

객체 지향 프로그래밍을 했을 때 중복을 줄일 수 없는 부분을 줄이기 위해 종단면(관점)에서 바라보고 처리합니다.

주로 '로깅', '트랜젝션', '에러처리'등 비지니스단의 메서드에서 조금 더 세밀하게 조정하고 싶을 때 사용합니다.

Intercaptor나 Filter와는 달리 메소드 전후에서 자유롭게 설정이 가능합니다.

Interceptor와 Filter는 주소로 대상을 구분해서 걸러내는 반면, AOP는 주소, 파라미터, 어노테이션 등 다양한 방법으로 대상을 지정할 수 있습니다.

AOP의 Advice와 HandlerInterceptor의 가장 큰 차이는 파라미터의 차이입니다. Advicer의 경우 JoinPoint나 ProceedingJoinpoint 등을 활용해서 호출하는 반면 HandlerInterceptor는 Filter와 유사하게 HttpServletRequest, HttpServletResponse를 파라미터로 사용합니다.