안녕하세요. 데브코스 발표 스터디에서 옵티아미저라는 주제로 발표를 맡게 된 김소현입니다. 하하하.
데브코스에서 속해있는 팀에서는 발표 스터디를 진행한다 >_0 당시 아프고.. 바빠서.. 슬랙 확인을 늦게 한 나! 남은 주제를 가져가게 되었는데 그게 바로 옵티마이저였다-! 완전 처음 들어보는 용어 @! 하지만 오히려 조아 ~!~!
옵티마이저 (Optimizer)
- 가장 효율적인 방법으로 SQL 쿼리를 수행 할 최적의 처리 경로를 생성하는 DBMS 내부의 핵심 엔진
- 컴퓨터의 CPU 역할
- 사용자가 구조화 된 질의(SQL)로 결과 집합을 요구하면, 이를 생성하는 데 필요한 처리 경로를 계획한다. ( = 실행 계획)
- 실행 계획을 세우고, 통계 정보를 활용하여 각 예상 비용을 산정 및 비교해서 최고 효율을 가지는 실행 계획을 판별 및 수행한다.
최적화 과정
1. 사용자가 요구한 쿼리 수행을 위해 후보군이 될 만한 실행 계획을 찾는다.
2. 미리 수집한 통계 정보를 이용해서 각 실행 계획의 예상 비용을 산정한다. (Data Dictionary 에 미리 수집되어 있는 통계 정보 활용)
3. 각 실행 계획을 비교해서 최적의 것을 선택한다. (최저 비용)
종류
규칙 기반 옵티마이저 (RBO, Rule Based Optimizer)
- 실행 속도가 빠른 순으로 규칙을 세우고 우선순위가 높은 방식을 채택한다.
- 비용을 예측하는 능력이 좋지 않았던 과거에서 주로 사용하던 방식이다.
- 인덱스 구조, 연산, 조건절 형태 등을 주요 요인으로 하여 우선 순위를 결정한다.
- 우선 순위가 존재하기 때문에, 실행 계획이 세워지는 것을 미리 예측할 수 있다. (사용자가 원하는 방향으로 실행 계획 유도도 가능)
- 우선 순위에 의해 비효율적인 계획이 세워질 수 있다. (FULL TABLE SCAN이 유리한 경우에서 INDEX를 확인하는 비효율적인 방식)
비용 기반 옵티마이저 (CBO, Cost Based Optimizer)
- 실행 계획을 세운 후, 비용을 기반으로 최적하 수행 (비용은 쿼리를 수행하는데 소요되는 일의 양 또는 시간을 의미한다.)
- 최근에 많이 사용되는 방식이다.
- 비용을 예측하기 위해 예상치를 사용한다. (객체 및 시스템 통계 정보를 기반으로 예상치를 세운다.)
- 정확한 통계 정보를 필요로 한다.
최적화 목표
전체 처리 속도 최적화
- 쿼리의 최종 결과를 끝까지 읽는 것을 전제로 하여, 시스템 리소스(자원)를 가장 적게 사용하는 실행 계획을 선택한다.
- 대부분의 DBMS 기본 옵티마이저 모드는 전체 처리 속도 최적화 모드로 되어 있다.
최초 응답 속도 최적화
- 전체 결과 집합 중 일부만 읽다가 멈추는 것을 전제로 하여, 가장 빠른 응답 속도를 낼 수 있는 실행 계획을 선택한다.
- 해당 모드로 실행한 결과를 끝까지 읽을 경우 전체 처리 속도 최적화보다 더 많은 리소스를 사용하고 실행 속도 또한 느려질 수 있다.
영향을 미치는 요소
SQL과 연산자 형태
결과가 같더라도 SQL 을 어떤 형태로 작성했는지 또는 어떤 연산자를 사용 했는지에 따라 달라진다.
옵티마이징 팩터
인덱스, IOT, 클러스터링, 파티셔닝 등을 어떻게 구성 했는지에 따라 실행 계획과 성능이 달라진다.
DBMS 제약 설정
무결성을 위해 DBMS에서 제공하는 다양한 제약 설정은 쿼리 성능을 최적화하는데 중요한 정보를 제공한다.
옵티마이저 힌트
사용자가 지정한 옵티마이저 힌트가 우선된다.
통계 정보
CBO의 판단 기준이 된다. 즉, 통계 정보의 정확성에 따라 영향을 미친다.
옵티마이저 관련 파라미터
옵티마이저 모드 등과 같이 설정할 수 있는 옵티마이저 관련 파라미터
DBMS 버전과 종류
DBMS 버전에 따라 실행 계획이 다를 수 있다. (내부적으로 처리하는 방식이 다르기 때문)
한계점
옵티마이징 팩터의 부족
주어진 환경에서 최적의 실행 계획을 수립하기 위해 정해진 기능을 수행할 뿐이다. 아무리 기술적으로 뛰어나도 사용자가 적절한 옵티마이징 팩터를 제공해주어야 좋은 실행 계획을 수립할 수 있다.
통계 정보의 부정확성
최적화에 필요한 모든 정보를 수집해서 보관할 수 있다면 옵티마이저도 그만큼 고성능 실행계획을 수립하겠지만, 100% 정확한 통계정보를 유지하기는 현실적으로 불가능하다. 이는 상관관계에 있는 두 칼럼이 조건절에 사용될 때 옵티마이저가 잘못된 실행계획을 수립하게 만드는 주 요인이다.
바인드 변수 사용시 균등 분포 가정
바인드 변수 : "select * from tab where id = ?” 에서의 ?
바인드 변수를 사용하면 최초 수행할 때 최적화를 거친 실행계획을 캐시에 적재하고,실행 시점에는 그것을 그대로 가져와 값을 다르게 바인딩하면서 반복 재사용하게 된다. 변수를 바인딩하는 시점은 더 늦은 실행 시점이다. 즉, 바인드 변수를 사용함으로 인해 최적의 실행계획을 만드는 것은 한계가 있다.
비현실적인 가정
옵티마이저는 쿼리 수행 비용을 평가할 때 여러 가정을 사용하는데, 그 중 일부는 비현실적이어서 이해할 수 없는 실행계획을 수립하곤 한다. 예를 들어, 예전 Oracle 버전에선 Single Block I/O와 Multiblock I/O의 비용을 같게 평가하고 데이터 블록의 캐싱 효과도 고려하지 않았다고 한다. DBMS 버전이 올라가면서 계속 보완되고 있지만 완벽하지는 않다.
규칙에 의존하는 CBO
아무리 비용 기반 옵티마이저라 하더라도 부분적으로는 규칙에 의존한다. 예를 들어, 최적화 목표를 최초 응답속도에 맞추면 order by 소트를 대체할 인덱스가 있을 때 무조건 그 인덱스를 사용한다.
하드웨어 성능
옵티마이저는 기본적으로 옵티마이저 개발팀이 사용한 하드웨어 사양에 맞춰져 있다. 따라서 실제 운영 시스템의 하드웨어 사양이 다를 때 잘못된 실행계획을 수립할 가능성이 높아진다. 또한 애플리케이션 특성(I/O 패턴, 부하 정도 등)에 의해서도 하드웨어 성능은 달라진다.
발표 후기
요점부터 말하자면 좋은 경험이었다. 고등학생 때부터 발표 못한다는 소리는 꽤 들었어도 고등학교에서는 발표를 경험해 볼 기회가 많았다. 하지만 대학 들어와서는 이론 공부하랴 코딩하랴 생각보다 전만큼 발표할 기회가 없었긴 했다. (물론 굉장히 좋았다. 😀) 그래도..!! 앞으로 면접도 봐야할 거고! 내 의견, 기술 설명 등등 말로 전달해야 할 상황이 많이 생길텐데 오히려 만들어 준 기회라 감사했다. ㅎㅅㅎ
오랜만의 오프라인 발표라 안 떨릴 줄 알았는데 막상 나가니까 떨려서 마이크 두 손으로 꼭 쥐고 말도 좀 더듬었다. ㅋㅋㅋ큐ㅠㅠㅠㅠ 음음 말하고 전달하는 법을 더 연습하고 익혀야겠다. 그런 의미에서 곧 다시 진행될 발표 스터디도 기대된다 :)
References
'회고 > 데브코스 백엔드 3기' 카테고리의 다른 글
| [프로그래머스 데브코스 백엔드 3기] 8주차 회고 (0) | 2022.12.22 |
|---|---|
| [과제] JPA 게시판 과제 후기 (0) | 2022.12.21 |
| [프로그래머스 데브코스 백엔드 3기] 7주차 회고 (0) | 2022.12.06 |
| [프로그래머스 데브코스 백엔드 3기] 6주차 회고 (0) | 2022.11.30 |
| [프로그래머스 데브코스 백엔드 3기] 5주차 회고 (0) | 2022.11.30 |
