Plan을 보는 두 가지 관점

Sibeet·2020년 5월 22일
0

Query processing

목록 보기
1/2

거창한 것은 아니고, 퇴근전에 그냥 간단하게 돌려봄...

최근에 Plan 관련해서 회사 내부에서 세미나를 하고 있는데, 과연 우리 제품의 Plan과 동일한 결과가 나올지 궁금해졌다.

oracle에 해도 되긴 하는데 개인장비에 설치된 것도 아니고 해서, tpc-h를 대강 설치해서 mysql에 쏘고 이것저것 해서 plan을 출력해 봤다.

TPC-H-SF1 20번째 query

국적이 캐나다인 뭐시기 제품이 선적날짜가 1년 이내인 뭐시기 같은 내용의 쿼리인데 이건 중요한 게 아니고.

  • 우리 제품( lst파일을 vi로 연거라 하이라이팅이 좀 그렇다)

오라클도 이런 식으로 보여주는 것으로 알고 있는데, 계층적 구조를 보여주면서 해당 항목마다 어떤 식으로 Filter를 거치는지, 어떤 hint를 사용해서 실행하는지, 어떤 식으로 테이블을 Access하고 어떤 index를 사용했는지 등등의 정보를 보여준다.

해당 항목 별로 description을 만들어 조금 더 상세한 정보를 제공하는데, selection을 실행하는 column 등을 적어 주기도 하는 등 상세한 정보가 빽빽하게 들어차 있다.

이 plan 출력 방식은 Query Processing에서 사용하는 이론인 relational algebra를 바탕으로 이해할 수 있다. region-projection-selection 등으로 이어지는 일련의 흐름을 역순으로 따라갈 수 있는 트리 구조인 것.
이런 구조는 처음 보기에 플랜을 해석하기가 굉장히 어렵지만, 이론적인 이해가 있으면 설령 테이블을 처음 본 사람이라도 손쉽게 이해할 수 있다는 점이다. 러닝커브는 높지만 그만큼 많은 정보를 담고 있는데다 각 operation 별로 SQL도 출력하니(근데 이 부분은 오라클도 그러는지는 잘 모르겠고) 튜닝이 필요한 쿼리일 때 세세한 도움이 된다.

  • Mysql

처음 플랜을 출력하고 상당히 놀랐다. 내가 원하는 정보가 전혀 없는데다 심지어 Select 구문같은걸 플랜으로 출력하면 단 한줄이 나온다. 심지어 내용도 Simple이나 null이 가득함..

첨에는 이걸로 뭘 할수 있나...이런 생각이 들었는데 쭉 보다 보니까 생각보다 센스있는 플랜 출력 방식이라는 생각이 들었다.
이전 플랜보다 상세한 내용을 빼곡히 적어놓진 않았지만 꽤 필요한 건 잘 적어놨다. row 갯수라던가 key와 관련된 항목도 있고, select_type을 통해 어떤 식으로 select를 수행했는지 full scan인지 index scan인지 PK의 영향을 받았는지 등등.

기존의 relational algebra 기반의 플랜 출력 방식과 달리 필요한 점만을 나열해놨고 뷰 형식으로 보여주기 때문에 한 눈에 상황을 파악할 수 있다. 큰 그림을 그릴 필요 없이 단순한 hint 한두개 집어넣거나 index태우거나 하는 형식의 튜닝에 상당한 이점을 가질 수 있을 것 같다.
모든 튜닝이 tree를 모두 이해해야 할 수 있는 것은 아니니...

단순한 Plan 정책에도 제작사의 철학이 숨어 있다.

우리 제품의 기본적인 철학은 표준과 이론적 바탕이다. 대다수의 설계가 Database 관련 이론을 바탕으로 설계되는데, 그렇기 때문에 약간은 이론적인 부분이 가미된 Plan을 사용한다.
이 부분은 oracle도 마찬가지일 것이다. DB 초기시절부터 DB 이론을 가장 많이 사용하는 제품이었으니, 그렇게 플랜을 생성하는 것도 당연하다고 봄.
반면에 mysql은 오픈소스 정신을 바탕으로 한 개발자 친화적인 DB다. 좀 더 효율적이고 간단함을 추구하는 플랜 또한 마음에 든다. 실제로 사용할 땐 mysql의 플랜이 좀 더 다루기 쉬워 보인다. (물론 난 익숙하지 않아서 공부를 좀 해야겠지만..)

0개의 댓글