제품 여행

기획연재[3] CUBRID 제품 분석 – CUBRID제품 구조

by cubebridge posted Dec 30, 2009

CUBRID 기획 연재 시리즈로 지난 시간 CUBRID기반의 지원 툴에 대해서 알아보았다. 지난 시간에 예로 들었던 모든 툴들의 사용법은 홈페이지 개발자->튜토리얼에 있으니 참조하고 부족한 부분이나 이해되지 않는 부분에 대해서는 덧글로 문의 바란다. CUBRID를 처음 접하는 사람들이 가장 궁금해 할 것이 무엇인가 고민하다가 이번 시간에는 CUBRID제품 구조에 대해서 간략하게 다뤄보려고 한다. 


CUBRID와 타 DBMS의 가장 두드러진 차이점이 무엇일까? 

여러가지가 있겠으나 하나 꼽는다면 DB와 AP가 연결되는 구조라고 할 수 있겠다. 어떤 구조를 이야기 하는 것인가?

2-Tier, 3-Tier에 대한 이야기다. 각각에 대해서 간략하게 설명하는 아래와 같다.(S/W관점에서 이야기 하겠다.)


1) 2-Tier :  Client Side에 프리젠테이션/비지니스 로직을 작성하고, Server Side에는 데이터베이스가 위치하는 구조이다. 많이 알고 있는 대부분의 DBMS는 2-Tier구조로 되어 있다.

2) 3-Tier : Client Side에 프리젠테이션 로직을 작성하고, Server Side에 비지니스 로직과 데이터베이스가 위치하는 구조이다. 인터넷 서비스를 예로 들면 Application Server와 Database Server라고 볼 수 있으며, CUBRID가 3-Tier구조의 DBMS이다.


과거의 서비스 환경에 비교하여 최근 인터넷 서비스 환경에서 3-Tier구조는 2-Tier구조보다 많은 장점을 가지고 있다.

확장성, 재사용성, 시스템 관리측면 등 여러가지가 있겠으나 다수의 접속자에 의해 운영되는 인터넷 서비스 환경에서는 부하에 따른 성능과 자원활용 측면이 가장 클 것으로 생각된다.


현재 많은 DBMS가 WAS를 이용한 3-Tier구조를 지원하고 있으나, CUBRID의 경우는 태생적으로 3-Tier구조라 할 수 있겠다. 

CUBRID를 살짝 분리해 보면 아래와 같이 나눌 수 있다.

CUBRID DB Server ------ CUBRID Broker ------- AP interface(JDBC, ODBC, etc.)


CUBRID를 사용해보지 않은 사용자는 CUBRID Broker부분에 대해 의문을 가질 수 있을 것이다. 

Broker는 CUBRID제품의 일부분으로 AP에서 들어오는 요청을 받아 DB로 전달해 주는 미들웨어이다. 

아래는 CUBRID제품의 구조이다.

각각의 부분(Application Client, Cub_Broker, Database Server)은 각각의 서버에 존재할 수 있다.

CUBRID와 Broker, AP(프로그램)이 별도로 존재하여 부하 분산이 가능하고 각각의 자원 활용에 맞춰 서버를 배분할 수 있을 것이다.

위 구조에나 나타나는 각 항목(cub_cas, cub_broker 등)은 메뉴얼을 참조하기 바란다.


위와 같은 구조하에 사용자는 CUBRID와 직접 접속을 시도할 필요가 없다. DB의 port를 찾을 필요가 없는 것이다. Broker의 port와 통신을 하게 되고, Broker의 개수와 자원 등을 조정할 수 있다.


간략하게 CUBRID제품의 구조에 대해서 이야기를 해보았다. 다음은 CSQL에 대해서 살펴볼까 한다. CSQL에 숨겨진 알토란 같은 기능에 대해 살펴보는 시간을 가져보도록 하자.