연재/하이브리드 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의 구조를 도식화한 것이다.