CUBRID | Enterprise Open Source DBMS

CloudBeaver Community에서 CUBRID 사용하기

hwanyseo — Tue, 17 Mar 2026 15:12:34 +0900

CloudBeaver Community에서 CUBRID 사용하기

CloudBeaver는 SQL, NoSQL, 클라우드 데이터베이스를 포함한 다양한 데이터베이스를 지원하며, 웹 브라우저를 통해 모든 데이터베이스에 접근할 수 있습니다.

팀워크에 최적화된 CloudBeaver는 데이터베이스 작업을 간소화하고 클라우드 기반 환경에서 여러 사용자가 원활하게 협업할 수 있도록 지원합니다.

간단한 라이브 데모는 아래 URL에서 경험해 볼 수 있습니다.

https://demo.cloudbeaver.io/#/

이 글에서는 CloudBeaver Community버전에서

1. CUBRID를 활성화 할 수 있는 Script를 설치하는 방법과

2. CloudBeaver를 설치 할 수 있는 방법을 간략하게 소개합니다.

참고 URL :

CUBRID DBEAVER관련 GitHub : https://github.com/CUBRID/cubrid-dbeaver-plugins

CloudBeaver Docker Hub : https://hub.docker.com/r/dbeaver/cloudbeaver/

CloudBeaver 설치 가이드 : https://github.com/dbeaver/cloudbeaver/wiki/CloudBeaver-Community-deployment-from-docker-image

CloudBeaver Community에서 CUBRID 활성화 하기

CUBRID는 CloudBeaver Enterprise버전에서는 활성화 되어 있지만, CloudBeaver Community버전에서는 기본적으로 비활성화 되어 있습니다.

https://github.com/CUBRID/cubrid-dbeaver-plugins/releases를 공개된 script를 이용해 간단하게 CUBRID를 활성화 할 수 있습니다.

CloudBeaver Community 버전이 설치되어 있어야 하므로 설치되어 있지 않다면 본 글의 'CloudBeaver Community 설치'를 참고하세요.

1. https://github.com/CUBRID/cubrid-dbeaver-plugins/releases에서 cubrid-enabler.sh를 다운로드 받습니다.

2. cubrid-enabler.sh를 Docker container 내부의 /opt/cloudbeaver폴더에 복사합니다.

(Docker Image를 사용하지 않는 경우 cloudbeaver가 설치된 root 폴더에 복사하면 됩니다.)

예) docker cp c:\cubrid-enabler.sh (my-container-name):/opt/cloudbeaver

Docker Desktop UI를 이용하는 경우 컨테이너의 "Files" 탭에서 파일을 우클릭하여 직접 다운로드하거나, 파일을 드래그 앤 드롭하여 업로드할 수도 있습니다.

3. 복사된 폴더로 이동하여 Script를 실행합니다.

chmod +x cubrid-enabler.sh  //실행권한이 없는 경우

./cubrid-enabler.sh

4. 실행 후 아래와 같이 정상적으로 설치완료 메시지를 확인 할 수 있습니다.

./cubrid-enabler.sh

Created folder: /opt/cloudbeaver/drivers/cubrid

CUBRID JDBC driver extracted

Backup original file: /opt/cloudbeaver/server/plugins/io.cloudbeaver.resources.drivers.base_1.0.141.202603020941.jar

Backup successful: /opt/cloudbeaver/server/plugins/io.cloudbeaver.resources.drivers.base_1.0.141.202603020941.jar.1773182108.bak

Bundle replaced successfully

** 참고 **

패치 설치 후 문제가 발생될 경우 백업파일(.bak)을 이용하여 원본 파일로 다시 변경 후 재시작하면 됩니다.

e.g.) cp /opt/cloudbeaver/server/plugins/io.cloudbeaver.resources.drivers.base_1.0.141.202603020941.jar.1773182108.bak /opt/cloudbeaver/server/plugins/io.cloudbeaver.resources.drivers.base_1.0.141.202603020941.jar

5. Docker Container 재부팅

아래와 같은 명령어를 통해 Container를 재시작하거나 Docker Desktop 사용자는 UI에서 Container를 재시작합니다.

docker restart (my-container-name)

6. 활성화 확인

기본 포트인 8978을 사용하는 경우 브라우저에서 ip:8978을 입력하여 CloudBeaver에 접속하여 활성화 상태를 확인 합니다.

New Connection 메뉴로 이동하면 아래 그림과 같이 CUBRID 활성화가 확인됩니다.

CloudBeaver Community 설치

Cloudbeaver Docker Hub에 공개된 정보를 통해 Windows와 Linux에서의 설치 방법을 소개합니다.

[Windows]

Windows의 경우 Docker Desktop(https://www.docker.com/products/docker-desktop/)설치 후에

1. CloudBeaver Docker Hub에서 [Run in Docker Desktop] 버튼을 클릭하여 간단하게 설치 할 수 있습니다.

특정 버전을 사용하고 싶은 경우 Tags Tab으로 이동 후 특정 버전의 Run in Docker Desktop 아이콘으로 설치 할 수도 있습니다.

2. Docker Desktop 실행 팝업이 실행 되고 아래 화면에서 Confirm을 눌러 Image를 Download 받습니다.

3. Container name을 입력하고 Default로 사용할 경우 바로 실행하거나 포트변경예정일 경우 추후 이용할 Port번호를 입력 후 실행을 합니다.

[Linux]

Linux의 경우 Docker 사용을 위해 docker-ce docker-ce-cli containerd.io가 설치가 필요합니다.
Docker의 설치 방법은 다양한 정보를 통해 설치가 가능하므로 Cloudbeaver 설치에 대해서만 설명하겠습니다.

1. 아래와 같이 command를 이용하여 docker image를 download할 수 있습니다.

특정 버전을 이용하고자 하는 경우 ':latest' 부분을 ':25.3.5'와 같이 특정 버전으로 변경하여 download 받습니다.

docker pull dbeaver/cloudbeaver:latest

2. Docker Container를 생성 및 실행

아래와 같은 명령어를 통해 Container 생성 및 실행이 가능합니다.

-p 옵션의 경우 추후 포트를 변경할 예정이라면 다른 포트를 입력하여야 합니다. CloudBeaver 기본 포트는 8978입니다.
-v 옵션의 경우 추후 업데이트를 위해 내부 /opt/cloudbeaver/workspace를 Host 저장소(/var/cloudbeaver/workspace)에 연결하게 되어 docker를 삭제하여도 추후 업데이트시 데이터를 그대로 사용할 수 있습니다. (필요에 따라 위치를 다르게 설정하세요.)

network등 다른 추가 설정이 필요한 경우 reference site를 참고하세요.

docker run -d --name (my-container-name) \

  -p 8978:8978 \

  -v /var/cloudbeaver/workspace:/opt/cloudbeaver/workspace \

  --restart always \

  dbeaver/cloudbeaver:latest

HA 다중화 구성에서 loadBalance를 활용해 읽기 분산해 보기

큐브02 — Tue, 24 Dec 2024 09:35:12 +0900

* HA 다중화 구성에서 loadBalance를 활용해 읽기 분산해 보기

먼저, CUBRID HA와 loadBalance를 잘 이해할 수 있도록 CUBRID HA 특징과 CUBRID Broker의 특징에 대해 정리해 본다.

CUBRID HA는 마스터 노드(master node), 슬레이브 노드(slave node), 레플리카 노드(replica node)로 나눌 수 있다.

마스터 노드 : 액티브 서버를 사용한 읽기, 쓰기 등 모든 서비스를 제공한다.
슬레이브 노드 : 스탠바이 서버를 사용한 읽기 서비스를 제공하며 마스터 노드 장애 시 failover가 일어난다.
레플리카 노드 : 스탠바이 서버를 사용한 읽기 서비스를 제공하며 마스터 노드 장애 시 failover가 일어나지 않는다.

CUBRID Broker의 ACCESS_MODE는 RW(Read Write), RO(Read Only), SO(Standby Only)로 나눌 수 있다.

RW : 읽기, 쓰기 서비스를 제공하는 브로커이다. 일반적으로 액티브 서버에 연결하며, 연결 가능한 액티브 서버가 없으면 일시적으로 스탠바이 서버에 연결한다.
RO : 읽기 서비스를 제공하는 브로커이다. 가능한 스탠바이 서버에 연결하며, 스탠바이 서버가 없으면 액티브 서버에 연결한다.
SO : 읽기 서비스를 제공하는 브로커이다. 스탠바이 서버에 연결하며, 스탠바이 서버가 없으면 서비스를 제공하지 않는다.

이 외에 레플리카로 접속 할 수 있는 파라미터인 REPLICA_ONLY가 존재한다.

REPLICA_ONLY : 레플리카 서버에 접속된다. 이 때의 ACCESS_MODE 값이 RW이면 레플리카 DB에도 쓰기 작업을 수행할 수 있고 이를 허용하지 않으려면 ACCESS_MODE 값을 RO로 설정해야 한다.

또한 CUBRID 브로커에서 QUERY의 종류를 구분하지 않기 때문에 읽기 부산을 위한 브로커에는 SELECT QUERY 만을 수행해야 한다.

이제 마스터-슬레이브-레플리카로 구성 되어 있을 때 loadbalance 읽기 부하 분산을 어떻게 할 수 있을지 살펴본다.

위 그림과 같이 마스터 브로커는 ACCESS_MODE=RW로 설정하여 기본적으로 마스터에 연결되도록 하고, 슬레이브브로커는 ACCESS_MODE=RO로 설정하여 슬레이브에 연결되도록 한다.

(이 때 주의할 점은 마스터, 슬레이브 노드에 부하분산을 위한 브로커는 별도 구성을 해야한다는 점이다. 기본적으로 RW브로커는 마스터, 슬레이브 양 쪽에 구성이 되어 있어야 한다.)

레플리카의 경우 REPLICA_ONLY=ON으로 설정하고, ACCESS_MODE=RO로 설정하여 레플리카 서버에만 접속을 허용하되, 쓰기 작업은 허용하지 않는다.

이 때 마스터 노드 액티브 서버의 장애 발생으로 DB 프로세스가 Down되면 fail-over가 발생되어 기존의 슬레이브 노드가 마스터 노드로 변경된다.

위와 같이 기존 마스터 노드였던 1번 서버에 장애가 발생되더라도, 새로운 마스터 서버(기존 슬레이브)로 연결이 되어 서비스가 정상적으로 동작한다.

이 때 접속량이 기존의 두 배로 발생될 수 있기 때문에 이를 고려하여 각 DB의 max_clients를 설정해야 한다.

위와 같이 기존에 마스터 노드였던 1번 서버의 DB 프로세스가 정상적으로 올라온다면, 슬레이브 노드로 상태가 변경되며, 기존 구성과는 브로커-노드가 CROSS(교차)로 연결 된다.

다만 이 구성에서 고려해야할 점은 REPLICA_ONLY를 설정해둔 경우 레플리카 노드 외에 다른 노드로는 접속 시도를 하지 않기 때문에 레플리카 노드에 장애가 날 경우 서비스 안정성에 문제가 있을 수 있다는 점이다.

레플리카 노드의 장애에 대비하여 레플리카 노드 역시 다중화 할 수 있다.

위와 같은 구성에서는 어떤 서버에서 장애가 발생하더라도, 서비스 안정성을 보장할 수 있으며 읽기 부하 분산도 가장 이상적으로 가능하다.

위 구성에서 각 레플리카 노드의 databases.txt 내 db-host는 각각 자신을 우선순위로 두어야 의도에 맞게 사용할 수 있다. REPLICA1의 경우 REPLICA1:REPLICA2로 설정하고, REPLICA2의 경우 REPLICA2:REPLICA1로 설정 하여야 한다.

각 노드의 databases.txt는 아래와 같이 되어야 한다.

노드	마스터	슬레이브	레플리카1	레플리카2
db-host	마스터:슬레이브	마스터:슬레이브	레플리카1:레플리카2	레플리카2:레플리카1

이렇게 CUBRID HA는 여러가지 구성을 유동적으로 제공하기 때문에 안정성과 성능 모두 만족할 수 있도록 각 사이트에 맞는 구성을 고려하면 좋다.

참고 매뉴얼

- CUBRID HA 구성 형태 : https://www.cubrid.org/manual/ko/11.3/ha.html#id32

- 브로커 모드 : https://www.cubrid.org/manual/ko/11.3/ha.html#broker-mode

- HA 관련 환경 설정 : https://www.cubrid.org/manual/ko/11.3/ha.html#ha-configuration

DBMS와 효과적인 SQL 처리

박세훈 — Fri, 29 Dec 2023 09:13:05 +0900

DBMS는 SQL을 효과적으로 처리하기 위해서 어떠한 노력을 하고 있을까요?

- 질의 재작성기(Query Rewriter)
여러 개발자에게 동일한 요구사항을 주고 질의를 작성하게 하면 서로 다른 형태로 작성할 수 있습니다. 질의를 어떻게 작성하느냐에 따라서 성능에 차이가 발생할 수 있기 때문에 개발자가 질의를 효과적으로 작성하는 것은 중요한 일이지만, DBMS가 상당부분 그 일을 대신하고 있습니다.

위 질의를 작성한 그대로 수행하게 되면 부질의 결과를 임시파일에 저장하고 그것을 재가공해야 합니다. 하지만 오른쪽 질의처럼 작성되어 있다면, 따로 부질의를 수행해서 저장할 필요도 없고, 인덱스의 사용도 가능합니다. 위와 같이 부질의를 제거하고 주질의에 합병하는 것을 뷰머징이라고 합니다. DBMS는 가능한 경우 뷰머징을 진행하며, 인라인 뷰와 뷰 객체에 대해서도 동일하게 합병을 진행합니다.

부질의가 뷰머지가 불가능한 경우에 주질의에 있는 조회조건을 부질의로 넣는 것을 predicate push라고 합니다. 조회시 스캔하는 양을 줄일 수 있기 때문에 상당히 성능을 향상시킬 수 있습니다.

필요 없는 select list와 조인 테이블 그리고 order by절등을 제거하여, 필요없는 처리과정을 진행하지 않을 수 있습니다. 해당 항목을 조회 하지 않아도 동일한 결과가 보장될 때 제거가 가능합니다. 테이블은 외부 조인되거나 외례키 관계에서 조인 조건의 컬럼이 유니크한 경우 제거가 가능합니다.

위에서 소개한 재작성 이외에도 DBMS는 다양한 재작성을 진행합니다. CUBRID는 이러한 재작성된 질의를 실행계획에서 직접 확인할 수 있습니다.

- 질의 최적화기(Query Optimizer)
SQL은 어떻게 데이터를 조회할 것인가에 대한 정보를 포함하고 있지 않습니다. 질의 최적화기가 이러한 정보인 실행계획을 생성합니다.

위 질의의 조회조건으로 얼마나 데이터가 필터링될지 예측할 수 있을까요? 만약 'COLUMN'의 값이 고유하다면 한건이 조회 될 것이고, 모두 '1'이라면 전체 데이터가 조회 될 것입니다. 이렇게 조회조건을 평가했을 때 전체 데이터 대비 조회되는 양의 비율을 선택도(selectivity)라고 합니다. 선택도를 통해서 읽어야하는 페이지수와 결과 행수를 예측할 수 있습니다. 예를 들어 'table'의 전체 페이지수는 1000개, 데이터 건수는 10,000개이고 조회조건의 선택도가 0.01이면, 읽어야 하는 페이지수는 10개, 결과 행수는 100건으로 예측할 수 있습니다. 비용계산 공식은 스캔 방법에 따라 다르고 복잡하지만, 기본적인 원리는 선택도를 활용하여 결과 행수와 읽어야 하는 페이지를 예측하는 것입니다.

위와 같이 조인된 질의는 각테이블 별로 분리해서 비용을 산출합니다. 첫번째 테이블의 선택도와 전체 페이지수로 비용을 계산하고 두번째 테이블역시 같은 방법으로 비용을 산정합니다. nested loop 조인 방법이라면 첫번째 결과 행수만큼 두번째 테이블 조회를 반복하게 됩니다. 이 경우 전체 비용은 첫번째 비용 + (첫번째 행수 * 두번째 비용) 으로 계산할 수 있습니다. 질의 최적화기는 각각 테이블 순열의 비용을 계산하고, 비교하여 최적의 실행계획을 선택합니다.

실행계획을 보면 최적화시에 사용된 정보들을 확인할 수 있습니다. 테이블의 전체 건수와 페이지수 그리고 조회조건의 선택도가 얼마인지 확인 할수 있습니다. 실행계획의 card는 cardnality의 약자로 예측되는 결과 행수를 의미합니다. 각각의 정보를 알고 있으면 실행계획을 정확하게 이해하는데 도움이 될 것입니다.

- 질의 실행기(Query Executor)

질의 실행기에서는 성능 향상을 위해 진행 단계를 생략하는 최적화를 진행합니다. 인덱스를 활용하여 정렬과정을 생략하거나 인덱스의 정보만으로도 조회가 가능하면 데이터영역에 접근하는 과정을 생략합니다. 다중 키 범위 최적화와 SORT-LIMIT 최적화와 같이 필요한 양의 데이터만 조회하여 나머지 데이터의 스캔 과정을 생략하기도 합니다.

TRACE 정보를 확인하면 질의 실행기가 어떤 최적화를 진행했는지 알 수 있습니다. 또한 실제로 읽은 페이지수와 결과 행수도 확인 가능합니다.

- 마치며

DBMS는 성능향상을 위해 다양한 최적화를 진행하고 있으며, 사용자는 실행계획과 TRACE 정보를 통해 이것을 확인할 수 있습니다. CUBRID는 이러한 성능 향상을 위한 개선 작업을 지속적으로 진행하고 있습니다. 질의가 더 효과적으로 재작성되도록 다양한 사례의 재작성을 추가하고 보완하였습니다. 효과적인 실행계획을 생성하기 위해서 선택도관련 통계정보의 대상을 인덱스에서 테이블로 확대하고, 규칙기반 최적화는 최소화하는 작업을 진행하고 있습니다. CUBRID는 아직 병렬 질의를 지원하지 않지만 2024년을 목표로 개발을 진행하고 있습니다. 조금씩 꾸준히 사용자 관점에서 개선되는 CUBRID를 기대해 주시기를 바랍니다.

CUBRID Internal: B+ 트리의 노드(=페이지)와 노드 분할 방법

주영진 — Wed, 27 Dec 2023 19:55:37 +0900

개요

큐브리드는 B+ 트리 인덱스를 사용하고 있습니다. B+ 트리 인덱스는 새로운 키가 입력되거나 기존 레코드가 변경될 때, B+ 트리를 유지하기 위해서 노드의 분할 또는 병합이 발생할 수 있습니다. 노드는 B+ 트리를 구성하는 가장 작은 단위로, 하나의 노드는 데이터베이스에서 하나의 페이지에 해당합니다. 이 글에서는 노드가 되는 페이지에 대해서 살펴보고, 노드 분할이 발생하는 경우와 그 과정에 대해서 알아보겠습니다.

예시의 모든 질의는 11.3.0.1089-bd31bd5 버전에서 실행했습니다.

B+ 트리의 노드(= 페이지)

데이터베이스의 모든 데이터는 페이지에 저장되며, 모든 페이지는 슬롯 페이지 구조(Slotted Page Structure)로 되어 있습니다. 슬롯 페이지 구조에 대해 더 알고 싶다면 "CUBRID 슬랏 페이지(slotted page) 구조 살펴보기" 글을 참고해주세요. 모든 페이지는 페이지 헤더(SPAGE_HEADER)를 포함하고 있습니다. 페이지는 페이지 헤더의 페이지 타입(PAGE_TYPE)을 통해 어떤 테이터를 저장하고 있는지를 구분할 수 있습니다. 페이지 타입에 따라 추가로 필요한 헤더를 가질 수 있습니다. B+ 트리의 노드는 페이지 타입이 PAGE_BTREE인 페이지입니다. PAGE_BTREE 페이지는 페이지 헤더와 페이지 타입에 필요한 노드 헤더(BTREE_NODE_HEADER) 또는 오버플로 헤더(BTREE_OVERFLOW_HEADER)를 가지고 있습니다.

일반적으로 B+ 트리는 노드를 3 계층으로 구분합니다. 가장 상위 노드를 루트(Root) 노드, 가장 하위 노드를 리프(Leaf) 노드, 루트와 리프 사이에 있는 노드를 브랜치(Branch) 노드라고 합니다. 노드가 어느 계층의 노드인지는 노드 헤더가 가지고 있는 노드 레벨 (node_level)로 확인할 수 있습니다. 리프 노드의 노드 레벨은 항상 1이며, 루트 노드의 노드 레벨은 B+ 트리의 높이입니다. B+ 트리의 높이가 3인 경우, 브랜치 노드의 노드 레벨은 2가 되고, 루트 노드의 노드 레벨은 3이 됩니다.

노드 레벨에 따라서 노드 타입을 구분하고 있습니다. 노드 타입은 리프가 아닌 노드(BTREE_NON_LEAF_NODE), 리프 노드(BTREE_LEAF_NODE), 오버플로 노드(BTREE_OVERFLOW_NODE) 등 3가지가 있습니다. 노드 레벨이 1인 경우 노드의 노드 타입은 BTREE_LEAF_NODE(리프 노드)가 되며, 노드 레벨이 1보다 큰 경우 BTREE_NON_LEAF_NODE(리프가 아닌 노드)가 됩니다. B+ 트리의 높이가 1인 경우에는 인덱스를 구성하는 페이지가 1개이고, 루트 노드의 노드 레벨이 1이기 때문에 루트 노드의 노드 타입이 BTREE_LEAF_NODE(리프 노드)가 됩니다. 오버플로 노드에 대해서는 좀 더 아래에서 알아보겠습니다.

	
			1
2
3
4
5
6
7
8

			/* src/storage/btree.h */
 
typedef enum
{
  BTREE_LEAF_NODE = 0,
  BTREE_NON_LEAF_NODE,
  BTREE_OVERFLOW_NODE
} BTREE_NODE_TYPE;

		

루트 노드는 루트 헤더(BTREE_ROOT_HEADER)를 가지고 있습니다. 루트 헤더는 노드 헤더를 포함하고 있고, 인덱스 전체에 대한 메타 정보를 저장하고 있습니다. 브랜치 노드와 리프 노드는 노드 헤더만 가지고 있습니다.

페이지의 0번 슬롯이 루트 헤더 또는 노드 헤더를 가리키고 있습니다. 루트 노드와 브랜치 노드의 레코드는 다음 계층 노드의 VPID를 저장하고 있고, VPID는 페이지에 접근할 수 있는 주소입니다. VPID는 볼륨 아이디, 페이지 아이디로 구성되어 있습니다. 리프 노드의 레코드는 테이블 레코드들의 OID를 저장하고 있고, OID는 레코드에 접근할 수 있는 주소입니다. OID는 볼륨 아이디, 페이지 아이디, 슬롯 아이디로 구성되어 있습니다.

오버플로 노드 (BTREE_OVERFLOW_NODE)

리프 노드에 동일한 키가 여러 번 입력되면 해당 키는 한 번만 저장하고 테이블 레코드들의 OID를 모아서 저장합니다. 이러한 구조는 같은 키를 가지는 테이블 레코드들을 빠르게 찾을 수 있도록 하는 장점이 있습니다. 그러나 OID 목록에서 특정 OID를 찾는 것은 어려울 수 있습니다. OID 목록의 크기는 페이지 크기의 1/8을 초과할 수 없으며, 페이지 크기의 1/8을 초과하는 OID들은 오버플로 노드에 저장됩니다.

	
			1
2
3

			/* src/storage/btree_load.h */
 
#define BTREE_MAX_OIDLEN_INPAGE ((int) (DB_PAGESIZE / 8))

오버플로 노드에는 2개의 슬롯만 존재합니다. 0번 슬롯은 오버플로 헤더를 가리키고 있으며, 1번 슬롯은 OID 목록을 가리키고 있습니다. 하나의 오버플로 노드에 OID 목록을 모두 저장할 수 없는 경우에는 오버플로 헤더가 다음 오버플로 노드의 VPID를 저장하고 있습니다.

리프 노드의 레코드가 오버플로 노드에 OID 목록을 저장하고 있는 경우에는 첫 번째 OID의 슬롯 아이디에 BTREE_LEAF_RECORD_OVERFLOW_OIDS 플래그를 설정하며, 레코드 마지막에는 첫 번째 오버플로 노드의 VPID가 저장되어 있습니다.

	
			1
2
3
4
5
6
7
8
9
10

			/* src/storage/btree.c */
 
if (btree_leaf_is_flaged (rec, BTREE_LEAF_RECORD_OVERFLOW_OIDS))
  {
    btree_leaf_get_vpid_for_overflow_oids (rec, &leaf_rec->ovfl);
  }
else
  {
    VPID_SET_NULL (&leaf_rec->ovfl);
  }

		

PAGE_OVERFLOW 페이지

사용자가 입력하는 키의 크기가 너무 커서 하나의 페이지에 저장할 수 없는 경우가 있습니다. 리프 노드에 저장할 수 있는 키의 크기는 페이지 크기의 1/8을 초과할 수 없습니다. 페이지 크기의 1/8을 초과하는 키는 리프 노드에 저장되지 않고, 하나 이상의 PAGE_OVERFLOW 페이지에 나누어 저장됩니다.

	
			1
2
3

			/* src/storage/btree_load.h */
 
#define BTREE_MAX_KEYLEN_INPAGE ((int) (DB_PAGESIZE / 8))

PAGE_OVERFLOW 페이지는 페이지 타입이 PAGE_OVERFLOW인 페이지입니다. 이 페이지는 페이지 헤더가 없으며, 슬롯 페이지 구조도 아닙니다. 첫 번째 PAGE_OVERFLOW 페이지는 OVERFLOW_FIRST_PART를 저장하고 있고, 두 번째 PAGE_OVERFLOW 페이지부터는 OVERFLOW_REST_PART를 저장하고 있습니다. 전체 키의 길이는 OVERFLOW_FIRST_PART에만 저장되어 있습니다.

리프 노드의 레코드가 PAGE_OVERFLOW 페이지에 키를 저장하고 있는 경우에는 첫 번째 OID의 슬롯 아이디에 BTREE_LEAF_RECORD_OVERFLOW_KEY 플래그를 설정하며, 레코드 마지막에는 첫 번째 PAGE_OVERFLOW 페이지의 VPID가 저장되어 있습니다.

	
			1
2
3
4
5
6

			/* src/storage/btree.c */
 
if (btree_leaf_is_flaged (rec, BTREE_LEAF_RECORD_OVERFLOW_KEY))
  {
    key_type = BTREE_OVERFLOW_KEY;
  }

		

PAGE_OVERFLOW 페이지는 인덱스 페이지가 아니라 데이터 페이지입니다. PAGE_BTREE 페이지는 인덱스 페이지로 개수를 세고 있지만, PAGE_OVERFLOW 페이지는 데이터 페이지로 개수를 세고 있습니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13

			/* src/storage/page_buffer.c - pgbuf_scan_bcb_table () */
 
switch (page_type)
  {
  case PAGE_BTREE:
    show_status_snapshot->num_index_pages++;
    break;
  case PAGE_OVERFLOW:
  case PAGE_HEAP:
    show_status_snapshot->num_data_pages++;
    break;
  ...
}

		

노드 분할

노드 분할이 발생하는 경우

새로운 키를 저장하기 위한 공간이 부족하거나 기존 레코드의 크기가 증가하는 경우에는 노드 분할이 발생할 수 있습니다. 이를 좀 더 자세히 살펴보면 다음과 같은 경우가 있습니다:

1. 새로운 키가 입력되는 경우

2. 기존 키의 크기가 증가하는 경우

3. 기존 레코드에 테이블 레코드의 OID가 추가되는 경우

4. 기존 레코드에 MVCC 아이디가 추가되는 경우

1. 새로운 키가 입력되는 경우

새로운 키의 입력은 충분한 여유 공간을 필요로 합니다. 해당 페이지에 여유 공간이 부족하면 노드 분할이 발생할 수 있습니다. 노드 분할이 발생하기 전까지 1978개의 키를 입력했습니다. 이 상태에서 새로운 키를 입력하면 노드 분할이 발생한 것을 확인할 수 있습니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

			/**
 * standalone mode
 *   $ csql -u dba  -S
 */
 
drop table if exists t1;
create table t1 (c1 int, index i1 (c1));
 
insert into t1 with recursive cte (n) as (
    select 1
    union all
    select n + 1 from cte where n < 1978
  )
select n from cte;
 
/* csql> ;line-output on */
show index capacity of t1.i1;
 
insert into t1 values (1979);
 
/* csql> ;line-output on */
show index capacity of t1.i1;
 
/*
<00001> Table_name                       : 'dba.t1'
        Index_name                       : 'i1'
        Btid                             : '(0|4160|4161)'
        Num_distinct_key                 : 1983 (1980 -> 1983)
        Total_value                      : 1983 (1980 -> 1983)
        ...
        Num_leaf_page                    : 3 (2 -> 3)
        Num_non_leaf_page                : 1
        Num_ovf_page                     : 0
        Num_total_page                   : 4 (3 -> 4)
        Height                           : 2
        ...
*/

		

2. 기존 키의 크기가 증가하는 경우

기존 키의 크기가 증가하면 레코드의 크기도 증가하게 됩니다. 해당 페이지에 여유 공간이 부족하면 노드 분할이 발생할 수 있습니다. 가변 길이 문자열 타입(VARCHAR)에서는 기존 키의 크기를 변경할 수 있습니다. 노드 분할이 발생하기 전까지 1581개의 키를 입력했습니. 이 상태에서 기존에 입력했던 키의 크기를 크게 변경하면 노드 분할이 발생한 것을 확인할 수 있습니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

			/**
 * standalone mode
 *   $ csql -u dba  -S
 */
 
drop table if exists t1;
create table t1 (c1 varchar, index i1 (c1));
 
insert into t1 with recursive cte (n) as (
    select 1
    union all
    select n + 1 from cte where n < 1581
  )
select lpad (n, 4, '0') from cte;
 
/* csql> ;line-output on */
show index capacity of t1.i1;
 
update t1 set c1 = lpad (c1, 20 /* 4 -> 20 */, '9') where c1 = 1581;
 
/* csql> ;line-output on */
show index capacity of t1.i1;
 
/*
<00001> Table_name                       : 'dba.t1'
        Index_name                       : 'i1'
        Btid                             : '(0|4160|4161)'
        Num_distinct_key                 : 1585 (1583 -> 1585)
        Total_value                      : 1585 (1583 -> 1585)
        ...
        Num_leaf_page                    : 3 (2 -> 3)
        Num_non_leaf_page                : 1
        Num_ovf_page                     : 0
        Num_total_page                   : 4 (3 -> 4)
        Height                           : 2
        ...
*/

		

3. 기존 레코드에 테이블 레코드의 OID가 추가되는 경우

같은 키가 입력되면 중복된 키를 저장하지 않고, 기존 키 뒤에 테이블 레코드의 OID를 추가합니다. 추가된 OID의 크기만큼 레코드의 크기도 증가하게 됩니다. 해당 페이지에 여유 공간이 부족하면 노드 분할이 발생할 수 있습니다. 노드 분할이 발생하기 전까지 1977개의 키를 입력했습니다. 이 상태에서 기존에 입력했던 키와 같은 키를 몇 번 더 입력하면 노드 분할이 발생한 것을 확인할 수 있습니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

			/**
 * standalone mode
 *   $ csql -u dba  -S
 */
 
drop table if exists t1;
create table t1 (c1 int, index i1 (c1));
 
insert into t1 with recursive cte (n) as (
    select 1
    union all
    select n + 1 from cte where n < 1977
  )
select n from cte;
 
select count (*) from t1 where c1 = 1977;
/* <00001> count(*): 1 */
 
/* csql> ;line-output on */
show index capacity of t1.i1;
 
insert into t1 values (1977);
insert into t1 values (1977);
insert into t1 values (1977);
 
select count (*) from t1 where c1 = 1977;
/* <00001> count(*): 4 */
 
/* csql> ;line-output on */
show index capacity of t1.i1;
 
/*
<00001> Table_name                       : 'dba.t1'
        Index_name                       : 'i1'
        Btid                             : '(0|4160|4161)'
        Num_distinct_key                 : 1981 (1979 -> 1981)
        Total_value                      : 1984 (1979 -> 1984)
        ...
        Num_leaf_page                    : 3 (2 -> 3)
        Num_non_leaf_page                : 1
        Num_ovf_page                     : 0
        Num_total_page                   : 4 (3 -> 4)
        Height                           : 2
        ...
*/

		

4. 기존 레코드에 MVCC 아이디가 추가되는 경우

레코드를 변경할 때 MVCC 아이디가 추가되도록 하려면 클라이언트/서버 모드에서 AUTO COMMIT을 비활성화하고 질의를 실행해야 합니다. 이 상태에서 질의를 실행하면 트랜잭션을 시작합니다. 트랜잭션 중에는 키를 삭제해도 물리적으로 삭제하지 않고, DELETE MVCC 아이디를 추가합니다. 추가되는 DELETE MVCC 아이디의 크기만큼 레코드의 크기도 증가하게 됩니다. 해당 페이지에 여유 공간이 부족하면 노드 분할이 발생할 수 있습니다. 노드 분할이 발생하기 전까지 1318개의 키를 입력했습니다. 이 상태에서 AUTO COMMIT을 비활성화하고 몇 개의 기존 키를 삭제하면 노드 분할이 발생한 것을 확인할 수 있습니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

			/**
 * client-server mode
 *   $ cubrid server start 
 *   $ csql -u dba 
 */
 
drop table if exists t1;
create table t1 (c1 int, index i1 (c1));
 
insert into t1 with recursive cte (n) as (
    select 1
    union all
    select n + 1 from cte where n < 1318
  )
select n from cte;
 
/* csql> ;line-output on */
show index capacity of t1.i1;
 
/* csql> ;autocommit off */
delete from t1 where c1 = 1318;
delete from t1 where c1 = 1317;
delete from t1 where c1 = 1316;
delete from t1 where c1 = 1315;
delete from t1 where c1 = 1314;
delete from t1 where c1 = 1313;
 
/* csql> ;line-output on */
show index capacity of t1.i1;
 
/*
<00001> Table_name                       : 'dba.t1'
        Index_name                       : 'i1'
        Btid                             : '(0|4160|4161)'
        Num_distinct_key                 : 1322 (1320 -> 1322)
        Total_value                      : 1322 (1320 -> 1322)
        ...
        Num_leaf_page                    : 3 (2 -> 3)
        Num_non_leaf_page                : 1
        Num_ovf_page                     : 0
        Num_total_page                   : 4 (3 -> 4)
        Height                           : 2
        ...
*/

		

사용자가 키를 입력하는 패턴에 따라 달라지는 노드 분할 #1

B+ 트리의 키가 항상 정렬되어 있기 때문에 사용자가 어떤 패턴으로 키를 입력하더라도 B+ 트리의 상태는 항상 동일하다고 착각할 수 있습니다. University of San Francisco의 B+ Tree Visualization을 사용하여 아래 2개의 시나리오 결과를 비교해 보았습니다.

1. 시나리오 #1 - 1부터 27까지 오름차순으로 증가하는 패턴으로 키를 입력하는 경우

2. 시나리오 #2 - 1부터 27까지 불규칙 패턴으로 키를 입력하는 경우

Max. Degree는 7로 설정했습니다. 페이지에 7번째 키가 입력될 때 노드의 레코드가 반으로 분할됩니다.

시나리오 #1 - 1부터 27까지 오름차순으로 증가하는 패턴으로 키를 입력하는 경우

1→2→3→4→5→6→7→8→9→10→11→12→13→14→15→16→17→18→19→20→21→22→23→24→25→26→27 순서로 키를 입력했습니다.

시나리오 #2 - 1부터 27까지 불규칙 패턴으로 키를 입력하는 경우

14→13→26→12→24→11→22→10→20→9→18→27→8→16→7→21→6→5→15→25→4→3→2→1→17→19→23 순서로 키를 입력했습니다.

비교 결과

B+ 트리의 높이가 시나리오 #1은 3이고, 시나리오 #2는 2입니다. B+ 트리의 높이가 높아지면 키를 탐색할 때 더 많은 노드에 접근해야 하므로 성능 저하가 발생 수 있습니다. 사용하는 페이지 수도 시나리오 #1은 11개이고, 시나리오 #2는 8개입니다. 시나리오 #1에서는 가장 오른쪽 리프 노드를 제외하고는 키를 4개 이상 저장하고 있는 리프 노드가 없습니다. 오름차순으로 증가하는 패턴으로 키를 입력하기 때문에 새로운 키는 가장 오른쪽 리프 노드에만 입력되고, 나머지 리프 노드에서는 저장 공간이 낭비됩니다. 시나리오 #1과 시나리오 #2는 키를 입력하는 패턴만 다르고, 나머지는 동일합니다. 사용자가 불규칙 패턴으로 키를 입력할 때는 성능 저하와 저장 공간의 낭비가 발생하지 않았습니다. 그러나 사용자가 항상 같은 패턴으로 키를 입력하는 것을 기대하는 것은 불가능합니다. 사용자는 서비스하고 있는 데이터의 성격에 따라 오름차순, 내림차순 또는 불규칙한 패턴으로 키를 삽입합니다.

똑똑하게 노드 분할하기

B+ 트리에서는 키가 정렬된 위치에 입력되기 때문에 키가 입력되는 슬롯 아이디의 변화를 통계적으로 분석하면 사용자가 키를 입력하는 패턴을 파악할 수 있습니다. 예를 들어, 오름차순 인덱스라고 가정할 때, 리프 노드의 가장 마지막 슬롯에 새로운 키가 입력되면 오름차순으로 증가하는 패턴으로 키가 입력되고 있다고 예측할 수 있습니다. 반대로 리프 노드의 노드 헤더 바로 다음 슬롯에 새로운 키가 입력되면 내림차순으로 감소하는 패턴으로 키가 입력되고 있다고 것으로 예측할 수 있습니다.

노드 헤더는 노드 분할 정보(BTREE_NODE_SPLIT_INFO)를 포함하고 있습니다. 이 정보는 페이지에 입력되는 슬롯 아이디에 대한 누적 이동 평균(pivot)을 계산해서 저장합니다. 새로운 키가 입력될 때마다 btree_split_next_pivot 함수에서 새로운 누적 이동 평균을 계산하고, 노드 분할이 필요한 경우에는 btree_find_split_point 함수에서 현재의 누적 이동 평균을 확인해서 노드의 레코드를 분할합니다.

	
			1
2
3
4
5
6

			#0  btree_split_next_pivot (...) at src/storage/btree.c:12603
#1  0x00007ff421cd3e96 in btree_key_insert_new_key (...) at src/storage/btree.c:27717
#2  0x00007ff421cd335e in btree_key_insert_new_object (...) at src/storage/btree.c:27484
#3  0x00007ff421cc7d9c in btree_search_key_and_apply_functions (...) at src/storage/btree.c:22802
#4  0x00007ff421ccfb63 in btree_insert_internal (...) at src/storage/btree.c:26345
#5  0x00007ff421ccf635 in btree_insert (...) at src/storage/btree.c:26199

		

누적 이동 평균은 다음과 같은 수식으로 계산됩니다. 여기서 CA_i는 i+1번째 키가 입력되기 전에 노드 분할 정보에 저장된 누적 이동 평균을 나타냅니다. 또한, X_i+1은 i+1번째 키에 대한 이동 평균을 나타냅니다. 이는 i+1번째 키가 입력된 슬롯 아이디를 i+1번째 키가 입력된 후의 전체 키 개수로 나누어 계산됩니다.

노드 분할이 발생할 때 레코드를 분할할 위치는 btree_split_find_pivot 함수에서 결정됩니다. 이 함수는 누적 이동 평균을 직접적으로 반영하지 않습니다. 누적 이동 평균이 0.2f(BTREE_SPLIT_LOWER_BOUND)와 0.8f(BTREE_SPLIT_UPPER_BOUND) 사이에 있는 경우에는 레코드를 반으로 분할하고, 벗어나는 경우에만 누적 이동 평균을 직접적으로 반영하여 레코드를 분할할 위치를 결정합니다. 만약 누적 이동 평균이 0.05f(BTREE_SPLIT_MIN_PIVOT)보다 작으면 0.05f를 사용하고, 0.95f(BTREE_SPLIT_MAX_PIVOT)보다 크면 0.95f를 사용하여 레코드를 분할할 위치를 결정합니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

			#0  btree_split_find_pivot (...) at src/storage/btree.c:12575
#1  0x00007ff421cafaee in btree_find_split_point (...) at src/storage/btree.c:12289
#2  0x00007ff421cb3cbd in btree_split_root (...) at src/storage/btree.c:13889
#3  0x00007ff421cd1934 in btree_split_node_and_advance (...) at src/storage/btree.c:27003
#4  0x00007ff421cc7b93 in btree_search_key_and_apply_functions (...) at src/storage/btree.c:22753
#5  0x00007ff421ccfb63 in btree_insert_internal (...) at src/storage/btree.c:26345
#6  0x00007ff421ccf635 in btree_insert (...) at src/storage/btree.c:26199
 
#0  btree_split_find_pivot (...) at src/storage/btree.c:12575
#1  0x00007ff421cafaee in btree_find_split_point (...) at src/storage/btree.c:12289
#2  0x00007ff421cb1a1e in btree_split_node (...) at src/storage/btree.c:13051
#3  0x00007ff421cd28f9 in btree_split_node_and_advance (...) at src/storage/btree.c:27290
#4  0x00007ff421cc7b93 in btree_search_key_and_apply_functions (...) at src/storage/btree.c:22753
#5  0x00007ff421ccfb63 in btree_insert_internal (...) at src/storage/btree.c:26345
#6  0x00007ff421ccf635 in btree_insert (...) at src/storage/btree.c:26199

		

사용자가 키를 입력하는 패턴에 따라 달라지는 노드 분할 #2

1. 오름차순으로 증가하는 패턴으로 키를 입력하는 경우

새로운 키는 항상 페이지의 마지막 슬롯에 입력되기 때문에 노드 분할 정보에서 누적 이동 평균은 0.95f(BTREE_SPLIT_MAX_PIVOT)보다 큰 값을 유지합니다. 따라서 노드 분할이 발생할 때 누적 이동 평균이 0.95f보다 크기 때문에 분할되는 왼쪽 페이지에는 전체 레코드 길이의 95%가 이동하고, 오른쪽 페이지에는 나머지 5%가 이동합니다. SHOW INDEX CAPACITY에서 Total_free_space_non_ovf를 보면 공간 낭비가 없는 것을 확인할 수 있습니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

			/**
 * standalone mode
 *   $ csql -u dba  -S
 */
 
set system parameters 'cte_max_recursions=100000';
 
drop table if exists t_asc;
create table t_asc (c1 int, index i1 (c1));
 
insert into t_asc with recursive cte (n) as (
    select 1
    union all
    select n + 1 from cte where n < 100000
  )
select n from cte;
 
/* csql> ;line-output on */
show index capacity of t_asc.i1;
 
/*
<00001> Table_name                       : 'dba.t_asc'
        Index_name                       : 'i1'
        Btid                             : '(0|4160|4161)'
        Num_distinct_key                 : 100206
        Total_value                      : 100206
        ...
        Num_leaf_page                    : 104
        Num_non_leaf_page                : 1
        Num_ovf_page                     : 0
        Num_total_page                   : 105
        Height                           : 2
        ...
        Total_space                      : '1.6M'
        Total_used_space_non_ovf         : '1.5M'
        Total_free_space_non_ovf         : '101.9K'
        ...
*/

		

2. 내림차순으로 감소하는 패턴으로 키를 입력하는 경우

새로운 키는 항상 페이지의 1번 슬롯에 입력되기 때문에 노드 분할 정보에서 누적 이동 평균은 0.05f(BTREE_SPLIT_MIN_PIVOT)보다 작은 값을 유지합니다. 노드 분할이 발생할 때 누적 이동 평균이 0.05f보다 작기 때문에 분할되는 왼쪽 페이지에는 전체 레코드 길이의 5%가 이동하고, 오른쪽 페이지에는 나머지 95%가 이동합니다. SHOW INDEX CAPACITY에서 Total_free_space_non_ovf를 보면 공간 낭비가 없는 것을 확인할 수 있습니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

			/**
 * standalone mode
 *   $ csql -u dba  -S
 */
 
set system parameters 'cte_max_recursions=100000';
 
drop table if exists t_desc;
create table t_desc (c1 int, index i1 (c1));
 
insert into t_desc with recursive cte (n) as (
    select 1
    union all
    select n + 1 from cte where n < 100000
  )
select n from cte order by n desc;
 
/* csql> ;line-output on */
show index capacity of t_desc.i1;
 
/*
<00001> Table_name                       : 'dba.t_desc'
        Index_name                       : 'i1'
        Btid                             : '(0|4160|4161)'
        Num_distinct_key                 : 100206
        Total_value                      : 100206
        ...
        Num_leaf_page                    : 104
        Num_non_leaf_page                : 1
        Num_ovf_page                     : 0
        Num_total_page                   : 105
        Height                           : 2
        ...
        Total_space                      : '1.6M'
        Total_used_space_non_ovf         : '1.5M'
        Total_free_space_non_ovf         : '101.9K'
        ...
*/

		

3. 불규칙 패턴으로 키를 입력하는 경우

키가 입력될 때마다 키가 입력되는 슬롯 아이디에 대한 누적 이동 평균이 갱신됩니다. 그래프를 보면 0.5f에서 크게 벗어나지 않고 있습니다. 노드 분할이 발생할 때 누적 이동 평균이 0.2f(BTREE_SPLIT_LOWER_BOUND)와 0.8f(BTREE_SPLIT_UPPER_BOUND) 사이에 있기 때문에 분할되는 왼쪽 페이지와 오른쪽 페이지에 각각 전체 레코드 길이의 50%를 이동합니다. SHOW INDEX CAPACITY 결과를 확인하면 오름차순 및 내림차순 패턴과 비교했을 때 Total_free_space_non_ovf가 큰 편입니다. 하지만 불규칙 패턴에서는 분할되는 왼쪽과 오른쪽 페이지 양쪽에 새로운 키가 입력될 가능성이 있으므로, 잦은 노드 분할을 방지하기 위해 적당한 여유 공간을 유지하는 것이 좋습니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

			/**
 * standalone mode
 *   $ csql -u dba  -S
 */
 
set system parameters 'cte_max_recursions=100000';
 
drop table if exists t_random;
create table t_random (c1 int, index i1 (c1));
 
insert into t_random with recursive cte (n) as (
    select 1
    union all
    select n + 1 from cte where n < 100000
  )
select n from cte order by random ();
 
/* csql> ;line-output on */
show index capacity of t_random.i1;
 
/*
<00001> Table_name                       : 'dba.t_random'
        Index_name                       : 'i1'
        Btid                             : '(0|4160|4161)'
        Num_distinct_key                 : 100254
        Total_value                      : 100254
        ...
        Num_leaf_page                    : 128
        Num_non_leaf_page                : 1
        Num_ovf_page                     : 0
        Num_total_page                   : 129
        Height                           : 2
        ...
        Total_space                      : '2.0M'
        Total_used_space_non_ovf         : '1.5M'
        Total_free_space_non_ovf         : '482.4K'
        ...
*/

		

루트 노드 → 브랜치 노드 → 리프 노드 순서의 노드 분할

노드 분할은 루트 노드 → 브랜치 노드 → 리프 노드 순서로 발생합니다. 키는 리프 노드에 입력되기 때문에 처음에는 리프 노드에서 노드 분할이 발생할 것으로 생각할 수 있습니다. 그러나 실제로는 루트 노드부터 시작하여 새로운 키를 입력할 수 있는 여유 공간이 있는지 확인합니다. 루트 노드에 공간이 부족하다면 키가 입력되지 전에 루트 노드에서부터 노드 분할이 발생합니다. 나중에 리프 노드에서 분할이 발생했을 때 분할된 페이지를 구분하기 위한 분할 키를 루트 노드와 브랜치 노드에 저장해야 하기 때문에 미리 여유 공간이 확보하는 것입니다.

아래는 B+ 트리의 높이가 1에서 2가로 증가하는 과정입니다. B+ 트리의 높이 1일 때는 리프 노드가 1개만 존재합니다. 리프 노드에 새로운 키를 저장할 수 있는 공간이 부족할 때 노드 분할이 발생합니다. 루트 노드의 분할은 새로운 키가 입력되기 전에 발생하며, 노드 분할이 완료된 후에 정렬된 위치에 새로운 키가 입력됩니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

			/**
 * standalone mode
 *   $ csql -u dba  -S
 */
 
drop table if exists t1;
create table t1 (c1 int auto_increment, index i1 (c1));
 
insert into t1 with recursive cte (n) as (
    select 1
    union all
    select n + 1 from cte where n < 1012
  )
select null from cte;
 
insert into t1 values (null); /* 1013 */

		

아래는 B+ 트리의 높이가 2에서 3으로 증가하는 과정입니다. 리프 노드에 새로운 키를 저장할 공간이 부족해서 노드 분할이 발생한 것이 아니라 루트 노드에 여유 공간이 부족해서 노드 분할이 발생했습니다. 루트 노드의 노드 분할이 완료된 후에는 정렬된 위치의 리프 노드에 새로운 키가 입력된 것을 확인할 수 있습니다. 이 때 리프 노드의 공간은 충분하기 때문에 노드 분할이 발생하지 않았습니다. 루트 노드가 분할하면서 B+ 트리의 높이가 2에서 3으로 증가할 때 새로운 브랜치 노드 2개가 추가됩니다. 루트 노드와 리프 노드의 VPID는 변경되지 않고, 새로운 브랜치 노드에 리프 노드의 레코드를 이동합니다.

	
			1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

			/**
 * standalone mode
 *   $ csql -u dba  -S
 */
 
set system parameters 'cte_max_recursions=1000000';
 
insert into t1 with recursive cte (n) as (
    select 1
    union all
    select n + 1 from cte where n < (976629 - 1013)
  )
select null from cte;
 
insert into t1 values (null); /* 976630 */

		

참고

1. [CUBRID Blog] CUBRID 슬랏 페이지(slotted page) 구조 살펴보기

2. [NAVER D2] CUBRID Internals - 키와 인덱스의 관계

3. [University of San Francisco] B+ Tree Visualization

4. [Wikimedia] Moving average - Cumulative average

Visual Studio Code 소개

송일한 — Thu, 21 Dec 2023 15:37:19 +0900

시작하며

Visual Studio Code (이하 VSCode) 는 마이크로소프트에서 오픈소스로 개발하고 있는 코드 에디터입니다. VSCode는 활용하기에 따라 메모장과 비슷한 기능을 하기도, IDE(통합 개발 환경) 로써의 기능을 하기도 합니다. 이미 많은 개발자들이 VSCode를 사용하고 있습니다. 그러나 VSCode의 사용이 낯선 개발자들을 위해 이 글에서는 VSCode의 기본적인 사용 방법을 소개드리려고 합니다.

설치 및 시작

VSCode는 공식 웹 사이트(https://code.visualstudio.com)에서 자신의 운영체제에 맞는 버전을 다운로드 받아 설치할 수 있습니다. 설치하고 난 뒤 VSCode를 실행하면 다음과 같은 화면을 마주할 수 있습니다.

이제, 수정하고 싶은 파일을 VSCode 내부로 끌어다 놓거나, Open File, Open Folder 를 통해 파일 및 폴더를 열어 로컬에 있는 코드를 개발할 수 있습니다. 하지만 VSCode의 성능을 온전히 이용하려면 확장(Extension)을 설치하여 응용하는 것을 추천합니다.

확장 (Extensions)

확장은 다음 버튼을 누르거나 Ctrl+Shift+X 를 입력하여 확장 탭에 진입할 수 있습니다.

초기에는 확장이 설치되지 않은 상태인데, Search Extensions in Marketplace 라고 적혀있는 텍스트 상자에 원하는 확장명을 입력하여 확장을 마켓플레이스에서 검색해 설치할 수 있습니다. 예시로 VSCode를 한글로 번역해주는 확장을 설치해보겠습니다.

Korean 이라고 검색하면 다수의 확장들이 같이 검색됩니다. 검색 결과 중, Microsoft에서 제공하는 Korean Language Pack for Visual Studio Code 확장을 설치합니다. 검색된 확장 옆의 Install 을 클릭해 설치할 수 있습니다.

확장을 설치하고 난 이후에는 우측 하단에 Change Language and Restart 버튼을 눌러 VSCode를 재시작하여 확장을 적용할 수 있습니다. 확장을 추가/삭제하는 경우 종종 VSCode를 재시작해야 적용되는 경우가 있으니 주의해야합니다. 이제 확장 설치 방법을 알게 되었으니, 다음으로 VSCode를 더욱 유용하게 만들어주는 몇 가지 확장을 소개하겠습니다.

1. Remote - SSH

Remote - SSH 확장은 VSCode에서 원격 서버에 있는 파일을 직접 편집하거나, 터미널을 열어 원격 서버에 명령을 송신할 수 있는 확장입니다. 이 확장을 설치하면 로컬 컴퓨터가 아닌, SSH를 통해 연결된 원격 서버의 개발 환경을 직접적으로 사용할 수 있게 됩니다. 이는 특히 원격 서버를 사용하는 개발자나 클라우드 기반 개발 환경에서 작업하는 개발자들에게 유용합니다.

VSCode 확장 탭에서 'Remote - SSH'를 검색하여 설치합니다. Microsoft에서 제공하는 확장을 추천합니다.

설치하면 왼쪽 사이드 바에 아래와 같은 탭이 추가됩니다.

SSH 오른쪽에 +를 클릭하면 다음과 같은 텍스트 박스가 나오는데, 이 곳에 자신이 접속하고자 하는 서버에 연결할 수 있는 ssh 명령을 입력합니다.

접속하고자 하는 서버의 OS와 비밀번호를 입력하면, 서버에 VSCode 서버를 설치한 뒤 연결됩니다. 이 과정에서 약간의 시간이 소요됩니다. 연결되고 나면 폴더 열기 를 통해 작업 영역으로 사용할 폴더를 열어 접속할 수 있습니다.

공개 키를 서버에 등록해놓으면, VSCode로 서버에 연결할 때 매번 비밀번호를 입력하는 과정을 건너뛸 수 있으니 공개 키 설정을 미리 하는 것을 추천드립니다. 또한 상단바의 터미널/새 터미널 을 통해 서버의 쉘 세션에 원격으로 연결할 수 있습니다.

개발 환경 셋업

접근하고자 하는 장치(로컬/리모트)가 리눅스 기반 운영체제임을 가정하고 작성합니다.

1. Github 레포지토리 설정

상단 바 메뉴에서 터미널/새 터미널을 이용하면, 현재 열려있는 장치(로컬/원격)의 디렉토리를 기준으로 기본 터미널이 열리게 됩니다. 여기서 원하는 폴더에 접근하여 GitHub 레포지토리를 클론하여 작업할 수 있습니다. 폴더 열기를 통해 원하는 작업 영역 폴더를 열었다고 가정하고 다음 과정에 대해 소개하겠습니다.

먼저 원하는 레포지토리를 클론합니다. 포크되어있는 큐브리드 레포지토리를 클론해보겠습니다.

git clone명령어를 사용하여 큐브리드 레포지토리를 클론하였습니다. 작업할 브랜치를 생성한 다음, 레포지토리에 있는 파일을 수정하면, VSCode의 소스 제어 탭을 통해 변경된 파일을 관리할 수 있습니다.

변경한 파일이 소스 제어 탭의 변경 사항 에 추가됩니다.

변경한 파일을 클릭하면 변경사항이 좌우로 나뉘어 나타나게 됩니다.

또한 VSCode의 '소스 제어' 탭을 사용하면 다음과 같은 Git 명령어들을 GUI를 통해 수행할 수 있습니다:

git add

VSCode에서 'git add'를 실행하려면, 변경된 파일 목록에 있는 파일 위에 마우스를 가져가면 나타나는 '+' 버튼을 클릭하면 됩니다. 이렇게 하면 해당 파일이 스테이징 영역에 추가됩니다.

git commit

'git add'로 커밋에 포함시킬 파일들을 추가한 후, 커밋 메시지를 입력할 수 있는 텍스트 상자에 커밋 메시지를 작성하고, 커밋 버튼을 누르면 커밋이 완료됩니다.

git push

'git commit'을 실행한 후에는 커밋 버튼이 'push' 버튼으로 바뀝니다. 이 버튼을 클릭하면 변경사항이 원격 저장소(예: GitHub)의 해당 브랜치에 반영됩니다.

2. 디버깅

디버깅 도구인 GDB 등을 사용할 때, VSCode를 활용하여 디버깅을 진행하면 보다 깔끔하고 효율적입니다. 단순히 GDB를 실행하는 것이 아니기 때문에 다소 복잡할 수 있지만 하나씩 설명 드리겠습니다. VSCode에서 제공하는 다양한 디버깅 환경은 설정 방식에 따라 다양하게 활용할 수 있습니다. 여기서는 간단한 예로, CUBRID csql을 독립 실행 모드(standalone mode)로 실행하여 디버깅 환경을 설정하는 방법을 소개하겠습니다.

launch.json 파일 만들기

현재 작업 디렉토리에 .vscode 폴더를 만들고 내부에 launch.json 파일을 만들어 다음 내용을 붙혀넣습니다. /home/cubrid/CUBRID/bin/csql 으로 설정되어있는 csql 경로는 각자 설정에 맞게 변경해야합니다.

{
        "version": "0.2.0",
        "configurations": [
            {
                "name": "(gdb) csql 시작",
                "type": "cppdbg",
                "request": "launch",
                "program": "/home/cubrid/CUBRID/bin/csql",
                "args": [ "-u","dba","-S", "demodb"],
                "stopAtEntry": false,
                "cwd": "${workspaceFolder}",
                "environment": [],
                "externalConsole": false,
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "gdb에 자동 서식 지정 사용",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ]
}
]
}

중단점(breakpoint) 설정

소스코드에 중단점으로 설정하고 싶은 line 좌측을 클릭하여 빨간색 원형 마크를 활성화합니다.

디버깅 시작 및 진행

좌측 디버깅 탭 내부의 (gdb) csql 시작 텍스트 좌측의 재생 버튼을 눌러 디버깅을 시작합니다.

중단점으로 설정해놓은 코드 라인이 실행될 경우 프로그램이 해당 코드 라인에서 일시 정지됩니다. 코드를 다음 중단점까지 실행하려면 F5, 한 라인씩 실행하려면 F10을 눌러 진행할 수 있습니다.

프로그램이 일시 정지될 시, 디버그 콘솔 창에서 함수를 실행할 수 있습니다.

또한 변수 창이나 일시 정지된 코드 상에서 특정 변수의 값을 확인할 수도 있습니다.

또한 호출스택/중단점 에서 호출 스택과 활성화/비활성화된 중단점들을 확인할 수 있습니다.

마무리하며

VSCode 는 다양한 확장(Extension)을 지원하며 아주 다양한 기능들을 내포하고 있습니다. 이 게시물에서 모든 기능에 대한 소개를 담지 못해 아쉽다는 생각이 듭니다. 또한 저도 꽤나 긴 시간동안 VSCode를 사용하고 있지만, VSCode에 대해 더 공부해야할 게 많습니다. 이 게시물이 VSCode를 사용하지 않았던 개발자들에게 도움이 되길 바랍니다. 감사합니다.

CUBRID QA 절차 및 업무 방식 소개

윤시온 — Fri, 17 Nov 2023 18:20:14 +0900

큐브리드의 QA 절차 및 업무 방식에 대해 소개하겠습니다.

CUBRID QA팀이 하는 일?

QA(Quality Assurance)팀은 CUBRID의 품질 보증에 대한 전반적인 절차를 다루는 업무를 맡고 있습니다. 단순 테스트뿐만 아니라, 개발 프로세스에 직간접적인 관여와 QA Tool 확장 및 유지보수, 제품 결함 관리, 제품 릴리즈 등 제품이 출시되는 과정에서 여러가지 일을 하고 있습니다.

특히, 개발과정의 처음부터 끝까지 참여하여 품질 저하에 문제가 될 만한 부분이 있는지 검증하고, 개선안을 제안하는 등 개발 프로세스 전반적으로 개입하여 제품 품질을 높이는 일을 하고 있습니다.

CUBRID QA 절차

CUBRID QA 절차는 크게 다음과 같이 볼 수 있습니다.

각 절차에 대한 상세한 과정은 다음과 같습니다.

1. Kick off 참여

-먼저, 개발팀으로부터 프로젝트를 할당 받으면, 킥오프를 참여합니다. 요구사항 및 목표를 파악하고, 사용자 관점에 부합하지 않을 경우 개선을 요청합니다. 프로젝트에 따라 검증방법이나 절차가 달라질 수도 있고 때에 따라 새로운 환경이 필요할 수 있기 때문에 여러 가지 의견들을 종합하여 팀 내 담당자를 선정합니다.

2. 테스트 환경 구축

-프로젝트를 위해 어떤 테스트가 필요한지에 대한 분석이 끝났다면, QA를 진행할 환경을 구축합니다. 만약 기존 구축되어 있는 테스트 환경이 요구사항을 충족시키지 못한다면 직접 환경을 설정하여 테스트를 수행하거나, 직접 테스트 프로그램을 만들기도 합니다. 제작된 테스트 프로그램이 장기적으로 유효한 테스트라고 판단될 시 regression test에 추가합니다.

3. 테스트 시나리오 수립

-프로젝트가 진행되면서 사용자 예상 시나리오를 수립합니다. 일반적으로 테스트 시나리오는 유효한 입력을 사용한 긍정적 테스트와 유효하지 않은 입력을 고려한 부정적 테스트를 고려합니다. 그러나 비정상적인 상황은 너무나 다양하기 때문에 현실적으로 모든 부정 테스트의 시나리오를 수립하고 자동화하여 테스트하기는 불가능합니다. 때문에 최대한으로 다양하고 확장된 시나리오를 수립하는 것을 목표로 합니다.

4. 테스트 케이스 작성

-사용자 시나리오 수립이 완료되면, 시나리오를 검증하고 테스트 케이스를 작성합니다. 이때, 문제점이 발견될 시 JIRA에 보고합니다.
-테스트 케이스는 SQL문으로만 이루어진 경우엔 SQL 테스트로, CUBRID 유틸리티나 프로세스 제어, 사용자의 동작 등이 테스트 시나리오에 포함된 경우는 shell 테스트 케이스로 작성하게 됩니다.
-SQL, shell 테스트 이외에도 요구사항 목적에 맞는 테스트 프로그램의 테스트 케이스로 작성하게 됩니다.

다음은 간단한 SQL 테스트 케이스와 답지의 예시입니다.

sql 테스트 케이스 예시) cubrid-testcases/sql/cbrd_24478/deduplicate/cases/02_create_table1.sql

sql 테스트 케이스 답지 예시) cubrid-testcases/sql/cbrd_24478/deduplicate/answers/02_create_table1.answer

5. 버그 리포팅

-만약 제품 내 결함을 발견했다면, 버그 리포팅을 진행합니다. 버그는 보통 테스트 시나리오를 검증하는 테스트 케이스 작성 단계나, 테스트 수행 단계에서 주로 발견됩니다. 개발자와 구두로만 소통할 시, 히스토리 관리가 매우 어렵기 때문에 JIRA를 이용하여 기록을 남기는 것이 중요합니다.
-버그리포트에는 core가 있다면 call stack 등의 core 정보, 테스트 버전, 재현절차, 기대결과, 실제결과 등의 내용이 포함됩니다.

6. 테스트 수행

-작성된 테스트 케이스는 Regression test에 포함됩니다. Regression test 결과를 분석하여 새로 작성된 테스트 케이스의 결과가 통과하였는지, 그리고 기존 제품의 영향도나 버그가 있는지 확인합니다.

7. 프로젝트 종료

-이슈가 발생하지 않았을 경우, 프로젝트를 종료하고 결과 및 관련 내용을 JIRA를 이용해 기술합니다.

각 프로젝트들은 이러한 과정을 거쳐 QA의 검증이 완료되면 계획된 하나의 버전으로 빌드 및 배포가 이루어지게 됩니다. 또, 배포 이후 발생한 문제점이나 제품 성능 등에 대해 신속히 대처하여 추가적인 버전 관리를 수행합니다. 이처럼 QA팀은 프로젝트 기획 단계부터 시작하여 릴리스 하기까지 비즈니스 리스크를 줄이면서 최대한 이상적인 제품을 제공하기 위해 개발팀과 상시적으로 교류하고 더 나은 방향을 제안하고 있습니다.

CUBRID QA TOOL

CUBRID QA팀은 자체적인 QA솔루션 툴인 CTP(CUBRID Test Program)를 사용하고 있습니다. 효율적인 QA를 위해 이 툴을 사용하며, 자동화된 Regression test 수행 및 QA home을 통한 결과를 확인을 할 수 있습니다. 확인 중 발견된 버그는 JIRA(=Bug tracking system)를 이용하여 관리합니다.

1. QA HOME

먼저, QA home에 대해 자세히 알아보겠습니다. QA home은 Regression test나 커버리지 테스트가 수행되었을 때, 테스트 결과를 관리 및 공유할 수 있는 웹 페이지입니다. 개발팀에서 수정한 코드가 commit되면 자동적으로 Jenkins에서 CUBRID 빌드가 진행되며, 빌드가 성공적으로 완료되면 regression test를 수행하게 됩니다. 테스트 결과는 QA home 웹페이지와 연동되어 있어 히스토리 추적 및 관리를 용이하게 할 수 있습니다.
Regression test에는 sql/medium 등 개별적인 동작 기능이 미리 정의된 사양을 준수하는지 테스트하는 functional test 와 YCSB, Sysbench, HA Replication Delay Time, DOTS-Stress, TPC-W, TPC-C 등 안정성, 신뢰성과 같은 성능을 검증하는 performance test로 이루어져 있습니다.

1-1) Functional test

다음은 Functional test의 결과 페이지입니다.

qahome 웹페이지 화면

Functional test에서는 Fail이 발생했을 경우, Fail count 숫자를 클릭하면 아래의 화면과 같이 테스트케이스의 실패 내역 리스트가 나옵니다.

qahome fail case 화면

Case file 리스트에 있는 테스트케이스를 클릭하면 테스트의 결과내용을 좀 더 자세히 볼 수 있고, 이 정보를 토대로 왜 테스트가 실패했는지 분석합니다. 실패의 원인은 다양합니다.

첫째로, 답지의 수정이 필요한 경우입니다. 최근에 개발팀에서 의도하지 않은 통계 업데이트를 막고자 ‘UPDATE STATISTICS’ 구문으로만 통계 업데이트가 되도록 하는 기능이 추가되었습니다. 그로 인해, show index 구문이 들어간 테스트 케이스들의 답지에서 통계 부분이 달라지는 현상이 있었습니다. 테스트 케이스들은 Git에서 각 테스트 별 레포지토리로 관리되고 있으므로, 해당하는 레포지토리에 직접 답지를 수정하여 pr(pull request)하고, 담당 개발자 및 QA팀원들의 리뷰를 거쳐 병합합니다.

QA home Fail case 상세결과화면

둘째로, 버그일 경우입니다. 다음은Isolation test에서 public 유저로 서브 쿼리를 실행했을 때 성능 저하가 발생하는 현상을 JIRA에 보고한 예시입니다. 버그일 경우에는 담당 개발자가 JIRA 내용을 보고 분석하여 해결하는 과정을 거칩니다.

JIRA 버그리포팅 화면

추가로 Core가 발생했을 경우는 Fail count 칸에 빨간 점멸등 아이콘으로 표시가 되고, 이를 JIRA에 보고합니다. Shell test의 경우에는 core를 자동으로 보고하는 기능이 탑재되어 있습니다.

shell test core report 화면

셋째로, 장비 환경에 문제가 있는 경우입니다. 장비 설정을 잘못 설정한 채로 테스트가 돌아가게 되면 해당 장비에서 실행된 테스트케이스들은 fail이 발생합니다. 이러한 경우는 설정을 올바르게 해주고 다시 실행하면 정상적인 결과가 도출됩니다.

위와 같이 QA home에서 fail결과를 발견할 때는 상황을 분석하여 JIRA에 보고하거나 구두로 담당 개발자에게 해당 내용을 정리해서 전달합니다.

1-2) Performance test

다음은 Performance test의 결과 페이지입니다.

QAhome Performance 결과 화면

Performance test는 CUBRID 데이터베이스 시스템의 성능을 측정하고 버전 별로 비교하는 데에 의의가 있으며, 사용되는 일반적인 작업 부하를 시뮬레이션하고 각 시스템이 이러한 부하에서 어떻게 수행되는지를 측정하여 평가합니다. Functional test와 마찬가지로, 성능에 문제가 있는 것으로 보일 경우 JIRA에 보고합니다.

신규 기능뿐만 아니라 기존 기능에 대해서도 품질을 유지하는 것이 중요하기 때문에 Regression test의 결과를 유지 및 관리하고 분석하는 업무는 매우 중요합니다. 앞서 설명했듯이, 기존 동작에 문제가 생겼다면 원인을 파악하고 개발팀과 논의하여 문제를 해결합니다.

1-3) Code coverage

QA home에 탑재된 다양한 테스트들은 소프트웨어 품질 지표인 코드 커버리지 테스트로 관리되고 있습니다. 코드 커버리지는 현재의 테스트들로 전체 소스코드가 얼마나 수행되고 있는지에 대한 수치를 나타내며, QA팀에서는 커버리지 수치를 유지 및 향상시키는 노력을 하고 있습니다. 다음은 코드 커버리지 테스트의 수행 결과 페이지이며, 항목별로 간단히 설명 드리도록 하겠습니다.

QAhome code coverage 화면

①   Current view : top level
현재 수행된 커버리지 테스트는 top level커버리지이며, 이는 프로그램 또는 모듈 전체에서 코드가 얼마나 실행되었는지를 나타내는 메트릭 중 하나입니다.
②   Test: 11.3.0.0957-baed85b 빌드 버전으로 Coverage Test를 수행한 결과를 의미합니다.
③   Date: 테스트가 끝난 시점을 의미합니다.
④   Category: 커버리지 테스트에 사용된 테스트들의 리스트이며, 각각의 테스트를 클릭하면 해당 테스트에서의 커버리지 수치를 볼 수 있습니다.
⑤   Legend: code coverage report에서 사용된 색상에 대한 설명입니다. 75%미만은 빨강, 75%이상은 노랑, 90%이상은 연두색으로 표현되어 있습니다.
⑥   커버리지 테스트에서 “Hit”는 일반적으로 특정 코드 또는 프로그램의 실행 경로에 따라 어떤 코드 블록, 라인, 함수 등이 실행되었음을 나타냅니다. 위 커버리지 테스트에서 Hit한 코드라인의 개수는 총 303688입니다.

2. CTP (CUBRID Test Program)

CTP는 CUBRID의 function test들을 수행하기 위해 만들어진 테스트 툴입니다. SQL/MEDIUM/SQL_BY_CCI, Shell, HA_repl, Isolation, RQG, Unit test, JDBC, Code Coverage 등의 테스트들을 수행할 수 있고, git clone을 통해 CTP를 다운로드 받을 수 있습니다.

가이드 문서를 참조하여 장비 설정 후, 테스트를 수행할 수 있습니다. (각 테스트들의 가이드 문서는 https://github.com/CUBRID/cubrid-testtools/tree/develop를 참조). CTP에 대해서는 추후 더 자세하게 소개하도록 하겠습니다.

이처럼 CUBRID QA팀은 기본적으로 QA home, CTP를 통해 업무를 진행하고, Git, Jira를 이용하여 전체 프로젝트를 관리하고 있습니다.

마무리하며

지금까지 CUBRID QA팀의 업무 방식 및 검증 프로세스를 간단하게 소개했습니다. “품질은 QA 전문가의 노력만으로 높아지지 않는다.”라는 말이 있습니다. 품질을 향상시키고, 좋은 제품을 제공하기 위해서는 모든 구성원이 협력해야 합니다. CUBRID는 모든 구성원이 버그 리포팅 및 버그 수정을 하고 있으며, 품질 향상에 기여하는 일에 협력하고 있습니다. QA팀도 다양한 QA활동을 통해 단순히 테스트를 하는 것이 아닌, 정확한 요구사항 분석에 기반한 품질 높은 제품을 만들어 나가도록 노력하겠습니다.

CUBRID의 개발 문화: CUBRID DBMS 프로젝트 빌드 가이드와 빌드 시스템 개선

유형규 — Fri, 08 Sep 2023 16:19:02 +0900

시작하며

이전 포스팅에서 CUBRID의 개발 문화: CUBRID DBMS는 어떻게 개발되고 있을까? 라는 주제로 블로그 글을 작성했었던 기억이 납니다. 날짜를 들여다보니 2021년 4월 29일에 작성되었으니 코로나 팬데믹을 이겨내고 CUBRID에서 여러 프로젝트를 진행하느라 시간이 훌쩍 지나갔네요. 그 사이 CUBRID는 11.2 (elderberry) 버전 릴리즈를 지나 11.3 (fig) 버전 릴리즈를 앞두고 있습니다.

이번에도 마찬가지로 [CUBRID의 개발 문화]라는 말머리를 가지고 CUBRID DBMS 프로젝트 빌드에 대한 이야기를 해보려고 합니다. 이전 포스팅의 ‘CUBRID DBMS는 어떻게 개발되고 있을까?’에서 소개했던 개발 프로세스와 프로젝트 기여 가이드의 내용과 조금 주제가 달라보일 수 있는데, 프로젝트 빌드에 대한 내용이 어떻게 개발 문화로까지 이어질 수 있는지 소개해 드리려고 합니다.

빌드 준비하기

누군가 코드를 기여하려고 할 때 빌드는 가장 먼저 해야 하는 첫 발걸음이면서, 동시에 제일 첫 번째로 마주하는 어려움입니다. 먼저 개발 환경에서 프로젝트를 빌드하기 위해서 여러 도구와 라이브러리를 설치하고, 프로젝트의 빌드 방법을 알아야 합니다. 이 때 기여하려는 개발자는 여러가지 어려움을 겪을 수 있습니다.

예를 들어:

(1) 나의 개발 환경에서 빌드가 가능한지 모름
(2) 필요한 개발 환경 (예를 들어 C++ 컴파일러), 라이브러리와 관련 도구를 어떤 것을 미리 설치해야 하는지 모름
(3) 빌드 필요 요소 (Build Requirements) 의 최소/권장 버전과 설치 경로를 모름
(4) 빌드 시스템/도구를 어떻게 사용하는지 모름

이러한 어려움에 대해서 물어보고 답을 받을 수 있는 커뮤니티 창구가 있으면 도움이 될 수도 있습니다. 하지만 대부분의 오픈소스 커뮤니티에서는 이러한 커뮤니티 창구가 없거나, 충분히 활성화 되어있지 않아서 답을 받아보지 못하거나 오랜 시간이 걸리게 됩니다. 많은 사람들이 이 단계에서 기여하기를 그만두게 될 것입니다.

빌드 준비를 도와주기

가이드 문서 작성하기

빌드를 시작해보기에 어려움을 겪을 수 있는 개발자를 도와주기 위해 빌드를 위한 가이드 문서를 코드와 함께 작성해야 합니다. 위의 ‘빌드 준비하기’ 에서의 어려움을 겪는 예를 기반으로 어떤 내용을 적어주면 좋을지 설명하면서 CUBRID 프로젝트의 사례를 소개합니다.

나의 개발 환경에서 빌드가 가능한지 모름: 프로젝트를 빌드 가능한 OS와 그 버전에 대해 명시해주는 것이 좋습니다. 만약 주기적으로 여러 OS 환경과 버전에서 빌드 테스트를 (Continous Testing) 수행하고 있다면 그것을 보여줌으로써 더 확실한 정보가 될 수 있을 것입니다.
필요한 개발 환경, 라이브러리와 관련 도구를 어떤 것을 미리 설치해야 하는지 모름: 기본적으로 C++ 컴파일러의 버전이나 자바 버전과 같은 지원하는 컴파일러와 함께 사용하는 라이브러리, 빌드 도구들을 어떤 걸 설치 해야하는지 알려주면 좋습니다. 만약 자동으로 설치된다면 어떤 것들이 설치될지도 알려준다면 혹시 이미 내 환경에 설치된 것과 충돌이 발생하지 않는지 확인할 수 있습니다. 아무런 정보 없이 빌드를 하면서 반복해서 빌드를 실패하고, 순식간에 지나가는 출력 속에서 에러를 찾아 헤매지 않도록 해야합니다.
빌드 필요 요소의 최소/권장 버전과 설치 경로를 모름: 특히 ‘yum’, ‘apt’와 같은 패키지 설치 도구에서 ‘yum install g++’, 또는 ‘apt-get install cmake’와 같이 명령을 입력했을 때 리눅스 배포판이나 그 버전에 따라 기본적으로 설치되는 버전이 다르므로 빌드가 가능한 명확한 버전을 알려주어야 합니다. 또 패키지 설치 도구를 통하지 않고 라이브러리르 직접 설치하거나 빌드해야 하는 경우에는 다운로드 받을 수 있는 경로를 적어주어야 합니다.
빌드 시스템/도구를 어떻게 사용하는지 모름: 프로젝트의 작성 언어나 플랫폼에 따라 다양한 빌드 도구를 사용할 수 있습니다. 자바 기반 프로젝트에서 사용하는 Ant, Maven, Gradle나 C/C++에서 Make, SCons, CMake, Ninja 등 다양한 빌드 시스템/도구가 있습니다. 이러한 빌드 시스템을 사용하여 작성한 스크립트를 처음부터 파악하기는 매우 어렵습니다. 같은 빌드 시스템을 사용하는 프로젝트라도, 빌드를 수행할 때 도구에게 넘겨주어야 하는 파라미터가 다르고 그 스크립트를 작성하는 컨벤션이 다를 수 있어 이해하지 못할 수 있습니다. 따라서 개발자가 기본적인 설정으로 쉽게 빌드해볼 수 있는 명령어나 스크립트를 제공해주어야 합니다.

CUBRID의 사례

CUBRID의 경우에는 최근 fig에서 업데이트 된 README 파일에서 Linux 와 Windows 환경에서 빌드할 수 있음을 소스로 부터 빌드 가이드에서 알려주고 있습니다. CUBRID의 엔진은 주로 C++로 구현되어 있지만, 저장 루틴 기능은 Java를 사용하고 있어서 C++ 컴파일러와 JDK 버전에 대해 명시하고 있습니다.

빌드 시스템은 CMake를 사용하고 있습니다. CMake는 빌드 시스템에서 필요로 하는 파일을 유연하게 생성할 수 있는데, 그런 만큼 꽤나 어렵게 느낄 수 있습니다. 특히 빌드 도구에 넘겨줄 수 있는 여러 파라미터에 따라 디버그/릴리즈와 같이 다른 모드로 빌드할 수 있습니다. 이런 파라미터를 잘 지정할 수 있도록, 복잡한 빌드를 좀 더 쉽게 하기 위해서 CUBRID는 Linux에서 build.sh, Windows에서 build.bat을 제공하고 있습니다. 다음은 ./build.sh -h 명령어로 사용법을 출력한 예입니다.

Usage: ./build.sh [OPTIONS] [TARGET]
OPTIONS
-t arg Set target machine (32(i386) or 64(x86_64)); [default: 64]
-m Set build mode(release, debug or coverage); [default: release]
-i Increase build number; [default: no]
-a Run autogen.sh before build; [default: yes]
-g Specifies the generator for a build (make, ninja); [default: make]
-c opts Set configure options; [default: NONE]
-s path Set source path; [default: current directory]
-b path Set build path; [default: /build__]
-p path Set prefix path; [default: /_install/CUBRID]
-o path Set package output path; [default: ]
-j path Set JAVA_HOME path; [default: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.302.b08-0.el7_9.x86_64]
-z arg Package to generate (src,zip_src,shell,tarball,cci,jdbc,rpm,owfs);
[default: all]
-? | -h Show this help message and exit

TARGET
all Build and create packages (default)
build Build only
dist Create packages only

EXAMPLES
./build.sh # Build and pack all packages (64/release)
./build.sh -t 32 build # 32bit release build only
./build.sh -t 64 -m debug dist # Create 64bit debug mode packages

CUBRID에서 사용하는 대부분의 의존 라이브러리들은 빌드할 때 CMake에서 함께 자동으로 설치하고 빌드하고 있는데, 의존 라이브러리를 다루는 빌드 스크립트 (3rdparty/CMakeLists.txt) 와 함께 의존 라이브러리의 목록과 버전을 적은 README 파일을 함께 참고할 수 있도록 하고 있습니다. 또 미리 개발자의 환경에 설치되어야 하는 빌드 필수 요소들에 대해서는 각 OS 환경에서 설치할 수 있는 스크립트를 다음과 같이 적어주고 있습니다.

https://github.com/CUBRID/cubrid/blob/develop/docs/install_build_requirements.md

가이드 문서 개선하기

가이드 문서를 작성하는 것은 많은 노력이 필요하지만 빌드를 해보면서 겪을 수 있는 모든 문제를 완벽히 해결해줄 수 없습니다. 이제는 기여를 기대해볼 차례입니다. 위의 내용을 따라 작성한 가이드로 잘 안내했다면, 문제가 발생하는 부분은 보통 사소한 부분입니다. 예를 들어 시간이 지나면서 최신 버전의 리눅스 배포판 버전을 사용하는 개발자의 환경에 기본적으로 설치되는 라이브러리의 버전이 너무 높다라거나 라이브러리를 설치할 때 환경변수를 설정하지 않았다와 같은 것입니다. 이런 문제의 보고와 가이드 문서 개선은 오픈소스 기여의 좋은 출발점입니다.

따라서 개발자가 오픈소스 세상에 발자취를 남길 수 있도록 문서를 별도의 웹사이트에서 따로 관리하기 보다는 가이드 문서를 소스 코드와 똑같이 기여할 수 있게 해야 한다고 생각합니다. 그것은 개발자들이 오픈소스에 기여하려는 이유와도 같습니다.

가상 환경 제공하기

충분히 위의 내용과 같이 가이드 문서를 작성하더라도 개발자의 환경에서 이미 설치/설정된 라이브러리와 충돌 또는 잘못 설정된 환경 변수 등의 문제로 빌드 실패를 겪을 수 있습니다. 이 때 각 환경에 대해 트러블슈팅을 세세하게 제공해줄 수도 있지만 앞에서 설명한 것과 같이 아주 어려운 일입니다. 대신, 다음과 같은 도구를 이용하여 필요한 요소가 모두 갖추어진 가상 환경을 제공해주는 것도 하나의 방법입니다.

Docker (https://www.docker.com/)
Vagrant (https://www.vagrantup.com/)

CUBRID는 엔진 소스 코드의 높은 허들을 (복잡한 시스템에 대한 분석 비용) 낮추기 위해 오픈소스 커뮤니티에서 좀 더 모듈/프로젝트를 쉽게 기여할 수 있는 cubrid-contrib (https://github.com/CUBRID/cubrid-contrib) 저장소를 운영하고 있습니다. CUBRID는 @lsahn-gh (https://github.com/lsahn-gh) 님이 최근 기여한 ‘Sandbox’ 프로젝트를 통해 Docker 가상 환경에서 빌드/개발 환경을 제공하고 있습니다.

https://github.com/CUBRID/cubrid-contrib/tree/main/sandbox

또 아직 CUBRID 저장소에 반영하지 않았지만, Vagrant 환경에서 각 CUBRID 버전을 빌드하는 위한 가상 환경과 그 가이드도 참고할 수 있습니다.

https://github.com/hgryoo/cubrid-vagrant-dev

이제 빌드하고 개발해보자 그런데..?

이제 프로젝트에 기여하기 위한 첫 번째 산을 넘었습니다. 기여하기를 시작할 때 간단히 어떤 곳에 출력문을 추가해보거나 ‘프로그램을 죽여보는’ 코드를 집어넣은 뒤 빌드하고 실행해보면서 기능을 넣어볼 곳을 분석하기도 합니다.

이제 점점 프로젝트의 코드를 분석해서 알아가고 새로운 기능을 넣어봅니다. 이제는 소스 코드를 고쳐보고 빌드하고 테스트하는 것을 반복하는 (FIX - BUILD - TEST) 행복한 (?) 무한 루프 속에 자연스럽게 들어왔습니다.

이 때 프로젝트의 규모가 점점 더 커지다보면 한번의 루프를 반복하는 것도 꽤나 오랜 시간이 걸립니다. 예를 들어 겨우 코드 한줄 (!) 을 고쳐보고 테스트 하려고 하는데 거의 30분을 기다려야만 빌드가 완료됩니다. 이것은 점점 개발자의 생산성에 영향을 주기 시작합니다.

~~(농담을 하자면)~~ 이제 30분 동안 문서도 작성해보고 방금 작성한 코드를 더 아름답게 바꿀 순 없을까 고민도 합니다. 그러다 이것을 반복하다보면 멍해지며 생각에 빠집니다. 아.. 최고의 복지는 제대로 일할 수 있게 해주는 것이라던데, 진행이 안되는구나. 역시 더 비싸고 좋은 장비를 사주었어야 하는걸까, 저 옆의 어디는 그거 준다던데...

아주 무서운(?) 농담이지만 개인적인 경험에 따르면 빌드 성능이 개발자가 기능을 개발할 때 집중력과 적극성에 분명한 영향을 준다는 것을 강조하려는 것입니다.

빌드 성능 개선하기

빌드 성능에 신경을 쓰는 것은 중요합니다. CUBRID와 같은 대규모 시스템의 경우에는 특히 빌드 시간이 꽤나 오래 걸립니다. CUBRID의 경우에는 Github의 Pull Request에서 매 commit 마다 빌드 테스트를 진행하므로 빌드 성능은 생산성에도, 비용에도 영향이 있습니다.

빌드 성능을 개선하는 많은 방법이 있겠지만 대표적으로 증분 빌드와 병렬 빌드를 잘 지원하는 것이 있습니다.

증분 빌드: 규모가 큰 프로젝트를 빌드 할 때, 이전에 빌드 되었지만 최신 상태인 것은 다시 빌드하지 않도록 하는 것
병렬 빌드: 빌드하면서 만들어지는 의존성과 오브젝트를 파악하여 병렬적으로 동시에 생성

이러한 방법은 빌드 시스템이나 도구에서 제공하지만 빌드 도구를 잘 선택하고 스크립트를 잘 작성해야 충분한 성능을 이끌어낼 수 있습니다. 빌드 성능을 개선하는 방법에 대해 설명하자면 너무 길어지므로 CUBRID가 개선한 사례로 설명하려고 합니다.

CUBRID는 Linux 환경에서 기본적으로 사용하고 있던 Make를 사용하고 있었는데, 빌드 성능을 저해하는 몇 가지 문제가 있었습니다.

빌드 스크립트의 버그: 의존 라이브러리에 대한 의존성이 제대로 설정되지 않아 병렬 빌드에 성능 저하가 발생
Make는 너무 느리고 무겁다: Make 도구는 오랜 역사를 지닌 만큼 많은 것들을 고려하고 있어 비교적 빌드 속도가 느림
병렬 빌드를 위한 CPU 개수 확보: CUBRID는 Circle CI에서 빌드 테스트를 매 commit 마다 수행하는데 사용하는 Docker Containor의 CPU 개수가 적음

위의 문제를 기반해서 먼저 빌드 스크립트의 의존성을 제대로 설정하도록 수정하고, Circle CI에서 CPU를 2개만 제공하는 Medium을 Large로 변경했습니다. 또 Make보다 비교적 가볍고 빠른 Ninja 빌드 시스템으로 빌드할 수 있도록 도입했습니다.

다음의 결과로 보면 CUBRID 11.0 에서 12분이 걸리던 빌드 속도가 거의 절반인 6분으로 줄어든 것을 볼 수 있습니다.

CUBRID의 Windows 환경에서는 Appveyor에서 MSVC로 빌드하는데, 거의 30분 넘게 빌드를 기다려야 합니다. Appveyor는 오픈소스 커뮤니티 플랜의 경우에는 무조건 1 CPU로만 동작하기 때문에 병렬 빌드가 동작하지 않습니다. 따라서 충분한 자원을 확보해주고, 병렬 빌드가 작동하도록 개선했습니다.

개선 결과를 보면 Appveyor에서 거의 31분이 걸리던 빌드가 Circle CI에서 거의 13분 수준으로 향상된 것을 볼 수 있습니다.

Circle CI에서 Linux (build → test)와 Windows 환경 (build-windows)에서 테스트를 보면, 거의 동시에 끝나는 것을 볼 수 있어 각 테스트 워크플로우가 끝날 때마다 함께 대응할 수 있습니다.

마무리

빌드에 대한 가이드는 프로젝트에 새로 합류하는 개발자의 좀 더 편안한 온보딩에 도움을 주고 그 비용을 줄여줍니다.

또 프로젝트에서 릴리즈 노트에 적히는, 눈에 보이는 기능 개발이나 성능 개선도 중요합니다. 그러나 어떻게 보면 눈에 보이지 않을 수 있는 빌드에 대한 개선은 개발자들이 코드를 작성하고 기여하는 활동 (코드 리뷰, 피드백에 대응하고 수정하는) 에 영향을 주어 프로젝트의 지속적인 발전의 윤활유가 될 것입니다.

참고

다음의 링크에서 위에서 소개한 빌드 가이드와 개선 사항에 대한 이슈를 참고할 수 있습니다.

[1] 빌드 가이드 문서: http://jira.cubrid.org/browse/CBRD-21500
[2] 병렬 빌드 버그 수정:
- http://jira.cubrid.org/browse/CBRD-23963
- http://jira.cubrid.org/browse/CBRD-24627
[3] 의존성 라이브러리 개선:
- http://jira.cubrid.org/browse/CBRD-24490
[3] Ninja 빌드 시스템 도입:
- http://jira.cubrid.org/browse/CBRD-24570
[4] Windows 빌드 CI 개선:
- http://jira.cubrid.org/browse/CBRD-24528

CSQL에서 PreparedStatement 사용하여 Query Plan 확인하기

김지원 — Thu, 11 May 2023 08:19:43 +0900

CSQL에서 PreparedStatement 사용하여 Query Plan 확인하기

Prepare statement를 이용하여 값을 질의에 포함하지 않고 bind 했을 경우와 질의상에 값을 직접 포함하였을 경우,

일부 상황에서 값에 대한 해석이 모호해져 질의 플랜이 다르게 만들어져 질의의 성능이 달라지는 경우가 있습니다.

이를 위해 csql 에서 prepare statement 사용하는 방법을 정리하였습니다.

아래 확인 예시는 11.2 에서 해결된 부분이나, 그 이전 부분에서 질의 수행 계획이 달라졌음에 대한 이해를 위해 사용하였습니다.

CSQL에서 PreparedStatement 사용

1. Prepared Statement 생성

PREPARE stmt_name FROM 'sql문';

2. Prepared Statement 실행

EXECUTE stmt_name [USING value, value2 ...];

3. Prepared Statement 해제

{DEALLOCATE | DROP} PREPARE stmt_name;

사용 예시(2가지)

csql > PREPARE pstmt FROM 'SELECT 1 + ?';

csql > EXECUTE pstmt USING 4;

csql > DROP PREPARE pstmt;

csql > PREPARE pstmt FROM 'SELECT col1 + ? FROM tbl WHERE col2 = ?';

csql > SET @a=3, @b='abc';

csql > EXECUTE pstmt USING @a, @b;

csql > DROP PREPARE pstmt;

preparedstatement 사용법의 자세한 내용은 아래 링크의 매뉴얼을 참고하세요.

https://www.cubrid.org/manual/ko/11.2/sql/query/prepare.html

Query Plan 확인 예시

csql >;trace on

1. BIND 사용

PREPARE pstmt FROM '
SELECT /*+ recompile */
   (
       SELECT
           COUNT(id)
       FROM
           tbla
       WHERE
           id = a.id
   ) col1,
   (
       SELECT
           NVL(MAX(TO_NUMBER(SUBSTR(id, 5))), 0)
       FROM
           tbla
       WHERE
           id LIKE SUBSTR(?, 1, 3) || ''%''
           AND id IS NOT NULL
   ) col2
FROM
   tbla a
LIMIT ?, ?';
EXECUTE pstmt USING 'A123456', 10, 10;

=== ===

2 command(s) successfully processed.

Query Plan:
TABLE SCAN (tbla)

rewritten query: (select nvl(max( to_number( substr(tbla.id, 5))), 0) from tbla tbla where tbla.id like substr( ?:0 , 1, 3)|| cast('%' as varchar))

INDEX SCAN (tbla.idx1) (key range: tbla.id=a.id, covered: true)

rewritten query: (select count(tbla.id) from tbla tbla where tbla.id=a.id)

TABLE SCAN (a)

rewritten query: select (select count(tbla.id) from tbla tbla where tbla.id=a.id), (select nvl(max( to_number( substr(tbla.id, 5))), 0) from tbla tbla where tbla.id like su
bstr( ?:0 , 1, 3)|| cast('%' as varchar)) from tbla a where (inst_num()> ?:1 ) and (inst_num()<= ?:1 + ?:2 )

Trace Statistics:
SELECT (time: 8, fetch: 84, ioread: 0)
SCAN (table: tbla), (heap time: 0, fetch: 21, ioread: 0, readrows: 21, rows: 21)
SUBQUERY (uncorrelated)
SELECT (time: 2, fetch: 13, ioread: 0)
SCAN (table: tbla), (heap time: 1, fetch: 13, ioread: 0, readrows: 5121, rows: 1024)
SUBQUERY (correlated)
SELECT (time: 5, fetch: 50, ioread: 0)
SCAN (index: tbla.idx1), (btree time: 4, fetch: 40, ioread: 0, readkeys: 10, filteredkeys: 0, rows: 10240, covered: true)

2. 상수 사용

SELECT
   (
       SELECT
           COUNT(id)
       FROM
           tbla
       WHERE
           id = a.id
   ) col1,
   (
       SELECT
           NVL(MAX(TO_NUMBER(SUBSTR(id, 5))), 0)
       FROM
           tbla
       WHERE
           id LIKE SUBSTR('A123456', 1, 3) || '%'
           AND id IS NOT NULL
   ) col2
FROM
   tbla a
LIMIT 10, 10;

=== ===

1 command(s) successfully processed.

Query Plan:
INDEX SCAN (tbla.idx1) (key range: (tbla.id>= ?:4 and tbla.id< ?:5 ), covered: true)

rewritten query: (select nvl(max( to_number( substr(tbla.id, 5))), 0) from tbla tbla where (tbla.id>= ?:4 and tbla.id< ?:5 ))

INDEX SCAN (tbla.idx1) (key range: tbla.id=a.id, covered: true)

rewritten query: (select count(tbla.id) from tbla tbla where tbla.id=a.id)

TABLE SCAN (a)

rewritten query: select (select count(tbla.id) from tbla tbla where tbla.id=a.id), (select nvl(max( to_number( substr(tbla.id, 5))), 0) from tbla tbla where (tbla.id>= ?:4
and tbla.id< ?:5 )) from tbla a where (inst_num()> ?:0 and inst_num()<= ?:1 )

Trace Statistics:
SELECT (time: 7, fetch: 76, ioread: 0)
SCAN (table: tbla), (heap time: 0, fetch: 21, ioread: 0, readrows: 21, rows: 21)
SUBQUERY (uncorrelated)
SELECT (time: 1, fetch: 5, ioread: 0)
SCAN (index: tbla.idx1), (btree time: 0, fetch: 4, ioread: 0, readkeys: 1, filteredkeys: 0, rows: 1024, covered: true)
SUBQUERY (correlated)
SELECT (time: 5, fetch: 50, ioread: 0)
SCAN (index: tbla.idx1), (btree time: 4, fetch: 40, ioread: 0, readkeys: 10, filteredkeys: 0, rows: 10240, covered: true)

위 예시 질의의 서로 다른 plan 문제는 현재(11.2) fix됨.

Index의 capacity에 관한 정보 열람

사니조아 — Wed, 26 Apr 2023 11:24:22 +0900

Index Capacity 정보

들어가며

DBMS의 여러 기능 기능이나 구성 요소들 중에서 가장 중요한 것은 무엇일까요?
Index는 '가장' 중요한은 아니더라도 적어도 '아주 아주' 중요한 요소가 아닐까 생각 합니다.

Index가 없다면 데이터를 쌓아 두기만 할 수 있을 뿐 사실상 관리는 못하는 그런 시스템이 될 테니까요.

자료가 많으면 많을 수록 Index는 더 중요해 집니다.

이렇게 중요한 Index를 분석할 때에도 목적에 부합하는 여러가지 도구와 방법들이 있을 수 있습니다.

이 페이지에서는 그 중에서 Index의 Capaicty에 대한 정보를 리뷰해 보고자 합니다.

기본적인 사용 방법이나 설명은 매뉴얼을 통해 얻을 수 있으므로 여기서 설명은 생략합니다.

INDEX CAPACITY 정보 얻기

우선 CUBRID에서는 Index의 Capacity 정보를 다음과 같은 두 가지 방법으로 쉽게(?) 알아 볼 수 있습니다.

1. diagdb tool

-------------------------------------------------------------
BTID: {{0, 5952}, 5953}, idx0 ON dba.tbl, CAPACITY INFORMATION:
Distinct Key Count: 0
Total Value Count: 0
Average Value Count Per Key: 0
Total Page Count: 2
Leaf Page Count: 1
NonLeaf Page Count: 1
Height: 2
Average Key Length: 0
Average Record Length: 0
Total Index Space: 32688 bytes
Used Index Space: 200 bytes
Free Index Space: 32488 bytes
Average Page Free Space: 16244 bytes
Average Page Key Count: 0
-------------------------------------------------------------

2. SHOW INDEX CAPACITY 명령

Table_name           : 'dba.tbl'        
Index_name           : 'idx0'        
Btid                 : '(0|5952|5953)'        
Num_distinct_key     : 0        
Total_value          : 0        
Avg_num_value_per_key: 0        
Num_leaf_page        : 1        
Num_non_leaf_page    : 1        
Num_total_page       : 2        
Height               : 2        
Avg_key_len          : 0        
Avg_rec_len          : 0        
Total_space          : '31.9K'        
Total_used_space     : '200.0B'        
Total_free_space     : '31.7K'        
Avg_num_page_key     : 0        
Avg_page_free_space  : '15.9K'

위 두가지 수행 결과는 표현되는 키워드와 형식만 약간 다를 뿐 사실 동일한 내용입니다.

INDEX CAPACITY 세부 항목

각 항목에 대한 설명을 "SHOW INDEX CAPACITY" 명령의 결과 기준으로 설명하면 아래 표와 같습니다.

SHOW INDEX CAPACITY	diagdb	의 미	비고
Table_name		테이블 이름
Index_name		인덱스 이름
Btid		BTID 정보 (vol ID, file ID, root_page ID)
Num_distinct_key	Distinct Key Count	전체 leaf 페이지에 존재하는 Distinct key 개수
Total_value	Total Value Count	인덱스에 저장된 OID 값의 총 개수
Avg_num_value_per_key	Average Value Count Per Key	키 당 OID 값의 평균 개수	((Num_distinct_key > 0) ? (Total_value / Num_distinct_key) : 0)
Num_leaf_page	Leaf Page Count	Non-Leaf 페이지 개수
Num_non_leaf_page	NonLeaf Page Count	leaf 페이지 개수
Num_total_page	Total Page Count	전체 페이지 개수
Height	Height	트리의 높이
Avg_key_len	Average Key Length	평균 키 길이	((Num_distinct_key > 0) ? (sum_of_each_key_len / Num_distinct_key) : 0)
Avg_rec_len	Average Record Length	평균 페이지 레코드 길이	((Num_distinct_key > 0) ? (sum_of_each_record_len / Num_distinct_key) : 0)
Total_space	Total Index Space	인덱스에 의해 점유되는 전체 공간
Total_used_space	Used Index Space	인덱스의 전체 사용 공간	Total_space - Total_free_space
Total_free_space	Free Index Space	인덱스의 전체 여유 공간
Avg_num_page_key	Average Page Key Count	Leaf 페이지 당 평균 키 개수	((Num_leaf_page > 0) ? (Num_distinct_key / Num_leaf_page) : 0)
Avg_page_free_space	Average Page Free Space	전체 페이지 당 평균 여유 공간	((Num_total_page > 0) ? (Total_free_space / Num_total_page) : 0)

주1) v11.2.3 기준입니다.

주2) 각각의 항목은 Overflow Page에 대한 정보를 포함하지 않은 상태로 보여 집니다.

다만, Total_value 항목은 Overflow Page의 정보를 포함합니다.

주3) Overflow Page영역의 정보는 이후 버전에서 포함 될 예정입니다.

사용해 보기1

우선 자료가 많지 않은 작은 테이블을 가지고 검토를 해 봅시다.

아래와 같이 동일한 구성의 두 테이블읋 준비해서 각각 50건과 500건을 입력합니다.

drop table if exists t1, t2;
create table t1(id int primary key, v1 int, v2 int);
create index idx1 on t1(v1);
create index idx2 on t1(v2);
create table t2 like t1;  

insert into t1 select rownum, rownum % 10, 1 from db_class a, db_class b, db_class c limit 50;
insert into t2 select rownum, rownum % 10, 1 from db_class a, db_class b, db_class c limit 500;

아래 명령으로 Capacity 정보를 얻어 봅니다.

;line on
show all indexes capacity  of t1;
show all indexes capacity  of t2;

아래에서 왼쪽은 t1 테이블 오른쪽은 t2 테이블에 대한 결과입니다.

=== ===

<00001> Table_name : 'dba.t1'
Index_name : 'idx1'
Btid : '(0|5696|5697)'
Num_distinct_key : 10
Total_value : 50
Avg_num_value_per_key: 5
Num_leaf_page : 1
Num_non_leaf_page : 0
Num_total_page : 1
Height : 1
Avg_key_len : 4
Avg_rec_len : 84
Total_space : '16.0K'
Total_used_space : '1000.0B'
Total_free_space : '15.0K'
Avg_num_page_key : 10
Avg_page_free_space : '15.0K'
<00002> Table_name : 'dba.t1'
Index_name : 'idx2'
Btid : '(0|5760|5761)'
Num_distinct_key : 1
Total_value : 50
Avg_num_value_per_key: 50
Num_leaf_page : 1
Num_non_leaf_page : 0
Num_total_page : 1
Height : 1
Avg_key_len : 4
Avg_rec_len : 804
Total_space : '16.0K'
Total_used_space : '928.0B'
Total_free_space : '15.1K'
Avg_num_page_key : 1
Avg_page_free_space : '15.1K'
<00003> Table_name : 'dba.t1'
Index_name : 'pk_t1_id'
Btid : '(0|5568|5569)'
Num_distinct_key : 50
Total_value : 50
Avg_num_value_per_key: 1
Num_leaf_page : 1
Num_non_leaf_page : 0
Num_total_page : 1
Height : 1
Avg_key_len : 4
Avg_rec_len : 20
Total_space : '16.0K'
Total_used_space : '1.3K'
Total_free_space : '14.7K'
Avg_num_page_key : 50
Avg_page_free_space : '14.7K'

3 rows selected. (0.004562 sec) Committed. (0.000016 sec)

1 command(s) successfully processed.

=== ===

<00001> Table_name : 'dba.t2'
Index_name : 'idx1'
Btid : '(0|5952|5953)'
Num_distinct_key : 10
Total_value : 500
Avg_num_value_per_key: 50
Num_leaf_page : 1
Num_non_leaf_page : 0
Num_total_page : 1
Height : 1
Avg_key_len : 4
Avg_rec_len : 804
Total_space : '16.0K'
Total_used_space : '8.0K'
Total_free_space : '8.0K'
Avg_num_page_key : 10
Avg_page_free_space : '8.0K'
<00002> Table_name : 'dba.t2'
Index_name : 'idx2'
Btid : '(0|6016|6017)'
Num_distinct_key : 1
Total_value : 500
Avg_num_value_per_key: 500
Num_leaf_page : 1
Num_non_leaf_page : 0
Num_total_page : 1
Height : 1
Avg_key_len : 4
Avg_rec_len : 1380
Total_space : '16.0K'
Total_used_space : '1.5K'
Total_free_space : '14.5K'
Avg_num_page_key : 1
Avg_page_free_space : '14.5K'
<00003> Table_name : 'dba.t2'
Index_name : 'pk_t2_id'
Btid : '(0|5824|5825)'
Num_distinct_key : 500
Total_value : 500
Avg_num_value_per_key: 1
Num_leaf_page : 1
Num_non_leaf_page : 0
Num_total_page : 1
Height : 1
Avg_key_len : 4
Avg_rec_len : 20
Total_space : '16.0K'
Total_used_space : '11.8K'
Total_free_space : '4.1K'
Avg_num_page_key : 500
Avg_page_free_space : '4.1K'

3 rows selected. (0.005187 sec) Committed. (0.000019 sec)

1 command(s) successfully processed.

Num_distinct_key와 Total_value를 비교해서 보면 pk_t1_id는 unique 하므로 입력된 레코드 건수와 키의 개수, Total_value의 개수가 동일함을 볼 수 있고,

idx2는 레코드가 모두 동일한 값을 갖으므로 Total_value의 개수는 레코드 개수와 동일하지만 Num_distinct_key는 항상 1임을 볼 수 있다.

idx1은 키가 중복되어 Num_distinct_key는 값이 일정 개수 이상으로 늘지 않고 있음을 볼 수 있다.

사용해 보기2

이제 데이터의 양을 늘려서 다른 부분들에 대해 검토 해 보겠습니다.

우선 아래와 같은 구문을 이용해서 테이블을 생성하고 데이터를 입력합니다.

drop table if exists tbl;
create table tbl(id int primary key, v1 int, v2 int, v3 int, s char(120));
create index idx1 on tbl(v1, s);
create index idx2 on tbl(v2, s);
create index idx3 on tbl(v3, s);

insert into tbl select rownum, rownum % 5000, rownum % 500, 1, 'cubrid string test' from db_class a, db_class b, db_class c, db_class d limit 100000;
;line on
show all indexes capacity  of tbl;

이 상태에서 아래 명령으로 100건의 레코드를 삭제한 후의 상태와 전체를 모두 삭제한 후의 상태를 확인해 봅니다.

delete from tbl where id%1000 = 1;
show all indexes capacity  of tbl;

delete from tbl;
show all indexes capacity  of tbl;

아래의 표에서 비교해서 볼 수 있습니다.

100000건 입력 후

100건 삭제 후

전체 삭제 후

=== ===

<00001> Table_name : 'dba.tbl'
Index_name : 'idx1'
Btid : '(0|6208|6209)'
Num_distinct_key : 5688
Total_value : 100688
Avg_num_value_per_key: 17
Num_leaf_page : 345
Num_non_leaf_page : 1
Num_total_page : 346
Height : 2
Avg_key_len : 426
Avg_rec_len : 571
Total_space : '5.4M'
Total_used_space : '3.1M'
Total_free_space : '2.2M'
Avg_num_page_key : 16
Avg_page_free_space : '6.6K'
<00002> Table_name : 'dba.tbl'
Index_name : 'idx2'
Btid : '(0|6272|6273)'
Num_distinct_key : 650
Total_value : 100150
Avg_num_value_per_key: 154
Num_leaf_page : 76
Num_non_leaf_page : 1
Num_total_page : 77
Height : 2
Avg_key_len : 374
Avg_rec_len : 920
Total_space : '1.2M'
Total_used_space : '593.3K'
Total_free_space : '635.7K'
Avg_num_page_key : 8
Avg_page_free_space : '8.3K'
<00003> Table_name : 'dba.tbl'
Index_name : 'idx3'
Btid : '(0|6336|6337)'
Num_distinct_key : 1
Total_value : 100000
Avg_num_value_per_key: 100000
Num_leaf_page : 1
Num_non_leaf_page : 0
Num_total_page : 1
Height : 1
Avg_key_len : 485
Avg_rec_len : 1192
Total_space : '16.0K'
Total_used_space : '1.3K'
Total_free_space : '14.7K'
Avg_num_page_key : 1
Avg_page_free_space : '14.7K'
<00004> Table_name : 'dba.tbl'
Index_name : 'pk_tbl_id'
Btid : '(0|6080|6081)'
Num_distinct_key : 100310
Total_value : 100310
Avg_num_value_per_key: 1
Num_leaf_page : 156
Num_non_leaf_page : 1
Num_total_page : 157
Height : 2
Avg_key_len : 4
Avg_rec_len : 12
Total_space : '2.4M'
Total_used_space : '1.5M'
Total_free_space : '926.2K'
Avg_num_page_key : 643
Avg_page_free_space : '5.9K'

4 rows selected. (6.017251 sec) Committed. (0.000028 sec)

1 command(s) successfully processed.

=== ===

<00001> Table_name : 'dba.tbl'
Index_name : 'idx1'
Btid : '(0|6208|6209)'
Num_distinct_key : 5688
Total_value : 100688
Avg_num_value_per_key: 17
Num_leaf_page : 345
Num_non_leaf_page : 1
Num_total_page : 346
Height : 2
Avg_key_len : 426
Avg_rec_len : 571
Total_space : '5.4M'
Total_used_space : '3.2M'
Total_free_space : '2.2M'
Avg_num_page_key : 16
Avg_page_free_space : '6.6K'
<00002> Table_name : 'dba.tbl'
Index_name : 'idx2'
Btid : '(0|6272|6273)'
Num_distinct_key : 650
Total_value : 100150
Avg_num_value_per_key: 154
Num_leaf_page : 76
Num_non_leaf_page : 1
Num_total_page : 77
Height : 2
Avg_key_len : 374
Avg_rec_len : 921
Total_space : '1.2M'
Total_used_space : '593.6K'
Total_free_space : '635.4K'
Avg_num_page_key : 8
Avg_page_free_space : '8.3K'
<00003> Table_name : 'dba.tbl'
Index_name : 'idx3'
Btid : '(0|6336|6337)'
Num_distinct_key : 1
Total_value : 100000
Avg_num_value_per_key: 100000
Num_leaf_page : 1
Num_non_leaf_page : 0
Num_total_page : 1
Height : 1
Avg_key_len : 485
Avg_rec_len : 1192
Total_space : '16.0K'
Total_used_space : '1.3K'
Total_free_space : '14.7K'
Avg_num_page_key : 1
Avg_page_free_space : '14.7K'
<00004> Table_name : 'dba.tbl'
Index_name : 'pk_tbl_id'
Btid : '(0|6080|6081)'
Num_distinct_key : 100310
Total_value : 100310
Avg_num_value_per_key: 1
Num_leaf_page : 156
Num_non_leaf_page : 1
Num_total_page : 157
Height : 2
Avg_key_len : 4
Avg_rec_len : 12
Total_space : '2.4M'
Total_used_space : '1.5M'
Total_free_space : '925.4K'
Avg_num_page_key : 643
Avg_page_free_space : '5.9K'

4 rows selected. (0.016022 sec) Committed. (0.000017 sec)

1 command(s) successfully processed.

=== ===

<00001> Table_name : 'dba.tbl'
Index_name : 'idx1'
Btid : '(0|6208|6209)'
Num_distinct_key : 489
Total_value : 489
Avg_num_value_per_key: 1
Num_leaf_page : 30
Num_non_leaf_page : 1
Num_total_page : 31
Height : 2
Avg_key_len : 428
Avg_rec_len : 446
Total_space : '494.8K'
Total_used_space : '217.5K'
Total_free_space : '277.2K'
Avg_num_page_key : 16
Avg_page_free_space : '8.9K'
<00002> Table_name : 'dba.tbl'
Index_name : 'idx2'
Btid : '(0|6272|6273)'
Num_distinct_key : 495
Total_value : 495
Avg_num_value_per_key: 1
Num_leaf_page : 33
Num_non_leaf_page : 1
Num_total_page : 34
Height : 2
Avg_key_len : 422
Avg_rec_len : 447
Total_space : '542.7K'
Total_used_space : '221.3K'
Total_free_space : '321.4K'
Avg_num_page_key : 15
Avg_page_free_space : '9.5K'
<00003> Table_name : 'dba.tbl'
Index_name : 'idx3'
Btid : '(0|6336|6337)'
Num_distinct_key : 1
Total_value : 431
Avg_num_value_per_key: 431
Num_leaf_page : 1
Num_non_leaf_page : 0
Num_total_page : 1
Height : 1
Avg_key_len : 485
Avg_rec_len : 520
Total_space : '16.0K'
Total_used_space : '656.0B'
Total_free_space : '15.3K'
Avg_num_page_key : 1
Avg_page_free_space : '15.3K'
<00004> Table_name : 'dba.tbl'
Index_name : 'pk_tbl_id'
Btid : '(0|6080|6081)'
Num_distinct_key : 437
Total_value : 437
Avg_num_value_per_key: 1
Num_leaf_page : 4
Num_non_leaf_page : 1
Num_total_page : 5
Height : 2
Avg_key_len : 4
Avg_rec_len : 19
Total_space : '79.8K'
Total_used_space : '10.6K'
Total_free_space : '69.2K'
Avg_num_page_key : 109
Avg_page_free_space : '13.8K'

4 rows selected. (0.006074 sec) Committed. (0.000018 sec)

1 command(s) successfully processed.

이 비교 테이블 중에서 PK인 pk_tbl_id에 대해서 우선 살펴 보겠습니다.

우선 Num_distinct_key값이 각각 100000, 99900, 0 으로 표시 되지 않았음을 볼 수 있습니다. 이상하다고 생각되겠지만 이 값들은 사용자가 입력한 정보가 아니라 현재 Index의 상태를 보여주는 용도이기 때문입니다.

우선 처음 100000개를 입력한 상태에서 100310으로 입력건수보다 많은 키가 존재하는 이유는 내부 처리 과정에서 FENCE_KEY와 같은 관리용 키가 생성되었기 때문입니다.

100건을 삭제한 후에도 값이 줄지 않고 있는 이유는 삭제되었다고 해도 Index에 정보가 남아 있는 상태이기 때문입니다. 이런 정보는 VACUUM을 통해서 정리가 됩니다.

전체 삭제 후에도 437개가 있는 것으로 표시되는 것은 VACUUM이 현재 수행 중이어서 정리를 하고 있는 중이기 때문입니다. 아직 전체 정리가 덜 된 상태라고 볼 수 있습니다.

이제 idx3 인덱스를 살펴 보겠습니다.

Num_total_page와 같은 페이지 수 정보를 보면 1로 변함이 없습니다. 다른 인덱스들이 데이터 양에 따라 페이지수의 변화가 있는데 비해 idx3는 항상 1개의 페이지만 가지고 있는 것처럼 보입니다. 그 이유는 현재 보여지는 정보에서는 OID Overflow-pages에 대한 정보를 포함하고 있지 않기 때문에 그런 착각을 불러 일으키는 것입니다.

마무리

인덱스의 Capacity 정보를 볼 때 혼동 할 만한 부분들에 대해서 간단하게 살펴 보았습니다.

현재 버전에서 아쉬운 점은 OID Overflow pages에 대한 정보가 없다는 것인데 이 부분은 차후 버전에서 개선 될 것입니다.

새 버전에서 정보가 추가되면 다시 변경 사항에 대해 설명 드리겠습니다.

CUBRID Internal: Disk Manager #1: 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table)

김재은 — Thu, 30 Mar 2023 11:05:03 +0900

이전글: CUBRID Internal: 큐브리드의 저장공간관리 (DIsk Manager, File Manager)

볼륨은 어떻게 관리될까?

- 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table) -

앞선 글에서 디스크 매니저(Disk Manager)가 섹터의 예약(reservation)을 관리한다고 이야기하였다. 이번 글에서는 볼륨 내의 섹터들이 어떻게 관리되는지에 대한 구체적인 이야기와 이를 위해 볼륨이 어떻게 구성되어 있는지를 다룬다. 여기서 다루어지는 볼륨의 구조는 그대로 non-volatile memory (SSD, HDD 등)에 쓰여진다.

볼륨 구조

디스크 매니저의 가장 큰 역할은 파일생성과 확장을 위해 섹터들을 제공해주는 것이다. 이를 위해 각 볼륨은 파일들에 할당해줄 섹터들과 이를 관리하기 위한 메타(meta)데이터로 이루어져 있다. 메타데이터들이 저장된 페이지를 볼륨의 시스템 페이지(System Page)라고 하며, 볼륨에 대한 정보와 각 섹터들의 예약 여부를 담고 있다. 시스템 페이지는 다음과 같이 두가지로 분류할 수 있다.

볼륨 헤더 페이지 (Volume Header Page, 이하 헤더 페이지): 페이지 크기, 볼륨 내 섹터의 전체/최대 섹터, 볼륨 이름 등, 볼륨에 대한 정보를 지니고 있는 페이지
섹터 테이블 페이지 (Sector Table Page, 이하 STAB 페이지): 볼륨 내의 각 섹터의 예약여부를 비트맵으로 들고 있는 페이지

이러한 시스템페이지들은 볼륨이 생성될 때 미리 볼륨 내의 정해진 공간에 쓰이고, 이 페이지들이 포함된 섹터를 제외한 나머지 섹터들이 파일 매니저로부터의 섹터 예약요청을 처리하기 위해 사용된다. 볼륨 헤더는 볼륨의 첫 번째 페이지에 할당되고, STAB 페이지는 헤더 페이지의 바로 다음 페이지부터 볼륨의 크기를 모두 커버할 수 있는 만큼의 양이 연속적으로 할당된다(disk_stab_init()). 이를 도식화하면 다음과 같다.

첫 섹터가 시스템 페이지들을 위해 할당된 모습을 볼 수 있다. 시스템 페이지들의 수가 한 섹터를 못 채울 경우 그림처럼 시스템페이지들을 위해 할당된 섹터 내의 페이지들이 일부 사용되지 않을 수 있고, 볼륨에 크기가 커지면 이에 따라 시스템페이지들을 위한 섹터가 둘 이상 할당될 수도 있다.

볼륨 헤더 (Volume Header)

볼륨 헤더(DISK_VOLUME_HEADER)는 볼륨의 첫 번째 페이지에 쓰이며, 기본적으로 볼륨에 대한 정보들이 고정 크기로 들어가고 나머지 공간에는 가변길이 변수들이 들어간다. 볼륨 헤더가 담고 있는 정보는 크게 5가지 정도로 분류할 수 있다.

- 볼륨 정보: 볼륨 자체에 대한 정보로 볼륨 전체에 공통으로 적용되는 정보이다. 볼륨의 타입, 캐릭터 셋(set), 생성 시간, 섹터당 페이지 수, 페이지의 크기 등이 저장된다.

- 섹터 정보: 볼륨의 현재 섹터의 정보이다. 볼륨 내에 몇 개의 섹터가 있는지, 얼마나 확장될 수 있는지 등이 저장된다.

- 시스템페이지 정보: 앞서 이야기한 시스템페이지에 대한 정보들이 저장된다.

- 체크포인트 정보: 마지막으로 체크포인트가 성공 시 체크포인트의 시작 지점의 로그 레코드 LSA 정보가 저장된다. 이는 리커버리과정에서 사용된다.

- 가변길이 변수: 볼륨 헤더 페이지 내에서 볼륨 헤더의 모든 고정변수를 제외한 나머지 공간은 가변길이 변수들을 위한 공간이다. 볼륨의 full path나 사용자 정의 comment 등이 저장된다.

- 기타: reserved 등 동작과 무관한 특수목적 변수들이 저장된다.

구체적으로 볼륨 헤더 구조체(DISK_VOLUME_HEADER)가 담고 있는 정보(변수)들은 다음과 같다.

분류	변수 타입	변수명	설명
볼륨	INT8	db_charset	데이터베이스의 캐릭터 셋
	INT16	volid	해당 볼륨의 볼륨 식별자
	DB_VOLTYPE	type	볼륨의 타입, 볼륨이 어떻게 관리될지를 결정 Permanent: 영구적으로 볼륨유지 Temporary: 서버 종료/재시작시 제거. 임시데이터를 저장하는데 기존 볼륨의 공간이 부족할 경우 생성된다.
	DB_VOLPURPOSE	purpose	볼륨의 이용목적, 볼륨을 어떻게 사용할지를 결정 Permanent: 영구적인 데이터를 저장할 것. Temporary: 임시적인 데이터를 저장할 것. 임시데이터를 저장할 때에 임시타입의 볼륨을 만들기전에 임시목적의 영구타입볼륨이 있을 경우 먼저 사용한다.
	INT64	db_creation	데이터베이스 생성시간
	INT16	next_volid	여러 볼륨이 있을 경우 그들을 연결하는 포인터, 다음 볼륨의 식별자를 담음
	DKNPAGES	sect_npgs	한 섹터당 페이지 수
	INT16	iopagesize	한 페이지의 크기
	HFID	boot_hfid	볼륨 부팅과 멀티 볼륨관련된 정보를 담고있는 힙(Heap)파일의 식별자
섹터	DKNPAGES	nsect_total	볼륨의 현재 총 섹터 수, 볼륨파일의 크기를 결정
	DKNPAGES	nsect_max	볼륨이 확장될 수 있는 최대 크기의 섹터 수
	SECTID	hint_allocsect	섹터예약시 섹터테이블의 어디부터 탐색할지 캐싱해둔 값
시스템 페이지	DKNPAGES	stab_npages	섹터테이블이 차지하는 페이지 수
	PAGEID	stab_first_page	섹터테이블의 시작페이지
	PAGEID	sys_lastpage	마지막 시스템 페이지 (현재 stab_first_page+stab_npages -1)
체크포인트	LOG_LSA	chkpt_lsa	체크포인트 시작점의 LSA, 리커버리분석의 시작점 (ARIES의 master record)
가변길이 변수	char [1]	var_fields	가변길이 변수들의 시작점, var_fileds + offsetto* 가 각 가변변수의 위치
	INT16	offset_to_vol_fullname	볼륨의 절대경로 이름의 offset
	INT16	offset_to_next_vol_fullname	next_volid 볼륨의 절대경로 이름의 offset
	INT16	offset_to_vol_remarks	볼륨에 대한 코멘트의 offset 코멘트는 볼륨포맷(disk_format())시에 적히는 것으로 유저가 addvoldb를 실행하면서 적는 코멘트나 볼륨의 공간이 가득차 자동으로 새로운 볼륨을 만들어질 경우 적히는 코멘트("Automatic Volume Extension") 등이 들어간다.
기타	INT32	reserved0/1/2/3	미래 확장성을 위한 예약변수들
	INT8/32	dummy1/2	alignment를 위한 더미변수들
	char []	magic	볼륨파일의 매직넘버

* 각 변수에 대한 설명을 달아두었긴 했지만, 명확한 이해를 위해서는 각 변수의 값이 언제 설정되고, 어떻게 사용되는지 등을 알아야 한다. 이에 대한 자세한 내용은 각 변수가 이용되는 부분을 설명할 때 다시 살펴보도록 한다.

섹터 테이블 (Sector Table)

섹터 테이블(STAB)은 볼륨 내 모든 섹터들의 사용 여부(예약 여부)를 저장하고 있는 비트맵이다. 섹터 테이블 페이지의 하나의 비트는 하나의 섹터의 예약 여부를 나타낸다. 섹터 테이블은 볼륨 헤더 페이지의 바로 다음 페이지(볼륨의 두번째 페이지, stab_first_page)부터 시작하여 볼륨의 최대 크기(nsect_max)를 커버할 수 있는 만큼의 페이지(stab_npages)를 사용한다. 섹터예약에 관한 연산을 수행할 때, 각 비트를 하나씩 순회하며 연산을 수행할 수도 있지만 큐브리드는 비트들을 DISK_STAB_UNIT (이하 unit, 유닛)이라는 단위로 묶어 관리, 연산하고 불가피할 경우에만 비트를 순회한다. 비트연산을 할 때에 CPU 아키텍쳐등을 고려하여 효율적인 방법으로 처리 할 수 있도록 이러한 처리단위를 제공한다. 정리하자면 섹터 테이블의 비트맵은 여러페이지로 구성되며 각 페이지는 다시 유닛으로 나뉘고, 유닛의 비트들은 각각의 하나의 섹터의 예약 여부를 나타낸다. 섹터 테이블을 읽거나 조작하는 등의 연산은 모두 이 유닛을 기반으로 이루어진다.

* 현재 유닛은 다음과 같이 UINT64형이다. CPU아키텍처나 디자인에 맞춰 이 값을 변경시키면 STAB의 관리 단위를 변경 시킬 수 있다. 주석 또한 이 값의 변경을 통해 유닛단위를 쉽게 변경할 수 있을 것이라 이야기하고 있다.

만약 sector_id가 32100인 섹터에 대한 예약여부를 확인하려할 때, STAB에서 해당 비트의 위치는 어떻게 구할 수 있을까? 이는 마치 초에서 (시,분,초)를 구하듯 (page_id, offset_to_unit, offset_to_bit) 으로 다음과 같이 계산된다.

page_id: (볼륨헤더의 stab_first_page) + sector_id / (페이지의 비트 수)
offset_to_unit: sector_id % (페이지의 비트 수) / (페이지내 유닛의 수)
offset_to_bit: sector_id % (페이지의 비트 수) % (페이지내 유닛의 수)

만약 1KB 페이지, 64bit unit이라면 sector_id 32100인 (3, 117, 36)이 된다. 안타깝게도 페이지의 크기가 2^n형태가 아니기 때문에 OS의 페이지 테이블이나 CPU 캐시처럼 단순 비트 쉬프트연산으로 유닛과 오프셋등을 구할 수 없다. 때문에 비싼 /, % 연산이 사용된다.

* IO 페이지의 크기는 4KB, 16KB 등 2^n형태이더라도 모든 페이지가 공통적으로 페이지타입, LOG_LSA 등의 공간을 이미 예약해두었기 때문에 실제 사용가능한 크기는 이 영역을 제외한 크기이다.

섹터 테이블의 연산

섹터의 예약정보를 조회하거나 예약하려면 섹터테이블의 비트맵을 조작해야한다. 이러한 연산들은 앞서 말한 유닛 단위를 기반으로 이루어지며, 하나의 섹터 비트나 유닛을 참조할 일 보다는 여러 유닛들을 참조하는 경우가 대부분이기 때문에 커서(Cursor, DISK_STAB_CURSOR)와 이터레이션 인터페이스(disk_stab_iterate_units())를 제공한다. 커서는 볼륨 내 한 섹터의 STAB에서의 위치(page_id, offset_to_unit, offset_to_bit)를 가리킨다. 또, 커서가 가리키는 유닛에 대한 연산을 위해 커서가 가리키고 있는 유닛의 포인터(page, unit)를 들고 있다.

typedef struct disk_stab_cursor DISK_STAB_CURSOR;                 
struct disk_stab_cursor
{
    const DISK_VOLUME_HEADER *volheader;    /* Volume header */

    PAGEID pageid;      /* Current page ID */
    int offset_to_unit;     /* Offset to current unit in page. */
    int offset_to_bit;      /* Offset to current bit in unit. */

    SECTID sectid;      /* Sector ID */     

        // 위의 변수들은 모두 현재 커서가 가리키는 섹터에 대한 정보와 STAB내에서 섹터의 위치
        // 아래의 변수들은 위의 변수들이 가리키는 STAB내의 유닛을 참조하기 위한 포인터

    PAGE_PTR page;      /* Fixed table page. */                   
    DISK_STAB_UNIT *unit;       /* Unit pointer in current page. */
};

이터레이션 함수인 disk_stab_iterate_units() 의 선언부는 다음과 같다. (설명에 필요하지 않은 인자들은 제외하였다.)

static int disk_stab_iterate_units (..., DISK_STAB_CURSOR * start, DISK_STAB_CURSOR * end, DISK_STAB_UNIT_FUNC f_unit, void *f_unit_args)

앞서 이야기한 커서 자료형의 start, end와 이터레이션하면서 유닛에 적용할 함수(DISK_STAB_UNIT_FUNC)와 함수의 인자를 매개변수로 받는 것을 볼 수있다. 이 함수는 [start, end) 범위의 유닛을 순회하면서 각 유닛마다 DISK_STAB_UNIT_FUNC함수를 적용 시킨다. 여타 프로그래밍언어에 있는 map() 함수를 생각하면 이해가 쉽다. start, end 커서는 disk_stab_cursor_setat\()) 류의 함수를 통해 STAB의 시작이나 끝, 특정 sector ID로 설정된다. DISK_STAB_UNIT_FUNC* 는 함수포인터로 다음과 같다.

typedef int (*DISK_STAB_UNIT_FUNC) (..., DISK_STAB_CURSOR * cursor, bool * stop, void *args);

disk_stab_iterate_units()에서 이터레이션되어 만나는 각 유닛에 대한 커서를 인자로 받아 사용자가 정의한 작업을 진행한다. 이 때 stop에 true를 넣고 함수를 종료하면, disk_stab_iterate_units() 의 이터레이션이 종료된다. 예를 들어 30개의 섹터를 예약하려 할 때, 이번 유닛에서 30개의 섹터 예약을 모두 완료했다면 더 이상의 작업을 중지하는 종료 조건으로 활용할 수 있다. 이러한 유닛 이터레이션을 통한 연산에는 섹터들 예약, 섹터들 예약 해제, 가용 섹터들의 갯수 확인 등이 있다. 좀 더 확실한 이해를 위해 가용 섹터들의 갯수확인에 사용되는 DISK_STAB_UNIT_FUNC 는 disk_stab_count_free() 와 이에 대한 호출부를 살펴보자.

// free sector의 갯수를 구하는 함수 정의
static int disk_stab_count_free (THREAD_ENTRY * thread_p, DISK_STAB_CURSOR * cursor, bool * stop, void *args)
{   
    DKNSECTS *nfreep = (DKNSECTS *) args;

    /* add zero bit count to free sectors total count */
    *nfreep += bit64_count_zeros (*cursor->unit);
    return NO_ERROR;
}

// 함수 호출부
int disk_rv_volhead_extend_redo (THREAD_ENTRY * thread_p, LOG_RCV * rcv)
{
      ...
      disk_stab_cursor_set_at_sectid (volheader, volheader->nsect_total - nsect_extend, &start_cursor); 
      disk_stab_cursor_set_at_end (volheader, &end_cursor);
        error_code = disk_stab_iterate_units (thread_p, volheader, PGBUF_LATCH_READ, &start_cursor, &end_cursor, disk_stab_count_free, &nfree);
      ...
    disk_cache_update_vol_free (volheader->volid, nfree);
      ...
}

호출부의 예는 recovery의 redo phase에 사용되는 함수중 하나인 disk_rv_volhead_extend_redo() 로, 실제로 확장된 볼륨 내의 free setor의 갯수를 디스크 캐시에 업데이트하기 위한 코드이다. 확장하기 전의 위치(volheader->nsect_total - nsect_extend)에 start커서를 두고, stab의 끝에 end커서를를 두고 disk_stab_iterate_units()함수를 호출하여 [start, end)를 순회하며 모든 유닛들에서 0인 비트들의 갯수를 구하는 것을 볼 수 있다.

* 이러한 이터레이션 방식은 파일매니저와 디스크매니저의 여러 곳에서 사용된다. 대표적으로 나중에 살펴볼 파일 매니저의 파일 테이블과 유저 테이블 등에서도 이러한 패턴으로 데이터를 접근, 조작한다.

이어서 다룰 디스크 매니저 내용은 다음과 같다.

- 섹터 예약 및 예약 해제

- 볼륨 확장

JPA와 CUBRID 연동 가이드

김동민 — Wed, 22 Feb 2023 16:21:31 +0900

JPA?

JPA는 자바의 ORM 기술 표준으로 인터페이스의 모음입니다.
표준 명세를 구현한 구현체들(Hibernate, EclipseLink, DataNucleus)이 있고, JPA 표준에 맞춰 만들면 사용자는 언제든 원하는 구현체를 변경하며 ORM 기술을 사용할 수 있습니다.

이번 CUBRID 연동 가이드에서는 대표적으로 많이 사용하는 Hibernate를 사용하여 작성했습니다.

버전 정보

SpringBoot: 2.7.8

Hibernate: 5.6.14.Final

Java: 11
CUBRID: 11.0.10, 11.2.2

JPA와 CUBRID 연동

1) 라이브러리 설정

Maven 프로젝트에 JPA(Hibernate), CUBRID JDBC 라이브러리를 넣기 위해 pom.xml에 설정을 합니다.

CUBRID JDBC를 받기 위해 repository도 같이 추가해야 합니다.

2) JPA 설정

필요한 라이브러리를 다 받은 뒤 JPA 설정 파일인 persistence.xml에 설정을 해줘야 합니다. 해당 파일은 표준 위치가 정해져 있기 때문에 /resources/META-INF/ 밑에 위치해야 합니다.

DBMS 연결 시 필요한 정보와 JPA 옵션들을 설정해 줍니다.

기본적으로 driver, url, user, password를 설정하고, 방언(dialect)도 필수적으로 설정해야 합니다.

DBMS가 제공하는 SQL 문법과 함수들이 조금씩 다르기 때문에 JPA가 어떤 DBMS의 방언(dialect)를 사용해야 할지 알아야 하기 때문입니다.

추가적으로 필수 설정은 아니지만, SQL 출력과 관련된 옵션들을 추가했습니다.

- show_sql: Hibernate가 만든 모든 SQL을 콘솔에 보여준다.

- format_sql: 로그와 콘솔에 SQL을 보기 편하게 포맷해서 보여준다.

- use_sql_comments: SQL 내부에 주석을 생성하여 보여준다.

그 외 옵션들은 hibernate user guide를 통해 확인할 수 있습니다.

3) 테이블 스키마

demodb의 olympic 테이블을 사용합니다.

=== ===

olympic

host_year INTEGER NOT NULL

host_nation CHARACTER VARYING(40) NOT NULL

host_city CHARACTER VARYING(20) NOT NULL

opening_date DATE NOT NULL

closing_date DATE NOT NULL

mascot CHARACTER VARYING(20)

slogan CHARACTER VARYING(40)

introduction CHARACTER VARYING(1500)

PRIMARY KEY pk_olympic_host_year ON olympic (host_year)

4) 엔티티 클래스 생성

olympic 테이블의 컬럼들과 동일하게 olympic 엔티티 클래스를 하나 생성합니다.

5) 데이터 입력, 조회 테스트

간단한 코드를 통해 생성되는 SQL을 확인해 보겠습니다.

Insert code

Insert SQL

Select code

Select SQL

Select result

CUBRID 11.2 버전 이상을 사용하는 경우

CUBRID 11.2 버전부터 user schema가 추가 되었습니다. (CUBRID11.2 릴리즈)

11.2 버전 이상을 사용하는 경우 추가로 JPA 설정을 2가지 더 해야합니다.

1) 테이블명 어노테이션 설정

엔티티에 유저 스키마 + "." + 테이블명으로 설정

@Table(name="[schema_name].[table_name]")

2) persistence.xml에 설정 추가

테이블명의 "."을 Hibernate가 자동으로 "_"로 변환시키기 때문에 "."을 그대로 사용하기 위해 파라미터 설정

SpringBoot, JPA 와 CUBRID 연동

SpringBoot를 이용하면 더 간단하게 JPA와 CUBRID를 연동할 수 있습니다.

이번에는 gradle과 yml로 CUBRID 11.2 버전으로 설정해 보겠습니다.

build.gradle

application.yml

olympic 엔티티

repository 생성

JpaRepository를 상속 받은 OlympicRepository 인터페이스를 만듭니다.

데이터 조회 테스트

dblink를 이용한 remote-server materialized view 기능

bwkim — Mon, 20 Feb 2023 15:49:11 +0900

Materialized View

Materialized View(이하 MView) 이것은 말 그대로 View의 일종으로 일반 View는 논리적인 스키마인데 반해, MView는 물리적 스키마입니다. 논리적 스키마는 실제 데이터가 데이터베이스에 저장되어 있지 않고 데이터를 가져오기 위한 SQL질의만 저장되어 있다라는 것이고, 물리적 스키마 혹은 테이블이라는 것은 셀제 데이터가 데이터베이스에 저장되어 있다라는 것입니다.

MView는 필요한 결과를 가져오는 질의가 빈번하게 자주 사용 될 경우, 질의 실행 시간 속도 향상을 위해 데이터베이스 테이블을 만들어 저장해 두는 것으로 실행 비용이 많이 드는 조인이나, Aggregate Function을 미리 처리하여 필요할 때 테이블을 조회 하도록 하는 것 입니다. 예를 들면 대용량의 데이터를 COUNT, SUM, MIN, MAX, AVG 처럼 자주 사용되는 Aggregate Function 실행 속도를 향상을 위해서, 질의 실행 결과을 데이터베이스 테이블로 생성해 두는 벙법입니다. 즉, 자주사용되는 View의 결과를 데이터베이스에 저장해서 질의 실행 속도를 향상시키는 개념입니다.

이번 글에서는 일반적인 MView와 더불어 현재 작업 중인 데이터베이스 로컬 서버가 아닌 원격지(remote) 데이터베이스 서버의 테이블을 로컬 서버로 연결하는 것에 대한 내용으로, 일반적인 MView의 필요성에 더해 원격지 데이터를 가져오기 위한 효율성까지도 고려한 것으로 CUBRID에서는 아직 지원하지 않는 MView를 우회적으로 적용할 수 있는 팁이라고 할 수 있습니다.

MView의 특징

MView를 만들어 둠으로써 질의 실행 시간을 줄일 수 있습니다.
응용프로그램에서 MView 사용 시 DBA는 응용에 영향을 주지 않고 생성하거나 수정/제거할 수 있습니다.
MView는 대신 질의 실행 결과가 모두 저장되기 때문에, MView에 해당하는 테이블 만틈 공간을 차지하게 됩니다.
특히, 원격지 테이블의 경우 로컬 테이블에서 데이터를 가져오는 것보다 수 배의 시간이 소요될 수 있는데, 이를 로컬에 MView 테이블로 유지함으로써 성능을 최대한으로 끌어올릴 수 있습니다.

Oracle과 MView

MView 또는 스냅샷이라고 하며, 로컬 또는 원격 테이블에 대한 질의를 기반으로 내용이 주기적으로 새로 고쳐지는 테이블 세그먼트입니다.

기본 문법은 아래와 같습니다.

-- Pre-Built
CREATE MATERIALIZED VIEW view-name
ON PREBUILT TABLE
REFRESH [FAST | COMPLETE | FORCE ]
ON [COMMIT | DEMAND ]
[[ENABLE | DISABLE] QUERY REWRITE]
AS
SELECT ...;

문법을 잘 보면 MView가 어떻게 생성되고, 어떻게 동기화를 하는지에 대해 알 수 있습니다. 좀더 자세한 내용은 오라클 메뉴얼을 참조하시기 바랍니다. 동기화는 REFRESH와 ON절을 통해 연결된 테이블이 COMMIT될 때 혹은 요청이 올 때마다로 각각 동작이 됩니다.

CUBRID와 MView

CUBRID는 아직 MView를 지원하지 않습니다. 그래서 MView와 유사한 효과를 만들기 위해서는 TRIGGER를 사용할 수 있습니다. 예를 들면 아래와 같이 update_logs라는 테이블에 데이터를 INSERT하는 것입니다.

CREATE TABLE update_logs(event_code INTEGER, score VARCHAR(10), dt DATETIME);

  CREATE TRIGGER example
  BEFORE UPDATE ON history(score)
  EXECUTE INSERT INTO update_logs VALUES (obj.event_code, obj.score, SYSDATETIME);

로컬 서버의 데이터만 대상으로 하는 MView는 위와 같이 TRIGGER를 정의해서 테이블에 데이터를 INSERT하거나 UPDATE/DELETE할 수 있는데, 원격지 서버의 경우엔 아래와 같이 dblink를 활용할 수 있습니다.

CREATE TABLE remote_logs(event_code INTEGER, score VARCHAR(10), dt DATETIME);

CREATE SERVER remote_srv1 (
HOST='192.168.2.194',
PORT=33000,
DBNAME=demodb,
USER=dba,
PASSWORD=''
);

CREATE TABLE mview_trig(upd datetime);

CREATE TRIGGER remote_exam
BEFORE UPDATE ON mview_trig(upd)
EXECUTE INSERT INTO remote_logs
SELECT a, b, c
FROM dblink(remote_srv1, 'SELECT event_code, score, dt FROM history WHERE ...')
t(a INTEGER, b VARCHAR(10), c DATETIME);

위의 예는 remote_logs라는 일종의 MView 역할을 하는 테이블에 원격지 history 테이블의 데이터를 INSERT하는 과정으로 정리할 수 있습니다. 트리거를 정의할 때, 원격지 테이블에서 가져올 수 있는 질의문은 조인이 포함된 복잡한 질의일 수도 있고, SUM이나 COUNT와 같이 Aggreate Function이 포함될 수도 있습니다.

DBeaver 환경을 새로운PC에 간편하게 복원하기

HiCLASS — Mon, 26 Dec 2022 15:05:24 +0900

현재 Java로 구현된 데이터베이스 관리 툴 중에 가장 인기가 있는 툴이 DBeaver가 아닌가 생각된다.

DBeaver 툴은 CUBRID 또한 지원을 해서 SQL Query browser의 기능을 충분히 수행한다.

※ DBeaver 특징

□ Community Edition 버전을 사용하면 라이센스(Apache License)가 무료이다.

□ 자바/이클립스 기반으로 개발되어서 윈도우, 리눅스, MAC에서 구동된다.

□ JDBC 기반으로 해서 DB를 지원한다. (CUBRID, ORACLE, SQL Server, MySQL, Postgresql ... )

□ 개발소스가 공개되어서 버그픽스가 가능하고 새로운 기능을 개발하여 사용이 가능하다.

□ 릴리즈도 거의 2주마다 되기 때문에 버그 픽스또한 매우 빠른 편이다.

CURBID를 DBeaver에서 사용하는 방법은 "DBeaver Database Tool 큐브리드 사용하기" 를 참조 하면 도움이 될 것이다.

필자는 해당 툴을 사용하다가 사용하는 PC를 바꾸게 되어 기존 설정을 백업해서 복구 하고자 한다.
Workspace를 따로 빼서 사용하지 않은 기본 설정으로 사용하신 분을 기준으로 백업/복구를 가이드 하고자 한다.

순서는 다음과 같다.

1. 먼저 백업하고자 하는 기존의 환경에서 탐색기 창을 연다.

2. 주소/디렉터리 위치 표기창에 %appdata% 를 입력한다.
(C:\Users\사용자명\AppData\Roaming 디렉터리 인지 확인 한다.)

3. DBeaverData 디렉터리를 통채로 백업을 받는다.

4. 새로운 환경에서 동일하게 %appdata% 로 이동하여 백업 받았던 디렉터리를 복사해 넣는다.

5. DBeaver를 실행한다.

6. 환경설정 창으로 이동한다. Drivers location을 새로운 %appdata%(C:\Users\유저명\AppData\Roaming)로 변경한다.

7. 잘 사용한다.

CUBRID Flashback

김주호 — Tue, 25 Oct 2022 15:40:44 +0900

Introduction

큐브리드 11.2 버전이 릴리즈되면서 Flashback 기능도 함께 소개되었습니다. 아래에서는 큐브리드에서 제공하는 Flashback 에 대한 기능을 이해하기 위한 Background와 흐름, 그리고 사용방법에 대해 소개해드리겠습니다.

Background

Supplemental logging

사용자가 트랜잭션을 수행하면 트랜잭션 로그가 기록됩니다. 트랜잭션 로그에는 사용자가 변경하기 전의 데이터 (UNDO)와 사용자가 변경한 후의 데이터 (REDO)가 저장됩니다. Flashback에서는 별도의 전용 데이터 공간을 만들기 보다는 이미 로그 볼륨에 저장된 트랜잭션 로그를 사용합니다. 트랜잭션 로그의 UNDO와 REDO를 이용해 사용자가 수행한 SQL구문을 추측합니다. 하지만 트랜잭션 로그에는 데이터베이스의 물리적인 변경에 대한 데이터만을 가지고 있기 때문에, 논리적인 단위 (SQL 구문)으로 반환해야하는 Flashback을 위해서는 추가적인 데이터가 필요합니다. 추가적인 데이터에는 트랜잭션을 수행한 사용자 정보 등이 있으며, 해당 정보는 Supplemental log를 통해 저장됩니다. 따라서, Flashback을 수행하기 위해서는 ‘supplemental_log’ 시스템 파라미터를 1 또는 2로 설정해줘야 합니다.

CUBRID Flashback

Overview

사용자가 실수로 테이블내의 모든 데이터를 삭제하고 commit을 했다고 가정해봅시다. 사용자는 우선 백업된 데이터가 있는지 찾아볼 것이고, 없다면 기억을 더듬어서 하나씩 데이터를 삽입할 것입니다. 이런 경우를 대비해서 큐브리드는 Flashback 기능을 제공하게 되었습니다. Flashback 기능은 아래 5단계를 거쳐 제공되며, 각 단계에 대한 설명은 다음과 같습니다.

1. 요청

- 특정 테이블(user.tbl)에 대하여 flashback을 요청합니다.

2. 정보 생성

- CUB_SERVER는 요청받은 테이블에 가해진 변경사항을 알기 위해 트랜잭션 로그들을 순회합니다.

- 트랜잭션 로그를 순회하며, 테이블에 수행된 트랜잭션들을 찾고 각 트랜잭션 내에서 몇개의 행이 삽입/갱신/삭제 되었는지 정보를 수집합니다.

3. 요약 정보 반환

- 테이블에 수행된 트랜잭션 요약 정보를 사용자에게 보여줍니다.

- 요약 정보에는 트랜잭션을 수행한 사용자, 트랜잭션 시작 시간, 트랜잭션 종료 시간, 트랜잭션 내에서 삽입/갱신/삭제 된 행의 수 등이 표시됩니다.

4. 트랜잭션 식별자 전달

- 사용자는 요약 정보를 보고 되돌리고 싶은 트랜잭션을 선택하여 CUB_SERVER에 전달합니다.

5. SQL 구문 반환

- CUB_SERVER에서는 트랜잭션 로그와 supplemental log를 이용해, 선택된 트랜잭션을 되돌릴 수 있도록 SQL구문을 작성합니다.

- 작성된 SQL 구문을 사용자에게 시간 역순으로 반환합니다.

- 역순으로 반환된 SQL구문을 수행하면, 해당 트랜잭션을 수행하기 이전으로 데이터를 되돌릴 수 있습니다.

How to use

1. Supplemental log 설정

- $CUBRID/conf/cubrid.conf에 아래와 같이 supplemental_log 시스템 파라미터를 설정합니다.

- supplemental_log 설정 이후에 수행된 트랜잭션에 대해서만 flashback을 수행할 수 있습니다.

- supplemental_log 의 값은 1 또는 2로 설정하면 되며, 설정 값의 차이 (1 또는 2)는 flashback 기능에는 영향을 끼치지 않습니다.

cubrid.conf

...

supplemental_log=1 또는 supplemental_log=2

...

2. flashback 수행

2.1 기본 수행

데이터베이스 명과 테이블 명을 입력하면 최근 10분동안 해당 테이블에 수행된 트랜잭션에 대한 정보를 보여줍니다. 명령어는 아래와 같이 수행하면 됩니다.
요약 정보에서 출력되는 컬럼 정보는 메뉴얼¶을 참고하면 됩니다.

$ echo "supplemental_log=1" >> $CUBRID/conf/cubrid.conf
$ cubrid server start demodb
$ csql -u dba demodb -c "create table tbl (a int)"
$ csql -u dba demodb -c "insert into tbl values (10);"

$ cubrid flashback demodb dba.tbl
Flashback Summary
Number of Transaction: 1
Start date - End date: 25-10-2022:14:17:24 - 25-10-2022:14:18:03
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
14 DBA 25-10-2022:14:17:49 25-10-2022:14:17:50 1 0 0 dba.tbl
Enter transaction id (press -1 to quit): 14

delete from [dba.tbl] where [a] = 10 limit 1;

2.2 필터링 적용

2.2.1 시간 범위
트랜잭션 시작 시간 (start-date), 트랜잭션 종료 시간 (end-date) 옵션으로 시간 범위를 정할 수 있습니다. 사용자가 되돌리고 싶은 트랜잭션이 어느 시간대에 수행되었는지 특정할 수 있는 경우 사용합니다.

시간 범위 사이에서 commit된 트랜잭션에 대해서만 Flashback 기능을 제공합니다. 위 그림에서는 Transaction 1과 Transaction 2가 Flashback 대상이 될 수 있습니다. 하지만 Transaction 1의 경우에는 start-date 이전에 수행된 DML에 대해서는 트랜잭션 로그를 지우지 않을 것이라고 보장하지 않기 때문에, Flashback이 불가능할 수도 있습니다.

2.2.1.1. 옵션 설정

- 트랜잭션 시작 시간 및 종료 시간 설정하지 않은 경우 : (현재 - 10분) ~ 현재 사이에 커밋된 트랜잭션들에 대해서 정보를 추출합니다.

- 트랜잭션 시작 시간만 설정 : (start-date) ~ (start-date + 10분) 사이에 커밋된 트랜잭션들에 대해서 정보를 추출합니다.

- 트랜잭션 종료 시간만 설정 : (end-date - 10분) ~ (end-date) 사이에 커밋된 트랜잭션들에 대해서 정보를 추출합니다.

- 트랜잭션 시작 시간 및 종료 시간 설정 : (start-date) ~ (end-date) 사이에 커밋된 트랜잭션들에 대해서 정보를 추출합니다.

2.2.1.2. 사용 예시

- 트랜잭션 시작 시간 설정 (start-date)

$ cubrid flashback demodb dba.tbl
Flashback Summary
Number of Transaction: 2
Start date - End date: 25-10-2022:14:36:01 - 25-10-2022:14:46:01
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
17 DBA 25-10-2022:14:45:01 25-10-2022:14:45:19 2 0 2 dba.tbl
18 DBA 25-10-2022:14:45:36 25-10-2022:14:45:50 0 1 1 dba.tbl
Enter transaction id (press -1 to quit): -1

// start-date를 트랜잭션 18의 Start time으로 설정
$ cubrid flashback demodb dba.tbl --start-date 25-10-2022:14:45:36
Flashback Summary
Number of Transaction: 1
Start date - End date: 25-10-2022:14:45:36 - 25-10-2022:14:46:22
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
18 DBA 25-10-2022:14:45:36 25-10-2022:14:45:50 0 1 1 dba.tbl
Enter transaction id (press -1 to quit): -1

- 트랜잭션 종료 시간 설정 (end-date)

// end-date를 트랜잭션 17의 End time으로 설정
$ cubrid flashback demodb dba.tbl --end-date 25-10-2022:14:45:20
Flashback Summary
Number of Transaction: 1
Start date - End date: 25-10-2022:14:35:20 - 25-10-2022:14:45:20
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
17 DBA 25-10-2022:14:45:01 25-10-2022:14:45:19 2 0 2 dba.tbl
Enter transaction id (press -1 to quit): -1

- 트랜잭션 시작 시간 및 종료 시간 설정 (start-date, end-date)

// start-date를 트랜잭션 17의 Start time으로 설정하고, end-date를 트랜잭션 18의 End time으로 설정
$ cubrid flashback demodb dba.tbl --start-date 25-10-2022:14:45:01 --end-date 25-10-2022:14:45:50
Flashback Summary
Number of Transaction: 2
Start date - End date: 25-10-2022:14:45:01 - 25-10-2022:14:45:50
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
17 DBA 25-10-2022:14:45:01 25-10-2022:14:45:19 2 0 2 dba.tbl
18 DBA 25-10-2022:14:45:36 25-10-2022:14:45:50 0 1 1 dba.tbl
Enter transaction id (press -1 to quit): -1

2.2.2 트랜잭션 사용자 (user)
테이블에 변경을 가한 트랜잭션을 누가 수행했는지 특정하고 싶을 경우 사용합니다.

$ cubrid flashback demodb public.tbl
Flashback Summary
Number of Transaction: 2
Start date - End date: 25-10-2022:14:45:55 - 25-10-2022:14:55:55
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
28 PUBLIC 25-10-2022:14:55:18 25-10-2022:14:55:19 1 0 0 public.tbl
31 DBA 25-10-2022:14:55:46 25-10-2022:14:55:47 0 1 0 public.tbl
Enter transaction id (press -1 to quit): -1

// dba 사용자가 수행한 트랜잭션만 추출

$ cubrid flashback demodb public.tbl --user dba
Flashback Summary
Number of Transaction: 1
Start date - End date: 25-10-2022:14:46:08 - 25-10-2022:14:56:08
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
31 DBA 25-10-2022:14:55:46 25-10-2022:14:55:47 0 1 0 public.tbl
Enter transaction id (press -1 to quit): -1

// public 사용자가 수행한 트랜잭션만 추출

$ cubrid flashback demodb public.tbl --user public
Flashback Summary
Number of Transaction: 1
Start date - End date: 25-10-2022:14:46:12 - 25-10-2022:14:56:12
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
28 PUBLIC 25-10-2022:14:55:18 25-10-2022:14:55:19 1 0 0 public.tbl
Enter transaction id (press -1 to quit): -1

2.3 자세한 내용 확인 (detail)

$ cubrid flashback demodb public.tbl
Flashback Summary
Number of Transaction: 2
Start date - End date: 25-10-2022:14:49:30 - 25-10-2022:14:59:30
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
28 PUBLIC 25-10-2022:14:55:18 25-10-2022:14:55:19 1 0 0 public.tbl
31 DBA 25-10-2022:14:55:46 25-10-2022:14:55:47 0 1 0 public.tbl
Enter transaction id (press -1 to quit): 31

update [public.tbl] set [a] = 10 where [a] = 10 limit 1;

// detail 정보 출력

$ cubrid flashback demodb public.tbl --detail
Flashback Summary
Number of Transaction: 2
Start date - End date: 25-10-2022:14:49:38 - 25-10-2022:14:59:38
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
28 PUBLIC 25-10-2022:14:55:18 25-10-2022:14:55:19 1 0 0 public.tbl
31 DBA 25-10-2022:14:55:46 25-10-2022:14:55:47 0 1 0 public.tbl
Enter transaction id (press -1 to quit): 31

[TRANSACTION ID] 31
[USER] DBA
[ORIGINAL] update [public.tbl] set [a] = 10 where [a] = 10 limit 1;
[FLASHBACK] update [public.tbl] set [a] = 10 where [a] = 10 limit 1;

2.4 출력 순서 변경 (oldest)
사용자가 해당 SQL구문들을 받아와 바로 적용할 수 있도록, 기본적으로 트랜잭션 내에서 수행된 구문들을 시간 역순으로 출력해줍니다. 하지만, 시간 순으로 수행된 구문들이 궁금할 경우 oldest 옵션을 사용하면 아래와 같이 시간 순으로 출력됩니다.

$ cubrid flashback demodb dba.tbl
Flashback Summary
Number of Transaction: 1
Start date - End date: 25-10-2022:14:53:04 - 25-10-2022:15:03:04
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
40 DBA 25-10-2022:15:02:42 25-10-2022:15:03:01 3 0 3 dba.tbl
Enter transaction id (press -1 to quit): 40

insert into [dba.tbl] values (100000000);
insert into [dba.tbl] values (100000);
insert into [dba.tbl] values (1000);
delete from [dba.tbl] where [a] = 100000000 limit 1;
delete from [dba.tbl] where [a] = 100000 limit 1;
delete from [dba.tbl] where [a] = 1000 limit 1;

// 역순으로 출력

$ cubrid flashback demodb dba.tbl --oldest
Flashback Summary
Number of Transaction: 1
Start date - End date: 25-10-2022:14:53:10 - 25-10-2022:15:03:10
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
40 DBA 25-10-2022:15:02:42 25-10-2022:15:03:01 3 0 3 dba.tbl
Enter transaction id (press -1 to quit): 40

delete from [dba.tbl] where [a] = 1000 limit 1;
delete from [dba.tbl] where [a] = 100000 limit 1;
delete from [dba.tbl] where [a] = 100000000 limit 1;
insert into [dba.tbl] values (1000);
insert into [dba.tbl] values (100000);
insert into [dba.tbl] values (100000000);

3. 예외 상황

3.1 요약 정보를 받고, 트랜잭션 식별자를 선택할 때 일정 시간을 초과한 경우에는 에러를 반환합니다.

cubrid.conf 에서 flashback_timeout 값을 통해 설정할 수 있습니다. 0초 부터 3600초 사이로 설정 가능합니다. 기본값은 300초입니다.

$ cubrid flashback demodb dba.tbl -s 25-10-2022:15:02:42
Flashback Summary
Number of Transaction: 1
Start date - End date: 25-10-2022:15:02:42 - 25-10-2022:15:12:42
Transaction id User name Start time End time Num_insert Num_update Num_delete Table
40 DBA 25-10-2022:15:02:42 25-10-2022:15:03:01 3 0 3 dba.tbl
Enter transaction id (press -1 to quit): Transaction ID should be entered in 300 seconds. The timeout can be adjusted through the 'flashback_timeout' setting in 'cubrid.conf'

3.2 시스템 클래스¶에 대해서는 추출할 수 없습니다.

$ cubrid flashback demodb _db_class
The system catalog class (_db_class) is not supported in flashback.

3.3 owner_name.class_name 형식을 지켜서, Flashback 대상 테이블 명을 입력해야합니다.

$ cubrid flashback demodb tbl
Invalid format for owner_name.class_name ('tbl').

3.4 현재 DB에 존재하지 않는 테이블에 대해서는 추출할 수 없습니다. (Drop된 테이블)

$ csql -u dba demodb -c "drop table tbl2"

// 테이블 DROP 후 flashback 수행

$ cubrid flashback demodb dba.tbl2
Table (dba.tbl2) does not exist in database

3.5 로그가 기록된 시점 (과거)의 스키마와 Flashback을 수행하는 시점의 스키마가 다를 경우, 해당 테이블에 대해 flashback할 수 없습니다.

$ csql -u dba demodb -c "alter tbl add column col2 char"

// 스키마 변경 후 Flashback 수행

Unable to get flashback because schema (dba.tbl) has been changed.

Restriction

1. CS 모드만 지원합니다.

2. 동일한 데이터베이스에 대해 동시에 두 개 이상의 Flashback을 수행할 수 없습니다.

3. DDL은 지원하지 않습니다.

CUBRID to MySQL DBLink

smnam — Tue, 25 Oct 2022 13:30:50 +0900

CUBRID DBLink 란

데이터베이스에서 정보를 조회하다 보면 종종 외부 데이터베이스의 정보 조회가 필요한 경우가 있습니다. 이렇게 외부 데이터베이스의 정보를 조회하기 위해서 CUBRID DBLink를 이용하면 CUBRID, Oracle, MySQL의 데이터베이스의 정보를 조회할 수 있도록 기능을 제공하며, 타 데이터베이스의 정보를 마치 하나의 데이터베이스에서 조회하는 것과 같은 효과를 발휘합니다.

이 글에서는 CUBRID DBLink와 MySQL의 데이터베이스의 정보를 조회하는 방법을 가이드합니다.

적용 환경

OS 버전 : CentOS Linux 7
CUBRID 버전 : CUBRID 11.2.1
MySQL 버전 : MySQL 8.0

MySQL 서버 설정

설치되어 있는 MySQL 서버에서 해야하는 설정입니다.

1. MySQL SSL 설정

SQL 8.0 이상부터 ssl이 기본으로 설정되어 있어 설정을 끄고 실행합니다. 변경 후에는 MySQL을 재시작 해야합니다.

파일 위치: /etc/my.cnf

ssl=0

ssl이 잘 적용이 되었는지 확인합니다.

[root@localhost ~]# show variables like '%ssl%';

+----------+| Variable_name| Value |+-------------------------------------+----------+

| have_openssl | DISABLED |

| have_ssl | DISABLED |

2. MySQL 패스워드 설정

MySQL 8.0부터는 default_authentication_plugin 이 “mysql_native_password”에서 “caching_sha2_password”로 변경되었습니다.따라서, 다음과 같은 에러가 발생이 됩니다.

ERROR: dblink - [HY000][2061] [unixODBC][MySQL][ODBC 8.0(a) Driver]Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection...

이를 해결하기 위해선 MySQL 패스워드 정책을 변경이 필요한데 아래와 같은 3가지 방법이 있습니다.

my.cnf 파일에 아래 구문을 추가합니다. 그 후 MySQL을 재시작한 뒤 새로운 계정을 생성하게 되면 자동으로 mysql_native_password 정책으로 변경됩니다.

...

default_authentication_plugin=mysql_native_password
...
이미 생성된 user를 이용 시에는 아래와 같은 구문 이용해 plugin을 mysql_native_password으로 변경합니다.

ALTER user ' test'@'%' IDENTIFIED WITH mysql_native_password BY 'Mysql12!';

새로운 user(test)를 추가하여 사용 시 다음과 같은 구문을 이용해 정책을 명시합니다.

#구문
CREATE USER '{username}'@'{hostname}' IDENTIFIED BY '{passwordString}';

#예시

CREATE USER 'test'@'%' IDENTIFIED WITH mysql_native_password BY 'Mysql12!';

* hostname : 사용자가 연결할 호스트, % : 모든 아이피 허용

다음 구문을 이용하여 해당 사용자의 host가 모든 IP(%)인지 또는 CUBRID IP인지 확인합니다. 또한 plugin이 “mysql_native_password”로 설정이 되어 있는지 확인합니다.

mysql> select user,host, plugin

from mysql.user;

| user | host | plugin |

....

3. 사용자 테이블 권한 설정

만약 사용자가 테이블 권한이 없을 시 설정이 필요합니다.

다음 구문을 통해서 모든 db 및 테이블에 권한을 주고 로컬 및 리모트에서도 접속 가능하도록 설정합니다.

#구문

GRANT ALL PRIVILEGES ON [데이터베이스명.테이블명] to [사용자@호스트] identified by '비밀번호' [with grant option];

#예시

GRANT ALL PRIVILEGES ON *.* TO 'test'@'%';

CUBRID DBLink 설정

다음은 CUBRID에서 MySQL DBLink를 위한 설정 방법입니다.
설정에 필요한 부분들은 다음과 같이 설정하였습니다.

MySQL Server IP : 192.168.64.155
MySQL Server Port : 56000
MySQL DB명 : test_db
MySQL 계정 : root
MySQL 계정 암호 : Mysql12!
CUBRID Server IP : 192.168.64.145
CUBRID DB명 : demodb

MySQL테이블 정보

create table mysql_code(

s_name char(1),

f_name varchar(6)
);

1. MySQL 설정

1.1) MySQL ODBC Driver 설치

MySQL ODBC Driver 다운로드 사이트:

링크를 통하여 OS 버전과 MySQL 버전에 맞는 파일을 다운로드하여 설치합니다.
https://dev.mysql.com/downloads/connector/odbc/

[root@localhost ~]# yum install -y https://dev.mysql.com/get/Downloads/Connector-ODBC/8.0/mysql-connector-odbc-8.0.31-1.el7.x86_64.rpm

1.2) ODBC Driver Name 확인 및 설정

Linux의 경우, MySQL ODBC Driver Name을 설정하기 위해서는 unixODBC를 설치 한 후 /etc/odbcinit.ini 파일에 Driver name을 작성해야 합니다

unixODBC 드라이버 관리자는 Linux 및 UNIX 운영 체제에서 ODBC 드라이버 와 함께 사용할 수 있는 오픈 소스 ODBC 드라이버 관리자이다.

unixODBC 설치 예시입니다. 버전에 맞는 ODBC를 설치를 진행합니다.

[root@localhost]$ yum install unixODBC.x86_64

설치 관련 자세한 내용은 http://www.unixodbc.org의 download를 참고 바랍니다.

unixODBC 설치 확인 및 odbcinst.ini 위치를 알 수 있다.

[root@localhost ~]# odbcinst -j
unixODBC 2.3.1
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /root/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8

1.3) odbcinst.ini 설정

odbcinst.ini 에 MySQL 드라이버를 설정을 해주어야합니다. 다운로드 받은 드라이브 위치를 Driver에 입력합니다.

*CUBRID에서는 odbc.ini파일 설정이 필요 없음

# 세션의 이름이 driver 이름이다.

# cubrid_gateway.conf의 CGW_LINK_ODBC_DRIVER_NAME 세션의 이름을 작성해야 한다.

[mysql odbc driver]
Driver=/usr/lib64/libmyodbc8a.so

2. CUBRID 설정

CUBRID gateway

게이트웨이는 CUBRID 데이터베이스 서버가 타 데이터베이스 서버에 연결할 수 있도록 중계하는 미들웨어이다.

cubrid_gateway.conf 설정

SERVICE 를 ON으로 변경
CGW_LINK_SERVER_IP 에 mysql database 서버의 ip주소 설정
CGW_LINK_SERVER_PORT 에 mysql database 서버의 port 설정
CGW_LINK_ODBC_DRIVER_NAME 에 odbcinst.ini에서 설정한 세션의 이름(mysql odbc driver)

*추가적인 GATEWAY 파라메터 설명은 메뉴얼을 참고해주시기 바랍니다.

https://www.cubrid.org/manual/ko/11.2/sql/dblink.html

[gateway]
MASTER_SHM_ID =50001
ADMIN_LOG_FILE =log/gateway/cubrid_gateway.log

[%mysql_gateway]
SERVICE =ON
SSL =OFF
APPL_SERVER =CAS_CGW
BROKER_PORT =56000
MIN_NUM_APPL_SERVER =5
MAX_NUM_APPL_SERVER =40
APPL_SERVER_SHM_ID =56000
LOG_DIR =log/gateway/sql_log
ERROR_LOG_DIR =log/gateway/error_log
SQL_LOG =ON
TIME_TO_KILL =120
SESSION_TIMEOUT =300
KEEP_CONNECTION =AUTO
CCI_DEFAULT_AUTOCOMMIT =ON
APPL_SERVER_MAX_SIZE =256
CGW_LINK_SERVER =MYSQL
CGW_LINK_SERVER_IP =192.168.64.155
CGW_LINK_SERVER_PORT =3306
CGW_LINK_ODBC_DRIVER_NAME =mysql odbc driver
CGW_LINK_CONNECT_URL_PROPERTY ="charset=utf8;PREFETCH=100;NO_CACHE=1"

cubrid_gateway.conf 확인

gateway 설정값을 확인 시 cubrid_gateway.conf 파일 열기 또는 cubrid gateway info 명령어를 통해 확인할 수 있습니다.

[cubrid@localhost]$ cubrid gateway info

#
# cubrid_gateway.conf
#

# gateway parameters were loaded from the files
# /home/cubrid/CUBRID-11.2.1.0677-82f461a-Linux.x86_64/conf/cubrid_gateway.conf

# gateway parameters
[gateway]
MASTER_SHM_ID =50001

[%mysql_gateway]
SERVICE =ON
APPL_SERVER =CAS_CGW
MIN_NUM_APPL_SERVER =5
MAX_NUM_APPL_SERVER =40
APPL_SERVER_SHM_ID =56000
SSL =OFF
APPL_SERVER_MAX_SIZE =256
SESSION_TIMEOUT =300
LOG_DIR =log/gateway/sql_log
SLOW_LOG_DIR =log/gateway/sql_log/
ERROR_LOG_DIR =log/gateway/error_log
LOG_BACKUP =OFF
SOURCE_ENV =
SQL_LOG =ALL
SLOW_LOG =ON
SQL_LOG_MAX_SIZE =10240
LONG_QUERY_TIME =60.00
LONG_TRANSACTION_TIME =60.00
AUTO_ADD_APPL_SERVER =ON
JOB_QUEUE_SIZE =1024
TIME_TO_KILL =120
ACCESS_LOG =OFF
ACCESS_LOG_MAX_SIZE =10240K
ACCESS_LOG_DIR =log/gateway/
ACCESS_LIST =
MAX_STRING_LENGTH =-1
KEEP_CONNECTION =AUTO
STATEMENT_POOLING =ON
CCI_PCONNECT =OFF
ACCESS_MODE =RW
CONNECT_ORDER =SEQ
MAX_NUM_DELAYED_HOSTS_LOOKUP =-1
RECONNECT_TIME =600
REPLICA_ONLY =OFF
TRIGGER_ACTION =ON
MAX_QUERY_TIMEOUT =0
ENABLE_MONITOR_HANG =OFF
ENABLE_MONITOR_SERVER =ON
REJECTED_CLIENTS_COUNT =0
STRIPPED_COLUMN_NAME =ON
CACHE_USER_INFO =OFF
SQL_LOG2 =0
BROKER_PORT =56000
APPL_SERVER_NUM =5
APPL_SERVER_MAX_SIZE_HARD_LIMIT =1024
MAX_PREPARED_STMT_COUNT =2000
PREFERRED_HOSTS =
JDBC_CACHE =OFF
JDBC_CACHE_HINT_ONLY =OFF
JDBC_CACHE_LIFE_TIME =1000
CCI_DEFAULT_AUTOCOMMIT =ON
MONITOR_HANG_INTERVAL =60
HANG_TIMEOUT =60
REJECT_CLIENT_FLAG =ON
CGW_LINK_SERVER =MYSQL
CGW_LINK_SERVER_IP =192.168.64.155
CGW_LINK_SERVER_PORT =3306
CGW_LINK_ODBC_DRIVER_NAME =mysqltest
CGW_LINK_CONNECT_URL_PROPERTY =charset=utf8;PREFETCH=100;NO_CACHE=1

gateway 상태 확인

cubrid gateway status 명령어를 통하여 현재 gateway 상태를 확인할 수 있습니다.

cubrid gateway info 예시)

[cubrid@localhost]$ cubrid gateway status

@ cubrid gateway status
% oracle_gateway OFF

% mysql_gateway
----------------------------------------------------------------------
ID PID QPS LQS PSIZE STATUS
----------------------------------------------------------------------
1 44165 1 0 199128 IDLE
2 44166 0 0 50928 IDLE
3 44167 0 0 50928 IDLE
4 44168 0 0 50928 IDLE
5 44169 0 0 50928 IDLE

CUBRID DBLink 사용 예시

1. MySQL 데이터 조회

타 데이터베이스의 데이터 조회를 위한 DBLINK Query문 작성 방법은 2가지이며 그 중 FROM절에 DBLINK 구문을 작성하여 데이터를 조회하는 방법입니다.

SELECT * FROM DBLINK ('CUBRID IP:CUBRID-GATEWAY-PORT:DBNAME:USER:PASSWORD:','SELECT select-list FROM remote_table') AS t(column-name column-type, …);

*MySQL DBLINK 실행 전 CUBRID gateway를 시작하여야 합니다.(cubrid gateway start)

다음 구문은 CUBRID에서 MySQL의 mysql_code 테이블 정보를 조회하는 예시입니다.

csql> SELECT *
FROM DBLINK ('192.168.64.145:56000:test_db:root:Mysql12!:',

'select s_name, f_name from mysql_code')

AS M(s_name varchar(20), f_name varchar(20));

=== ===

s_name f_name

============================================

'X' 'Mixed'

'W' 'Woman'

'M' 'Man'

'B' 'Bronze'

'S' 'Silver'

'G' 'Gold'

2. MySQL 서버 등록 후 데이터 조회

타 데이터베이스의 데이터 조회를 위한 DBLINK Query문 중 SERVER를 활용하여 데이터를 조회하는 방법입니다.

DBLINK Query를 작성할 때 마다 매번 작성해야 하는 번거로움과 사용자 정보(id, password) 가 외부로 노출될 우려가 있습니다.

이런 번거로움과 정보 보호를 위해 CREATE SERVER문을 이용하면, Query문 보다 간단하고, 사용자 정보 보호에 도움이 됩니다.

2.1) 서버 등록

CREATE SERVER문을 사용하여 원격 접속 정보를 생성합니다. 생성된 서버는 DBLINK를 이용하는 SELECT 질의를 수행 할 때 원격 서버를 지정하는데 사용합니다.

CREATE SERVER server-name(HOST,PORT,DBNAME,USER,PASSWORD,PROPERTIES,COMMENT);

*option: PASSWORD,PROPERTIES,COMMENT

다음 구문은 "remote_mysql"라는 이름으로 서버를 등록하는 예시입니다.

csql> CREATE SERVER remote_mysql

( HOST='192.168.64.145',
  PORT=56000,
DBNAME=test_db,
  USER=root,
  PASSWORD='Mysql12!');

Execute OK. (0.032039 sec) Committed. (0.001417 sec)

2.2) 서버 등록 확인

다음 구문은 DB_SERVER 테이블에 서버가 등록된 것을 확인하는 예시입니다.

csql> SELECT *

FROM DB_SERVER

WHERE link_name='remote_mysql';

link_name host port db_name user_name properties owner comment

=====================================================================================================================

'remote_mysql' '192.168.64.145' 56000 'test_db' 'root' NULL 'PUBLIC' NULL

2.3) 서버 등록 후 데이터 조회

다음은 Create server 구문으로 만든 remote_mysql(서버명)을 조회하는 예시입니다.

SELECT * FROM DBLINK ('서버명','SELECT select-list FROM remote_table') AS t(column-name column-type, …);

csql> SELECT *

FROM DBLINK (remote_mysql,'select s_name, f_name from mysql_code')

AS M(s_name varchar(20), f_name varchar(20));

s_name f_name

============================================

'X' 'Mixed'

'W' 'Woman'

'M' 'Man'

'B' 'Bronze'

'S' 'Silver'

'G' 'Gold'

3. MySQL VIEW 등록 및 조회

3.1) MySQL View 등록

mysql 데이터 조회 구문을 View로 생성하여 사용이가능합니다.

다음 구문은 CUBRID의 event 테이블과 MySQL의 mysql_code 테이블을 조인하여 View(test_view)로 등록하는 예시입니다.

csql> CREATE VIEW test_view as
SELECT *
FROM DBLINK ('192.168.64.153:56000:test_db:root:Mysql12!:','select * from mysql_code')

AS M(s_name varchar(20), f_name varchar(20));

3.2) MySQL View 등록 후 조회

다음 구문은 View(test_view) 등록 후 조회하는 예시입니다.

csql> select * from test_view;

=== ===

f_name s_name
============================================
'Mixed' 'X'
'Woman' 'W'
'Man' 'M'
'Bronze' 'B'
'Silver' 'S'
'Gold' 'G'

4. HA 환경에서 DBLink

HA 환경에서 절체되었을 경우 기존 슬레이브에서 mysql 연결을 위해 gateway 로 접속을 해야합니다. 일반적으로 gateway 는 CUBRID DB 서버상에 설정하는데, 절체되었을때 기존 마스트가 shutown 된 경우, 기존 마스터의 gateway 로는 접속이 불가능해지므로 MySQL db link 연결을 위해 접속할 gateway 는 슬레이브 상의 gateway 로 접속을 해야 합니다.
따라서 HA 환경에서는 master/slave 모두 동일하게 gateway 를 설정하여야 하며, DB link 를 위한 서버 설정시 gateway 서버의 주소를 localhost 로 해줘야, 절체후 자신의 서버의 gateway 를 통해 mysql 과 연결이 가능해집니다.

DBLink 시 사용하는 server는 master에서 등록 시 slave에도 복제가 됩니다.

csql> CREATE SERVER ha_remote_mysql
(HOST='localhost',
PORT=56000,
DBNAME=test_db,
USER=root,
PASSWORD='Mysql12!');

master와 slave는 동일하게 적용된것을 확인할 수 있습니다.

#Master DB_SERVER 테이블 결과

csql> SELECT *

FROM DB_SERVER

WHERE link_name='ha_remote_mysql';

=== ===

link_name host port db_name user_name properties owner comment
====================================================================================================================
'ha_remote_mysql' 'localhost' 56000 'test_db' 'root' NULL 'DBA' NULL

#Slave DB_SERVER 테이블 결과

csql> SELECT *

FROM DB_SERVER

WHERE link_name='ha_remote_mysql';

=== ===

DBLink 사용 시 볼 수 있는 에러 메시지

ERROR: dblink - Cannot connect to CUBRID CAS
- 원인 : ip,port 정보 불일치
ERROR: dblink - Connection timed out
- 원인 : MySQL 미구동
ERROR: dblink - not supported type SQL_UNKNOWN_TYPE(0). [CAS INFO 192.168.64.145:56000,1,32448]
- 원인 : MySQL 버전 과 ODBC Driver 버전 불일치, 버전 동일 설정 후 정상동작

CUBRID | Enterprise Open Source DBMS

CloudBeaver Community에서 CUBRID 사용하기

CloudBeaver Community에서 CUBRID 사용하기

CloudBeaver Community에서 CUBRID 활성화 하기

CloudBeaver Community 설치

HA 다중화 구성에서 loadBalance를 활용해 읽기 분산해 보기

DBMS와 효과적인 SQL 처리

CUBRID Internal: B+ 트리의 노드(=페이지)와 노드 분할 방법

목차

개요

B+ 트리의 노드(= 페이지)

오버플로 노드 (BTREE_OVERFLOW_NODE)

PAGE_OVERFLOW 페이지

노드 분할

노드 분할이 발생하는 경우

1. 새로운 키가 입력되는 경우

2. 기존 키의 크기가 증가하는 경우

3. 기존 레코드에 테이블 레코드의 OID가 추가되는 경우

4. 기존 레코드에 MVCC 아이디가 추가되는 경우

사용자가 키를 입력하는 패턴에 따라 달라지는 노드 분할 #1

시나리오 #1 - 1부터 27까지 오름차순으로 증가하는 패턴으로 키를 입력하는 경우

시나리오 #2 - 1부터 27까지 불규칙 패턴으로 키를 입력하는 경우

비교 결과

똑똑하게 노드 분할하기

사용자가 키를 입력하는 패턴에 따라 달라지는 노드 분할 #2

1. 오름차순으로 증가하는 패턴으로 키를 입력하는 경우

2. 내림차순으로 감소하는 패턴으로 키를 입력하는 경우

3. 불규칙 패턴으로 키를 입력하는 경우

루트 노드 → 브랜치 노드 → 리프 노드 순서의 노드 분할

참고

Visual Studio Code 소개

시작하며

설치 및 시작

확장 (Extensions)

1. Remote - SSH

개발 환경 셋업

1. Github 레포지토리 설정

git add

git commit

git push

2. 디버깅

launch.json 파일 만들기

중단점(breakpoint) 설정

디버깅 시작 및 진행

마무리하며

CUBRID QA 절차 및 업무 방식 소개

CUBRID의 개발 문화: CUBRID DBMS 프로젝트 빌드 가이드와 빌드 시스템 개선

시작하며

빌드 준비하기

빌드 준비를 도와주기

가이드 문서 작성하기

CUBRID의 사례

가이드 문서 개선하기

가상 환경 제공하기

이제 빌드하고 개발해보자 그런데..?

빌드 성능 개선하기

마무리

참고

CSQL에서 PreparedStatement 사용하여 Query Plan 확인하기

CSQL에서 PreparedStatement 사용하여 Query Plan 확인하기

CSQL에서 PreparedStatement 사용

사용 예시(2가지)

Query Plan 확인 예시

Index의 capacity에 관한 정보 열람

Index Capacity 정보

들어가며

INDEX CAPACITY 정보 얻기

1. diagdb tool

2. SHOW INDEX CAPACITY 명령

INDEX CAPACITY 세부 항목

사용해 보기1

사용해 보기2

마무리

CUBRID Internal: Disk Manager #1: 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table)

볼륨은 어떻게 관리될까?

- 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table) -

볼륨 구조

볼륨 헤더 (Volume Header)

섹터 테이블 (Sector Table)

섹터 테이블의 연산

필자는 해당 툴을 사용하다가 사용하는 PC를 바꾸게 되어 기존 설정을 백업해서 복구 하고자 한다.
Workspace를 따로 빼서 사용하지 않은 기본 설정으로 사용하신 분을 기준으로 백업/복구를 가이드 하고자 한다.