연재/하이브리드 MM DBMS

연재/하이브리드 MM DBMS - 1회

최근 한 전자 업체가 HDD 대신 플래시 메모리를 저장장치로 이용해 데이터 액세스 속도는 높이고 부팅속도를 절반으로 줄인 노트북을 전시회에 출품, 화려한 스포트라이트를 받았다. 이는 노트북 업계에서도 HDD를 보조하는 저장 장치로서가 아닌, 느린 HDD를 대체하는 주 저장매체로서 메모리의 가능성을 타진하고 있음을 시사한다. 이외에도 다양한 분야에서 메모리는 단순히 프로그램을 실행하기 위한 임시 저장공간이 아니라 데이터를 저장하기 위한 용도로 활용하기 위한 노력들이 확대되고 있는데, 이는 메모리가 빠른 액세스 속도와 저전력, 소형화 등과 같이 저장 매체로서 매력적인 장점을 제공하기 때문이다.

데이터를 저장하고, 관리해야 하는 DBMS 분야도 예외는 아니다. 이미 오래 전부터 메모리를 저장 매체로 이용하기 위한 연구와 노력은 진행되어 왔고, 수 년 전부터는 메인 메모리 DBMS(Main Memory DBMS, 이하 MM DBMS)라는 제품으로 등장하여 사용되어 오고 있다.

비싼 메모리 가격으로 인한 높은 구축 비용으로 소규모의 리얼타임 시스템에만 제한적으로 사용되어 왔던 초기와 달리, 지금은 대용량 DB로서 사용되는 등 사용 범위가 크게 확대되었다. 불과 몇 년 만에 MMDBMS가 범용 DBMS로 자리매김 할 수 있었던 것은 메모리 가격의 하락과 운영체제에서의 본격적인 64비트 시대의 도래로 이용 가능한 메모리 용량이 무한대로 확장된 점에 기인한다고 볼 수 있겠다. 게다가 최근에는 실시간 기업(RTE), 유비쿼터스 컴퓨팅, 와이브로, 텔레매틱스, RFID 등 새롭게 등장하는 용어나 서비스들마다 실시간 데이터 처리에 기반하고 있어 향후 MM DBMS에 대한 관심과 수요는 더욱 폭발적으로 증가할 것으로 전망하고 있다.

MM DBMS의 등장배경과 개요
MM DBMS(Main Memory DataBase Management System)는 데이터베이스를 메모리에 상주시켜 운영하는 DBMS로, 업체별로 메모리 DBMS, MMDB(Main Memory Database), In-Memory Database System, in-Main Memory Database, 메모리 디비 등으로 다양하게 불리워지고 있지만, 데이터베이스를 메모리에 상주시켜 이용한다는 동일한 개념을 갖고 있다. 이번 연재에서는 독자들의 혼동을 피하기 위해 MM DBMS로 통일하기로 한다.

앞에서도 잠시 언급했듯이 MM DBMS란, 데이터베이스의 일부 또는 전부를 메인 메모리에서 관리하는 DBMS로, 디스크에 대한 접근 없이 직접 메모리 접근을 통해 데이터를 관리하므로 고성능 데이터베이스 처리를 가능하게 하는 데이터베이스 관리 기술이다.

MM DBMS가 소개되고 본격적으로 활용된 지는 5년여 남짓밖에 되지 않지만, 실제 이에 대한 연구는 90년대 초반부터 국내 학계와 산업계를 중심으로 다양한 연구가 진행된 분야이다. 국내 유수의 대학과 한국전자통신연구원(ETRI)가 공동으로 ‘실시간 처리 DBMS(MR.RT)’ 라는 과제로 수 년간 연구를 했던 것이 대표적인 사례이다. 당시 개발된 MM DBMS는 자료저장 시스템 수준에 불과했지만, 그 결과 많은 DBMS 개발 인력들이 양성될 수 있었다. 이들은 90년대 후반에 나타난 인터넷의 대중화와 이동통신의 폭발적인 증가세로 실시간 데이터 처리에 대한 요구가 크게 증대되기 시작하자, 주요 MM DBMS 업체에 참여하여 상용 MM DBMS를 탄생시키는 산파 역할을 담당하게 됐다.

이와 같이 장기적이고도 지속적인 연구 개발에 힘입어 MM DBMS에 대한 연구나 개발 활용 측면에서 우리나라는 이미 세계적인 수준에 이르렀으며, 토종 업체들이 관련 시장을 주도하고 있다. 백신, 그룹웨어 등과 같은 응용 소프트웨어 분야에서 토종 업체들이 로컬 시장을 중심으로 주도권을 잡는 경우는 종종 있기는 하지만, 기간 SW이자 기술 진입 장벽이 높은 DBMS 시장에서 토종 업체가 주도권을 잡고 있다는 것은 매우 이례적인 일로 받아들여 지고 있다. 이는 진입 장벽과 외산 의존도가 높은 분야라도 시장과 고객의 요구를 정확히 예측하여 품질과 서비스를 겸비한다면, 토종 제품이라도 충분히 시장 경쟁력이 있음을 시사한다.

또한 MM DBMS의 적용분야를 살펴보면, 우리의 일상생활과 매우 밀접하게 연관되어 있음을 알 수 있다. 소규모 실시간 데이터 처리를 위한 시스템에만 한정적으로 적용되던 초기와는 달리, 포털 사이트의 인증에서부터 증권사의 HTS(Home Trading System), 휴대폰 이용을 위한 HLR (Home Location Register)에 이르기까지 다양한 분야의 실생활 속에서 폭넓게 활용되고 있다. MM DBMS가 시장에 본격적으로 등장한 지 불과 몇 년 밖에 지나지 않았다는 사실을 감안할 때 단시간 내에 고객의 신뢰를 얻어 범용 DBMS로 성장할 수 있었던 것은 다음과 같은 여건들이 성숙되었기 때문이다.

실시간 데이터 처리 요구 증가
기업의 정보시스템 환경이 웹 기반으로 전환되고 인터넷이 대중화되면서 고성능/대규모 트랜잭션 처리 요구가 전 산업 분야에서 크게 증대되고 있다. 특히 통신, 금융분야는 고객 및 정보관리에 있어서 실시간 데이터 관리가 필수불가결한 요소이다. 온라인 서비스 환경이 일반화 되고 동시 사용자수는 과거에 비해서 비약적으로 증가하고 고객의 기대 수준 역시 높아졌다.

불과 몇 년 전만 하더라도 기업들은 사용자의 시스템 액세스 패턴을 예측할 수 있었기 때문에 사전에 시스템 증설 계획이나 피크 타임에 대한 방안을 마련하여 최상의 속도를 제공하기에 무리가 없었지만, 이제는 얼마나 많은 동시 사용자가 접속할 것인지, 그리고 특정 시간대에 집중될 것인지 아무 것도 예견할 수 없는 상황에 봉착하고 있다. 그럼에도 불구하고, 기업들은 언제 어디서나 수시로 접속하여 시스템을 사용할 지 모르는 사용자들을 위한 서비스 품질 보장 방안을 마련해야 하는 이중고를 겪고 있다. 결국 기업들은 이러한 고객들의 요구를 충족시키기 위해 피크타임에도 사용자들에게 최상의 처리속도를 제공할 수 있도록 실시간 데이터 처리 방안에 눈을 돌리게 된 것이다.

기존 DBMS의 처리 한계
고객의 변화하는 요구에 부합하기 위해서는 데이터는 일반적으로 지속적으로 증가하고 다양한 형태로 가공되고 시스템은 복잡 대형화 된다. Oracle, DB2, MS-SQL 과 같은 일반 디스크 상주형 DBMS(Disk Resident DBMS, 이하 DR DBMS)는 대용량 데이터 처리에 적합하나 대용량 데이터의 초고속 처리에는 그 한계를 드러내곤 한다. DR DBMS는 버퍼 캐쉬를 통해서 느린 디스크 성능을 보완하는 구조를 갖고 있다. 그러나 사용자의 선택에 따라서 버퍼 캐쉬에 상주시킬 데이터를 선택하는 것이 아니라 데이터의 접근 빈도에 따라서 DR DBMS가 판단하기 때문에 데이터의 운용상태에 따라서 실시간 처리의 중요도가 낮은 데이터가 버퍼 캐쉬를 점유하여 정작 실시간 처리가 필요한 데이터의 버퍼 미스(Buffer Miss Ratio)를 유발하여 기대한 효과를 얻지 못할 수가 있다. 이러한 문제 해결을 위해서 어떤 기업에서는 실시간 처리용 소프트웨어를 자체 개발하여 사용하기도 하였다. 일례로 일찍부터 증권업계에서는 고속 처리가 필요한 소규모의 데이터를 메모리에 저장하고 관리하기 위한 다양한 솔루션을 개발해 이용해 왔었다. 그러나 여전히 산업표준, 높은 가용성, 실시간 처리능력, 확장 가능한 구조를 동시에 만족시키는 DB 시스템이 절실히 요구되어 왔고 최근 증권 분야의 MM DBMS 활용 사례에서 살펴볼 수 있듯이 MM DBMS가 그 확실한 대안이 되고 있다.

메모리 가격 하락 및 64비트 운영체제 등장
반도체 칩의 집적도가 향상되고 대량생산을 통해 메모리 가격이 지속적으로 하락하면서 대용량 메모리를 장착한 시스템의 구성이 쉬워졌다. 32bit 운영체제는 메모리 어드레싱(addressing) 한계로 인해서 사용 가능한 최대 메모리크기가 4GB인 제약사항이 있어서 MM DBMS가 대용량 DB로 업무영역을 확장하는 데 큰 제약사항이 되어왔다. 그러나 메모리 가격 하락과 64비트 운영체제가 보편화 되면서 최근에는 512GB까지 메모리를 장착할 수 있는 시스템이 등장했다. 이러한 환경의 변화를 통해서 MM DBMS가 지원하는 최대 DB 사이즈가 커질 수 있는 유리한 여건이 조성되면서 그 적용분야도 점차 다양화 되고 있다.

고객의 마인드 변화
과거 첨단 정보 시스템이라면 앞다퉈 도입하던 기업들은 이제 기업의 비즈니스 기회 창출에 반드시 필요한 것인지 꼼꼼히 따져본 후 도입을 검토하고, TCO(Total Cost of Ownership) 및 ROI(Return of Invest) 측면에서 정량화된 효과를 측정 가능한 시스템만을 선별하여 투자를 집행하려는 움직임이 두드러지게 나타나고 있다.

과거에는 외산이냐 국산이냐 또는 어떤 브랜드이냐가 중요한 선택의 기준이었지만, 이제는 어떠한 제품이 더 뛰어난 성능과 신뢰성을 제공하는지 더 나아가 제대로 된 기술 지원을 받을 수 있는지, 경쟁력 향상에 기여할 수 있는 지 등을 판단 기준으로 삼고 있다. 그 결과, 굳이 외산을 고집하지도 않을 뿐 더러 보다 비용 효과적인 제품들의 선택에 눈을 돌리고 있다.

결국 기업들은 갈수록 방대해 지는 데이터의 효용성을 높이고, 트랜잭션 처리 속도의 향상이라는 해결 방안을 제시하고, 실제 상용 DBMS 대비 70~80% 비용에 10배 이상의 성능을 발휘하는 MMDBMS가 주목 받는 것은 지극히 당연한 일이라고 할 수 있겠다.
















<그림1> MM DBMS의 활용추이

MM DBMS의 개념
MM DBMS와 DR DBMS의 기능적 구조적 차이점을 살펴보기 전에 디스크 저장 장치와 메모리 간의 다른 특성에 대해서 먼저 간단하게 살펴 보기로 한다.

*메모리에 대한 접근 속도는 디스크 저장장치와 비교되지 않을 만큼 빠르다.
* 메모리는 휘발성 저장장치이다. 그러나 비용을 추가하면 메모리를 비휘발성 저장장치로 구성하는 것도 가능하다.
*디스크 데이터의 배치상태는 메모리의 데이터 배치상태보다 접근 속도에 결정적인 영향을 줄 수 있다. 때문에 디스크에 대한 순차적(sequential) 접근 속도가 랜덤 액세스(Random Access) 보다 훨씬 빠르다. 메모리 데이터에 대한 순차적 접근은 중요하지 않다.
* 보통 프로세서는 메모리를 직접 접근하지만 디스크는 그렇지 않다. 이 때문에 메모리상의 데이터는 디스크상의 데이터에 비해서 소프트웨어 에러의 영향을 받기가 쉽다.

위와 같은 차이점은 동시성제어, 데이터 저장구조, 인덱스 구조 등에 이르기까지 메모리의 빠른 접근속도를 효율적으로 이용하도록 MM DBMS의 설계와 구현시에 고려되어졌다.

MM DBMS가 ‘데이터의 고속 처리’라는 목표를 위해서 개발된 제품이긴 하지만 동시에 기본적인 DBMS의 요건인 데이터의 안정성 보장을 신뢰할 수 있어야 한다. 그러나 메모리는 그 특성상 전원공급이 차단되면 저장내용이 소실되는 휘발성의 저장장치이므로 정전이나 OS의 다운 등과 같이 예기치 않은 상황에서는 데이터의 안정성을 보장할 수 없다. 이에 대한 해결책으로 MM DBMS는 DR DBMS와 마찬가지로 메모리상의 데이터 변경사항을 디스크에도 동시에 기록한다. 일반적으로 메모리가 디스크에 비해서 수천 배 빠르지만 MM DBMS가 DR DBMS에 비해서 수천 배 빠르지 않은 이유는 데이터 안정성 보장을 위해서 비 휘발성 저장장치인 디스크 장치를 이용하는 디스크 I/O를 동반하기 때문이다.

MM DBMS는 구동하면서 데이터와 인덱스를 포함한 디스크 상의 모든 DB 전체를 메모리로 로딩하는 단계를 거친 후 모든 레코드의 접근이 메모리상에서 이루어진다. 구동 이후부터는 디스크는 메모리 상의 변경 트랜잭션에 대한 백업 데이터를 유지하는 용도로 사용된다. 휘발성의 저장공간인 메모리에 저장되는 데이터를 영구적인 기록장치인 디스크에도 동시에 기록함으로써 일반인이 우려하는 것처럼 정전이나 MM DBMS의 다운 혹은 시스템 다운으로 인해서 DB 데이터가 소실되지 않는 것이다. 그러나 데이터의 안정성 보장을 위한 디스크 I/O 작업은 MM DBMS에게 데이터 처리 성능저하라는 불가피한 손실(trade-off)을 요구하기 때문에 MM DBMS에는 디스크 I/O에 의한 성능저하를 감소시키기 위한 다양한 기법이 도입되었다.

첫째, 디스크 I/O 횟수를 가능한 한 최소화하였다. MM DBMS는 DR DBMS와는 달리 버퍼 캐쉬가 별도로 존재하지 않기 때문에 페이지 교체가 없고, 체크포인트 시점에서만 메모리와 DB간의 동기화가 이루어지며 이로 인해 DR DBMS보다 로그 버퍼가 강제로 디스크에 플러쉬(flush)되는 상황을 줄일 수 있어 I/O 횟수를 줄일 수 있다.

둘째, 디스크에 로깅되는 정보의 양을 최대한 줄였다. 로깅되는 정보를 로그 레코드라고 하는데 이 로그레코드에는 변경된 데이터의 내용뿐만 아니라 장애 발생시점 이전으로 회복(Recovery)하는 데 필요한 다른 정보들을 포함하기 때문에 변경된 데이터의 양보다 사이즈가 크다. 따라서 로그 레코드를 최대한 줄여서 디스크 I/O 양을 줄이는 것이 성능 저하를 최소화하는데 매우 중요하다. MM DBMS에서는 인덱스 구성을 DBMS 구동 시에 다시 생성하는 구조를 가져감으로써 인덱스 변경에 따른 트랜잭션 로그를 남기지 않는 방식을 채택하고 있다. 이로써 생성되어야 할 많은 양의 트랜잭션 로그를 획기적으로 줄일 수 있다. 그리고 트랜잭션 중간에 발생하는 언두 레코드(Undo Record) 역시 메모리 페이지에 만들기 때문에 트랜잭션 회복 데이터의 생성을 위한 디스크 연산을 줄일 수 있다.

장애시점 이전으로의 회복(Recovery)을 위해서 MM DBMS는 주기적인 체크포인트를 통해 변경된 메모리 데이터를 디스크로 동기화 하는 방법과 마지막 체크포인트 이후에 생긴 트랜잭션 로그파일을 통한 복구 방법을 사용하며 이는 일반적으로 사용되는 DBMS들의 회복기법이며 DR DBMS에서도 유사한 방식을 사용한다.

DRBMS와 대비되는 MM DBMS의 가장 큰 특징이자 차이점은 운영 데이터의 존재 위치가 다르다는 점이다. 그러나 DR DBMS 에서도 디스크 데이터는 빠른 액세스를 위해서 메모리를 사용하는 버퍼 영역으로 캐쉬될 수 있고 MM DBMS는 메모리에 있는 데이터를 디스크에 백업할 수 있다. 따라서 DR DBMS와 MM DBMS 모두 특정 데이터가 디스크와 메모리에 동시에 존재할 수 있다. 그러나 주요한 차이점은 MM DBMS에서는 주(primary) 데이터의 상주 위치가 메모리이고 디스크에는 단순히 백업 데이터가 저장된다는 점이며 DR DBMS는 디스크상에 주 데이터가 존재한다는 점이다. 그렇다면 충분히 큰 버퍼 캐쉬를 확보한 DR DBMS는 MM DBMS와 어떤 차이점이 있는 것일까라는 의문을 가져볼 수도 있다.

DR DBMS가 모든 디스크 데이터 전체가 버퍼 캐쉬에 상주할 수 있을 정도로 충분히 크게 확보된 경우 캐쉬가 작을 경우에 비해서 좋은 성능을 내는 것은 분명하나 메모리를 충분히 효율적으로 이용하지는 못한다. 어플리케이션이 특정 튜플(tuple)에 접근하고자 할 때마다 먼저 그 디스크 어드레스(address)가 계산되고 그런 후 버퍼 매니저는 해당 데이터 블록이 메모리에 있는지 조사할 것이다. 그러나 레코드가 메모리에 상주한다면 이러한 과정이 필요 없이 그 레코드의 주소를 메모리 어드레스로 바로 참조할 수 있다. 불필요한 연산과정을 생략하고 접근 알고리즘을 단순할 수 있기 때문에 DR DBMS와 탐색속도에서 차이가 난다.













<그림2> MM DBMS와 DR DBMS의 데이터 처리구조

MM DBMS의 구조
MM DBMS는 실시간 트랜잭션 처리를 주 목표로 개발된 제품이기는 하지만 DBMS의 목적인 데이터 관리와 DB 응용 프로그램 개발을 지원해야 하므로, DR DBMS와 유사한 구조를 지니고 있다. 보편적으로 사용되는 관계형 데이터 모델(Relational DBMS Model) 을 지원하고 표준 SQL 구문을 대부분 지원하며 DB 응용 프로그램 개발을 위한 다양한 도구를 제공한다는 점에서 기존 DR DBMS와 큰 차이가 없다.

MM DBMS의 내부구조는 각 벤더별로 약간의 차이가 있으므로 본 회에서는 알티베이스 제품을 대상으로 기술하도록 하겠다. 알티베이스 구조는 DB 인터페이스, 통신계층, 질의처리계층, 자료저장관리계층, 유틸리티 등으로 분류할 수 있다.

DB응용프로그램 개발과 밀접한 관련이 있는 인터페이스는 클라이언트-서버용 인터페이스들로서 ODBC, JDBC, ESQL(Embedded SQL)를 지원하므로 DR DBMS 개발방식과 유사한 방식으로 DB 응용프로그램개발이 가능하다. 통신계층(Communication Layer)은 DB 클라이언트 프로그램들과 DB 서버간의 통신과 연결정보를 관리한다. 질의처리계층(Query Processing Layer)은 실행할 SQL구문을 파싱하고 옵티마이저가 질의를 최적화하고 실행하는 계층이다. 자료저장관리계층(Storage Management Layer)은 메모리에 상주하는 실제 데이터를 저장하고 관리하는 계층이다. 유틸리티들로는 데이터 export/import 툴(ILOADER), 대화형 질의도구(ISQL), 프리컴파일러, GUI 툴(Admin Center), 이중화 데이터 관리툴(AUDIT) 등이 있다.












<그림 3> 알티베이스의 내부 구조

MM DBMS VS. DR DBMS
MM DBMS와 DRDBMS의 가장 근본적인 차이는 저장 장소의 차이이다. DR DBMS의 저장 장소는 기본적으로 디스크인 반면, MM DBMS의 데이터 저장 장소는 메모리이다. 그러나 데이터를 관리하는 기능에 있어서는 MM DBMS나 DR DBMS 간에는 거의 차이가 없다. 그러나 분명히 이들을 서로 구분 짓는 몇 가지 특징들이 있다. 다음은 MM DBMS와 DR DBMS를 비교 분석한 자료이다.

<표1> MM DBMS와 DR DBMS의 비교

구분	MM DBMS(알티베이스)	DR DBMS
DBMS Process구조	멀티 쓰레드 구조	멀티 프로세스 구조/멀티 쓰레드 구조
데이터 모델	관계형 모델 구조	관계형 모델 구조
아키텍처	클라이언트-서버/응용내장	클라이언트-서버
이중화	네트워크를 통한 데이터 이중화	디스크 공유 & 별개 Instance
데이터 버전관리	다중 버전 레벨 데이터 처리	다중 버전 레벨 데이터 처리
Locking Mode	레코드 레벨 락	레코드 레벨 락
DB Recovery	체크포인트& 로그파일 이용	체크포인트& 로그파일 이용
DBMS Interface	ODBC, JDBC, CLI, Embedded SQL, PHP, Perl, XA, SNMP, GIS, LDAP, Stored Procedure 등	ODBC, JDBC, CLI, Embedded SQL, PHP, Perl, XA, SNMP, GIS, LDAP, Stored Procedure, 4GL, XML 등 이외에도 다수의 API를 제공함
데이터 Access	SQL92 표준	SQL표준 뿐만 아니라 확장된 SQL
인덱스	변형된B Tree, T-tree	B* Tree
저장 데이터 용량	시스템에서 제공하는 메모리공간	시스템에서 제공하는 디스크 용량
DB 위치	메모리와 디스크 (체크포인트를 통해 동기화됨)	디스크
트랜잭션로그	디스크	디스크
온라인 백업	지원	지원
유틸리티	관리자 도구, 모니터링 도구, 대화형 질의 도구, 데이터 export/import 유틸리티, SQL 튜닝도구, 국내 DB 써드-파티업체와의 협력으로 모니터링 및 튜닝툴들이 출시예정	MM DBMS가 지원하는 유틸리티외에도 많은 다양한 도구가 있고 써드-파티 업체를 통해서도 다양한 유틸리티들이 제공됨.

<표1>에 보는 바와 같이 MM DBMS는 DR DBMS와 마찬가지로 데이터 관리와 접근이라는 DBMS의 기본적인 요구 기능을 지원해야 하므로, 많은 부분에서 유사한 특징을 갖고 있다. 특히 고가용성을 보장하기 위해서 MMDBMS가 이중화 기능을 지원하고 있는 점은 주목할 만하다. DR DBMS는 디스크 공유가 가능하기 때문에 데이터베이스 자체를 공유하는 것이 가능하므로 클러스터링 기법을 사용하는 반면, MM DBMS는 일반적으로 메인 메모리를 서버간에 공유하는 것이 불가능하므로 네트워크를 통해서 양 서버의 데이터베이스를 실시간으로 복제하여 사용하는 이중화 기법을 사용한다. 이러한 이중화 기능은 MM DBMS가 통신업무, 금융업무와 같은 고가용성을 요구하는 산업에도 하드웨어 상의 제약 사항을 극복하고 적용 가능하게 한 기술적인 성과이며, 다음 회에서 보다 자세히 살펴보기로 한다.

<표2>는 MM DBMS와 DR DBMS의 처리성능을 수치화하여 그래프화한 것이다. 데이터 변경 연산(Insert, Update, Delete문)은 약 50배 정도의 성능 차이가 나며 데이터 조회 작업은 DR DBMS 역시 버퍼 캐쉬에 존재하는 데이터를 대상으로 하였기 때문에 약 3-4배 정도의 차이가 발생한다.
















<표 2> MM DBMS와 DR DBMS의 처리성능

MM DBMS의 발전추이
짧은 역사에도 불구하고 MM DBMS는 소형 휴대기기인 PDA부터 대형 플랫폼까지 다양한 종류의 플랫폼에서 작동하며 데이터베이스 크기와 적용형태에 따라서 아래의 세 가지 유형의 제품군으로 분류되며 발전해 오고 있다.

*내장형(Embedded) MM DBMS
메모리 크기가 제한적인 특수목적의 하드웨어나 업무에 이용되며 게이트웨이, 통신 서비스 장비, HLR 등에 플랫폼 내장형, 또는 S/W 내장형 등의 형태로 활용된다. 일부 제품은 고성능 경량화를 위해서 범용 메모리 DBMS에서 사용되는 클라이언트-서버 아키텍처가 아닌 DB서버가 응용 프로그램에 내장되는 형태인 응용-내장형 구조를 갖기도 한다. 범용 MM DBMS의 많은 기능을 제거한 대신 고성능 경량화를 추구하며 디스크가 없는 장비에서 구동되는 경우 회복(Recovery)을 위한 로깅 조차 하지 않은 형태로 운영되기도 한다.

*범용 MM DBMS
DR DBMS로는 요구 성능을 만족시킬 수 없는 경우 대체용 DB로 활용되거나 MM DBMS와 DR DBMS를 병행 사용하는 형태로 사용된다. 때문에 DR DBMS을 대체할 수 있도록 많은 기본기능을 지원하고 산업표준 규약을 준수하여 DR DBMS와의 호환성을 유지한다. 처리 업무의 특성에 따라서 DB의 크기는 수백 메가바이트에서 에서 수십 기가바이트까지 다양하다. 한가지 제품으로 소용량 DB와 대용량 DB기능 모두를 지원한다.

* 하이브리드형(Hybrid) MM DBMS
일년 전부터 시장에 출시되기 시작한 신개념의 MM DBMS로서 기존의 MM DBMS가 갖는 시스템이 지원하는 메모리 크기를 초과할 수 없는 MM DBMS의 DB 용량의 한계를 극복한 제품이다. 데이터를 메모리뿐만 아니라 디스크에도 선택적으로 저장할 수 있도록 DR DBMS의 기능도 동시에 제공한다. 접근 빈도가 높은 데이터(Hot data)는 메모리에 빈도가 낮은 데이터(Cold data)는 디스크에 저장하는 것이 가능하므로 시스템 메모리보다 큰 DB용량을 사용할 수 있다. 고성능 대용량이라는 두 가지 기능을 동시에 요구하는 업무영역에 DB용량의 한계로 인해서 MM DBMS만으로는 대체가 불가능하여 MM DBMS와 DR DBMS를 병행 사용해야 할 때 발생할 수 있는 여러 가지 단점을 해결한 제품이다.

이상으로 MM DBMS의 등장배경과 개념 그리고 구조와 발전 과정에 걸쳐서 대략적으로 살펴보았다. 다음 시간에는 MM DBMS의 여러 특징들이 산업현장에서 어떻게 이용되고 있는지 MM DBMS의 활용사례를 중심으로 알아보기로 한다.

* 이 글은IT 전문 월간지 <온더넷> http://www.ionthenet.co.kr에도 게재된 내용입니다.

--------------------------------------------------------------------------------------------------------------------

구축 사례로 살펴본 MM DBMS 활용방안 -2회

지난 호에서 MMDBMS의 등장 배경에 대해 살펴본 데 이어, 이번 호에서는 MMDBMS가 DRDBMS에 비해 얼마만큼의 성능 우위를 가지고 있는지, MMDBMS를 이용한 시스템 구성으로 얻을 수 있는 혜택을 실제 적용 사례를 통해 살펴보는 시간을 갖고자 한다.

MMDBMS, 기존 DRDBMS 대비 약 10배 빠른 성능 제공
MMDBMS가 DRDBMS보다 월등히 높은 성능을 제공한다는데 이견이 없을 것이다. MMDBMS가 높은 성능을 보장하는 이유는 의외로 간단하다. 저장 장소가 DRDBMS와는 다르기 때문이다. 즉, 데이터베이스 전체를 물리적인 메모리에 모두 상주시켜 운영하므로 응용 프로그램에서 요구하는 데이터를 메모리에서 직접 읽어 보내줄 수 있기 때문이다. MMDBMS는 성능만 빠른 것이 아니라, DRDBMS와 동등한 수준의 데이터베이스를 관리하는 기능도 제공한다.
그렇다면, 실제 MMDBMS와 DRDBMS의 성능 차이를 다음에 제시하는 세 가지 도표를 통해 살펴보기로 하자. <표 1>은 단순 트랜잭션 성능 측정을 위한 벤치마크 도구인 TPC-B 벤치마크 suite를 이용해 DRDBMS와 MMDBMS의 성능을 비교 평가한 자료인데, 데이터 건수에 관계없이 MMDBMS가 DRDBMS보다 약 9배 이상의 빠른 성능을 제공하고 있음을 보여준다.


<표 1> MMDBMSMS의 기본 성능 비교

<표 2>는 지난 해 대만의 모 증권사에서 MMDBMS의 도입을 검토하면서 실시한 기존 DRDBMS와 ALTIBASE 3의 성능을 비교 테스트한 자료이다. TPC-B 보다 더 큰 성능 격차가 있음을 살펴볼 수 있다. 테스트 방법이나 장비, sql문 등에 따라 지표 차이가 발생할 수 있음을 충분히 고려한다고 하더라도 MMDBMS가 DRDBMS에 비해 월등한 성능 우위를 갖고 있음을 재확인할 수 있다.

Item	Disk DBMS		ALTIBASE3
Insert 100,000 records	100 seconds	1,000 tps	7 seconds	14,286 tps
Update 100,000 records	115 seconds	870 tps	5 seconds	20,000 tps
Delete 100,000 records	123 seconds	813 tps	3 seconds	33,333 tps
Truncate Table	2 seconds		1 seconds

(SUN E4500장비에서 측정된 자료임)

<표 2> 대만 모 증권사에서 실시된 MMDBMSMS VS DRDBMS 성능 비교 평가 자료

마지막으로 MMDBMS와 상용 DRDBMS를 TPC-H를 통해 비교한 자료인 <표 3>을 살펴보면, 일부 TPC-H 쿼리들의 경우 최대 30배까지의 빠른 응답 속도를 보이고 있음을 살펴볼 수 있다. 이 때 DRDBMS는 버퍼히트율(buffer-hit-ratio)이 99% 상태에서 측정하였다.

<표 3> TPC-H를 이용한 MMDBMS와 DRDBMS 성능 비교 자료

MMDBMS는 비단 조회를 통한 쿼리뿐만 아니라 변경연산(Insert, Update, Delete)도 트랜잭션 로깅(logging)의 단순화 및 메모리에 데이터를 적재해 둠으로써 통상적으로 10배 정도의 빠른 처리가 가능하다. 변경 연산이 디스크와 메모리의 성능과 비교할 때 100배 이상의 성능 차를 보이지 못하는 이유는 MMDBMS 역시 비정상 장애를 대비한 트랜잭션 롤백 로깅 등을 포함, 디스크 I/O가 발생하기 때문이다.

메인 메모리는 속성상 전원 공급이 차단되면 저장 내용을 잃어버리는 휘발성(volatile)을 갖고 있어서 컴퓨터 시스템의 전원이 차단되거나 OS의 운영이 멈춘다면, 메모리에 상주하고 있던 데이터베이스는 모두 지워지게 된다는 사실을 많은 사람들이 인지하고 있다. 그래서 통상적으로 MMDBMS라고 하면 데이터를 메모리에만 존재시키고 로깅조차 하지 않아 장애나 정전 발생시 데이터가 모두 날아가버릴 거라고 자칫 오해하기 쉽다. 그러나 MMDBMS 역시 데이터 유실을 방지하기 위한 다양한 회복 기법을 제공하고 있기 때문에 일반적인 DRDBMS와 마찬가지로 데이터 유실을 허용하지 않는다. 또한, 상용 DRDBMS들과 비교할 때 로깅의 기법 면에서 최적화되어 있기 때문에 동일한 환경에서도 빠른 성능을 가져갈 수 있다.

MMDBMS, 이중화를 통한 탁월한 유연성 제공
MMDBMS는 빠른 성능을 제공하는 것 이외에도 시스템 구성 측면에서도 탁월한 유연성을 제공하는데, 이는 ‘이중화(Replication)’라는 핵심 기술 때문이다.

이중화는 물리적으로 떨어져 있는 여러 개의 데이터베이스에 대해 로컬 데이터베이스의 변경 내용을 원격 데이터베이스에 복제하고 관리하는 기술이다. 사용자는 하나의 데이터베이스에 대해서만 작업을 수행하여도 데이터베이스 이중화 시스템에 연결되어 있는 다른 데이터베이스에서도 작업 내용이 동일하게 적용되어 여러 개의 데이터베이스를 동시에 관리할 수 있다. 이러한 데이터베이스의 이중화는 데이터베이스의 무정지 서비스를 가능하게 한다.

따라서 디스크 공유 방식의 시스템 페일오버(Failover) 형태의 서비스를 구성하는 DRDBMS는 하드웨어 장애 발생시 백업 미디어를 통한 복구(Recovery)를 수행해야 하고 어떠한 복구 방식을 채택한다고 하더라도 서비스 중단 사태를 방지할 수 없지만, MMDBMS는 TCP 방식의 이중화 구성을 이용해 각 서버는 최소한의 간섭으로 독립적으로 운용될 수 있기 때문에 가용성(High Availability)와 확장성(Scalability)를 높일 수 있다. 즉, 주 시스템에 장애가 발생하더라도 n-way로 구성된 서비스에는 영향이 끼치지 않기 때문에 무정지 시스템 구성이 가능할 수 있다.

<그림 1> 알티베이스 이중화 내부 구조

데이터베이스 이중화 기법으로는 주-대기(Active-Standby) 위상과 활동-활동(Active-Active) 위상이 있는데, 최근에는 활동-활동 위상에 대한 요구가 크게 증가하고 있다. 이에 따라 동시성 제어 및 트랜잭션 관리 기술이 빠르게 발전하고 있다.
서버 구성에 따라 데이터베이스 이중화를 위한 통신 모델은 <그림 2>와 같이 4가지로 구분된다. 주-대기 서버 이중화 모델은 데이터베이스 이중화뿐만 아니라 분산 시스템의 전형적인 이중화 모델로서, 정상적인 운영 모드에서 주 서버는 일반적인 데이터베이스 서비스를 제공하는 것처럼 보이지만, 실제로 자신의 변경 내용을 대기 서버로 전달하고 있으며, 대기 서버는 데이터베이스 서비스는 하지 않은 채, 전달 받은 내용을 자신의 데이터베이스에 반영하게 된다. 주 서버에 오류가 발생하면, 주 서버의 서비스를 받던 응용들을 대기 서버로 옮겨 대기 서버에서 새로운 서비스를 시작하게 된다. 주 서버의 오류가 복구 되면 그 동안의 대기 서버의 변경 트랜잭션을 주 서버에 보내 이중화 작업을 계속 수행한다. 그 후, 양 서버의 역할을 바꾸어 계속 수행하거나, 주 서버와 대기 서버의 역할을 바꾸어 수행하기도 한다.
활동-활동 서버 이중화 모델은 응용 업무를 분리하여 처리하거나 부하 분산을 위해 주로 사용된다. 변경된 데이터 갱신 내용을 서로 상대편 서버에 이중화하는 작업을 수행하고, 응용에서 발생하는 트랜잭션을 두 그룹으로 분리하여 각각의 서버에서 수행하게 한다. 이후 변경 트랜잭션을 교환, 양 서버의 데이터 변경 내용을 일치시켜 상호 이중화하는 방식이다.
주-다중(Active-Multistandby) 대기 이중화 모델은 성능에 민감하고 높은 가용성을 요구하는 응용에 적합한 모델로서, 하나의 주 서버와 두 개 이상의 대기 서버로 구성된다. 주-대기 서버와 기본적으로 동일한 구성을 갖지만, 대기 서버 수가 많다는 점에서 시스템의 가용성을 더욱 높일 수 있다. 이 구조는 높은 고가용성을 얻을 수 있어, 크리티컬한 응용 시스템에 적합한 모델이지만 비용이 많이 든다는 단점이 있다.
다중 대기 서버에 변경 트랜잭션을 전달하기 위해 소요되는 주 서버의 오버헤드를 절감시키기 위해, <그림 2>의 (라)와 같은 전용 변경 전달 서버(propagator)를 운영하여 주-다중 대기 서버 모델을 운영할 수 있다.

<그림 2> MMDBMS 이중화 구성 모델

이상으로 MMDBMS의 성능 지표 및 로깅, 이중화 구성 등에 대해 알아보았다. 이를 통해 MMDBMS가 성능을 요구하는 다양한 시스템에 적용 가능한 DBMS임을 살펴볼 수 있었다. 지금부터는 주식시세, 과금, 빌링, 공장자동화 등 실제 구축된 사례들을 통해 기존 시스템을 MMDBMS로 교체하여 어떠한 개선 효과를 거두었는지에 대해 살펴봄으로써 독자들의 이해를 돕고자 한다.

구축 사례를 통해 살펴보는 MMDBMS 활용 방안
[증권사 적용 사례]
21세기 접어들면서 가속이 붙기 시작한 온라인의 대중화는 증권사들에게도 새로운 비즈니스 기회를 제공하게 되었고, HTS(Home Trading System)를 계기로 새로운 전성기를 맞이하게 됐다. HTS의 활성화는 개인 투자자들의 다양한 요구를 유발시켰는데, 특히 당일 시세 데이터 등에 대한 실시간 분석 및 다양한 차트/시세 분석 서비스에의 요구가 급증하게 되었다. 이러한 요구들은 DRDBMS의 성능 한계로 CISAM/공유 메모리(Shared Memory) 등을 이용해 서비스를 운영하던 증권사들에게 새로운 도전이 아닐 수 없었다. 그도 그럴 것이 파일 기반의 CISAM은 데이터에 대한 분석 정보를 만들기 위한 로직(logic) 자체가 너무나 복잡한데다가 통합적인 관리에 어려움이 있었고, 공유 메모리(Shared Memory) 역시 다양한 고객요구 분석을 구현하기에는 역부족이었기 때문이다.

당시 증권사들이 직면했던 문제점들을 정리해 보면, 다음과 같다.
1.파일로 ISAM을 관리하기 때문에 지연 처리된 DB를 병행운영을 한다고 해도 File-Crash로 인한 장애를 회복할 방안이 쉽지 않다.
2.CISAM에 대한 I/O 증가 시 급격한 성능 저하를 유발시킨다.
3.장애 발생에 대비한 데이터 이중화 구축이 불가능하다.
4.확장성의 문제
5.다양한 분석서비스 등에 대한 고객요구의 능동적인 수용이 어렵다.

증권사들은 위와 같은 문제들을 해결하고자 MMDBMS 도입을 검토하게 되었고, <그림 3>과 같이 시스템 가용성을 위해 MMDBMS 기반으로 직원용과 고객용으로 분리하여 시스템을 구축하여 가용성을 높이는 한편, 장애 발생시 페일오버(FailOver)가 가능한 시스템을 구축했다.

증권사들은 시스템 구축 이후 다음과 같은 성능 개선 효과를 거둘 수 있었다.
1.CISAM 사용시보다 성능이 개선되었으며 평균 시스템 Idle이 90%로 향상
2.고객의 요구사항을 능동적으로 수용함으로써 End-user의 만족도 향상
3.DBMS가 제공하는 이중화 기능을 통해 장애 대책이 구현됨으로 안정성 증가
4.DBMS 관리의 효율성 제고 및 개발의 편이성 증대
다시 정리해보면 HTS를 통한 개인 트레이더들의 양적 증가 및 주식시장 활성화로 인한 데이터 량의 증가로 인한 성능, 안정성, 고객만족이라는 벽에 부딪치게 되었다. 그러나 하드웨어의 성능 개선만으로는 따라가지 못하는 상황에서 과거의 구축방식은 많은 문제점들을 안게 되었고 이를 MMDBMS를 적용함으로써 성능, 안정성, 고객만족의 세가지 목적을 모두 충족시키는 효과를 거둘 수 있었다.


<그림 3> MMDBMS를 이용한 증권사 시세 조회 서비스 시스템 구축 사례

[인증 분야]
최근 웹사이트를 통한 서비스는 물론, 웹을 유무선 서비스와 연동한 다양한 서비스가 제공 되고 있다. 가입자들에 대한 동시 인증이 웹 서비스의 부하에 있어 큰 부분을 차지하고 있다. 그러나 하나의 서비스를 위해 별도의 인증서비스를 개별 사이트마다 부여하는 것은 여러 가치 측면에서 낭비와 부하를 초래하게 된다.

MMDBMS 도입을 고려하던 A사의 경우, 개별 구축된 사이트의 인증 작업을 하나의 서비스로 통합하는 포탈 사이트 통합 인증시스템을 구축하기로 결정하였다. 인증 업무 자체에 대한 신뢰성 및 다수의 동시 접속 시에도 무리 없는 처리 성능, 안정성 등이 필요하다고 판단, 철저한 테스트를 수행했다.

그 결과, A사는 액티브 디렉토리(Active Directory)에서 MMDBMS를 변경, 도입하였고, 도입 후 <표 4>와 같은 성능 향상 효과를 거둘 수 있었다.

	MMDBMS	Active Directory
Select Speed	4000 tps	1000 tps
Simple Query	OK	OK
Joined Query	OK	NO
Data Upload	2 Hrs	Over 10 days
Replication	OK	OK
Response Time	0.003	0.01
CPU Usage	6%	6%

<표 4> A사의 액티브 디렉토리 VS MMDBMS를 이용한 인증 서비스 성능 비교표

<표 4>에서 살펴볼 수 있듯이 조회만을 처리하는(물론, 고객정보의 변경도 동시에 수행되지만 조회에 비해 많은 양이라고 보기는 어렵다) 업무에 있어서 A사는 MMDBMS 도입을 통해 장비의 효율성을 극대화한 것은 물론, 성능 측면에서도 3배 이상의 개선 효과를 볼 수 있었다.

[빌링/과금 분야]
국내 최대 트랜잭션을 처리하는 B 통신사는 서비스 플랫폼의 변화 및 사용량의 증가, 다양한 요금체계, 비즈니스 모델의 효과적인 IT 지원, 고객 요구를 만족시키기 위해 실시간 과금 처리가 가능한 빌링 인프라 구축이 필요하다고 판단하고, 관련 계획을 수립했다. 특히 효과적인 구현을 위해 요구되는 처리 성능은 일일 최대 4억 Call에 대한 과금 처리(초당 5,000Call)가 가능해야 하고, DBMS측면에서 20-30억/일 처리를 할 수 있어야 한다는 것이 전제 조건이었다.

이를 염두에 두고 DBMS 검토에 들어간 B 통신사는 DRDBMS나 별도의 방안을 고려해도 일일 20-30억이라는 트랜잭션 처리는 불가능하다고 판단하였고, 엄격한 벤치마크 테스트를 거쳐 MMDBMS 도입을 결정하게 되었다. 현재 A 통신사는 다시 별도의 분리된 MMDBMS와 4웨이로 이중화를 구성하여 서비스를 운영 중에 있다.

<그림 4> A 통신사의 차세대 빌링 시스템

<표 5>는 A 통신사가 기존 방식과 MMDBMS 도입 후 거두고 있는 효과를 도표화한 것이다.

	기존 HOST 방식	MMDBMS 도입 후
처리방식	Batch 처리	실시간 처리
일처리량	Max 1.5억 Call/일	Max 4억 Call/일
일평균처리량	X	1.5억 Call/일
월평균처리량	X	1.5억 Call/월
개발환경	HOST COBOL	C++, JAVA 등 다양함
시스템상태	시스템의 한계상황	시스템의 50% 유지

우선 개발자 입장에서 살펴보면 과거의 COBOL 등으로 현재의 다양한 구현기법들을 적용하기 어려워 소스자체에 대한 개선/유지 보수 등이 상당히 쉽지 않았음을 짐작할 수 있다. 또한 운영자 입장에서 보면 과거 빈번한 시스템 한계 상황을 맞음으로써 장애에 대한 불안감을 갖고 있어야 했을 것이다(물론 운영자에게 있어 장애란 늘 인지되는 사항이겠지만). 업무/서비스 개발자의 입장에서 보면 일 처리량의 한계로 인해 다양한 수익모델을 창출할 수 있음에도 불구하고 IT 환경으로 인한 이익/서비스모델 창출에 매우 제한적인 요소가 되었음을 알 수 있다. 그러나 MMDBMS 도입을 통해 이러한 문제들을 일거에 해결함으로써 적용 단계에서 갖고 있던 문제점들을 해결할 수 있었다.

MMDBMS는 ‘하이브리드 MM DBMS’로 진화중
MMDBMS는 위에서 언급한 인증, 빌링/과금, HTS 등 이외에도 포탈 사이트에 접속하거나 핸드폰 통화를 시도할 때에도 사용되고 있으니 우리 생활과 매우 밀접하게 관련을 맺고 있다고 해도 과언이 아닐 것이다. 다만 우리가 인식하지 못할 뿐이다.

이렇게 폭넓게 사용되고 있는 MMDBMS이지만, 그 동안 많은 기업들은 검토나 응용 단계에서 다음의 2가지 문제로 인해 도입을 꺼려해 왔던 것이 사실이다.

1.메모리에 적재되는 데이터 처리로 안정성을 보장할 수 있을까?
2.물리적 메모리의 공간제약으로 인한 확장성은 어떻게 해결할 것인가?

1번에 대한 의문은 이제 더 이상 MMDBMS를 적용하는 단계에서 문제시 되지 않는다. 이미 많은 레퍼런스 사이트들이 이를 입증해 주고 있기 때문이다. 이미 언급한 것처럼 MMDBMS는 DRDBMS와 유사한 복구 기법 등을 사용하고 있을 정도로 상당히 진보하였고, 만일 안정성의 문제가 제기되었다면 이미 시장에서 사장되어 자취를 감췄을 것이다. (성능이 안정성보다 우선시되어 도입하는 IT담당자는 없을 것이다.)

그러나 2번에 대한 의문은 여전히 제기되고 있는 문제점이기도 하다. 실제 확장성의 문제로 기존 DRDBMS와 동시에 연동하는 서비스를 구축한 고객사도 다수 있는데, 이로 인해 중복 투자에 따른 비용 부담과 이기종 DBMS에 대한 데이터 일관성 보장으로 인한 적용 어려움을 겪고 있기도 하다. 그러나 최근 등장한 하이브리드 MM DBMS가 이에 대한 해답을 제시할 것으로 보여진다. 하이브리드 MM DBMS는 빈번한 액세스를 요하는 테이블은 메모리에 상주시키고, 히스토리 테이블 등과 같이 대량의 데이터이지만 접근이 빈번하지 않는 테이블들은 디스크에 상주시키고 하나의 DBMS로 통합관리하면서 서비스가 가능하도록 구현하는 DBMS이기 때문이다.

이제 MMDBMS는 확장성의 제약을 뛰어 넘어 하이브리드 MM DBMS로 진화하고 있다. 즉, 메모리의 빠른 처리성능과 무제한적인 디스크 공간의 저장성을 동시에 갖춘 형태로 발전되어 가고 있다는 것이다. 다음 장에서는 MMDBMS의 발전된 형태인 하이브리드 MM DBMS에 대해 좀 더 자세히 알아보도록 하겠다.

* 이 글은IT 전문 월간지 <온더넷> http://www.ionthenet.co.kr에도 게재된 내용입니다.

------------------------------------------------------------------------------------------------------------------------------------------

DBMS의 새로운 대안, 하이브리드 MM DBMS - 3회(끝)

최근 사회, 산업, 문화, 기술 등 전 산업분야에서 하이브리드(hybrid)라는 개념이 넘쳐나고 있다. 이론을 넘어서 실제 제품에 다양하게 적용되고 시장에 출시되고 있다. 연료를 혼용하여 에너지 효율을 높인 하이브리드 자동차, 플래시메모리를 이용한 하이브리드 디스크 등을 비롯해 하이브리드 마케팅, 하이브리드 증권, 하이브리드 쌀 등 다양한 분야에서 활발하게 적용되고 있다.
‘하이브리드’ 개념이 각광받는 이유는 각각 장단점을 가지는 제품 혹은 시스템의 장점들을 유연하게 결합하여 새로운 제품으로 재탄생시킴으로써 기존 제품의 단점을 극복함과 동시에 ‘고효율성’을 원하는 사용자들의 요구사항을 충족시켜 주기 때문인 것으로 보인다. 이와 같이 특정 분야를 막론하고 ‘고효율성’을 좇는 시장의 요구에 따라 제품이 능동적으로 변화하고 발전을 해야만 제품으로서의 영속성을 보장받게 되었다.
DBMS 분야에서도 예외가 아니어서 빠른 데이터 처리에의 요구 충족을 위해 메인 메모리 DBMS(이하 MM DBMS)가 등장하게 되었고, 최근에는 메모리와 디스크를 혼용하여 데이터를 저장하는 하이브리드 MM DBMS로 진일보하고 있는 상황이다.

MM DBMS의 한계
지난 호에서는 고성능이 요구되는 시스템을 MMDBMS를 기반으로 구축한 사례와 실제 효과에 대해 살펴보는 시간을 가졌다. 여기서 우리가 주목해야 할 사실은 단순히 고성능이 요구되는 시스템의 DBMS를 MM DBMS로 대체한다고 해서 모든 문제가 해결되지는 않는다는 점이다.
시스템 운영 환경이 64비트 환경으로 전환되면서 메모리 사용 제약은 없어졌고 메모리 가격도 지속적으로 하락하고는 있으나, 여전히 시스템에서 사용 가능한 메모리는 제한적이며, 디스크에 비해 메모리 가격은 여전히 높아서 실제 수 많은 메모리를 시스템에 탑재하기 위해서는 많은 비용을 지불해야만 하기 때문이다.
MM DBMS는 특성상 모든 데이터가 메모리에 상주하여 관리되므로 아직까지는 관리 가능한 데이터의 양이 제한적이라고 볼 수 있다. 그러나 실제 기업들이 관리해야 하는 데이터의 양은 대상이 늘어날수록 계속 커지며 이력(History) 관리를 위해서도 많은 양의 데이터를 계속 보관하여야 하므로 이를 MM DBMS로 대체하기에는 한계가 있다.
이와 같은 이유로 많은 기업들은 MM DBMS를 도입할 경우, 빠른 처리가 요구되는 업무의 데이터만 MM DBMS에 보관하고 이외에 이력 데이터는 별도의 디스크 기반 DBMS(이하 DR DBMS라 지칭함)를 두어서 따로 관리하는 구성하는 이기종 DBMS 혼용 방법을 채택하고 있다. 이는 업무상 핫(Hot) 데이터는 MM DBMS에 두고서 관리를 하다가 일정시간이 지나 통계성 업무에만 사용하는 데이터 혹은 이력 데이터로 데이터 가치가 하락하면 해당 데이터를 디스크 DBMS가 관리하는 디스크 테이블로 이관하여 MM DBMS가 관리하는 데이터의 크기를 조절하는 구성 방법이다.

MM DBMS와 DR DBMS의 혼용 구성의 문제점
실제 많은 기업들이 기업 내 빠른 처리 성능을 제공하는 MM DBMS의 제약 사항인 대용량 데이터 저장 문제를 해결하고 보다 효율적인 데이터 관리를 위해 MM DBMS와 DR DBMS의 혼용 시스템 구성을 채택하고 있다고 이미 언급한 바 있다. 그러나 실제 이기종 DBMS의 혼용 구성을 시스템에 적용하다 보면, 다음과 같이 해결해야 할 몇 가지 문제점들이 발생하게 된다.

1. 이기종 DBMS 간의 연동 문제
MM DBMS와 DR DBMS를 혼용하는 시스템은 이기종 DBMS간의 변경 부분에 대한 데이터 동기화 작업이 필요하다. 이런 구조로 시스템을 설계해 본 사람들은 알겠지만 이질적인 DBMS의 데이터를 서로 맞추는 작업이 그리 쉬운 일이 아니다. 별도의 애플리케이션을 이용하여 데이터를 직접 맞춘다 하더라도 예외 상황에 대한 처리나 달라진 데이터에 대한 감사(Audit) 작업을 자동적으로 수행하는 것은 거의 불가능하다. 각 DBMS 벤더마다 이기종 DBMS간의 연동을 위한 기능을 제공한다고는 하나 실제로는 사용상 많은 제약이 따르며, 원활한 연동을 하기 위해서는 DBMS 업체들 간에 기능 개발에 대한 협업이 전제되어야 한다. 그래서 대부분의 업체들이 MM DBMS의 변경 데이터에 대한 로그를 쌓았다가 주기적으로 DR DBMS로 전송하는 방법을 사용하고 있으며 이와 같은 작업을 수행하기 위해서는 이기종 DBMS에 각각 접속하여 SQL을 수행하는 에이전트(Agent) 애플리케이션의 개발이 부가적으로 필요하게 되는데, 양 DBMS간의 데이터 정합성을 감시 및 보정하기 위한 업무 프로세스를 만들어야 하므로 추가적인 개발비용을 부담해야 한다.

2. 애플리케이션 복잡성 증가
시스템에서 구동되는 애플리케이션은 접근하는 테이블의 위치에 따라서 DBMS를 지정하도록 설계되어야 한다. 이질적인 DBMS간의 SQL 조인(Join) 연산이나 트랜잭션(transaction) 관리가 되지 않기 때문에 애플리케이션 로직(Logic)에서 이러한 부분에 대한 처리를 해주어야만 한다(분산 트랜잭션을 사용할 경우에는 트랜잭션 관리는 가능하다). 예를 들면, 메모리 테이블의 내용을 조회하여 디스크 테이블로 입력하고자 할 경우 애플리케이션에서 MM DBMS로 연결을 맺은 후 메모리 테이블에 대한 SQL문을 수행하여 결과를 받아오고 이렇게 넘겨받은 결과를 DR DBMS로 연결하여 디스크 테이블에 입력하는 방법을 택해야 한다. 이렇듯 애플리케이션 개발 시 추가적인 고려사항이 생기므로 애플리케이션의 복잡도가 증가하게 된다.

3. 시스템 구성의 복잡성으로 인한 관리비용 증가
시스템 개발이 완료된 후 성공적으로 운영단계에 진입한다고 하더라도 문제점은 여전히 존재한다. 먼저 이기종 DBMS를 사용하기 때문에 각 DBMS 마다 관리 요소가 틀려지고 그 방법 또한 상이하다. 또한 이기종 DBMS간 데이터 동기화를 위해 추가된 여러 모듈들도 모두 관리의 대상이 되어야만 한다. 이외에도 장애복구시 절차가 복잡해지고 양 DBMS 간의 데이터 정합성을 확인하고 필요한 경우 보정해야 하는 등 실제 운영시 이기종 DBMS를 혼용함으로써 발생하는 추가적인 운영 비용이 많기 때문에 초기 시스템 설계시 미처 고려하지 못한 부분이 있다면 운영이 매우 어려운 상황까지도 생길 수 있다.

4. 시스템 자원의 낭비
빠른 처리가 필요한 업무는 MM DBMS로 접근하고 이력관리, 통계성 업무는 별도의 DR DBMS를 접근하도록 구성하더라도 양 DBMS 모두에 존재해야만 하는 데이터가 필요한 경우가 발생한다. 물론 애플리케이션에서 이기종 DBMS 모두를 접속하여 각각 데이터를 가지고 온 후 직접 가공하여 사용할 수도 있겠지만 참조해야 하는 데이터가 굉장히 많은 경우에는 이러한 방법 또한 불가능하다. 이와 같은 이유로 각 DBMS에 중복된 데이터를 저장해야 한다면 해당 테이블은 거의 실시간으로 데이터 동기화가 이루어져야 하며(물론 실시간으로 데이터 동기화가 이루어지게 하는 것은 분산 트랜잭션을 사용하지 않는 한 불가능하다) 중복된 데이터들을 관리해야 하므로 자원의 낭비가 생긴다.

하이브리드 MM DBMS의 등장
MM DBMS는 빠른 성능을 제공하지만, 관리 가능한 데이터 크기의 제약 사항으로 인해 그동안 알티베이스를 비롯한 대다수 MM DBMS 업체들은 특정 업무용 DBMS로써 공급에 주력해 왔다. 일정량의 데이터를 유지하면서 고성능 처리속도를 요구하는 증권사의 시세처리 시스템이나 실시간 과금처리, 위치정보, SMS 시스템 등의 통신사 업무, 단시간에 많은 트랜잭션이 발생하는 가입자 인증 서비스나 교통정보 시스템 등을 예로 들 수 있겠다. 그러나 점차 데이터가 대용량화되고, 데이터의 고성능 처리 요구가 급증하자 이를 모두 충족시킬 수 있는 시스템 등장이 요구되면서 MM DBMS와 DR DBMS 혼용 구성이 각광받기 시작했다. 그러나 이러한 이기종 DBMS의 혼용 구성은 개발 비용과 운영 비용의 증가라는 문제들을 유발시키면서 실질적인 대안으로 정착하지 못했다. 단일 DBMS 내에서 고성능 처리와 대용량 관리를 모두 지원하는 새로운 개념의 DBMS 등장을 필요로 하는 기업들의 요구에 힘입어 MM DBMS와 DR DBMS를 결합시킨 새로운 형태의 하이브리드 MM DBMS 인 ‘ALTIBASE 4’가 탄생하게 된 것이다.

사실 DBMS 분야에서도 하이브리드 개념은 새로운 것이 아니어서 기존 DBMS들이 성능, 기능 상의 이유로 하이브리드 DBMS 형태의 기능을 제공하기도 한다. DR DBMS에서 접근이 많이 일어나는 특정 테이블을 메모리에 캐시(Cache)시켜서 고정시키고 나머지 테이블은 버퍼 매니저(Buffer Manager)를 통해 관리함으로써 성능 향상을 꾀하는 기능도 있으며, MM DBMS에서 자주 참조되지 않는 대용량의 데이터를 파일로 쌓아서 관리한다든지 테이블들을 Pin(메모리에 올림), Unpin(메모리에서 내림)함으로써 부족한 메모리 공간을 효율적으로 관리하는 기능도 있다. 그러나 이와 같은 방법들은 DR DBMS를 위한 캐싱 기능 혹은 MM DBMS를 위한 파일관리를 기능일 뿐 양 DBMS의 장점을 포용한 진정한 의미의 하이브리드 DBMS는 아니다. 진정한 의미의 하이브리드 DBMS는 질의처리기가 메모리 테이블에 대해서 동작할 때에는 메모리 테이블에, 디스크 테이블에 대해서 동작할 때에는 디스크 테이블에 적합하게 동작해야 하며 데이터 관리 역시 파일 관리 수준이 아니라 테이블 형태로 지원이 되어야 하며 이 모든 과정이 사용자에게 투명(transparent)하게 제공되어야 한다.

하이브리드 MM DBMS의 특징
DR DBMS와 MM DBMS 두 시스템의 장점은 그대로 살리면서 기존의 개발환경과 DBMS로서의 기본 기능에 충실해야만 진정한 의미의 하이브리드 MM DBMS로 평가받을 수 있는데, ALTIBASE 4야말로 이러한 요구를 모두 충족시키는 유일한 상용 DBMS라고 할 수 있겠다. 그럼 지금부터는 ALTIBASE 4를 중심으로 하이브리드 MM DBMS가 어떠한 특징을 갖고 있는지 살펴보기로 하자.

1. 기존의 MM DBMS를 확장하여 추가적으로 디스크 테이블 스페이스를 제공
기존에 MM DBMS에서 메모리 저장 공간만 사용하던 것을 메모리 저장 공간과 디스크 저장 공간으로 분리하기 위해 테이블 스페이스(Table Space) 개념을 도입하였다. 기존의 메모리 저장 공간은 메모리 테이블 스페이스로 구성하고 디스크 테이블 스페이스를 추가하면서 이를 처리하기 위한 버퍼 관리자(Buffer Manager)를 두게 되었다. 이렇게 기존 MM DBMS에 DR DBMS 기능을 완전히 포함함으로써 기존 MM DBMS의 장점인 빠르고 안정적인 처리속도를 보장하면서 DR DBMS의 장점인 대용량 데이터 처리도 가능하게 되었다.

2. 메모리와 디스크의 선택적인 테이블 생성
MM DBMS에서는 테이블 생성시 해당 테이블은 메모리에 존재하며, DR DBMS에서는 생성된 테이블은 무조건 디스크에 존재하게 된다. 그러나 하이브리드 MM DBMS는 초기 테이블 생성 시 사용자의 필요와 판단에 따라 데이터를 메모리 혹은 디스크에 선택적으로 저장하는 것이 가능하다. 대부분의 시스템은 설계 당시부터 테이블 별 데이터의 접근 빈도 및 활용 가치가 예측 가능하기 때문에, 이와 같은 선택적인 테이블 생성은 효율적인 데이터 관리를 가능하게 해 준다. 데이터가 보관될 저장공간을 해당 업무를 잘 아는 사용자가 직접 판단하여 지정함으로써 데이터 별로 차별성을 부여하고 보다 효율적으로 데이터를 관리할 수 있다. 따라서 사용자는 액세스 빈도가 높을 것으로 예상되는 핫 데이터는 메모리 테이블로, 액세스 빈도가 낮은 콜드(Cold) 데이터나 대용량 테이블은 디스크 테이블로 구성하면 되는 것이다.
또한 동일한 데이터라도 시간의 흐름에 따라 그 가치가 달라지게 되는데 대부분 처음 데이터가 생성되면 액세스 빈도가 높은 핫 데이터 상태로 존재하다가 이후 시간이 흐르면서 새로운 핫 데이터들이 계속해서 쌓이면 이전 데이터는 중요도는 점점 낮아져서 액세스 빈도가 매우 낮은 콜드(Cold) 데이터가 된다. 하지만 이제까지 어떤 DBMS에서도 데이터 별로 이러한 차별성을 인정하지 않았으므로 이러한 핫 데이터와 콜드 데이터는 동일한 저장공간에 동일한 우선순위로 존재하게 되면서 데이터 관리의 효율성이 떨어졌던 것이 사실이다.

3. 메모리 테이블과 디스크 테이블의 트랜잭션 관점의 통합
대부분의 중요한 데이터베이스 엔진들이 이용하는 트랜잭션은 ACID(Atomicity, Consistency, Isolation, Durability)의 네 가지 특징을 만족시키는 기능들의 집합이라고 할 수 있다. 이러한 특성들은 디스크 테이블과 메모리 테이블에 접근되는 트랜잭션들에 대해서도 일관되게 보장되어야만 한다. 대부분의 DBMS는 트랜잭션의 동시성을 보장하기 위해서 락(Lock) 기법을 사용하며, 장애복구나 트랜잭션 실패 등을 처리하기 위해서 로깅(Logging) 기법을 사용한다. ‘ALTIBASE 4’는 메모리 테이블과 디스크 테이블에 접근하는 트랜잭션에 대해서 분리되지 않은 통합된 락 관리 기법과 로그 관리 기법을 제공한다.
만일 메모리 테이블과 디스크 테이블의 동시성 제어를 위해 각각 분리된 락 관리를 하고, 두 개의 서로 다른 종류의 테이블에 접근하기 위해 분리된 트랜잭션으로 접근하게 된다면 메모리 테이블과 디스크 테이블간에 제대로 된 동시성을 보장할 수 없을뿐더러 락 기법에서 항상 주요 이슈가 되는 데드-락(Dead-Lock)에 노출될 확률이 크게 증가할 수 있다.
로깅 기법은 트랜잭션의 지속성(Durability)와 함께 원자성(Atomicity)을 보장하기 위한 한 방법으로, DBMS에서 발생하는 모든 갱신 작업은 항상 그 이력이 로그를 통해 기록되어야 하며 이러한 기록은 반드시 순서가 보장되어야 한다. 만일 메모리 테이블과 디스크 테이블 간의 로깅 구조가 틀리거나 다른 어떠한 이유로 인하여 각각 독립적으로 로그 관리를 해야만 한다면 이 두 로그간의 순서는 보장되기가 매우 힘들다. 얼핏 모든 변경 이력을 변경된 순서에 따라서 연속된 ID를 부여함으로써 물리적으로 분리한다면 로그 병렬화를 통한 성능향상을 기대할 수 있을 것으로 생각할 수도 있겠지만, 로그의 내용에는 트랜잭션의 물리적인 갱신 이력뿐만 아니라 논리적인 형태와 상호 연계된 구조상의 정보 모두를 포함해야 하기 때문에 전체 시스템 수준에서의 순서적인 일관성이 보장되어야 하며 분리된 로그를 따로 관리하면서 이와 같은 내용을 모두 보장하는 것은 매우 어려운 일이다.
메모리 테이블과 디스크 테이블의 트랜잭션 관점에서 통합함으로써 보다 정확하고 안전한 동시성 제어 및 데이터 복구가 가능하다.

4. 상이한 저장구조에 대해 최적의 실행 계획이 가능한 통합된 질의 처리기
질의 처리기(Query Processor)는 요청 받은 SQL 구문을 분석하여 최적의 실행 계획을 세우고 생성된 실행 계획에 따라 데이터에 접근하여 요청된 작업을 수행하게 된다. 동일한 SQL 구문이라도 대상 테이블이 메모리 테이블인지 디스크 테이블인지에 따라서 서로 다른 방식으로 처리하는 것이 효율적일 수 있다. 예를 들면, 일정량을 초과하는 인덱스를 검색해야 하는 경우 디스크 테이블은 인덱스를 이용한 검색이 전체 테이블을 검색하는 것보다 디스크 I/O 횟수가 많아져 처리 비용이 증가하게 되므로 전체 테이블을 검색하는 것이 유리한 반면에 메모리 테이블은 모든 데이터가 메모리에 존재하기 때문에 I/O가 발생하지 않으므로 인덱스를 이용한 검색이 더 유리하다. 이와 같은 상황들을 질의처리기가 자동적으로 판단하여 SQL문을 해석하고 보다 효율적으로 데이터를 처리한다.

5. 하나의 SQL을 이용하여 디스크 테이블과 메모리 테이블을 동시에 접근 가능
메모리 테이블과 디스크 테이블이 트랜잭션 관점에서 완전히 통합되고 한 개의 질의 처리기를 이용하여 모두 처리가 가능하기 때문에 하나의 SQL로 메모리 테이블과 디스크 테이블의 접근이 가능하다. 기존에 고성능 대용량의 데이터 처리를 위해 두 개의 이질적인 DBMS를 사용하여 시스템을 구성하였을 경우 SQL문을 이용한 DBMS간 연결이 어렵기 때문에 애플리케이션의 복잡도가 증가하였었지만 단일 SQL로 모든 테이블에 접근하는 것이 가능하게 되어 애플리케이션의 복잡도를 크게 낮출 수 있다.

6. 저장공간의 위치에 상관없이 모든 테이블은 사용자에게 투명성을 보장
메모리 테이블과 디스크 테이블에 대해 사용자에게 투명성을 보장하지 않는다면 애플리케이션 개발 시 테이블의 종류(메모리 테이블과 디스크 테이블)에 따라 사용될 쿼리를 구분해서 사용해야 하며 개발 혹은 유지보수 도중에 DB의 형상 변경 요구가 발생하면(실제환경에서 이러한 일은 매우 비일비재하다) 애플리케이션을 다시 수정해야 하므로 이러한 환경에서의 개발작업은 매우 부담스러운 작업이 될 것이다. 테이블의 종류에 상관없이 투명한 접근을 보장함으로써 애플리케이션 개발자는 접근해야 하는 데이터의 위치가 메모리 테이블인지 디스크 테이블인지를 인지할 필요 없이 동일한 방식으로 SQL을 작성하는 것이 가능하며 이후 테이블의 저장위치가 변경되더라도 기존의 SQL을 변경 없이 그대로 사용할 수 있다. 사용자들 또한 테이블 종류를 인지할 필요 없이 테이블 이름만으로 해당 테이블에 접근할 수 있고 필요한 데이터를 이용할 수 있다.

하이브리드 MM DBMS의 구조
이제까지 하이브리드 MM DBMS의 특징을 살펴보았는데 <그림1>은 이러한 하이브리드 MM DBMS의 구조를 도식화한 것이다.

<그림 1> Hybrid MM DBMS ‘ALTIBASE 4’의 아키텍처

먼저 저장구조를 살펴보면 기존의 메모리 테이블 저장공간은 그대로 사용되며 디스크 테이블 스페이스와 이를 위한 버퍼가 추가된 형태이다. 메모리 테이블과 디스크 테이블은 저장공간 위에 위치한 통합 저장 관리자에 의해 멀티레벨(Multi-Level)의 저장구조로 진화되어 추상화되었으며 모든 데이터의 변경 이력은 동일한 로그 파일에 기록되어 관리됨으로써 트랜잭션 관점의 통합을 가능하게 하였다.
통합 질의 처리기는 SQL 구문을 분석하고 검증하며 저장 관리자가 가지고 있는 여러 가지 정보(테이블의 저장위치와 통계정보 등)를 이용하여 자동으로 최적의 실행계획을 수립하고 사용자의 요청을 처리함으로써 사용자에게 모든 테이블에 대한 투명성을 보장한다.

하이브리드 MM DBMS 적용 예제
하이브리드 MM DBMS를 이용하여 시스템을 구성할 때 구성 방법과 구성 효과를 간단한 예제를 가지고 좀 더 구체적으로 살펴보자.

A라는 은행에서 15일 동안의 거래 내역에 대한 조회 및 입력 작업이 빈번하게 일어나 시스템에 부하가 많이 발생하는 문제를 해결하기 위해 부분적으로 MMDBMS를 도입했다면 아래 <그림 2>와 같은 모습으로 시스템이 구성될 것이다.

<그림 2> 은행권 사례를 통해 살펴본 MM DBMS와 DR DBMS의 혼용 구성 예

거래내역을 보여주기 위해서는 계좌정보 테이블과 고객원장 테이블이 필요하기 때문에 MM DBMS에는 거래내역, 고객원장, 계좌정보 테이블로 구성된다. 과거 이력 조회 시에도 고객원장 테이블과 계좌정보 테이블이 필요하다면 DR DBMS에도 동일한 구성이 되어야 한다. 고객원장 테이블과 계좌정보 테이블은 양 DBMS간에 항상 일치해야 하므로 데이터의 변경이 생길 때마다 거의 실시간으로 동기화가 이루어져야 한다. 고객원장 테이블과 계좌정보 테이블의 실시간 동기화 방법으로는 애플리케이션 단에서의 분산 트랜잭션을 사용하거나 한쪽 DBMS 시스템에서의 변경 사항을 감지하여 다른 쪽 DBMS로 변경 내용을 반영하는 독립된 에이전트 역할의 애플리케이션을 작성하는 방법 등을 고려할 수 있다.

MM DBMS 상의 거래내역1 테이블에는 새로 발생되는 거래내역에 대한 정보가 기록되며 15일 동안에 거래내역 조회가 빈번하므로 생성된 데이터들은 15일 동안 이 테이블에 보관하면서 핫 데이터로 관리한다. 거래내역1 테이블에 데이터가 지속적으로 쌓이면 유한한 메모리 자원을 확보하기 위해 15일이 지난 데이터는 콜드 데이터로 분류하고 이렇게 분류된 콜드 데이터는 DR DBMS 상의 거래내역2 테이블로 이관시켜야 한다. 이러한 이관 작업은 작성된 독립된 에이전트에 의해 매일 자동으로 처리되도록 구성할 수도 있고 아니면 매일 배치작업을 수행하는 운영 프로세스를 만들어 운영할 수도 있다.

<그림 2>와 같이 MM DBMS와 DR DBMS를 혼용하여 시스템을 구성함으로써 15일 이내 거래내역 조회 업무의 성능을 향상시켜 시스템의 부하를 줄이고 대용량의 이력관리 업무도 가능했으나, 이를 위해서 계좌정보 테이블과 고객원장 테이블의 실시간 동기화 방법과 15일이 경과된 거래내역 이관 방법에 대하여 추가적인 고려 및 관리가 필요하게 되었다. 또한 장애 발생 시 양 DBMS의 데이터 일치에 대한 정합성 보장 및 검사방법, 정합성이 깨어졌을 때 보정 방법 등에 대해서도 고려하여야 하며 만일 15일이 넘는 데이터에 대해 조회가 필요한 경우(예를 들면, 최근 한달 간 거래내역 조회 등)가 있다면 애플리케이션에서는 거래내역1 테이블과 거래내역2 테이블간의 조인(Join)연산이 불가능 하기 때문에 양쪽 테이블의 내용들을 합치는(Merge) 작업을 수행하여 처리해야 하는 불편함이 생긴다.

이러한 시스템 구성의 단점을 감안하더라도 문제가 되는 업무의 부하를 줄이고 고성능의 서비스를 실현하여 기업이 고객의 만족도를 높이게 된다면 이것만으로도 훌륭한 성과를 이룬 것이 분명하나 만일 마땅히 감수해야 하는 단점 없이도 동일한 효과를 얻을 수 있다고 한다면 이것은 정말 매력적인 이야기가 아닐 수 없다.

위에서 살펴본 예를 하이브리드 MM DBMS로 대체한다면 <그림 3>와 같은 구성이 된다.

<그림 3> 은행권 사례를 통해 살펴본 하이브리드 MM DBMS 구성 예

모든 테이블이 단일 DBMS로 관리되기 때문에 데이터 이관이나 동기화에 대한 고려를 할 필요가 없으며 메모리 테이블과 디스크 테이블에 대한 일관적인 관리로 인해 장애 발생 시에도 데이터의 정합성에 대한 걱정을 할 필요가 없다. 15일이 경과된 콜드 데이터에 대한 데이터 이관도 별도의 프로그램을 작성하거나 데이터 추출(Export) 및 입력(Import) 작업을 이용할 필요 없이 하나의 SQL로 수행이 가능하다. 실제로 ‘ALTIBASE4’ 에서는 테이블 간 레코드 이동을 위해 “MOVE” 구문을 지원한다.
최근 15일 이내 거래내역 조회는 메모리 테이블을 이용하기 때문에 빠르게 처리가 가능하며 15일이 지난 이력 데이터들은 디스크 테이블에 저장함으로써 대용량 처리 또한 가능하다. 또한 최근 한달 거래내역 조회와 같이 메모리 테이블과 디스크 테이블을 동시에 조회해야 하는 업무도 이제는 하나의 SQL로 처리가 가능하다.
이전에 중복되게 저장되었던 고객원장 테이블과 계좌정보 테이블도 중복되지 않고 하나의 테이블로 관리가 가능하기 때문에 실시간 데이터 동기화에 대한 고민도 사라지고 시스템의 자원낭비도 줄일 수 있다. 만일 시스템 운영 중 두 테이블이 성능상으로 중요한 테이블이 된다면 디스크 테이블을 간단히 메모리 테이블로 옮겨주기만 하면 된다.

하이브리드 MM DBMS의 나아갈 방향
이제까지 살펴 본 바와 같이 하이브리드 MM DBMS의 등장으로 보다 다양해지는 시장의 요구에 보다 유연하게 대처할 수 있게 되었다. 그러나 하이브리드 MM DBMS는 이제 막 걸음마를 떼기 시작한 단계이기 때문에, 특정 시장을 뛰어넘어 보다 넓은 시장으로 진입하기 위해서는 해결해야 할 많은 과제들이 있다.

1. 데이터 및 테이블 관리 측면
테이블 파티션 기능이나 테이블 클러스터 개념 등 디스크 테이블 관리 측면에서 보다 다양한 기능의 보강이 필요하며 분산 데이터베이스 기술과 그리드(Grid) 컴퓨팅 기술 등 계속 발전하고 있는 여러 가지 새로운 개념과 기술들을 접목시켜 나가야 한다.

2. 사용자의 편의성
사용자 편의성 측면에서 직관적으로 DBMS의 상태를 점검하고 관리할 수 있는 GUI 사용자 도구들을 지속적으로 추가하고 확장하여 운영자가 보다 손쉽게 DBMS를 관리할 수 있어야 한다. 따라서 개발도구나 관리도구 등 DBMS와 관련된 여러 가지 유용한 제품들을 개발하는 써드파티(Third Party) 업체들과의 꾸준한 협력을 통해 사용자 편의성을 증대시킴으로써 사용 기반을 넓혀야 한다.

3. 다양한 제품들과의 호환성
실제로 시스템을 구성하게 되면 DBMS 이외에도 여러 가지 제품들과 연동이 필요하다. 웹 기반의 서비스를 위한 시스템에서의 웹 애플리케이션 서버(Web Application Server) 라던지 OLTP성 업무를 수행하는 시스템에서의 TP모니터 등 다양한 서비스 환경에 대응하기 위해 현재도 수많은 새로운 미들웨어(middleware)가 시장에 나오고 있다. DBMS는 필수 소프트웨어 이기 때문에 이러한 다양한 미들웨어와의 원활한 연동이 가능해야 하며, 이를 위해서는 해당 제품을 개발하는 업체들과의 지속적인 기술교류와 협력이 이루어져야 한다. 또한 기업의 입장에서 기존의 레거시(Legacy) 시스템들과의 연동 문제 또한 간과할 수 없기 때문에 이기종 DBMS 제품들과의 원활한 데이터 교환 방법의 연구 및 개발도 앞으로 꾸준히 진행되어야 한다.

4. 비정형 데이터 처리
이전에는 DBMS가 주로 기업의 정형화된 비즈니스 정보를 관리하는 용도로 사용되면서 문자, 숫자 등 기본적인 타입만으로도 충분히 관리가 가능하였으나 하드웨어나 소프트웨어 기술의 지속적인 발달과 인터넷의 발전으로 인해 이제는 기본적인 데이터 타입뿐 아니라 보다 복잡한 데이터를 관리해야 하는 요구사항이 생기게 되었다. 이제 DBMS는 이미지, 오디오, 비디오와 같은 멀티미디어 정보와 점, 직선, 곡선, 평면 등 공간 데이터까지도 관리할 수 있어야 한다. 최근에는 XML(Extensible Markup Language)이 각광을 받으면서 많은 기업들이 XML과 관련된 솔루션 개발에 참여하고 있고 데이터베이스 분야에서도 XML 데이터 처리가 중요한 화두로 떠올라 많은 연구가 이루어지고 있으며 XML 데이터 처리를 위한 새로운 기능들이 개발되고 있다. 이렇듯 앞으로 다양한 분야에 적용되어지기 위해서는 비정형 데이터를 처리할 수 있는 기능의 개발도 필요하다.

이제까지 살펴 본 하이브리드 MM DBMS인 ‘ALTIBASE4’는 고성능의 MM DBMS에서 출발하여 대용량 데이터 처리를 위해 DR DBMS의 구조와 개념을 흡수함으로써 새로운 개념의 DBMS로 재탄생 하였으나 이제 막 시장에 진출한 초기 제품이므로 아직은 그 기능이 미약한 것이 사실이다. 30년 이상 데이터베이스 시장을 지배해오면서 다양한 적용 사례와 연구를 통해 축적되고 계선되어 온 기존의 DR DBMS의 풍부한 기능과 편의성을 한 순간에 따라갈 수는 없을 것이다. 그러나 다양한 업무에 적용되어 그 가능성을 입증하고 있으며, 꾸준한 연구 개발을 통해 그 격차는 빠르게 좁혀 가고 있다.

결론
인터넷 환경의 발달로 인해 네트워킹 기술은 더 이상 소수만이 사용하는 어려운 기술이 아니다. 오늘날의 기업들은 전세계의 사용자들을 대상으로 수많은 사람들이 밤낮 구분 없이 쏟아내는 방대한 양의 자료들을 처리해야 하고 다양한 형태의 데이터를 효율적으로 통합하고 관리할 수 있어야 하며 언제든지 빠른 응답을 보장해야 한다. 하이브리드 MM DBMS는 고성능, 대용량 처리가 가능하므로 이러한 기업들의 요구조건을 충족시킬 수 있는 가장 적합한 형태의 DBMS임에 틀림없다. 따라서 앞으로 주어진 과제를 잘 해결하고 꾸준히 발전시켜 나간다면 하이브리드 MM DBMS가 DBMS의 주류로 자리매김하는 데 그리 오랜 시간이 걸리지는 않을 것이다. 점점 다양해지는 고객의 요구를 만족시켜야만 살아남을 수 있는 시대의 흐름 속에서 끊임없이 고민하고 노력하는 전 세계의 수많은 기업들에게 하이브리드 MM DBMS가 오아시스와 같은 해결책이 되는 날이 오기를 기대해 본다.

* 이 글은IT 전문 월간지 <온더넷> http://www.ionthenet.co.kr에도 게재된 내용입니다.