오래 전에 정보시스템의 근간이었던 File System (VSAM,ISAM등) 환경과 3세대 구현언어(Programming Language)가 독립적인 정보관리 위주의 절차형 프로그램 방식이었다. 당시에는 얼마나 효과적이고 구조적인 프로그램 로직을 구사하느냐가 시스템 성능을 보장하여주는 핵심 열쇠였으며 그러한 3GL Language (C, COBOL, FORTRAN, 등)구사 능력이 뛰어난 고급 기술인력이 매우 중요하였다.

이제 우리의 현실을 돌아보자, 거의 모든 정보시스템의 근간은 File System 이 아닌 DBMS(DataBase Management System) 환경이며 구현 언어 역시 절차형 로직 흐름 중심의 3GL 언어가 아닌 SQL이란 비절차형 언어가 DBMS에게 정보를 저장하거나 추출하기 위한 유일한 의사소통 언어(Communication Language)가 되어버렸다.

File System 환경과는 다르게 DBMS는 단순히 데이터 저장소 역할만 하는 것이 아닌 효율적인 데이터 관리에서부터 최적의 성능으로 정확한 정보제공 서비스까지 모두를 책임지고 있는 "첨단 인공지능"과 같은 통합 운영체제라고 표현해도 무방할 것이다.

DBMS 시장에서도 이미 전 세계적인 기반 S/W로 자리매김한 관계형데이터베이스 (Relational DBMS) 발전은 10년이 넘도록 발전에 발전을 거듭하고 있다. 필자는 15년 가량을 IT업계에서 대부분의 독자들과 마찬가지로 프로그램 개발 그리고 분석/설계 업무를 같이 호흡해 왔다. 그 동안 필자가 접해온 여러 동료나 고객 그리고 선후배 들의 DBMS에 관한 이해와 응용을 위한 기술력 발전사는 DBMS 발전추세와는 너무도 동떨어져 형편없이 뒤떨어져 있는 현실을 매우 안타깝게 생각하고 있다. 과연 우리는 DBMS를 얼마나 잘 이해하고 있으며 엄청난 고가의 비용을 치르고 도입한 "첨단인공지능"의 첨단 기능을 얼마나 활용하고 있는지 우리 스스로에게 반문하여 보자. 아마 20% 도 활용하고 있지 못하고 단순한 데이터 저장소 역할로만 사용하는 수준이 대부분일 것이다.

또한 이러한 DBMS 환경에서 개발자들이 프로그램에 사용하는 SQL은 아예 3GL에서 Read / Write 와 같은 단순한 Statement 수준으로 이해하고 활용되다 보니 DBMS에게 시킬 수 있는 일(명령)은 어쩔 수 없이 단순한 Simple Statement 만 무수히 반복하게 되며 이러한 명령을 수행하는 DBMS는 고가의 몸값 역할을 할 수 있는 기회가 아예 박탈된 채 단순 노무자와 같은 일만 반복하여 시스템의 부하는 가중시키며 효과는 마이너스를 나타내게 되는 현실이다.

우리가 처한 이러한 현실을 설득력 있게 전달하기 위해 누구나 이해할 수 있는 아주 이해하기 쉬운 사례를 들어보자.

만일 당신이 지금 5가지의 물품(볼펜, 담배, 건전지, 생수, 딸기)을 구입하여야 되는 상황이라고 가정하자.

먼저, 판단력과 응용력이 거의 없다고 해야 할 4살이 채 되지 않은 막내 아이에게 심부름을 보내는 상황을 가정하여 보자. 그렇다면 어쩔 수 없이 한가지씩의 물품을 사오도록 5번에 나누어 심부름(가는 길까지 가르쳐 가며)을 보낼 수 밖에 없을 것이다. 시간은 걸리겠지만 정확히 원하는 5가지를 얻게 될 것이다.

하지만, 나름대로의 판단력이 있으며 응용력과 자기계발능력이 있는 14살이 된 큰 아들에게 심부름을 보낼 때는 어떻게 해야 할 것인가 ? 만일 이 큰 아들에게도 막내 아이에게 시킨 방식대로 "먼저 볼펜 사오너라" 심부름을 무사히 다녀오고 난 뒤 "이번에는 담배 한갑 사오너라" 역시 무사히 다녀온 뒤 또 "건전지 사오너라" 이런 식으로 심부름을 보낸다면 과연 어떠한 반응이 나올까 ? 생각만 해도 끔찍하지 않은가 ?

DBMS 역시 마찬가지이다. File System환경과 DBMS환경의 능력 차이는 그야말로 엄청난 차이라고 할 수 있다. DBMS의 능력은 100을 가지고 있지만 주인님(우리)께서는 그러한 능력을 제대로 파악하지 못하고 단순하게 1의 능력 밖에 할 수 없도록 문제를 준다면 … 말 못하고 불평을 할 수 없는 S/W 이기에 시킨 대로 묵묵히 단순 고행의 길을 걸으며 주인님 잘못 만난 죄를 한탄하고 있지 않았을까 ?

필자가 접했던 시스템 성능저하로 인한 Performance Tuning 컨설팅 사례의 대부분의 가장 핵심 근본 원인은 다음과 같이 크게 3가지로 요약할 수 있다.

첫째, 관계형 데이터베이스에 적합하지 못한 DB 설계의 문제

둘째, RDBMS의 구조 이해 부족과 비절차형 언어인 SQL 활용/응용력 부족

셋째, 적절치 못한 옵티마이징 전략으로 인한 엑세스 비효율(불필요한 I/O)과 옵티마이져가 수립한 실행계획의 비효율

필자는 RDB최적 활용을 위한 상기 3가지 주요 핵심에 대한 필요성을 전달하기 위하여 몇 가지의 간단한 예제를 통하여 설명하기로 하고 본 글에서는 먼저 "관계형 데이터베이스에 적합하지 못한 DB 설계의 문제"에 대한 중요성에 대하여 언급하기로 하고 다음 기회에 연재의 논고로 본 글에서 못다 표현한 내용과 나머지 두가지 요소에 대한 중요성을 피력하기로 한다. 그리고 본 필자의 글 다음 여타 기고의 논고에서부터는 본격적인 단위 요소별 RDBMS 실전/응용 기술자료들로 여러분을 만나게 될 것이다.

첫째, 관계형 데이터베이스에 적합하지 못한 DB 설계의 문제

모든 일에 첫 단추가 가장 중요하듯이 데이터베이스를 근간으로 하는 정보시스템 구축에서 개념데이터모델링에서부터 물리적 데이터베이스 설계단계는 매우 중요하다는 것은 대부분 모두가 공감하는 부분이다. 그러나, 적지 않은 많은 현장에서 접하는 데이터베이스 설계는 참으로 답답하기가 이루 말로 표현하기가 어려울 정도로 상태가 심각한 경우가 많다.

그야말로 무늬만 RDB 형태를 나타내고 있는 파일시스템이라는 착각이 드는 경우도 있으며 IMS와 같은 HDB 설계 구조를 그대로 RDB에 옮겨 놓거나 또는 기본적인 정규화도 생략되는 것은 고사하고 RDB에서 조인 때문에 속도가 느려진다고 착각하는 몇몇 잘못된 선입관으로 거의 전 테이블에 반정규화를 무분별하게 하여 놓고 마치 고성능 보장을 위한 특별 처방인 것처럼 생각하는 설계자도 있으며 Relation과 Entity을 혼동하고 Entity 집합의 정의가 애매하다 보니 설계가 진행되어 가면서 개발단계 까지 진행되어 가다 보면 1:M이던 Relation이 M:M으로 바뀌게 되는 경우도 있으며 약간의 업무 요구사항이 바뀌게 되면 몇 개의 테이블이 새로 태어나거나 Relation의 Degree가 바뀌는 등 갈수록 DB 설계의 골격이 하나 둘 허물어져 모델링 단계에서는 전체 100개의 엔터티가 개발이 끝날 시점에는 300개가 넘는 테이블로 설계되는 기형적인 DB설계가 되다 보니 최초 설계한 ERD 구조는 무의미한 산출물이라며 물리적인 테이블을 역으로 그림을 그려내어 ERD라고 가지고 있는 현장을 여러 번 접하였다.

이미 지난 몇 차례 당사의 이화식 대표께서 데이터모델링에 대한 좋은 논고를 본 매체를 통하여 게재하였으니 본 글에서는 해당 부분에 대한 중요성과 필요성에 대하여는 언급을 하지 않기로 한다. 여기서는 RDB에 적합한 설계에 따른 Performance 이해를 위해 간단한 예제로 여러 독자들의 이해를 돕기로 한다.

다음 제시된 [그림1]의 ERD는 사원(EMP)이라는 Entity와 부서(DEPT)라는 Entity를 표현한 간단한 ERD이다.

[img]

[그림1]

상기 ERD가 정상적인 물리적인 DB Design 단계로 넘어온다면 EMP 테이블과 DEPT테이블로 아래 좌측과 같은 정규화된 테이블 구조를 가지는 경우가 있을 수 있으며, 혹자는 사원정보를 추출할 때는 대부분 해당사원이 속한 소속 부서명칭(DEPT테이블의 dname 컬럼)도 같이 보고자 하는 업무 요구가 매우 많으므로 어쩔 수 없이 조인이 발생하게 되며 조인을 하면 속도가 느려진다고 생각하는 설계자는 아예 EMP 테이블에 부서번호 참조키(Foreign Key)에 해당하는 DEPT 테이블의 부서명칭(dname)을 복제하여 EMP 테이블의 컬럼으로 가지게 하는 우측 형태의 테이블 구조로 만드는 경우도 있다. 아마 이러한 경험을 가지고 있는 독자들이 적지 않을 것으로 예상한다.

[그림2]

자 그럼, 위의 [그림2]에서 표현한 정규화된 테이블 설계 상황과 조인의 속도 향상을 위한 특별조치를 했다고 생각하는 반정규화 테이블 설계 상황에서의 한가지 실제 사례를 가지고 비교하여 본다.

사례 문제가 "직책이 MAMAGER가 아닌 (job <> 'A2') 전 직원의 부서별 급여의 합계와 인원 수를 구하라" 라고 한다면 실제 다음과 같은 일반적인 Simple SQL을 각각 수행할 수 있을 것이다.

[그림3]

상기 [그림3]의 ①번 형태의 SQL은 부서명칭 추출을 위하여 2개의 테이블을 조인을 이용한 데이터 연결을 하여 GROUP BY를 하였으며 ②번 형태의 SQL은 하나의 테이블(EMPD)에 부서명칭이라는 컬럼도 존재하기 때문에 조인이 불필요하여 단지 하나의 EMPD 테이블만을 엑세스하여 단순 GROUP BY를 하였다.

자, 그렇다면 ①번 SQL과 ②번 SQL의 수행 속도는 어느 편이 유리할 것인가 ? 아마 대부분의 독자들은 당연히 조인을 하지 않고 하나의 목적 테이블만을 엑세스한 ②번 SQL이 속도가 빠를 것으로 단언할 것이다. 하지만 실제 측정 결과는 ①번 SQL이 오히려 더 유리하다는 것이다. 아래 [그림4]에 제시된 각 SQL에 대한 실행계획과 I/O Block및 처리응답속도를 살펴보면 해답은 명확하며 매우 상식적인 결과라고 할 수 있다.

[그림4] (확대해서 보기)

상기 [그림4] 결과에서 보듯이 정상적인 DB설계 상황 하에서 조인 SQL문장의 ①번 SQL이 오히려 처리응답속도가 빠르다는 것을 확인할 수 있다. 이유는 매우 간단하다. 시스템 성능을 좌우하는 요소는 CPU/Memory 부문의 일량 보다 Disk나 N/W에 관련한 I/O 부문의 요소라는 것은 모두가 아는 주지의 사실이다. File System에서는 정보의 가로길이가 아무리 길더라도 I/O 단위는 Record이지만 RDBMS에서의 I/O 단위는 DB Block이기 때문에 RDBMS에서의 처리 속도에 영향을 미치는 핵심 요소는 물리적인 I/O Block의 절대량이라는 것을 잊어서는 안된다.

RDBMS에서 I/O하는 단위 Block의 크기란 가로길이(Row length (Size)) 곱하기 세로길이(Row건수)에 해당하는 면적이므로 위의 사례에서 EMPD 테이블과 같이 100종류 밖에 안되는 부서명칭(30Bytes)을 10만건 EMPD 테이블에 가져다 놓는다면 원래 정상적인 EMP 테이블의 크기가 4MB(약 40bytes(가로길이) * 100,000건(세로길이))이면 충분한 DB Block의 공간이었던 테이블 저장공간의 크기가 EMPD에서는 7MB((약 40bytes+30bytes(dname)) * 100,000건) 정도의 크기로 거의 2배에 가까운 크기의 DB Block이 필요하게 된다는 단순한 원리이다. 그리고 DEPT라는 테이블은 가로길이가 100bytes의 크기라 하더라도 세로의 길이는 100건에 불과하므로 10KB정도의 공간이면 충분할 것이다. 그렇다면 ①번 SQL에서는 물리적인 Disk Block I/O하는 엑세스량은 4MB+10KB 정도가 될 것이며 반대로 ②번 SQL에서는 하나의 EMPD 테이블만을 엑세스하였지만 결국 7MB 정도의 물리적인 Disk Block을 엑세스해야만이 원하는 결과를 추출할 수 있다. 이러한 현상을 상기 [그림4]에 나타난 trace 통계 수치를 가지고 설명한다.

먼저 ①번 SQL에서는 물리적인 DISK Block I/O개수(Disk)는 총 2097개의 Block을 엑세스 하였으며 Sort Merge Join방식으로 조인을 하여 Memory Block I/O가 많이 나타나 Memory Block I/O개수(Query)는 9068개의 Memory Block을 I/O하여 응답속도(Response Time)은 3.14초라는 결과를 보여 주었다. 이와 대조적으로 ②번 SQL에서는 물리적인 DISK Block I/O개수(Disk)가 총 3295개의 Block을 엑세스 하여 결국 응답속도는 5.06초의 결과를 보여주고 있다. 사원 테이블의 엑세스 대상건수는 두가지 경우 모두 100,003건을 Full Table Scan하여 JOB <> 'A2' 조건을 만족하는 대상 정의역 건수는 24,556건이며 최종적으로 부서별로 GROUP BY 된 결과 Return Row는 둘다 동일하게 101개의 부서 결과 집합으로 추출된 상황으로 둘다 동일한 결과이다.

관계형 데이터베이스란 자료의 중복을 최소화하면서 서로 독립적인 자기 자신에 충실한 정보들로 구성된 상황에서 언제든지 필요하면 직간접적인 관계(Relation)를 통하여 유연하게 연결되어 새로운 여러가지 형태의 정보를 창출하는 장점을 가지고 있다. 이러한 특성을 가지고 있는 RDB의 장점과 특성에 역행하는 DB설계가 과연 최적 성능을 위한 정답이라고 착각해서는 안된다.

"조인을 하면 속도가 느리다" 라고 단언하는 잘못된 선입관을 가지고 자료의 중복과 자료의 일치성을 무시해가면서 RDB 설계의 기본을 벗어나는 오류만큼은 이제는 더 이상 없어야 할 것이다.

조인은 데이터를 연결하는 방법 중의 하나로서 RDB를 활용하는데 있어서 없어서는 안될 매우 유용한 기법이며 조인이 속도를 저하시키는 것이 아니라 비효율적인 조인 방식으로 인하여 속도가 느리게 나타나는 경우가 간혹 있으며 이를 극복하기 위해서 상황에 따른 효율적인 데이터 연결 방식과 효율적인 옵티마이징 실행계획을 유도할 수 있는 능력을 키워야 하는 것이 바로 우리가 갖추어야 될 기본기가 아닐까?

최적화 RDB 시스템 구축을 위한 DB설계에 대한 중요성에 대하여 몇 가지 추가적인 실례를 더 제시하고 싶지만 논고의 한계상 여기서 줄이고 다음 논고에서 계속 언급하기로 한다.