일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- 스프링요청반응
- DispatcherServlet
- 중첩클래스
- 클라이언트요청반응
- biblecash
- multipart바인딩
- Wrapper class
- fcm성능비교
- 왜불변객체인가
- 불변객체
- 동등성동일성
- 래퍼클래스
- fcmv1
- 프로세스 생성
- 동기비동기블로킹논블로킹
- java enum
- HttpServlet
- 공유기작동방식
- 데이터베이스파서
- rest api 검증
- 디스패처서블릿
- 검증 실패 예외처리
- httpservlet기술
- HTTP프로토콜
- fcm데이터구조
- 옵티마이저
- equals
- multiparfile데이터
- rest api
- 옵티마저
- Today
- Total
개발은 아름다워
[ Database ] 데이터에 접근하는 방법은 어떻게 결정할까? 본문
데이터 접근 절차를 결정하는 모듈 : 쿼리 평가 엔진
쿼리 평가 엔진은 사용자로부터 입력 받은 SQL구문을 처음 읽어들이는 모듈이다. 쿼리 평가 모듈은 추가로 파서 또는 옵티마이저와 같은 여러 개의 서브 모듈로 구성된다.
- 쿼리평가엔진이 사용자로부터 입렵받은 SQL문을 읽어들임
- 파서
- 옵티마이저에서 플랜 생성 후 비용 평가
- 카탈로그 매니저
- 플랜평가로 실행 계획을 알려줌
파서
파서의 역할은 구문을 해석하는 것이다. 왜냐하면 사용자로부터 입력 받은 SQL 구문이 항상 구문적으로 올바르다는 보증할 수 없기 때문이다. 예를 들어 FROM 구에 존재하지 않는 테이블 이름을 쓰는 경우 서류 심사에서 미리 떨어뜨리는 것이다.
또한 파서는 SQL 구문을 정형적인 형식으로 변환해준다. 그렇게 해야 DBMS 내부에서 일어나는 후속 처리가 효율화 되기 때문이다.
옵티마이저
서류 심사를 통과한 쿼리는 옵티마이저로 전송된다. 옵티마이저의 한국어 번역은 ‘최적화’이다. 이 때 최적화의 대상은 데이터 접근법(실행 계획)이다. 옵티마이저가 DBMS 두뇌의 핵심이다.
옵티마이저는 인덱스 유무, 데이터 분산 또는 편향 정도, DBMS 내부 매개변수 등의 조건을 고려해 선택 가능한 많은 실행계획을 작성하고(플랜 계획) 이들의 비용을 연산하고(비용 평가) 가장 낮은 비용을 가진 실행 계획을 선택한다.
카탈로그 매니저
옵티마이저가 실행 계획을 세울 때 옵티마이저에 게 중요한 정보를 제공하는 것이 카탈로그 매니저이다. 카탈로그란 DBMS의 내부 정보를 모아놓은 테이블들로, 테이블 또는 인덱스의 통계 정보가 저장되어 있다. 따라서 이러한 카탈로그 정보를 간단하게 ‘통계 정보’라고 부르기도 한다.
플랜 평가
옵티마이저가 SQL 구문에서 여러 개의 실행 계획을 세운 뒤 그것을 받아 최적의 실행 결과를 선택하는 것이 플랜 평가이다. 실행 계획이라는 것이 곧바로 DBMS가 실행할 수 있는 형태의 코드가 아니다. 실행 계획은 오히려 인간이 읽기 쉽게 만든 ‘계획서’이다. 따라서 성능이 좋지 않은 SQL 구문이 있을 떄 실행 계획을 읽고 수정 방안 등을 고려할 수 있다.
최적의 실행 결과 하나를 선택하면, 이후에 DBMS는 실행 계획을 절차적인 코드로 변환하고 데이터 접근을 수행한다.
이상이 DBMS가 쿼리를 읽어들여 실제로 데이터 접근을 수행할 때까지의 흐름이다.
옵티마이저와 통계 정보 (Garbage In, Garbage Out)
중요한 것은 옵티마이저를 잘 사용하는 것이다. 예를 들어 플랜 선택을 옵티마이저에게 맡기는 경우, 실제로 최적의 플랜이 선택되지 않는 경우가 꽤 많다. 대표적인 원인은 통계 정보가 부족한 경우이다.
구현에 따라 차이가 있지만 카탈로그에 포함되어 있는 통계 정보는 다음과 같은 것들이다
- 각 테이블의 레코드 수
- 각 테이블의 필드 수와 필드의 크기
- 필드의 카디널리티(중복성의 정도)
- 필드 값의 히스토그램
- 필드 내부에 있는 NULL의 수
- 인덱스 정보
이러한 정보를 가진 카탈로그를 활용함으로써 옵티마이저는 실행 계획을 만든다. 문제가 생기는 경우는 이러한 카탈로그 정보가 테이블 또는 인덱스의 실제와 일치하지 않을 때 발생한다.
테이블에 데이터 삽입/갱신/제거가 수행될 때 카탈로그 정보도 갱신되지 않는다면, 옵티마이저는 오래된 정보를 바탕으로 실행 계획을 세우게 된다. 옵티마이저는 과거 정보밖에 가지고 있지 않으므로 어쩔 수 없이 잘못된 계힉을 세울 수 밖에 없게 되는 것이다.
극단적인 예로 테이블을 만들면 일단 레코드 0개의 상태로 카탈로그 정보가 저장된다. 그런데 이후에 1억 건의 데이터를 올리고 카탈로그 정보를 갱신하지 않는다면 옵티마이저는 데이터 0개를 기준으로 플랜을 세우게 되는 것이다. 이렇게 된다면 절대로 최적의 플랜을 세울 수 없는 것이다.
최적의 실행 계획이 작성되기 위해서는?
올바른 통계 정보가 모이는 것은 SQL 성능에 있어서 굉장히 중요한 문제이다. 따라서 테이블의 데이터가 많이 바뀌면 카탈로그의 통계 정보도 함꼐 갱신해야 한다는 것은 엔지니어에게 상식이다. 수동으로 갱신하는 것뿐만 아니라, 데이터를 크게 갱신하는 배치 처리가 있을 때는 Job Net을 조합하는 경우 등이 있다.
'데이터베이스' 카테고리의 다른 글
정규화 좀! 쉽고 간단하고 명료하게 정리해보자 (1) | 2024.10.04 |
---|