통계 위젯 (화이트)

3851
300
2204133

저작권

모든 내용은 허락없이 상업적으로 사용하실 수 없습니다. - 오광섭 -

클릭몬 (와이드)





DB 어플리케이션과 인덱스.. ▣ 컴터야그 ▣

DB 어플리케이션이라고 하면 DBMS 프로그램과 연계되어 실행되는 프로그램을 말한다.. OODB가 오래전부터 이야기는 많이 되어 왔지만 아직까지도 확산은 더딘 상태다.. 아직까지는 RDBMS가 대세다.. DB 어플리케이션에서 중요한 것은 당연히 DB다.. 기본적인 관리법 및 SQL 이라 불리우는 데이터를 저장, 수정, 삭제, 조회 할 수 있는 방법을 제공하는 방법에 대해서 잘 알아야 한다.. SQL은 표준이 정해져 있지만, RDBMS의 구현사 마다 마음대로 확장한 문법들이 있다.. 개발자들은 이런 부분까지 신경을 써야한다..

요즘의 어플리케이션들은 DB 어플리케이션의 비중이 상당히 높다.. 웬만한 웹 어플리케이션들은 거의 대부분이 DB 어플리케이션이라고 봐도 된다.. 많은 양의 윈도우 데스크탑 어플리케이션들도 DB와 함께 실행된다..

그럼, DB에 관해 어떤 내용들을 알아야 할까? 아는 만큼 보인다고, 많이 알면 많이 알 수록 프로그래밍에 도움이 된다.. 하지만, 대부분의 사람들이 당장 뭘해야 하는데 모르면 안되는 것들을 먼저 학습을 하게 마련이고, 당장 눈앞에 문제를 해결하는데 도움이 안되는 것이라면 그다지 시간을 투자하지 않는 경향이 있다.. 그래서 그런지 DB 모델링, 쿼리문 작성에 대한 학습 및 실습은 꽤 많이 하는 편인데, 인덱스나 튜닝 등 성능에 관한 부분은 관심이 별로 없는 것 같다는 느낌을 많이 받는다..

쿼리문을 작성할때 조금만 더 신경을 쓰면 (사실 이 조금만 더 라는 표현이 상당히 애매하고 이견이 많은 표현이다..) 성능에 상당한 영향을 미치는 부분을 미연에 제거할 수 있다.. 인덱스는 데이터를 조회하고 검색하는데 성능향상을 시키기 위해 미리 정렬된 색인을 만들어 놓도록 지정하는 방법이다.. 따라서 모든 select 문을 작성할때 이 인덱스를 잘 활용하도록 작성을 해야 한다.. 만약 인덱스가 없다면 해당 쿼리의 특징에 맞게 인덱스를 구성할 필요가 있다..

그런데 개발자들 중에는 초기 개발에만 신경을 쓰고, 운영시나 향후 데이터가 많이 쌓이게 되었을때를 전혀 고려하지 않은 개발 당시 동작하는데만 집중해 개발을 진행하는 사람들이 간혹 있다.. 이런 사람들이 작성한 프로그램은 처음에 테스트 할때는 동작에 아무런 문제가 없다.. 하지만, 짧게는 3개월 정도 지나면 데이터들이 쌓이고 나서 서서히 느리게 동작하기 시작한다.. 나중에는 참아주기 힘들 정도로 느려진다..

처음 코드 및 쿼리를 작성할 때 부터 이 테이블에서 가져오는 데이터는 주로 어떤 식으로 조회가 자주 되며, 조회되는 방식이 다르더라도 속도를 위해 미리 정렬해두면 좋을 것 같은 엔티티를 식별해 두고 필요시 DBA에게 인덱스를 걸어달라고 요청을 해야 한다.. 아울러 쿼리문의 where 절에 조건을 걸때도 인덱스의 순서에 맞춰 가장 범위를 좁힐 수 있어 인덱스의 효과가 높게 작성을 해야 한다.. 이런 과정이 사실은 그리 시간을 많이 소요되는 것은 아니다.. 처음에는 고민을 해야할 필요도 있을 것이고, 경우에 따라서는 복잡한 조인 등으로 인해 고민해야 할 시간이 많이 필요하게 되는 경우도 있을 수 있다.. 그렇다고 해도 대부분의 경우는 그리 많은 시간이 필요하지는 않으며, 이는 연습을 통해 짧아질 수 있다.. 하지만, 이런 부분에 대한 중요성을 인식하고, 이런 훈련을 평소에 해두지 않으면 인덱스는 고려치 않는 나쁜 버릇으로 발전하게 된다.. 평소에 귀찮고 힘들더라도 이런 부분은 고려하면서 코드를 작성할 수 있는 훈련을 하자.. 나중에 성능향상을 위해 대충 만들어져 곳곳에 숨어 있는 쿼리문들을 모두 발췌해 내는 작업은 아주 귀찮은 작업이다..

덧글

  • 스팟 2008/02/16 21:05 # 답글

    DBMS에 대한 기초지식이 없던 때는 무조건 프로그램에서 처리하려고 했었는데 시간이 좀 지나고 나서는 되도록 DBMS에서 처리하는게 좋다는 생각입니다.
  • 미친병아리 2008/02/16 22:55 # 답글

    스팟님 : 맞습니다.. 최대한 DBMS가 처리해주도록 하는 것이 훨씬 빠릅니다.. 그렇다고 무덕대고 쿼리 날리는 횟수를 줄일 수 있는 방법이 있는데도, 쿼리를 왕창 날리는건 바람직하지 않겠지만 말입니다..
  • 하늘처럼™ 2008/02/16 23:17 # 답글

    ㅎㅎ 몇달이 지난 후에 DB가 느려진 것을 되려 묻는 분들이 간혹 있지요..
    참으로 난감하지요..
  • opnc 2008/02/17 01:30 # 삭제 답글

    초기 개발에만 신경쓰는 개발자들.. 그렇지 않으면.. 작업시간이 길어지고.. 눈치주는 관리자.. 실력이 없어서 빨리빨리 못한다.. 뭐라 그러고..
  • KONA 2008/02/17 23:26 # 답글

    새삼 당연하지만, 미쳐 못 느끼고 그냥 넘어가는 부분이 아닌가 싶습니다. OJT때 WHERE절을 쓸때 주의사항 같은걸 배운적이 있는데... DB에 따라서 조금씩 특성이 다르다보니 가끔은 제가 아는게 맞는게 잇기도 하고, 틀린게 잇기도 하더군염... 근래에는 인사쪽 근태데이터에 인덱스를 다시 걸어줬더니 프로그램 속도가 확연하게 개선된걸 본적도 있구요...
  • 쩌비 2008/02/18 09:39 # 답글

    맞습니다. 역시 초기에 유지보수를 생각해서 좀 더 신경을 쓴다면 좋을 텐데요.
  • 윌리 2008/02/18 09:59 # 답글

    예전에 제가 국내 기술영업이사로 일할 때 모 회사 (나름 중견기업) 전살실장이 시스템이 느려서 교체해야 한다고 사장회의에 보고를 할 당시 우리 팀(후배들과 급조한 몇명) 이 가서 인덱스 몇개 바꿔서 그간 처리속도보다 100배 이상 빠르게 해주었던 적이 있습니다.

    결론은 전살실장은 똑똑해야 한다는..은 아니고 동감되는 글이군요. ^^
  • wowhoon™ 2008/02/20 10:54 # 답글

    아주 가끔 컨설팅을 나가거나 하면 어떤 곳은 장비 납품하는 곳에서 이를 잘이용해서 영업을 하더군요, 기존 장비 보다는 몇배 빠른 장비가 나왔으니 지르시죠 라는 뉘양스의, 조금만 신경을 기울이면 엄청난 비용을 줄일 수 있는데 말이죠.
  • 미친병아리 2008/02/24 03:59 # 답글

    하늘처럼™ 님 : ㅋㅋㅋ 뭐, 별 수 있나여.. 원인 찾아서 해결해야죠..

    opnc님 : 이런 부분들까지 신경을 쓰면서도 일정이 늦어지지 않도록 하나 하나 준비하고 점검해 나가는 것들을 쌓아 나가야죠.. 그렇지 않으면 경력이 쌓인 개발자인데도 신입과 비슷한 결과물 내면서 시간 없다고만 하고 있겠죠..

    KONA님 : 초기에 인덱스에 전혀 신경을 쓰지 못한 경우엔 인덱스만 제대로 걸어줘도 정말 놀라운 성능 향상을 경험하게 되지요..

    쩌비님 : 유지보수에 대해 생각하며 개발하는 것은 아무리 간단한 것이라도 평소에 연습과 준비를 해두지 않으면 발전이 없게됩니다..

    윌리님 : 정말 그렇습니다.. 초기에 인덱스를 하나도 고려치 않고 개발한 경우라면..

    wowhoon™님 : 제가 영업을 한다면 일단 그런 부분은 인덱스를 걸어줘 해결해주고, 나중에 제대로 팔아볼 것 같은데.. 장비구매 없이도 성능향상을 할 수 있었다는 것을 알게되면 고객이 뭐라 생각할까요? 또한 주변에 인덱스만으로도 해결 방법이 있다는 것을 아는 사람들에게는 거짓말임이 들통난 셈인데, 그렇게 영업을 하고 싶을까 하는 생각이 듭니다.. 거짓말은 언젠가 들통나고 진실은 언젠가는 통하죠..
  • 이재학 2009/02/14 11:17 # 삭제 답글

    튜닝의 기본은 모델링이죠. 모델링에서 근본적인 잘못이 있으면 튜닝을 아무리 해도 소용없습니다.튜닝은 익덱스와 힌트로 보면 되겠는데, 구현에만 중점을 두지 말고 튜닝을 염두에 두면서 쿼리를 만들면 좋을 듯.. 그런데, 그러면 개발 시간이 되나요..? 암튼, DB 설계시 튜닝을 염두에 두어야 하니까, 설계사의 업무가 정말 중요하겠네요.
댓글 입력 영역