hyeonsig notes

지난번에 소개했던 SQL(Structured Query Language)에서 SQL에 대해 간단히 살펴보는 시간을 가졌습니다. 이번 시간에는 많은 분이 놓치고 있는 중요한 내용에 대해 이야기하려 합니다. 글의 작성 순서로 볼 때, 기본적인 SQL 작성법을 먼저 설명하는 것이 옳을 것입니다만, 제가 쓰는 글이 어떤 순서를 갖고 쓰이는 책이 아니기에 꼭 순서를 맞출 필요는 없다고 판단되어 이 주제부터 작성합니다.


오늘 작성하는 글의 주제는 SQL을 어느 정도 숙지하고 있는 독자를 대상으로 이야기를 진행[각주:1]합니다. 응용프로그램을 작성하다 보면 데이터베이스를 활용하는 코드를 빈번히 작성할 것입니다. 이때, 많은 개발자가 작성한 질의문의 결과를 확인한 후, 이 결과가 옳으면 질의문의 성능을 검증하지 않고 바로 프로그램에 이식하고 있습니다. 물론 이런 현상은 개발 프로젝트의 특성상 많은 시간을 주지 않아 발생하는 문제일 수 있습니다[각주:2]. 그러나 이와 같은 개발 방식은 개발 당시에는 생산성(?)이 향상된다고 생각할 수 있으나, 결과적으로는 그렇지 않은 경우가 대다수입니다. 오히려 시간이 지나고 데이터가 커질수록 큰 문제를 발생할 수 있는 폭탄을 안고 개발하는 것으로 보는 것이 타당합니다. 그렇다면 작성한 질의문의 성능 검증은 어떻게 해야할까요?


실행계획(Execution Plan)

간단한 질의문의 성능 검증은 누구에게나 그다지 어렵지 않습니다. 그렇지만, 복잡한 SQL의 성능 검증은 경험과 지식, 그리고 비법(Knowhow)에 따라 천지차이가 납니다. 데이터베이스 튜닝 전문가가 쉽게 만들어지지 않는 것도 이런 이유가 있는 것이겠지요. 초보자나 전문가 모두 SQL 문의 성능 검증을 위해 반드시 활용해야 하는 도구[각주:3]가 있습니다. 바로 이 절의 주제인 실행계획입니다. 그렇다면 실행계획은 무엇일까요?


실행계획을 이해하려면, 옵티마이저(Optimizer)에 대해 이해를 해야 합니다. 여기에서 옵티마이저에 대한 내용을 장황하게 설명하기는 어렵습니다[각주:4]. 다만, 옵티마이저는 작성한 SQL을 가장 빠르고 효율적으로 수행할 수 있도록, 최적의 처리 경로를 생성해주는 DBMS 내부의 핵심 엔진이라고 이해하시면 됩니다. 이처럼 옵티마이저가 생성한 SQL 처리 경로를 실행계획이라고 이해하시면 됩니다. 이것도 복잡하다고 생각하시는 분들을 위해 간단히 요약하면, 질의문이 실행되는 절차라고 볼 수 있습니다.


우문현답

질의문을 작성하는 이유는 무엇인가요? 데이터베이스에 저장된 수많은 데이터 중에서 질의 작성자가 원하는 정보를 찾는 것이 가장 큰 목적일 것입니다. 사실 질의 작성자는 데이터베이스가 질의문을 분석한 후, 어떤 방법으로 자신이 원하는 데이터를 찾는지는 관심이 없습니다. 원하는 것은 질의문과 일치하는 정보이니까요. 그럼에도 질의문을 효율적으로 작성하는 방법은 분명히 존재합니다.


최근에 옵티마이저가 똑똑(?)해지면서, 사용자가 잘못 구성한 질의도 꽤 우수한 성능을 발휘할 수 있도록 자동으로 질의를 변환(Query Transformation)하고 있습니다. 그러나 이것은 어디까지나 운 좋은 상황이거나 또는 우연(?)이라고 보시는 것이 좋을 것입니다. 전문가를 꿈꾸는 개발자가 이런 우연을 기대하는 것은 옳지 못한 방법이겠지요?


그럼 최적 비용을 소모하며, 결과를 얻을 수 있는 잘 작성된 질의문은 무엇일까요? 다양한 답변이 있을 수 있을 것입니다만, 원론적인 답변은 DBMS가 처리해야 할 일의 양을 줄이는 질의문을 만드는 것[각주:5]입니다. 간단한 예를 들어 설명해 볼까요? 누군가가 필자를 찾는다고 할 때, 대한민국 전체에서 검색하는 것이 빠를까요? 아니면 필자가 자주 머무르는 지역을 한정으로 검색하는 것이 빠를까요? 아주 쉬운 질문이죠? 당연히 뒤의 예가 훨씬 힘도 적게 들고, 빨리 찾을 수 있을 것입니다. 이처럼 사람을 찾는 방법은 많지만, 찾는 방법을 어떻게 하느냐에 따라 일의 양과 검색 시간은 10배 아니 그 이상 차이가 날 수 있습니다. 


질의문도 이와 같습니다. 사용자가 효과적으로 질의문을 작성하면, 데이터베이스는 효과적으로 사용자가 원하는 정보를 찾아주겠지만, 그렇지 않은 경우라면 데이터베이스의 눈물겨운 노력이 발생할 것입니다.


지금부터라도 실행계획을 꼭 확인하자

여러분께서 지금까지 작성한 질의문 중 가장 긴 코드는 몇 줄 정도 되나요? 대용량 데이터베이스를 다루는 곳에서는 A4 용지로 수십 페이지 분량의 질의문도 작성[각주:6] [각주:7]한다고 합니다. 아무리 똑똑하고 명석한 사람이라도 질의문의 실행계획을 머릿속에 그리는 것은 거의 불가능에 가까울 것입니다. 또한, 최근에 유행하는 데이터베이스에서는 최저비용을 계산하기 위해, 데이터베이스 내부에 존재하는 다양한 파라미터를 활용하기 때문에 실행계획을 정확하게 예측하는 것은 더 불가능해졌습니다.


실행계획에 대해 하고 싶은 이야기가 많습니다[각주:8]만, 이 글의 주제는 질의문을 작성한 후에는 반드시 실행계획을 확인하자는데에 있으므로 더 깊이 있는 이야기는 하지 않겠습니다. 다만, 이 글을 읽은 후부터라도 질의문을 작성한 후에는 반드시 실행계획을 확인하는 습관을 지녔으면 좋겠습니다. 물론, 실행계획을 보고 이해하는 데에는 꽤 많은 노력이 필요합니다. 실행계획에 대해서 인터넷에 수많은 자료가 있으니 관심 있으시면 검색해보시면 될 것 같습니다. 


다시 한번 말씀드리지만, 실행계획을 확인(이해)하지 않고, 최적화된 질의문을 작성하는 것은 어불성설입니다. 가장 기본적인 것이 가장 중요하다고 생각합니다. 지금부터라도 질의문을 작성한 후에는 꼭 실행계획을 확인하는 습관을 길러보는 것이 어떨까요?


마치면서

이번 시간에는 실행계획에 대한 기본적인 이야기와 왜 실행계획을 확인해야 하는지에 대한 당위성에 대해 이야기했습니다. 데이터베이스를 이용하는 수많은 프로젝트에서 질의문을 작성한 후, 실행계획을 확인하지 않고 결과만 확인하는 장면을 많이 보고 들었습니다. 다시 한번 말씀드리지만, 지금부터라도 질의문을 작성한 후에는 꼭 실행계획을 확인하세요.


원래 제 계획은 이번 시간에 소개하려고 했었는데, 글의 내용이 길어져 중단했습니다. 다음 시간에는 오라클에서 실행계획을 확인하는 방법을 소개하겠습니다.

  1. SQL에 대해 많은 지식이 없으신 분이라도 꼭 알고 있어야 하는 내용이기에 읽어두시면 좋을 것 같습니다. [본문으로]
  2. 필자는 실행계획을 확인하는 방법을 알지 못해서 적용을 못 하는 경우도 많다고 생각합니다. [본문으로]
  3. 물론 정말 뛰어난 전문가라면 질의문을 보고 대강의 실행계획을 머릿속에서 상상할 수 있겠지만 이런 경우는 논외로 하겠습니다. [본문으로]
  4. 곧 옵티마이저에 대해 자세히 설명할 기회를 만들겠습니다. [본문으로]
  5. 짧은 답변에 실제로는 많은 이론이 숨겨져 있습니다. 이에 대한 이야기는 주제가 크게 벗어나기 때문에, 자세한 설명은 생략하고 다음 기회에 다시 소개하겠습니다. [본문으로]
  6. 필자도 경험이 없어, 아직 그 정도로 긴 질의문을 보지는 못했습니다. [본문으로]
  7. 대체로 집합적인 사고를 못한 질의의 유형이라고 생각합니다. 당연히 효율은 나쁘겠지요. [본문으로]
  8. 실제로 실행계획에 대해 이해를 하기 위해서는 꽤 많은 학습이 필요합니다. [본문으로]
DISQUS 로드 중…
댓글 로드 중…

블로그 정보

hyeonsig notes - 천사마음

Carpe Diem~♥ 내일이 기대되는 사람이 되자.

최근에 게시된 글