친절한 SQL 튜닝 교육과정 수료 후기 및 MongoDB에서 쿼리 최적화 도전

 

 

최근 Real MySQL 스터디를 진행하면서 데이터베이스에 대해 더 관심을 갖게 되었는데, 그러던 중 글쓰기 모임에서 만난 한 개발자분이 해당 강의를 함께 듣자고 추천해주셨고 강의를 들은지 어느덧 4일간의 교육과정이 끝나게 되었다.

 

32시간이라는 짧은 시간동안 쿼리 최적화 부분을 공부하면서 그동안 스스로 잘못 알고있었던 부분들이 많았구나 하는 것을 느꼈다. 그리고 당장 회사에가서 slow query를 찾아서 개선해봐야지! 하는 의욕도 생기게 되었다. 💪

 

# 오라클 경험이 없고, 실무에서 오라클을 쓰지 않는데도 효과가 있을지?

회사에서는 주로 OLTP용으로는 MongoDB와 MySQL을 사용하고, OLAP용으로는 BigQuery와 Snowflake를 사용한다. 그래서 처음 강의를 수강하기 전에 과연 강의에서 오라클에 대해 배운 내용을 실무에 적용시킬수있을까? 고민을했었다.

 

강사님도 처음 강의때 오라클을 한번 배우면 왠만한 DB에 나오는 내용도 쉽게 이해 할 수 있을 것이다. 라고 말씀하셨는데, 강의를 수강하고 나서 어떤 이유에서 그렇게 말씀하셨는지 이해 할 수 있었다. 입문 강의인 만큼 데이터베이스의 구조, 인덱스 와 조인의 원리 등 원리에 기반해서 수업을 해주셨고, 그렇기 때문에 꼭 오라클이 아니니라도 전반적인 데이터베이스 시스템에 대해 원리적으로 이해하는데 큰 도움이 된것 같다.

 

# 앞으로 데이터베이스를 다룰때 어떻게 어디서부터 다루어야 할지 알게 된것 같다.

강의를 수강하면서 느낀점이 있다면 앞으로 공부할것들이 어떤 것들이 있는지 전체적인 시야를 얻는데 큰 도움이 된것 같다.

 

실행계획 및 트레이스 분석 할때 가져야 하는 마음가짐과 목표해야 할 부분

쿼리 최적화 할때 가져야할 마음가짐과 쿼리 힌팅

인덱스 최적화

조인 최적화

서브쿼리 최적화

정렬 최적화

부분 범위 처리 최적화

.

.

.

 

# 오개념이 많았구나

그동안 혼자 공부하면서 내가 잘못생각하고 있는 부분들이 많았구나 하는것을 깨달았다.

위에서 마음가짐이라고 표현한 부분이 있는데 바로 이 부분이다. 그동안 쿼리 최적화 작업을 할때 단순히 시간이 몇초에서 몇초로 빨라지는 결과만을 보고 최적화를 완료 했다고 생각한 적이 있었다. 또 실행계획을 확인할 때 cost가 적게 걸릴수록 단순히 좋다고 생각했는데, 강의를 수강하면서 실제로는 내가 짠 쿼리가 논리적으로 얼마나 많은 블록을 읽어들일지 기준으로 생각해야 한다는 것을 깨달았다. 그리고 그 과정이 머릿속에 그려질수있어야 겠다는 생각이 들었다.

 

마지막 강의 때 강사분께서 말씀주신 어느 정도 데이터량이 대용량이고, 어느정도 데이터량이 소용량이냐? 하는 질문에 대해 해주신 대답이 인상 깊었다. 결국 캐싱 상황에 따라, 클러스터링 펙터에 따라 데이터 몇 천 건도 대용량일 수 있다. 라는 말이 위에서 말한 쿼리에 대한 마음가짐을 잘 나타내는 말 같았다.

 

# 직접 해보면서 공부를 해보자

최근 회사에서 운용중인 웹페이지에서 조회시 발생되는 MongoDB쿼리 중 일부 유저에서 30초가 넘어가는 상황이 발생하여, 해당 부분을 직접 최적화 해보면서 공부를 해보려고 했다. 

 

해당 시스템의 DB는 MongoDB로 되어있었는데 MongoDB로 혼자 개발을 진행한 선임 개발자 분이 퇴사를 한 상황이라 팀 내에 물어볼 사람이 없었고 MongoDB를 사용해보지도 않았다. 데이터베이스의 원리는 같다는 마음가짐으로 내가 알고있는 부분이 MongoDB에도 있을까? 하는 마음가짐으로 최적화를 해보려고 했다.

MongoDB... 너무 어렵다

 

결국 33초 이상 걸리던 부분이 2.7초까지 줄어들긴 했지만 강의에서 배운대로 논리적으로 읽은 레코드 수, 테이블 접근 순서 등을 확인해보고 싶었지만, MongoDB에서의 실행계획에 익숙하지 않아서 그러지 못했다.

 

JSON 형식으로 실행계획을 찍어보니 거의 1000 줄이 넘게 나왔다....

이거 어디서 부터 어떻게 분석해야 할까 ㅠㅠ 🥲

MongoDB를 처음부터 공부하기에는 무리라는 생각이 들었다. 그래서 이 실행계획의 모든 항목에 대해 너무 깊게 들어가기 보단, document read 수 정도 만 확인하고 어디에서 스캔이 오래걸릴지 확인해보자는 마음가짐을가지고 최적화를 수행해나가려고 했다.

 

그리고 기존 방식대로 쿼리 수행시간과 실행계획에 표시되는 document 수를 기준으로 어떤 부분에 문제가 있을지 역추적 해나갔다. 🥲

 

먼저 profiler 옵션에서 slow query가 잡히도록 설정 한 후 원본 쿼리를 확인 해 보았다.

그 결과 조인이 최대 3중으로 걸려있었고, 조인의 연결 조건에 존재하지 않는 컬럼이 alias로 지정되어 연결되어있는 부분도 있었고, 또 조인의 드리븐테이블에 활용할수있는 인덱스도 없는 상태였다.

 

드리븐테이블의 경우 인덱스 설계를 100점짜리로 해야한다는 강의에서 들은 말이 생각나서 일부 연결조건이 잘못된 부분을 제대로 다시 설정하고, 드리븐 테이블에 인덱스를 설정해주어었더니 쿼리속도가 33초에서 2.7초까지 줄어들었다.

 

아쉬운점은 MongoDB에 익숙하지 않아서 실제로 어떤 스캔이 일어나는지, 얼마나 데이터를 읽으려고 했는지 이러한 부분을 직접 눈으로 확인하지 못하고 추측만 한 상태로 최적화를 수행 한 것이 아쉽다. 나중에 꼭 MongoDB에서 실행계획 보는 법, trace 분석을 걸수도 있는 지 등에 대한 부분도 숙지해서 더 최적화를 진행 해야겠다.