DBMS 튜닝(tuning)시 유의 점

DBMS의 튜닝의 70% 이상은 SQL튜닝과 Index튜닝으로 해결 됩니다.

하지만 예외적인게 조금 있지요.

얼마 전에 옆에서 이상하게 속도가 느려진 쿼리가 있어서 봐달라고 쿼리를 보여주었습니다.

힌트를 주어 강제로 인덱스를 태우고 있었습니다.
이 힌트는 왜 주었냐고 물어보니 원래 그렇게 되어 있어서 사용중이었다고 합니다. 아마 초기에 만든 사람이 사라지고 그냥 그 동안 문제 없이 쓰고 있었던 것 같네요.

그냥 잘 모르면 힌트를 없애고 돌려보세요.

라고 가이드를 했더니 3초 이상 걸렸던 쿼리가 0.01초로 끝났습니다.
이유는 뭘까요?

대부분의 인덱스는 초기 개발자가 개발하면서 만든 인덱스 외에는 나중에 추가 되는 경우가 많지 않습니다.
대부분 한 번 만들면 그게 최적이라고 생각하는 경우가 대 부분이고, 지금 처럼 초기에 만든 사람들이 사라지고 물려받은 사람들은 이유를 모르고 사용하는 경우도 있습니다.

테이블 설계시의 예상 데이터 축적량을 보고 아무리 DB 전문가가 Index를 걸어준들 사용자의 성향이나 시대에 따라 데이터는 전혀 달리 쌓이게 되는게 보통입니다.

예를 들어, 한국형 게시판은 대 부분 글이 많고 댓글이 적은 편입니다. 이유는 튀기 좋아하는 한국인들은 자기가 돋보여야 하기 때문에 댓글에 달 글 조차도 글쓰기로 올라와서 많은 사람들이 보게 하길 원하는 경우가 많기 때문이지요.
하지만 이 게시판으로 일본에서 서비스를 해보면 글은 얼마 안올라오는데 댓글이 수천에서 수만개가 쌓입니다.

즉 유저의 성향에 따른 데이터의 편중이 달라지는데,
이 때 게시글 옆에 댓글을 카운트 하는 경우 subquery를 이용해서 카운트 하는 경우도 많고, group by 를 이용해서 한 번 카운트 한 댓글 통계를 join하는 경우도 있습니다.

전자의 경우는 댓글 수가 적은 한국에서는 좋은 쿼리이나, 댓글이 너무 많아진 일본에서는 group by에 비해 많은 양의 카운트를 nested loop로 처리하게 되므로 효율이 많이 떨어집니다.

간단히 게시판만 가지고 얘길 하였으나, 다양한 인종 풍습에 따라 데이터의 편중은 달라지고 join을 하는 경우 왼쪽에 와야할 테이블을 오른쪽에 놓는게 차라리 나아지는 상황이 발생합니다.

때문에 개발을 할 때에는 당야한 쿼리의 변화를 생각해서 가급적 View나 Procedure를 이용해서 데이터를 조회하고 튜닝을 DB전문가에게 맡기시는 것을 추천합니다.

참고로 DBA는 DB Administrator이지 DB Tuner가 아닙니다. DB의 경험을 쌓을 첫 단추가 DBA이므로 경험이 풍부한 DBA는 별로 없습니다. (한국은 DB만 하면 전부 DBA라 불리지만..) 튜닝전문가나 DB Architect 등의 튜닝의 경험이 풍부한 사람에게 주기적으로 한 번씩 보여주면서 운영을 하게 되면 보다 좋은 효율의 서비스를 운영할 수 있을 것입니다.




Do not login your server any more! giip ::
Free server management tool!
https://giipasp.azurewebsites.net/