Background Image
조회 수 115 추천 수 4 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부

목차

1. 개요

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

2.1. 오버플로 노드 (BTREE_OVERFLOW_NODE)

2.2. PAGE_OVERFLOW 페이지

3. 노드 분할

3.1. 노드 분할이 발생하는 경우

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

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

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

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

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

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

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

3.2.3. 비교 결과

4. 똑똑하게 노드 분할하기

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

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

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

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

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

6. 참고

 

 

개요

큐브리드는 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)를 가지고 있습니다. 루트 헤더는 노드 헤더를 포함하고 있고, 인덱스 전체에 대한 메타 정보를 저장하고 있습니다. 브랜치 노드와 리프 노드는 노드 헤더만 가지고 있습니다.

 

BTREE_ROOT_HEADER.png

BTREE_NODE_HEADER.png

 

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

 

PAGE_BTREE.png

 

오버플로 노드 (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를 저장하고 있습니다.

 

BTREE_OVERFLOW_NODE.png

BTREE_OVERFLOW_HEADER.png

 

리프 노드의 레코드가 오버플로 노드에 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.png

OVERFLOW_FIRST_REST_PART.png

 

리프 노드의 레코드가 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 <db_name> -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 <db_name> -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 <db_name> -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 <db_name>
 *   $ csql -u dba <db_name>
 */
 
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까지 오름차순으로 증가하는 패턴으로 키를 입력하는 경우

123456789101112131415161718192021222324252627 순서로 키를 입력했습니다.

 

B+ Tree Image 001_crop.png

 

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

141326122411221020918278167216515254321171923 순서로 키를 입력했습니다.

 

B+ Tree Image 002_crop.png

 

비교 결과

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 함수에서 현재의 누적 이동 평균을 확인해서 노드의 레코드를 분할합니다.

 

BTREE_NODE_SPLIT_INFO.png

 

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

 

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

 

Cumulative Moving Average.png

 

노드 분할이 발생할 때 레코드를 분할할 위치는 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를 사용하여 레코드를 분할할 위치를 결정합니다.

 

Cumulative_Moving_Average_Range.png

 

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 <db_name> -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'
        ...
*/

 

pivot_asc.png

 

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 <db_name> -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'
        ...
*/

 

pivot_desc.png

 

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 <db_name> -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'
        ...
*/

 

pivot_random.png

 

 

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

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

 

아래는 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 <db_name> -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 */

 

btree_split_root_1-to-2.png

 

아래는 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 <db_name> -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 */

 

btree_split_root_2-to-3.png

 

 

참고

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

 


  1. DBMS와 효과적인 SQL 처리

    DBMS는 SQL을 효과적으로 처리하기 위해서 어떠한 노력을 하고 있을까요? - 질의 재작성기(Query Rewriter) 여러 개발자에게 동일한 요구사항을 주고 질의를 작성하게 하면 서로 다른 형태로 작성할 수 있습니다. 질의를 어떻게 작성하느냐에 따라서 성능에 차이가 발생할 수 있기 때문에 개발자가 질의를 효과적으로 작성하는 것은 중요한 일이지만, DBMS가 상당부분 그 일을 대신하고 있습니다. 위 질의를 작성한 그대로 수행하게 되면 부질의 결과를 임시파일에 저장하고 그것을 재가공해야 합니다. 하지만 오른쪽 질의처럼 작성되어 있다면, 따로 부질의를 수행해서 저장할 필요도 없고, 인덱스의 사용도 가능합니다. 위와 같이 부질의를 제거하고 주질의에 합병하는 것을 뷰머징이라고 합니다. DBMS는 가능한 경우 뷰머징을 진행하며, 인라인 뷰와 뷰 객체에 대해서도 동일하게 합병을 진행합니다. 부질의가 뷰머지가 불가능한 경우에 주질의에 있는 조회조건을 부질의로 넣는 것을 predicate push라고 합니다. 조회시 스캔하는 양을 줄일 수 있기 때문에 상당히 성능을 향상시킬 수 있습니다. 필요 없는 select list와 조인 테이블 그리고 order by절등을 제거하여, 필요...
    Date2023.12.29 Category제품 여행 By박세훈 Views102 Votes1
    Read More
  2. CUBRID Internal: B+ 트리의 노드(=페이지)와 노드 분할 방법

    목차 1. 개요 2. B+ 트리의 노드(= 페이지) 2.1. 오버플로 노드 (BTREE_OVERFLOW_NODE) 2.2. PAGE_OVERFLOW 페이지 3. 노드 분할 3.1. 노드 분할이 발생하는 경우 3.1.1. 새로운 키가 입력되는 경우 3.1.2. 기존 키의 크기가 증가하는 경우 3.1.3. 기존 레코드에 테이블 레코드의 OID가 추가되는 경우 3.1.4. 기존 레코드에 MVCC 아이디가 추가되는 경우 3.2. 사용자가 키를 입력하는 패턴에 따라 달라지는 노드 분할 #1 3.2.1. 시나리오 #1 - 1부터 27까지 오름차순으로 증가하는 패턴으로 키를 입력하는 경우 3.2.2. 시나리오 #2 - 1부터 27까지 불규칙 패턴으로 키를 입력하는 경우 3.2.3. 비교 결과 4. 똑똑하게 노드 분할하기 4.1. 사용자가 키를 입력하는 패턴에 따라 달라지는 노드 분할 #2 4.1.1. 오름차순으로 증가하는 패턴으로 키를 입력하는 경우 4.1.2. 내림차순으로 감소하는 패턴으로 키를 입력하는 경우 4.1.3. 불규칙 패턴으로 키를 입력하는 경우 5. 루트 노드 → 브랜치 노드 → 리프 노드 순서의 노드 분할 6. 참고 개요 큐브리드는 B+ 트리 인덱스를 사용하고 있습니다. B+ 트리 인덱스는 새로운 키가 입력되거나 기존 레코드가 변경될 때, B+ 트...
    Date2023.12.27 Category제품 여행 By주영진 Views115 Votes4
    Read More
  3. Visual Studio Code 소개

    시작하며 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 라고 적혀...
    Date2023.12.21 Category나머지... By송일한 Views110 Votes2
    Read More
  4. CUBRID QA 절차 및 업무 방식 소개

    큐브리드의 QA 절차 및 업무 방식에 대해 소개하겠습니다. CUBRID QA팀이 하는 일? QA(Quality Assurance)팀은 CUBRID의 품질 보증에 대한 전반적인 절차를 다루는 업무를 맡고 있습니다. 단순 테스트뿐만 아니라, 개발 프로세스에 직간접적인 관여와 QA Tool 확장 및 유지보수, 제품 결함 관리, 제품 릴리즈 등 제품이 출시되는 과정에서 여러가지 일을 하고 있습니다. 특히, 개발과정의 처음부터 끝까지 참여하여 품질 저하에 문제가 될 만한 부분이 있는지 검증하고, 개선안을 제안하는 등 개발 프로세스 전반적으로 개입하여 제품 품질을 높이는 일을 하고 있습니다. CUBRID QA 절차 CUBRID QA 절차는 크게 다음과 같이 볼 수 있습니다. 각 절차에 대한 상세한 과정은 다음과 같습니다. 1. Kick off 참여 -먼저, 개발팀으로부터 프로젝트를 할당 받으면, 킥오프를 참여합니다. 요구사항 및 목표를 파악하고, 사용자 관점에 부합하지 않을 경우 개선을 요청합니다. 프로젝트에 따라 검증방법이나 절차가 달라질 수도 있고 때에 따라 새로운 환경이 필요할 수 있기 때문에 여러 가지 의견들을 종합하여 팀 내 담당자를 선정합니다. 2. 테스트 환경 구축 -프로젝트를 위해 어...
    Date2023.11.17 Category나머지... By윤시온 Views250 Votes1
    Read More
  5. CUBRID의 개발 문화: CUBRID DBMS 프로젝트 빌드 가이드와 빌드 시스템 개선

    시작하며 이전 포스팅에서 CUBRID의 개발 문화: CUBRID DBMS는 어떻게 개발되고 있을까? 라는 주제로 블로그 글을 작성했었던 기억이 납니다. 날짜를 들여다보니 2021년 4월 29일에 작성되었으니 코로나 팬데믹을 이겨내고 CUBRID에서 여러 프로젝트를 진행하느라 시간이 훌쩍 지나갔네요. 그 사이 CUBRID는 11.2 (elderberry) 버전 릴리즈를 지나 11.3 (fig) 버전 릴리즈를 앞두고 있습니다. 이번에도 마찬가지로 [CUBRID의 개발 문화]라는 말머리를 가지고 CUBRID DBMS 프로젝트 빌드에 대한 이야기를 해보려고 합니다. 이전 포스팅의 ‘CUBRID DBMS는 어떻게 개발되고 있을까?’에서 소개했던 개발 프로세스와 프로젝트 기여 가이드의 내용과 조금 주제가 달라보일 수 있는데, 프로젝트 빌드에 대한 내용이 어떻게 개발 문화로까지 이어질 수 있는지 소개해 드리려고 합니다. 빌드 준비하기 누군가 코드를 기여하려고 할 때 빌드는 가장 먼저 해야 하는 첫 발걸음이면서, 동시에 제일 첫 번째로 마주하는 어려움입니다. 먼저 개발 환경에서 프로젝트를 빌드하기 위해서 여러 도구와 라이브러리를 설치하고, 프로젝트의 빌드 방법을 알아야 합니다. 이 때 기여하려...
    Date2023.09.08 Category오픈소스 이야기 By유형규 Views268 Votes2
    Read More
  6. No Image

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

    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가지) 1. csql > PREPARE pstmt FROM 'SELECT 1 + ?'; csql > EXECUTE pstmt USING 4; csql > DROP PREPARE pstmt; 2. 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 pst...
    Date2023.05.11 Category제품 여행 By김지원 Views349 Votes1
    Read More
  7. No Image

    Index의 capacity에 관한 정보 열람

    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 NonLea...
    Date2023.04.26 Category제품 여행 By사니조아 Views277 Votes1
    Read More
  8. CUBRID Internal: Disk Manager #1: 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table)

    이전글: CUBRID Internal: 큐브리드의 저장공간관리 (DIsk Manager, File Manager) 볼륨은 어떻게 관리될까? - 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table) - 앞선 글에서 디스크 매니저(Disk Manager)가 섹터의 예약(reservation)을 관리한다고 이야기하였다. 이번 글에서는 볼륨 내의 섹터들이 어떻게 관리되는지에 대한 구체적인 이야기와 이를 위해 볼륨이 어떻게 구성되어 있는지를 다룬다. 여기서 다루어지는 볼륨의 구조는 그대로 non-volatile memory (SSD, HDD 등)에 쓰여진다. 볼륨 구조 디스크 매니저의 가장 큰 역할은 파일생성과 확장을 위해 섹터들을 제공해주는 것이다. 이를 위해 각 볼륨은 파일들에 할당해줄 섹터들과 이를 관리하기 위한 메타(meta)데이터로 이루어져 있다. 메타데이터들이 저장된 페이지를 볼륨의 시스템 페이지(System Page)라고 하며, 볼륨에 대한 정보와 각 섹터들의 예약 여부를 담고 있다. 시스템 페이지는 다음과 같이 두가지로 분류할 수 있다. 볼륨 헤더 페이지 (Volume Header Page, 이하 헤더 페이지): 페이지 크기, 볼륨 내 섹터의 전체/최대 섹터, 볼륨 이름 등, 볼륨에 대한 정보를 지니고 있는 페이지 섹터 테이...
    Date2023.03.30 Category제품 여행 By김재은 Views344 Votes2
    Read More
  9. JPA와 CUBRID 연동 가이드

    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...
    Date2023.02.22 Category나머지... By김동민 Views985 Votes3
    Read More
  10. dblink를 이용한 remote-server materialized view 기능

    Materialized View Materialized View(이하 MView) 이것은 말 그대로 View의 일종으로 일반 View는 논리적인 스키마인데 반해, MView는 물리적 스키마입니다. 논리적 스키마는 실제 데이터가 데이터베이스에 저장되어 있지 않고 데이터를 가져오기 위한 SQL질의만 저장되어 있다라는 것이고, 물리적 스키마 혹은 테이블이라는 것은 셀제 데이터가 데이터베이스에 저장되어 있다라는 것입니다. MView는 필요한 결과를 가져오는 질의가 빈번하게 자주 사용 될 경우, 질의 실행 시간 속도 향상을 위해 데이터베이스 테이블을 만들어 저장해 두는 것으로 실행 비용이 많이 드는 조인이나, Aggregate Function을 미리 처리하여 필요할 때 테이블을 조회 하도록 하는 것 입니다. 예를 들면 대용량의 데이터를 COUNT, SUM, MIN, MAX, AVG 처럼 자주 사용되는 Aggregate Function 실행 속도를 향상을 위해서, 질의 실행 결과을 데이터베이스 테이블로 생성해 두는 벙법입니다. 즉, 자주사용되는 View의 결과를 데이터베이스에 저장해서 질의 실행 속도를 향상시키는 개념입니다. 이번 글에서는 일반적인 MView와 더불어 현재 작업 중인 데이터베이스 로컬 서버가 아닌 원격지(remote) ...
    Date2023.02.20 Category나머지... Bybwkim Views621 Votes2
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 ... 16 Next
/ 16

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2113 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales