위키원
"큐브리드"의 두 판 사이의 차이
(→구조) |
|||
| 12번째 줄: | 12번째 줄: | ||
큐브리드의 시스템은 프로세스, 데이터베이스 볼륨, 데이터베이스 서버, 브로커, 인터페이스 모듈 구조로 이루어져 있다. | 큐브리드의 시스템은 프로세스, 데이터베이스 볼륨, 데이터베이스 서버, 브로커, 인터페이스 모듈 구조로 이루어져 있다. | ||
; 프로세스 | ; 프로세스 | ||
| − | 큐브리드는 객체 관계형 데이터베이스 관리 시스템으로서, 데이터베이스 서버, 브로커, 큐브리드 | + | 큐브리드는 객체 관계형 데이터베이스 관리 시스템으로서, 데이터베이스 서버, 브로커, 큐브리드 매니저로 구성된다. 데이터베이스 서버는 큐브리드 데이터베이스 관리 시스템의 핵심 구성 요소로 데이터 저장 및 관리 기능을 수행하며, 멀티스레드 기반 [[클라이언트]]/서버 방식으로 동작한다. 또, 사용자가 입력한 질의를 처리하고, 데이터베이스 내의 객체를 관리한다. 잠금 기법과 로깅 기법을 이용해 다수 사용자가 동시에 사용하는 환경에서도 완벽한 트랜잭션을 지원하며, 운영에 필요한 데이터베이스 백업과 복구 기능을 지원한다. 브로커는 서버와 외부 응용 프로그램 간의 통신을 중계하는 큐브리드 전용 [[미들웨어]]로서, 커넥션 풀링, 모니터링, 로그 추적 및 분석 기능을 제공한다. 큐브리드 매니저는 데이터베이스와 브로커를 원격에서 관리할 수 있는 그래픽 유저 인터페이스 툴이다. 또한, 사용자가 데이터베이스 서버에 [[에스큐엘]] 질의를 수행할 수 있는 편리한 기능의 질의 편집기를 제공한다. |
; 데이터베이스 볼륨 | ; 데이터베이스 볼륨 | ||
데이터베이스 볼륨의 구조는 크게 '''영구적 볼륨''', '''일시적 볼륨''', '''백업 볼륨'''으로 분류한다. | 데이터베이스 볼륨의 구조는 크게 '''영구적 볼륨''', '''일시적 볼륨''', '''백업 볼륨'''으로 분류한다. | ||
| − | '''영구적 볼륨'''은 한번 생성되면 영구적으로 존재하는 데이터베이스 볼륨으로서, 볼륨 타입으로는 범용(Generic), 데이터(Data), 임시(Temp), 인덱스(Index), 제어(Control), 활성 로그(Active log), 보관 로그(Archive log)가 있다.<br>먼저 범용 볼륨에서 사용자는 데이터베이스에 추가할 볼륨 타입을 데이터, 임시, 인덱스 중 하나의 용도로 지정하여 효율적으로 관리할 수 있다. 별도로 볼륨 타입을 지정하지 않는 경우에는 범용 볼륨으로 지정되며, 범용 볼륨은 데이터 혹은 인덱스를 저장한다. 단, [[스키마]]는 범용 볼륨에만 저장되며, | + | '''영구적 볼륨'''은 한번 생성되면 영구적으로 존재하는 데이터베이스 볼륨으로서, 볼륨 타입으로는 범용(Generic), 데이터(Data), 임시(Temp), 인덱스(Index), 제어(Control), 활성 로그(Active log), 보관 로그(Archive log)가 있다.<br>먼저 범용 볼륨에서 사용자는 데이터베이스에 추가할 볼륨 타입을 데이터, 임시, 인덱스 중 하나의 용도로 지정하여 효율적으로 관리할 수 있다. 별도로 볼륨 타입을 지정하지 않는 경우에는 범용 볼륨으로 지정되며, 범용 볼륨은 데이터 혹은 인덱스를 저장한다. 단, [[스키마]]는 범용 볼륨에만 저장되며, 스키마 저장을 위한 별도의 볼륨 타입은 존재하지 않는다. 또, 볼륨이 자동으로 증가하는 경우에도 범용 볼륨으로 지정된다.<br>데이터 볼륨은 인스턴스, 테이블, [[멀티미디어]] 데이터 등과 같은 데이터를 저장하기 위한 공간이다.<br>임시 볼륨은 질의 처리 및 정렬을 수행할 때 중간, 최종 결과를 임시로 저장하는 공간으로, 아래에서 설명할 일시적 임시 볼륨과 구분하기 위해 영구적 임시 볼륨이라고도 한다. 임시 볼륨은 영구적으로 확보한 공간으로, 해당 공간에 존재하는 데이터가 임시로 저장 및 소멸하는 것을 의미한다. 따라서 큐브리드를 재시작하면 임시 볼륨 공간 내의 데이터는 초기화되고, 이에 관련된 로그 정보는 남지 않는다. 영구적 또는 일시적 임시 볼륨을 사용할 수 있는 질의의 예로, SELECT 문 등 질의 결과가 생성되는 질의, GROUP BY나 ORDER BY가 포함된 질의, 부질의(Subquery)가 포함된 질의, 정렬 병합(Sort-Merge) 조인이 수행되는 질의, CREATE INDEX 문이 포함된 질의 등이 있다. 이와 같은 질의를 수행할 때 SELECT 결과를 저장하거나 데이터를 정렬하기 위해 지정한 [[메모리]] 공간을 소진하면 임시 볼륨 공간을 사용한다. 질의 처리 및 정렬 결과를 저장하기 위해 사용하는 저장 공간의 순서는 temp_file_memory_size_in_pages 시스템 피라미터에 의해 확보된 메모리, 영구적 임시 볼륨, 일시적 임시 볼륨이며, 사용 중인 저장 공간을 모두 소진하면 이 순서대로 저장 공간을 사용한다.<br>인덱스 볼륨은 신속한 질의 처리 또는 무결성 제약 조건(Integrity Constraints) 검증을 위한 인덱스 정보를 유지하는 공간이다.<br>제어 파일은 데이터베이스 안에 존재하는 볼륨의 정보, 백업 정보 및 로그의 정보를 저장하는 파일이다. 이때, 볼륨 정보는 데이터베이스 내 모든 볼륨의 이름과 위치, 그리고 내부 볼륨 식별자를 포함하는 정보로서, 데이터베이스가 재시작될 때 큐브리드는 볼륨 정보 제어 파일을 판독하며, 새로운 데이터베이스 볼륨이 추가될 때에 새로운 엔트리를 볼륨 정보 제어 파일에 기록한다. 백업 정보는 정보 볼륨에 대한 모든 백업의 위치는 백업 정보 제어 파일에 기록되고, 이 제어 파일은 로그 파일이 관리되는 곳에 유지된다. 로그 정보는 모든 활성 로그와 보관 로그의 이름을 포함하며, 사용자는 로그 정보 제어 파일을 통해 보관 로그의 정보를 확인할 수 있다. 이러한 로그 정보 제어 파일은 로그 파일과 동일한 위치에서 생성 및 관리된다. 이처럼 각각의 제어 파일은 데이터베이스 볼륨의 위치, 백업 정보, 로그 정보를 포함하며, 데이터베이스가 재시작하면서 읽는 파일이므로 사용자 임의로 변경하면 안 된다.<br>활성 로그는 데이터베이스의 최근 변경 사항을 포함하는 로그이며, 데이터베이스에 문제가 발생하는 경우 활성 로그 및 보관 로그를 이용하여 고장 발생 전의 커밋된 시점으로 완전하게 데이터베이스를 복구할 수 있다.<br>보관 로그는 최근의 변경 사항을 포함하고 있는 활성 로그 공간이 모두 사용된 후에 지속해서 생성되는 로그를 보관하기 위한 볼륨이다. 시스템 파라미터 log_max_archives의 값이 0보다 크게 설정된 경우 활성 로그 볼륨의 공간이 소진된 후에 보관 로그 볼륨이 추가된다. 제품 설치 시에는 0으로 설치되어 있고 log_max_archives의 설정값만큼 볼륨 파일이 유지된다. 디스크 공간 확보를 위해 불필요한 보관 로그는 시스템의 설정에 의해 삭제되어야 하지만, 데이터베이스 복구에 사용하려면 이 값을 적절하게 설정해야 한다.<br>마지막으로 백그라운드 보관 로그는 백그라운드에서 로그 보관 작업을 수행할 때 사용하는 볼륨이다. |
| − | '''일시적 볼륨'''은 영구적 볼륨과 반대되는 의미이다. 즉, 사용자가 영구적 볼륨으로 지정한 공간을 초과하여 데이터가 축적되는 경우에만 일시적으로 마련되는 저장 공간을 일시적 볼륨이라 하며, 이는 서버 프로세스가 종료됨에 따라 | + | '''일시적 볼륨'''은 영구적 볼륨과 반대되는 의미이다. 즉, 사용자가 영구적 볼륨으로 지정한 공간을 초과하여 데이터가 축적되는 경우에만 일시적으로 마련되는 저장 공간을 일시적 볼륨이라 하며, 이는 서버 프로세스가 종료됨에 따라 소멸한다. 이처럼 일시적으로 생성 및 소멸하는 볼륨으로 일시적 임시 볼륨(Temporary Temp Volume)이 있다. 영구적 볼륨에 속하는 임시 볼륨은 영구적으로 공간을 확보하는 볼륨인 데 비해, 일시적 임시 볼륨은 영구적 임시 볼륨으로 지정된 공간 외에 추가 공간이 필요한 경우 시스템이 일시적으로 생성하는 임시 볼륨이다. 일시적 임시 볼륨을 생성하는 비용은 상당히 크기 때문에 데이터베이스 관리자는 데이터베이스 운영 상황을 고려하여 적절한 크기의 영구적 임시 볼륨을 추가하는 것이 성능상 유리하다. 데이터베이스 생성 시에 관리자는 일시적 임시 볼륨이 생성될 수 있는 공간도 고려해야 한다. 일시적 임시 볼륨은 한 번 생성되면 데이터베이스를 재시작하기 전까지 유지되며, 한 번 늘어난 크기는 줄어들지 않는다. 일시적 임시 볼륨의 크기가 지나치게 커지면, 데이터베이스를 재시작하여 일시적 임시볼륨이 자동으로 삭제되도록 하는 것이 좋다. 단, 일시적 임시 볼륨을 수동으로 삭제해서는 안 된다. 큐브리드의 일시적 임시 볼륨의 파일명은 db_name_tnum 형식의 이름을 갖는다. 여기서 db_name은 데이터베이스 이름이고, num은 볼륨 식별자이다. 볼륨 식별자는 32766에서부터 1씩 감소한다. 일시적 임시 볼륨이 생성되는 개수는 트랜잭션 처리에 필요한 공간의 크기에 따라 시스템이 결정한다. 그러나, 일시적 임시 볼륨의 크기는 사용자가 시스템 파라미터 설정 파일(cubrid.conf)의 temp_file_max_size_in_pages 파라미터의 값을 설정함으로써 제한할 수 있다. 이 파라미터의 기본값은 -1로, 여유 공간이 있는 한 최대한 생성할 수 있다. 0으로 설정되면 영구적 임시 볼륨이 소진되어도 일시적 임시 볼륨을 생성하지 않는다. 저장 위치 설정으로는 기본적으로 첫 번째 데이터베이스 볼륨이 생성된 위치에 만들어진다. 그러나, 사용자가 temp_volume_path 파라미터값을 설정하여 일시적 임시 볼륨이 저장될 다른 디렉터리를 지정할 수 있다. 마지막으로 일시적 임시 볼륨은 데이터베이스가 구동 중일 때만 일시적으로 존재하며, 서버가 운영 중일 때 일시적 임시 볼륨을 임의로 삭제하면 안 된다. 데이터베이스 서버가 정상적으로 종료되면 일시적 임시 볼륨이 삭제되고, 데이터베이스 서버가 비정상적으로 종료되면 서버가 재시작할 때 일시적 임시 볼륨이 삭제된다. |
'''백업 볼륨'''은 데이터베이스에 대한 스냅샷으로서, 이러한 백업 볼륨과 로그 볼륨을 기반으로 특정 시점까지 발생한 트랜잭션을 복구할 수 있다. 사용자는 큐브리드 백업 데이터베이스 유틸리티를 통해 데이터베이스 복구를 위해 필요한 모든 데이터를 복사할 수 있으며, 데이터베이스 환경 설정 파일의 backup_volume_max_size_bytes 파라미터값을 설정하여 백업 볼륨의 분할 크기를 조정할 수 있다. | '''백업 볼륨'''은 데이터베이스에 대한 스냅샷으로서, 이러한 백업 볼륨과 로그 볼륨을 기반으로 특정 시점까지 발생한 트랜잭션을 복구할 수 있다. 사용자는 큐브리드 백업 데이터베이스 유틸리티를 통해 데이터베이스 복구를 위해 필요한 모든 데이터를 복사할 수 있으며, 데이터베이스 환경 설정 파일의 backup_volume_max_size_bytes 파라미터값을 설정하여 백업 볼륨의 분할 크기를 조정할 수 있다. | ||
| 33번째 줄: | 33번째 줄: | ||
; 브로커 | ; 브로커 | ||
| + | 브로커는 다양한 응용 클라이언트가 데이터베이스 서버에 연결할 수 있도록 중계하는 미들웨어이다. 브로커를 포함하는 큐브리드 시스템은 '''응용 클라이언트''', '''cub_broker''', '''cub_cas''', 데이터베이스 서버(cub_server)를 포함한 다중 계층 구조를 가진다. | ||
| + | |||
| + | '''응용 클라이언트'''에서 사용할 수 있는 인터페이스는 C-[[API]](CUBRID Call Inter face-API), ODBC, JDBC, [[PHP]], [[파이썬]], [[루비]], OLEDB, ADO.NET, Node.js 등이 있다. | ||
| + | <br>'''cub_cas'''는 연결을 요청하는 모든 종류의 응용 클라이언트가 사용하는 공용 응용 서버 역할을 한다. 또한, 데이터베이스 서버의 클라이언트로 동작하여 클라이언트의 요청으로 데이터베이스 서버와 연결을 제공한다. 서비스 풀(service pool) 내에서 구동되는 cub_cas의 개수는 cubrid_broker.conf 설정 파일에 지정할 수 있으며, cub_broker에 의해 동적으로 조정된다. cub_cas는 큐브리드 데이터베이스 서버의 클라이언트 라이브러리와 링크되는 프로그램으로 데이터베이스 서버 프로세스에는 클라이언트 모듈로 동작하며, 쿼리 파싱이나 최적화, 실행 계획 생성 등의 작업이 클라이언트 모듈에서 수행된다. | ||
| + | <br>'''cub_broker'''는 응용 클라이언트와 cub_cas 사이의 연결을 중계하는 기능을 수행한다. 즉, 응용 클라이언트가 접근을 요청하면 cub_broker는 공유 메모리(shared memory)를 통해 cub_cas의 상태를 파악하여 접근 가능한 cub_cas에게 요청을 전달하고, 해당 cub_cas로부터 전달받은 요청에 대한 처리 결과를 응용 클라이언트에게 반환한다. 또한, cub_broker는 서비스 풀 내의 cub_cas 개수를 조정하여 서버 부하를 관리하고, cub_cas의 구동 상태를 모니터링 및 관리한다. 만약, 응용 클라이언트의 요청을 cub_cas 1에게 전달하였는데, 비정상적인 종료로 인해 cub_cas 1과의 연결이 실패하면, cub_broker는 응용 클라이언트에게 연결 실패에 관한 에러 메시지를 전송하고 cub_cas 1을 재구동한다. 새롭게 구동된 cub_cas 1은 정상적인 대기 상태가 되어, 새로운 응용 클라이언트의 요청으로 재연결된다. | ||
| + | <br>'''공유 메모리'''에는 cub_cas의 상태 정보가 저장되며, cub_broker는 공유 메모리에 저장된 cub_cas의 상태 정보를 참조하여 응용 클라이언트와의 연결을 중계한다. 공유 메모리에 저장된 cub_cas의 상태 정보를 통해 시스템 관리자는 어떤 cub_cas가 현재 작업을 수행 중인지, 어떤 응용 클라이언트의 요청이 처리 중인지를 확인할 수 있다. | ||
== 같이 보기 == | == 같이 보기 == | ||
2020년 8월 13일 (목) 16:31 판
큐브리드(Cubrid)는 오픈소스 기반의 관계형 데이터베이스 관리 시스템(RDBMS)이다. 2006년 2월에 설립된 ㈜큐브리드가 개발하였고, 2008년 네이버㈜의 계열사로 편입되었다. 이후 기술 개발은 네이버㈜가 담당하고 있으며, 기술 지원은 2010년 12월 네이버에서 분리 독립한 별도 회사인 ㈜큐브리드가 맡고 있다. 큐브리드는 2011년 11월 대한민국 정부 통합전산센터의 클라우드 구축 공식 데이터베이스 관리 시스템(DBMS)으로 선정되었다. 2014년 국방통합데이터센터의 표준 데이터베이스 관리 시스템(DBMS)으로 선정되었다.
개요
큐브리드는 관계형 데이터베이스 관리 시스템(RDBMS)으로서 엔터프라이즈 시장에서 요구하는 대용량 데이터 처리 능력 및 성능, 안정성, 가용성, 관리 편의성을 제공한다. 안시 에스큐엘(Ansi SQL)을 준수하고 있으며, 고가용성을 위한 HA(High-Availability) 기능, 데이터베이스 관리 및 마이그레이션을 위한 그래픽 유저 인터페이스(GUI) 기반의 각종 도구를 제공하고 있다. 큐브리드는 3-tier 구조를 이루는 응용(Application) - 브로커(Broker) - 서버(Server)로 구성되며, 유연하게 시스템을 구축할 수 있어 데이터가 급증하는 온라인 트랜잭션 처리(OLTP: On-line Transaction Processing) 서비스에 적합하다. 또, 인터넷 데이터 서비스에 최적화된 데이터베이스 시스템이며, 사용자가 편리하게 사용할 수 있는 다양한 기능을 제공한다.
특징
구조
큐브리드의 시스템은 프로세스, 데이터베이스 볼륨, 데이터베이스 서버, 브로커, 인터페이스 모듈 구조로 이루어져 있다.
- 프로세스
큐브리드는 객체 관계형 데이터베이스 관리 시스템으로서, 데이터베이스 서버, 브로커, 큐브리드 매니저로 구성된다. 데이터베이스 서버는 큐브리드 데이터베이스 관리 시스템의 핵심 구성 요소로 데이터 저장 및 관리 기능을 수행하며, 멀티스레드 기반 클라이언트/서버 방식으로 동작한다. 또, 사용자가 입력한 질의를 처리하고, 데이터베이스 내의 객체를 관리한다. 잠금 기법과 로깅 기법을 이용해 다수 사용자가 동시에 사용하는 환경에서도 완벽한 트랜잭션을 지원하며, 운영에 필요한 데이터베이스 백업과 복구 기능을 지원한다. 브로커는 서버와 외부 응용 프로그램 간의 통신을 중계하는 큐브리드 전용 미들웨어로서, 커넥션 풀링, 모니터링, 로그 추적 및 분석 기능을 제공한다. 큐브리드 매니저는 데이터베이스와 브로커를 원격에서 관리할 수 있는 그래픽 유저 인터페이스 툴이다. 또한, 사용자가 데이터베이스 서버에 에스큐엘 질의를 수행할 수 있는 편리한 기능의 질의 편집기를 제공한다.
- 데이터베이스 볼륨
데이터베이스 볼륨의 구조는 크게 영구적 볼륨, 일시적 볼륨, 백업 볼륨으로 분류한다.
영구적 볼륨은 한번 생성되면 영구적으로 존재하는 데이터베이스 볼륨으로서, 볼륨 타입으로는 범용(Generic), 데이터(Data), 임시(Temp), 인덱스(Index), 제어(Control), 활성 로그(Active log), 보관 로그(Archive log)가 있다.
먼저 범용 볼륨에서 사용자는 데이터베이스에 추가할 볼륨 타입을 데이터, 임시, 인덱스 중 하나의 용도로 지정하여 효율적으로 관리할 수 있다. 별도로 볼륨 타입을 지정하지 않는 경우에는 범용 볼륨으로 지정되며, 범용 볼륨은 데이터 혹은 인덱스를 저장한다. 단, 스키마는 범용 볼륨에만 저장되며, 스키마 저장을 위한 별도의 볼륨 타입은 존재하지 않는다. 또, 볼륨이 자동으로 증가하는 경우에도 범용 볼륨으로 지정된다.
데이터 볼륨은 인스턴스, 테이블, 멀티미디어 데이터 등과 같은 데이터를 저장하기 위한 공간이다.
임시 볼륨은 질의 처리 및 정렬을 수행할 때 중간, 최종 결과를 임시로 저장하는 공간으로, 아래에서 설명할 일시적 임시 볼륨과 구분하기 위해 영구적 임시 볼륨이라고도 한다. 임시 볼륨은 영구적으로 확보한 공간으로, 해당 공간에 존재하는 데이터가 임시로 저장 및 소멸하는 것을 의미한다. 따라서 큐브리드를 재시작하면 임시 볼륨 공간 내의 데이터는 초기화되고, 이에 관련된 로그 정보는 남지 않는다. 영구적 또는 일시적 임시 볼륨을 사용할 수 있는 질의의 예로, SELECT 문 등 질의 결과가 생성되는 질의, GROUP BY나 ORDER BY가 포함된 질의, 부질의(Subquery)가 포함된 질의, 정렬 병합(Sort-Merge) 조인이 수행되는 질의, CREATE INDEX 문이 포함된 질의 등이 있다. 이와 같은 질의를 수행할 때 SELECT 결과를 저장하거나 데이터를 정렬하기 위해 지정한 메모리 공간을 소진하면 임시 볼륨 공간을 사용한다. 질의 처리 및 정렬 결과를 저장하기 위해 사용하는 저장 공간의 순서는 temp_file_memory_size_in_pages 시스템 피라미터에 의해 확보된 메모리, 영구적 임시 볼륨, 일시적 임시 볼륨이며, 사용 중인 저장 공간을 모두 소진하면 이 순서대로 저장 공간을 사용한다.
인덱스 볼륨은 신속한 질의 처리 또는 무결성 제약 조건(Integrity Constraints) 검증을 위한 인덱스 정보를 유지하는 공간이다.
제어 파일은 데이터베이스 안에 존재하는 볼륨의 정보, 백업 정보 및 로그의 정보를 저장하는 파일이다. 이때, 볼륨 정보는 데이터베이스 내 모든 볼륨의 이름과 위치, 그리고 내부 볼륨 식별자를 포함하는 정보로서, 데이터베이스가 재시작될 때 큐브리드는 볼륨 정보 제어 파일을 판독하며, 새로운 데이터베이스 볼륨이 추가될 때에 새로운 엔트리를 볼륨 정보 제어 파일에 기록한다. 백업 정보는 정보 볼륨에 대한 모든 백업의 위치는 백업 정보 제어 파일에 기록되고, 이 제어 파일은 로그 파일이 관리되는 곳에 유지된다. 로그 정보는 모든 활성 로그와 보관 로그의 이름을 포함하며, 사용자는 로그 정보 제어 파일을 통해 보관 로그의 정보를 확인할 수 있다. 이러한 로그 정보 제어 파일은 로그 파일과 동일한 위치에서 생성 및 관리된다. 이처럼 각각의 제어 파일은 데이터베이스 볼륨의 위치, 백업 정보, 로그 정보를 포함하며, 데이터베이스가 재시작하면서 읽는 파일이므로 사용자 임의로 변경하면 안 된다.
활성 로그는 데이터베이스의 최근 변경 사항을 포함하는 로그이며, 데이터베이스에 문제가 발생하는 경우 활성 로그 및 보관 로그를 이용하여 고장 발생 전의 커밋된 시점으로 완전하게 데이터베이스를 복구할 수 있다.
보관 로그는 최근의 변경 사항을 포함하고 있는 활성 로그 공간이 모두 사용된 후에 지속해서 생성되는 로그를 보관하기 위한 볼륨이다. 시스템 파라미터 log_max_archives의 값이 0보다 크게 설정된 경우 활성 로그 볼륨의 공간이 소진된 후에 보관 로그 볼륨이 추가된다. 제품 설치 시에는 0으로 설치되어 있고 log_max_archives의 설정값만큼 볼륨 파일이 유지된다. 디스크 공간 확보를 위해 불필요한 보관 로그는 시스템의 설정에 의해 삭제되어야 하지만, 데이터베이스 복구에 사용하려면 이 값을 적절하게 설정해야 한다.
마지막으로 백그라운드 보관 로그는 백그라운드에서 로그 보관 작업을 수행할 때 사용하는 볼륨이다.
일시적 볼륨은 영구적 볼륨과 반대되는 의미이다. 즉, 사용자가 영구적 볼륨으로 지정한 공간을 초과하여 데이터가 축적되는 경우에만 일시적으로 마련되는 저장 공간을 일시적 볼륨이라 하며, 이는 서버 프로세스가 종료됨에 따라 소멸한다. 이처럼 일시적으로 생성 및 소멸하는 볼륨으로 일시적 임시 볼륨(Temporary Temp Volume)이 있다. 영구적 볼륨에 속하는 임시 볼륨은 영구적으로 공간을 확보하는 볼륨인 데 비해, 일시적 임시 볼륨은 영구적 임시 볼륨으로 지정된 공간 외에 추가 공간이 필요한 경우 시스템이 일시적으로 생성하는 임시 볼륨이다. 일시적 임시 볼륨을 생성하는 비용은 상당히 크기 때문에 데이터베이스 관리자는 데이터베이스 운영 상황을 고려하여 적절한 크기의 영구적 임시 볼륨을 추가하는 것이 성능상 유리하다. 데이터베이스 생성 시에 관리자는 일시적 임시 볼륨이 생성될 수 있는 공간도 고려해야 한다. 일시적 임시 볼륨은 한 번 생성되면 데이터베이스를 재시작하기 전까지 유지되며, 한 번 늘어난 크기는 줄어들지 않는다. 일시적 임시 볼륨의 크기가 지나치게 커지면, 데이터베이스를 재시작하여 일시적 임시볼륨이 자동으로 삭제되도록 하는 것이 좋다. 단, 일시적 임시 볼륨을 수동으로 삭제해서는 안 된다. 큐브리드의 일시적 임시 볼륨의 파일명은 db_name_tnum 형식의 이름을 갖는다. 여기서 db_name은 데이터베이스 이름이고, num은 볼륨 식별자이다. 볼륨 식별자는 32766에서부터 1씩 감소한다. 일시적 임시 볼륨이 생성되는 개수는 트랜잭션 처리에 필요한 공간의 크기에 따라 시스템이 결정한다. 그러나, 일시적 임시 볼륨의 크기는 사용자가 시스템 파라미터 설정 파일(cubrid.conf)의 temp_file_max_size_in_pages 파라미터의 값을 설정함으로써 제한할 수 있다. 이 파라미터의 기본값은 -1로, 여유 공간이 있는 한 최대한 생성할 수 있다. 0으로 설정되면 영구적 임시 볼륨이 소진되어도 일시적 임시 볼륨을 생성하지 않는다. 저장 위치 설정으로는 기본적으로 첫 번째 데이터베이스 볼륨이 생성된 위치에 만들어진다. 그러나, 사용자가 temp_volume_path 파라미터값을 설정하여 일시적 임시 볼륨이 저장될 다른 디렉터리를 지정할 수 있다. 마지막으로 일시적 임시 볼륨은 데이터베이스가 구동 중일 때만 일시적으로 존재하며, 서버가 운영 중일 때 일시적 임시 볼륨을 임의로 삭제하면 안 된다. 데이터베이스 서버가 정상적으로 종료되면 일시적 임시 볼륨이 삭제되고, 데이터베이스 서버가 비정상적으로 종료되면 서버가 재시작할 때 일시적 임시 볼륨이 삭제된다.
백업 볼륨은 데이터베이스에 대한 스냅샷으로서, 이러한 백업 볼륨과 로그 볼륨을 기반으로 특정 시점까지 발생한 트랜잭션을 복구할 수 있다. 사용자는 큐브리드 백업 데이터베이스 유틸리티를 통해 데이터베이스 복구를 위해 필요한 모든 데이터를 복사할 수 있으며, 데이터베이스 환경 설정 파일의 backup_volume_max_size_bytes 파라미터값을 설정하여 백업 볼륨의 분할 크기를 조정할 수 있다.
- 데이터베이스 서버
데이터베이스 서버는 크게 데이터베이스 서버 프로세스, 마스터 프로세스, 실행 모드로 나뉜다.
데이터베이스 서버 프로세스는 각 데이터베이스에 한 개의 서버 프로세스가 존재한다. 서버 프로세스는 큐브리드 데이터베이스 서버를 구성하는 핵심 프로세스로 데이터베이스 파일과 로그 파일 등에 직접 접근하여, 사용자의 요청을 처리한다. 클라이언트 프로세스는 서버 프로세스와 TCP/IP 통신을 통해 접속하며, 하나의 서버 프로세스는 스레드를 생성해서 다수의 클라이언트 프로세스의 요청 작업을 처리한다. 데이터베이스별, 즉 서버 프로세스별로 시스템 파라미터 설정을 지정할 수 있으며 서버 프로세스는 max_clients 파라미터값으로 지정된 수만큼 클라이언트 프로세스의 접속이 가능하다.
마스터 프로세스는 클라이언트 프로세스가 서버 프로세스에 접속하여 통신할 수 있게 하는 중개 프로세스로서, 호스트별로 한 개씩 동작한다. 또, 지정된 TCP/IP 포트에 대기하고 있고, 클라이언트 프로세스는 해당 TCP/IP 포트로 마스터 프로세스에 접속한 후 마스터 프로세스가 지정된 데이터베이스 이름에 따라 해당 서버 프로세스로 소켓 포트를 변경하여 접속을 처리한다.
실행 모드는 서버 프로세스를 제외한 큐브리드 프로그램들의 종류에 따라 두 가지 모드가 있다. 클라이언트/서버 모드와 독립 모드로 나뉜다. 클라이언트/서버 모드는 해당 프로그램이 클라이언트 프로세스로서 동작하여 서버 프로세스에 접속하는 방식이고, 독립 모드는 해당 프로그램이 서버 프로세스의 기능을 포함하고 있어 직접 데이터베이스 파일에 접근하여 수행하는 방식이다. 예를 들어, 데이터베이스 생성 유틸리티나 복구 유틸리티 등은 다수 사용자가 데이터베이스에 접근하는 것을 막고 해당 프로그램만이 온전히 점유해서 작업할 수 있도록 독립 모드로 실행된다. 또 다른 예로, C에스큐엘 인터프리터는 클라이언트/서버 모드로 동작하여 서버 프로세스에 접속할 수도 있고, 독립 모드로 동작하여 데이터베이스에 접근하여 에스큐엘 문을 실행할 수도 있다. 참고로, 하나의 데이터베이스에 서버 프로세스와 독립 모드로 실행되는 프로그램이 동시에 접근할 수는 없다.
- 브로커
브로커는 다양한 응용 클라이언트가 데이터베이스 서버에 연결할 수 있도록 중계하는 미들웨어이다. 브로커를 포함하는 큐브리드 시스템은 응용 클라이언트, cub_broker, cub_cas, 데이터베이스 서버(cub_server)를 포함한 다중 계층 구조를 가진다.
응용 클라이언트에서 사용할 수 있는 인터페이스는 C-API(CUBRID Call Inter face-API), ODBC, JDBC, PHP, 파이썬, 루비, OLEDB, ADO.NET, Node.js 등이 있다.
cub_cas는 연결을 요청하는 모든 종류의 응용 클라이언트가 사용하는 공용 응용 서버 역할을 한다. 또한, 데이터베이스 서버의 클라이언트로 동작하여 클라이언트의 요청으로 데이터베이스 서버와 연결을 제공한다. 서비스 풀(service pool) 내에서 구동되는 cub_cas의 개수는 cubrid_broker.conf 설정 파일에 지정할 수 있으며, cub_broker에 의해 동적으로 조정된다. cub_cas는 큐브리드 데이터베이스 서버의 클라이언트 라이브러리와 링크되는 프로그램으로 데이터베이스 서버 프로세스에는 클라이언트 모듈로 동작하며, 쿼리 파싱이나 최적화, 실행 계획 생성 등의 작업이 클라이언트 모듈에서 수행된다.
cub_broker는 응용 클라이언트와 cub_cas 사이의 연결을 중계하는 기능을 수행한다. 즉, 응용 클라이언트가 접근을 요청하면 cub_broker는 공유 메모리(shared memory)를 통해 cub_cas의 상태를 파악하여 접근 가능한 cub_cas에게 요청을 전달하고, 해당 cub_cas로부터 전달받은 요청에 대한 처리 결과를 응용 클라이언트에게 반환한다. 또한, cub_broker는 서비스 풀 내의 cub_cas 개수를 조정하여 서버 부하를 관리하고, cub_cas의 구동 상태를 모니터링 및 관리한다. 만약, 응용 클라이언트의 요청을 cub_cas 1에게 전달하였는데, 비정상적인 종료로 인해 cub_cas 1과의 연결이 실패하면, cub_broker는 응용 클라이언트에게 연결 실패에 관한 에러 메시지를 전송하고 cub_cas 1을 재구동한다. 새롭게 구동된 cub_cas 1은 정상적인 대기 상태가 되어, 새로운 응용 클라이언트의 요청으로 재연결된다.
공유 메모리에는 cub_cas의 상태 정보가 저장되며, cub_broker는 공유 메모리에 저장된 cub_cas의 상태 정보를 참조하여 응용 클라이언트와의 연결을 중계한다. 공유 메모리에 저장된 cub_cas의 상태 정보를 통해 시스템 관리자는 어떤 cub_cas가 현재 작업을 수행 중인지, 어떤 응용 클라이언트의 요청이 처리 중인지를 확인할 수 있다.
같이 보기
- 데이터베이스 관리 시스템(DBMS)
- 관계형 데이터베이스 관리 시스템(RDBMS)
- ㈜큐브리드
- 네이버㈜
